Project management in your company: the practical guide for business owners without a dedicated PM

Introduction

No public survey counts how many Italian companies have a dedicated Project Manager: the starting condition of this guide — a company where that role does not exist as a formal position — is a stated working assumption, not a measured share. Projects — opening a new location, launching a new service, implementing a management system — end up on the desk of the business owner or of an operations manager who already has a full plate. Work moves forward through improvised meetings, custom spreadsheets and a shared memory that works until someone gets sick.

Project management is the discipline that organizes a temporary initiative with defined objectives, time constraints, budget and responsibilities, and sets it apart from recurring work. It is not software, it is not a certification and it does not require a team of twenty people. It is a way of thinking about a single initiative that reduces surprises, dependence on specific people and systematic delays.

This practical guide is for those who don't have a PM and probably won't have one in the next three years. It covers established methodologies (Agile, Waterfall, Kanban, Scrum) as described in the primary sources, criteria for choosing the right one, the structure of a lean Project Charter, minimum roles in the team, and criteria for choosing tools before the tools themselves.

The goal is not to turn the business owner into a certified Project Manager. It is to make predictable the projects that today absorb time, money and energy in unmeasured ways, starting from the real constraint of a small organization.

Apply the 4-condition test to see when an activity becomes a project

Formally distinguishing between "something to do next week" and "a project" is not a practice that the available surveys track, and this section assumes that in your company that distinction is not written down anywhere. Yet the difference has practical consequences: deadlines, budget, people involved, risk of failure. Recognizing the moment when an activity changes nature lets you apply the right tools to it, avoiding treating a complex initiative as an extended to-do list or, conversely, setting up disproportionate infrastructure for a weekly task. This section distinguishes project management from tasks, operations, processes and strategy, and sets four conditions that turn an activity into a project.

How many of the initiatives currently underway in your company have an objective, a deadline, a budget and an owner stated in writing? No public statistic measures how much of this minimum documentation exists in Italian companies: the criterion adopted here is that an initiative lacking those four written elements should be considered undocumented, because it runs on memory, and that is where overruns come from.

The most solid definition of a project comes from the professional literature: a temporary endeavor undertaken to create a unique product, service or result, with explicit constraints of deadline, budget and scope [4]. There are four elements: temporariness (a defined start and end), uniqueness of the result (not recurring work), measurable constraints (time, money, scope), identified responsibility. The conceptual distinction between project and activity is not academic: it is what allows you to apply different tools to initiatives of a different nature, avoiding both too much and too little formalization.

For managers and business owners, the usefulness of the concept is measured by its ability to separate it from four terms it gets confused with every day.

• Task management (managing individual activities). Tasks are independent units of work, without a single objective, an overall deadline or a budget. A project includes them but goes beyond them. When someone in the company says "I need to manage this project" while referring to a list of items in an Excel sheet, they are doing task management and calling it project management.
• Operations management (managing the recurring flow). Operations continuously produce the company's ongoing output — production, order fulfillment, after-sales service. A project, on the other hand, is a temporary initiative that changes or creates something new. To explore the difference between a recurring process and a project initiative, see the guide on process mapping.
• Process management (managing a recurring process). A process repeats itself: it always has the same input, the same output, the same flow. A project happens only once, even if it can recur in different versions — opening three different locations consists of three distinct projects, not a single replicated process.
• Strategic planning (three-year horizon, vision). Strategic planning sets multi-year direction and objectives; project management translates a single strategic objective into a concrete initiative with explicit time and financial boundaries.

At this point the four-condition test becomes operational. An activity can be managed as a project when it meets all four of these conditions:

1. A single, identifiable objective — there is a concrete result to deliver, distinct from the ongoing recurring work.
2. An explicit time constraint — there is a start date and an expected end date (not "we'll see").
3. A budget or resource constraint — there is a defined scope in money, person-hours or out-of-pocket costs.
4. A unique, non-replicated result — the initiative produces something that is not already part of the usual operational flow.

Some practical examples. Opening a new sales location meets all four conditions: it is a project. The monthly update of the price list meets only the first two: it is a recurring process, not a project. Implementing a new management system meets all four: it is a project, and the frequent confusion with task management explains a good part of the delays and overruns documented in Italian institutional surveys on structured management practices [2]. To place the project within the broader discipline of business systemization, read the guide on business systemization.

Once you have recognized that an activity is a project, the next question is: is it worth managing formally, or is it too small to justify the framework? The next section sets an operational threshold.

Recognize when it is worth managing a project formally (and when it is a waste of time)

Adopting formal project management is not free: it takes time to set up the framework, alignment meetings, minimal documentation. For an initiative of a few hours or for recurring work, it is a net cost. For an initiative that involves several people, lasts weeks and commits significant resources, it is an investment that reduces delays and repeated problems. The question is not "do we do it or not", it is "from what threshold onward does it pay off". This section sets an operational threshold based on three measurable dimensions.

Is it worth setting up a formal project for an initiative that lasts two weeks and involves three people? The criterion proposed here says yes: the setup takes about an hour, and that hour pays for itself the first time confusion is avoided, even though the comparison between the two costs is not measured by any of the sources cited.

The available evidence on the spread of structured management practices in Italian companies shows a significant correlation between size and formalization: the share of companies that use formal tools for planning and controlling projects grows with size, is rare in micro-enterprises and becomes common above 50 employees [2]. Structured management practices are associated with higher levels of productivity and performance. The figure does not mean that formalization "causes" performance: it means that more structured companies also tend to be more productive, and that formalization is one of the levers available to the individual business owner. Project formalization, according to the Italian academic literature on management systems, is distinct from strategic planning (multi-year horizon) and from operational control (weekly horizon): it occupies the intermediate space of initiative-level operational programming [8].

From what point does it make sense to set up a formal project? Three measurable dimensions help set an operational threshold:

• Duration. Initiatives that last more than 2 calendar weeks tend to benefit from an explicit framework. Below this threshold, a detailed to-do list may be enough; above it, managing "from memory" starts to lose relevant information.
• People involved. If more than 2 people besides the manager take part in the initiative, a formal framework drastically reduces coordination costs. With 1-2 people, alignment can happen in real time; with 3 or more, the lack of a shared reference produces diverging reconstructions of the work.
• Budget or resources committed. If the initiative commits financial resources or person-hours beyond a defined internal threshold (which varies with company size, roughly the equivalent of one person-week of work), formalization protects against the invisible erosion of the budget.

A short operational checklist to tick off before deciding whether to frame an initiative as a formal project:

• Does the initiative last more than two calendar weeks?
• Does it involve more than two people besides the manager?
• Does it commit a budget or a volume of person-hours that is significant for the company?
• Does it have an identifiable, non-replicated final result?
• Is there at least one significant risk of slippage or overrun?

Three or more "yes" answers out of five indicate that formalization pays off. Below this threshold, the risk of over-formalizing outweighs the benefits. In a small company, formalization does not mean bureaucracy: it means writing on one page what you want to achieve, by when, with whom, with what resources, and what you commit not to change your mind about. The next section describes the five phases every project goes through, regardless of its size.

Run a project in 5 phases: from first draft to handover into operations

Initiating, planning, executing, monitoring, closing. These are the five phases codified by the project management literature, and they apply at very different scales, from the micro-enterprise to the multinational. What changes is not the phases but the weight they receive. In a small company, the planning and closing phases are the ones most often sacrificed: you start with an idea and close when "it looks done", with consequences for the budget and for future replicability. This section describes each phase with the bare minimum a small organization needs.

What happens to projects that are never formally "closed"? Not closing a project means not capitalizing on what was learned: the next project will repeat the same mistakes, and the company never builds a body of reusable experience.

The five phases are codified by the standard professional literature [4] and represent the process groups every project goes through. In a small company, each phase requires different tools and must be calibrated to the scale of the initiative. The common risk is reducing the project to phases 2 and 3 (planning and execution), skipping the formal start and the structured closing. The summary table below shows, for each phase, the input needed, the concrete result to deliver and the typical mistake observed in small companies.

scroll the table →

Three practical notes complete the reading of the table. In small companies, phase 1 is relatively the most neglected: often you start with an hour-long meeting that produces no written document, and three months later none of the participants remembers exactly what was decided. A one-page Project Charter (see next section) significantly changes the dynamics of the project, not least because it forces you to make explicit what is in scope and what is out of scope. Phase 4 (monitoring) requires a rhythm, not an arbitrary frequency: a 15-minute weekly meeting with a fixed format beats ten scattered message exchanges during the week in terms of decision quality. Phase 5 (closing) is the one that builds organizational memory: a half-hour retrospective at the end of each project turns experience into a reusable asset for the next project and protects against repeating the same mistakes. To integrate closing into the broader logic of systemizing business processes, the guide on process mapping is useful.

The language used for the five phases replaces international PM jargon with plain everyday terms: instead of "deliverable", "concrete result to deliver"; instead of "kick-off", "opening meeting"; instead of "stakeholder", "people involved and interested parties". The framework remains that of the standard literature, but the operational translation is designed for those who have neither the time nor the interest to learn a second vocabulary. The next section gets to the heart of the methodology choice: Agile, Waterfall, Kanban, Scrum — when each one works, and when it is simply a fad.

Choose the right methodology for the type of project: Agile, Waterfall, Kanban, Scrum

The choice between Agile, Waterfall, Kanban and Scrum is usually presented as a matter of fashion or industry ("Agile is for software, Waterfall for construction"). The peer-reviewed literature offers a more useful reading: each methodology works well under certain conditions of requirement stability, team autonomy and type of output, and poorly under the opposite conditions. For a manager or business owner, the question is not "which is better", it is "which conditions apply to my specific project" — and the answer is often a hybrid combination. This section provides a selection criterion based on 4 dimensions.

To implement a new ERP system in your company, is Agile, Waterfall or a hybrid better? It depends on how well the requirements are known at the start: if they are stable and detailed, Waterfall reduces chaos; if they change along the way, a hybrid with monthly sprints works better — the worst case is promising Agile and managing Waterfall.

The four most discussed methodologies have different roots and operating logic. It is worth describing them briefly before comparing them. Waterfall is the sequential approach: you plan at the beginning and execute in successive phases, each of which starts only after the previous one is closed. Agile is a family of iterative approaches that cycle rapidly between planning, execution and review, accepting that requirements may evolve during the project. Scrum is a specific Agile framework: it provides for three roles (Product Owner, Scrum Master, Developers), five recurring events (Sprint, Sprint Planning, Daily, Review, Retrospective) and defined artifacts; the framework's primary source specifies that Scrum is lightweight and not prescriptive about tools [3]. Kanban is a flow management system that limits work-in-progress to improve predictability and throughput.

The 2011 study by Cocco, Mannaro, Concas and Marchesi, published in Springer proceedings, systematically compared the three methodologies on software development scenarios using system dynamics simulation [5]. The results offer a non-ideological reading of the choice: Kanban reduces work-in-progress and improves flow predictability, Scrum sustains throughput in contexts with unstable requirements, and Waterfall proves effective where requirements are stable and defined upfront. The 2014 multi-case study by Conforto and colleagues in the Project Management Journal extended the analysis to the applicability of Agile outside software, on a sample of 19 non-software companies in Brazil and the United States [6]. It identified enabling conditions for Agile outside software (team autonomy, customer involvement, short iterations) and contexts in which adoption fails — useful for readers wondering whether "Agile is only for software".

In a small company, the choice of methodology should be made on four measurable dimensions.

Three practical considerations. First: when you apply the four dimensions, real projects almost always end up in hybrid zones. Opening a new sales location has waterfall aspects (permits, construction work, fit-out) and agile aspects (choosing the profiles to hire, defining the local offering). Forcing a single scheme is a common mistake — the worst case, as mentioned, is promising Agile to the team and then managing Waterfall in practice, which creates betrayed expectations. Second: the documented correlation between structured management practices and productivity [2] does not imply that the most sophisticated methodology is always the best. The methodology suited to the context, applied with discipline, beats the fashionable methodology applied poorly. Third: terms like "sprint" (an iteration of fixed duration, typically 2-4 weeks), "backlog" (an ordered list of activities to tackle) and "iteration" (a complete planning-execution-review cycle) should be explained to the team the first time they are used, not assumed to be known. If you want to go deeper into a single methodology, the primary reference on Scrum is the official guide by the framework's authors [3]; for Waterfall and for the principles framework of contemporary project management, the standard professional literature is available [4].

The chosen methodology does not replace the starting document: it specifies it. The next section describes the most underrated and most decisive tool of project management in a small company — the lean Project Charter.

Build a lean, one-page Project Charter (and why you need it even if you work alone)

The Project Charter is the document that sets in writing a project's objective, constraints, scope and owners before it starts. In large corporations it becomes a twenty-page dossier. In a small company a single page is enough, but that page must exist: it prevents a situation where, three months later, it is no longer clear what had been decided. This section describes the six minimum items of a lean Project Charter and applies them to a concrete small-business case.

How many company projects start without a one-page document that sets the objective in writing? No survey answers this question, but the consequence of starting without that document is visible downstream: the project closes with the feeling that "it went the way it went", hard to analyze and impossible to replicate consistently.

The Italian academic literature on management systems defines the Project Charter as a tool that summarizes objective, constraints and responsibilities before the project starts, distinct from the detailed planning that follows [8]. The standard professional literature describes it as a foundational document that formally authorizes the existence of the project and identifies responsibilities and scope [4]. For a small company, what matters is the operational version: a page that, read three months later by someone who was not at the initial meeting, conveys precisely what you wanted to achieve and under what constraints.

The six minimum items of a lean Project Charter for a small company are the following.

1. Measurable objective. A sentence that describes what the project must produce, phrased as an observable result (not "improve customer service" but "launch the new WhatsApp Business channel, run by two operators, by September 30").
2. In scope and out of scope. What is part of the project and what explicitly is not. The out-of-scope item is the one that protects against scope creep, the progressive widening of the scope during execution.
3. Time and budget constraints. Start date, expected end date, financial budget (even if estimated), volume of person-hours committed.
4. Owner and team. Who is responsible for bringing the project to completion, who is on the team, and who is the sponsor who decides if things get stuck.
5. Main risks. The three or four risks known at the start (e.g., dependence on an external supplier, summer vacations, a possible delay in an administrative permit).
6. Closing criteria. What "the project is finished" concretely means: measurable conditions that, once met, authorize formal closure.

A completed example for a small business — opening a new store.

• Measurable objective: Open the Via Roma store to the public by October 15, with trained staff, an operational management system and the first launch campaign live.
• In scope: fitting out the premises, the lease agreement, hiring two sales associates, configuring the management system, a launch campaign on the company's channels.
• Out of scope: negotiations for a second store in another city (a separate, possible project).
• Constraints: start June 1, opening October 15, total budget €85,000 (fit-out, training, initial inventory), 250 person-hours from the business owner and the operations manager.
• Owner: operations manager. Sponsor: business owner. Team: operations manager, bookkeeper, future store manager (from September 1).
• Main risks: delays in municipal permits, late furniture delivery, difficulties in staff recruitment.
• Closing criteria: store operational, first monthly accounts closed, project retrospective held, versioned operations manual for the store.

An editable Word version of this lean Project Charter, with pre-filled fields ready to adapt, is available in the blog's resources section as a free downloadable Project Charter Template. It does not replace the discipline of filling it in: it makes it easier.

Even for a business owner who works alone, the Project Charter is useful in two ways: it forces you to make explicit to yourself what often remains implicit, and it gives you a reference document for the decisions that will come up mid-project, when your initial memory has already faded. A Charter that is never written is a missed opportunity for upfront clarity. The next section shifts the focus from the document to the team: how to coordinate people without becoming the bottleneck.

Coordinate the team without becoming the bottleneck: minimum roles, essential meetings, readable status updates

The most common trap in a small company is the decision-making bottleneck: the business owner or the operations manager is the only node for every question, authorization and reallocation. The project moves at the speed of their calendar. The solution is not to add tools, it is to redistribute minimum roles and introduce two or three alignment rituals. This section describes the roles-meetings-status model for teams of 3 to 15 people.

How do you know where a project stands without receiving constant updates on your phone? A single 15-minute weekly meeting with a fixed format (what has been done, what will be done, what is blocked) replaces dozens of messy messages and frees up decision-making time.

The decision-making bottleneck is a structural consequence, not a personal one. The Italian business landscape described by ISTAT, the Italian national statistics institute, consists overwhelmingly of very small companies [1], in which the functions of Project Manager, sales manager and operations manager tend to coincide in a single person: the survey measures company size, not project roles, and the overlap is the working assumption stated at the beginning of this guide. The multi-case study on the applicability of Agile outside software documented that team autonomy is precisely one of the enabling conditions for effective iteration [6]: without redistributing minimum roles, even the best methodology turns into a stream of requests directed at the manager.

The minimum roles for a project with a team of 3 to 15 people are organized on three levels, inspired by the Scrum logic [3] but translated for non-software contexts.

• Sponsor (1 person). Typically the business owner or a partner. Decides on the overall scope, authorizes significant budget changes, steps in on escalations that go beyond the project manager's level. Does not take part in operational execution. Holds alignment meetings with the project manager monthly or by exception.
• Project manager (1 person). Coordinates progress, manages internal and external communication, keeps the plan and the Charter up to date, escalates to the Sponsor any decisions that go beyond their mandate. Runs the weekly team meeting. Is the single point of contact for anyone outside the team who wants to know the project's status.
• Team members (2-13 people). Carry out the assigned activities, flag risks and blockers, attend the weekly meeting, propose adjustments to the plan based on how operations evolve.

As for meetings, the model proposed here rests on only two rituals.

• Weekly team meeting (15 minutes). Fixed format, repeated week after week, ideally on the same day and at the same time. Three questions for each member: what has been done since the previous meeting, what will be done by the next one, what is blocked and needs intervention. No in-depth discussions during the fifteen minutes — follow-ups are scheduled afterward. The format is inspired by the stand-ups of the Scrum framework [3], adapted to non-software contexts.
• Monthly review (45 minutes). Overall progress, deviations from the plan, reallocation decisions, communication to the Sponsor. It includes rereading the Charter to verify that the project is still within the agreed scope.

The third element of the model — readable status updates — is the one that drastically reduces communication noise. A project status update, shared at the end of the weekly meeting, can be expressed in three lines:

• What was done this week: (1-3 concrete items)
• What is in progress: (1-3 items with a deadline)
• What is blocked and needs a decision/intervention: (0-2 items, indicating who needs to decide)

In practice, three lines replace dozens of messy messages on WhatsApp, email and company chat. The readable status update is also the document the Sponsor receives without having to call the manager, and that a Sponsor away on vacation can check on returning to catch up in three minutes. If you want to go deeper into the discipline of delegation, which is slightly different from redistributing project roles, see the guide on effective delegation in the team. On weekly reporting rituals, the guide on effective company meetings covers the design of short formats. On the project manager's time management, the pillar guide on time management for business owners complements the discussion of the decision-making bottleneck.

The roles-meetings-status model does not require tools: it requires discipline in applying it. The next section deals with tools — and with why they should be chosen last.

Project management tools: selection criteria come before the tools

Choosing the tool is almost always where people start: you look at Trello, Asana, Monday, ClickUp, Notion, you ask a cousin, you try whatever your biggest client uses. The typical result is a tool that gets adopted and then dropped, without anyone formally deciding to stop using it. The correct sequence is the reverse: first you set five selection criteria tied to the way your company works, then you evaluate the tools against those criteria. This section provides the criteria (not a list of specific tools, which becomes outdated within 12 months).

Should you choose the most popular project management tool or the one that is easiest to abandon if it doesn't work? The second option protects the company from lock-in: how often companies switch tools is not tracked by any public statistic, but the criterion adopted here is to plan for a switch from the moment of adoption, because it is much less costly if the data can be exported and the team has not invested in deep customizations.

European data on digital intensity offers a useful frame: according to the Eurostat dataset isoc_e_dii, in 2024 70.2% of Italian companies with 10 to 249 employees reached at least a basic level of digital intensity, compared with 72.9% for the EU-27 average [7]. The gap from the European benchmark is therefore small, and that is not where the difference lies: the index measures how many digital technologies are present in a company, not the skill with which they are used. It is that skill that determines the outcome of adoption, and it is why, in many small companies, the learning curve is the first variable to consider when introducing a new tool. Highly sophisticated tools that presuppose well-established digital familiarity can produce an adoption cost that exceeds the benefit.

Five selection criteria, to apply before evaluating a specific tool:

1. Learning curve for non-technical users. How long does it take the least digitally savvy team member to become operational? The working rule is: if more than two hours of initial training are needed to perform basic daily operations, the tool is probably oversized for the context.
2. Data exportability. Can the data you enter be exported in standard formats (CSV, Excel, PDF) at any time, without losing structure? Tools that trap data in proprietary formats make switching tools much more expensive than necessary.
3. Cost per user relative to the team. Is the pricing structure consistent with the company's current size and predictable for its expected size over the next 24 months? Tools with "all you can eat" pricing can become uneconomical for small teams; per-user tools can become expensive as the team grows.
4. Integration with tools already in use. Does the tool integrate with email, calendar, management system and other systems already used in the company? The friction of non-integration (manual copy-paste, double entry) is the recurring cost this criterion is meant to avoid.
5. Type of native view. Does the team's way of working require a list, kanban, Gantt or calendar view? Tools that offer only one view force awkward workarounds; tools that offer many views may seem flexible but make it hard for the team to find a common language.

Once the five criteria are set, you evaluate the available tools. Categories of tools familiar to readers — Trello, Asana, Monday, ClickUp, Notion — are named here only as market examples, not as sources or recommendations: every choice depends on the criteria and on the specific context. No tool is "the best" in absolute terms, and the ranking changes within 12 months. The most solid rule is to choose the simplest tool that meets the five criteria, accepting that it may be replaced as the company evolves. For a deeper look at the automation logic connected to tool selection, see the guide on business process automation.

The tool is the consequence of the criteria, not their premise. The next section closes the guide with the six most common mistakes — the ones that hollow out even a well-designed project management system.

Common mistakes in company projects (and how to spot them before they get expensive)

Mistakes in small-company projects recur with a regularity that no public statistic measures, but that can be recognized from how they arise. They are not random: they are produced by the same structural conditions (small organization, no dedicated PM, overlapping roles). Recognizing them early lets you intercept them with minimal interventions. This section brings together six mistakes selected by the editorial team, each linked where possible to the sources cited on this page, and for each one it indicates the early warning sign and the low-cost countermeasure.

Which is the most expensive mistake in a project: starting badly or not knowing when to stop? None of the sources cited compares the two costs; the criterion adopted here points to the second, because a project that starts badly shows it early and can be corrected, while one that keeps going out of inertia burns resources without anyone stopping the machine.

The six most common mistakes, each with the early warning sign that reveals it and the applicable low-cost countermeasure, are the following.

1. Confusing a task list with a project. The initiative starts as a list of items in an Excel sheet, with no single objective and no closing criteria. Italian evidence on the scarcity of structured management practices in companies below the size threshold [2] documents how widespread the phenomenon is. Early warning sign: asked "what is the project's objective?", three team members give three different answers. Countermeasure: apply the 4-condition test (see section 1) and, if positive, draft the lean one-page Project Charter before going any further.

2. Skipping the closing phase. The project ends "when it looks done", with no retrospective and no closing document. The knowledge gained is not transferred to the next project. Early warning sign: three months after the end, nobody can say precisely what went as planned and what didn't, and the same mistakes reappear in the following project. Countermeasure: from the Charter onward, schedule a 30-minute retrospective at the end of the project in the calendar, with three fixed questions (what worked, what didn't, what to replicate).

3. Choosing Agile because it's trendy in contexts with stable requirements. The Scrum framework or an agile approach is adopted on a project where requirements are stable and defined — a standard management system implementation, the opening of a traditional sales location. The multi-case study on the applicability of Agile outside software [6] and the system dynamics simulation by Cocco and colleagues [5] show that the methodology works when the conditions for its applicability are present. Early warning sign: the team takes part in sprints but the iterations produce no changes of course; the plan remains essentially the initial one. Countermeasure: recognize the pattern and switch to Waterfall (or a light hybrid), accepting to give up the "we're agile" narrative when the context doesn't call for it.

4. Centralizing every decision on the business owner. The project manager has to consult the business owner on every micro-decision, and the project moves at the speed of the owner's calendar. The overlap of roles described at the beginning, in companies of the size that ISTAT records as prevalent in Italy [1], makes the pattern common. Early warning sign: the business owner receives ten messages a day with operational questions, and the project visibly slows down in the weeks when the owner is less available. Countermeasure: in the Charter, state in writing which decisions the project manager can make independently and which require escalation; review the threshold periodically.

5. Choosing the tool before the criteria. A tool is adopted because the main client uses it or the supplier recommends it, without first setting the five selection criteria (see previous section). The learning curve of those who will use the tool every day is the variable this article ranks first among the five criteria. Early warning sign: after two months the team uses 30% of the tool's features, and someone is already proposing to "switch to another one". Countermeasure: stop the tool evaluation, set the five criteria in writing, restart the evaluation with the criteria as a grid.

6. Not documenting the Charter because "it's obvious anyway". You start with an opening meeting without producing any written document, relying on shared memory. Three months later, memories diverge. How widespread this mistake is fits with the Italian institutional data on how rare project formalization is below 50 employees [2]. Early warning sign: halfway through the project, two participants remember differently what was decided about scope or budget. Countermeasure: even mid-project, draft the lean Charter and have the Sponsor approve it; better late than never.

The six mistakes share a common root: they treat project management as a formality that can be skipped when "the project is simple". The criterion adopted here goes in the opposite direction: it is precisely in projects perceived as simple that minimal formalization pays off, because it protects against the invisible erosion of scope. It is a choice of prudence, not a comparison measured by any of the sources cited. The next section outlines the limits of applicability of the principles described here.

Limitations and conditions of applicability

The principles described in this guide rest on a combination of professional literature [4], the primary source of the Scrum framework [3], peer-reviewed studies [5] [6], Italian and European institutional data [1] [2] [7] and Italian academic literature on management systems [8]. Their direct transferability to the specific context of an individual company should be stated with caution.

The peer-reviewed evidence on methodology comparisons (Cocco et al. 2011, Conforto et al. 2014) was gathered, respectively, on software development scenarios using system dynamics simulation and on 19 non-software companies in Brazil and the United States. Generalizing to the context of small and mid-sized companies is reasonable in terms of principles, not automatic in terms of specific numbers. The Scrum framework [3] is a normative document from the community that defined it, not an empirical study of effectiveness: it describes how Scrum works, not how effective it is compared with alternatives. The reference professional standard [4] is a body codified by principles and processes, widely adopted but not subjected to independent empirical validation on the Italian population.

Italian institutional data (ISTAT, Bank of Italy) describe the structure of the business landscape and the spread of structured management practices, and document their correlation with performance. Correlation, it bears repeating, is not causation: more structured companies also tend to be more productive, but formalizing project management is one of the possible levers, not the only one and not necessarily the main one.

The project management tools named as example categories (Trello, Asana, Monday, ClickUp, Notion) are part of the market the guide describes, not sources or recommendations. The landscape evolves rapidly: the criteria check should be repeated with every adoption decision, and no tool-specific information in articles more than 12-18 months old can be considered up to date.

Methodologies work under the conditions described and fail under the opposite conditions. The guide provides selection criteria, not guaranteed results. Empirical verification in your own context remains essential.

Finally: project management does not replace the quality of the technical work or the soundness of the business model. Even the best-managed project on a poorly founded initiative produces a poorly founded result, on time and on budget. The lever of project management is predictability and replicability, not a transformation of the intrinsic value of the initiative.

FAQ

How long does it take to set up the Project Charter for a project in a small company? For an average project in a small company (2-9 months long, team of 3-9 people), drafting the Charter can be wrapped up in a one-hour meeting with the project manager and the Sponsor. Rereading and finalizing it takes another 30 minutes of individual work by the project manager. The cost-benefit ratio is asymmetric: an hour and a half invested protects against weeks of misdirected work.

Is it worth adopting Scrum in a company with no technology component? It depends on the four dimensions of the methodology choice (requirement stability, team size, decision-making autonomy, duration). Scrum works in contexts with unstable requirements and autonomous teams of 4-9 people. The multi-case study by Conforto and colleagues documents enabling conditions for Agile outside software [6]: where these conditions are present, adoption is reasonable; where they are not, it can produce frustration.

Can Waterfall and Agile be combined on the same project? Yes, and it is the combination the four-dimension criterion leads to most often, because a real project rarely has requirements that are all stable or all unstable. Typically, you adopt a waterfall phase structure for the components with stable requirements (e.g., permits, construction work, fit-out) and introduce agile iterations for the components with emerging requirements (e.g., configuring a service, defining a commercial offering). The condition for this to work is making it explicit in the Charter: state which component is waterfall and which is agile, avoiding ambiguity with the team.

How do you manage a project when the manager is also the business owner and has a thousand other things to do? This is the situation this guide addresses: a company where the business owner is also the operations manager for projects. Three practical rules: (1) limit the number of formal projects open at the same time — better to close one before opening the next; (2) use the weekly team meeting as the only synchronization point, avoiding constant availability via messaging; (3) delegate the day-to-day running of the project to a team member, keeping the role of Sponsor rather than executive manager.

What minimum metrics should you track to know whether a project is going well? Three essential metrics: progress against plan (percentage of activities completed compared with those planned to date), budget variance (actual spending vs. estimate), number of active risks (how many of the known risks have materialized and how many have been intercepted). For a deeper look at performance measurement, see the guide on business KPIs.

Practical summary

In a small company, project management is a discipline of predictability: it organizes a temporary initiative with a defined objective, constraints and responsibilities, and sets it apart from recurring work. The first step is diagnostic: apply the four-condition test — single objective, time constraint, budget or resource constraint, non-replicated result — to recognize when an activity really is a project. The second step is evaluative: understand when it is worth formalizing, based on three measurable dimensions (duration, people involved, budget committed).

Every project goes through five phases — initiating, planning, executing, monitoring, closing — and what changes from one company to another is the weight they receive, not whether they are present. The most neglected phases in small companies are initiating and closing: the lean one-page Project Charter (six items: objective, scope, constraints, responsibilities, risks, closing criteria) protects against the invisible erosion of scope, and the closing retrospective turns experience into an organizational asset. The choice of methodology (Agile, Waterfall, Kanban, Scrum) is made on four dimensions — requirement stability, team size, decision-making autonomy, duration — and in practice often produces hybrid configurations, which are legitimate if made explicit in the Charter.

Team coordination rests on three minimum roles (Sponsor, Project manager, Team members), two essential rituals (15-minute weekly meeting, 45-minute monthly review) and a status update readable in three lines. Tools come last, after setting five selection criteria (learning curve, exportability, cost, integration, type of view). Six recurring mistakes — task list confused with a project, closing skipped, Agile because it's trendy, centralized decision-making, tool before criteria, unwritten Charter — hollow out even well-designed systems. Recognizing them in time, through their early warning signs, is the most solid pattern of prevention.

Conclusion

Project management in a small company does not require complex structures, certifications or dedicated teams. It requires a simple, applicable core idea: every initiative with a single objective, a deadline and a budget deserves a minimal framework that sets it apart from recurring work, and that framework — a one-page Project Charter, explicit phases, a conscious choice of methodology, criteria before tools — reduces surprises, delays and dependence on specific people, regardless of the size of the company.

The next step, if you haven't taken it already, is to bring this framework into everyday organizational culture: the discipline of the single project is a specialization of the broader ability to systemize the business, and the two reinforce each other. For the overall picture, also read Business systemization: the practical guide and, on the operational execution side, Business process automation.

A company that truly manages its projects has shorter meetings, deadlines met without emergency interventions by the founder, a written memory of what worked and what didn't, and team members who decide independently within the boundaries of the Charter. At the national level, the Bank of Italy documents an association between structured management practices and productivity in Italy, describing it as descriptive and not causal [2]; how much closing that gap would produce in aggregate is not estimated by that source or by any other cited here. The framework remains simple; what changes everything is applying it.

Sources and references

[1] ISTAT (2024). Rilevazione sulla struttura e competitività delle imprese, dati 2022. Rome: Istituto Nazionale di Statistica. Available at: https://www.istat.it/statistiche-per-temi/struttura-e-competitivita-delle-imprese/

[2] Banca d'Italia (2024). Indagine sulle imprese industriali e dei servizi (Invind), Anno 2023. Rome. Available at: https://www.bancaditalia.it/pubblicazioni/indagine-imprese/index.html

[3] Schwaber, K., & Sutherland, J. (2020). The Scrum Guide — The Definitive Guide to Scrum: The Rules of the Game. scrumguides.org. Available at: https://scrumguides.org/

[4] Project Management Institute (2021). A Guide to the Project Management Body of Knowledge (PMBOK Guide), 7th ed. Newtown Square, PA: PMI. Available at: https://www.pmi.org/pmbok-guide-standards

[5] Cocco, L., Mannaro, K., Concas, G., & Marchesi, M. (2011). Simulating Kanban and Scrum vs. Waterfall with System Dynamics. In Lecture Notes in Business Information Processing, Vol. 77, Springer. Available at: https://link.springer.com/chapter/10.1007/978-3-642-20677-1_9

[6] Conforto, E. C., Salum, F., Amaral, D. C., da Silva, S. L., & de Almeida, L. F. M. (2014). Can Agile Project Management Be Adopted by Industries Other than Software Development?. Project Management Journal, 45(3), 21-34. DOI: 10.1002/pmj.21410.

[7] Eurostat. Digital intensity by size class of enterprise, dataset isoc_e_dii, indicator "Enterprises with at least basic level of digital intensity (DII Version 4)", companies with 10-249 employees, 2024 data. Luxembourg. Available at: https://ec.europa.eu/eurostat/databrowser/view/isoc_e_dii/default/table

[8] Brusa, L. (2012). Sistemi manageriali di programmazione e controllo. Giuffrè / Il Mulino. Established Italian academic reference.