Why so many projects fail before they start
The statistics are sobering. The Standish Group's CHAOS Report finds that roughly 31% of IT projects are cancelled outright. Another 52% struggle — missing deadlines, exceeding budgets, or failing to deliver what was promised. Only 16% succeed. In construction, in business process change, in product development — the numbers are similarly grim.
The standard response is to look at the planning. Was the scope well defined? Was the methodology right? Were there enough resources? These are legitimate questions. But Henning Christiansen argues in Project Management: The Red Pill that they miss the real culprit. Most projects fail because the people involved lose faith in them. Not because of technical errors. Not because of poor Gantt charts. Because someone — often someone senior — decided the project wasn't worth fighting for, and that decision preceded the project's formal failure by weeks or months.
This is the context in which project initiation matters. Getting started right is not about documentation. It is about creating genuine commitment — in the project board, in the team, in the key stakeholders — before the pressure arrives. Because pressure always arrives.
The project lifecycle: where initiation fits
Every project, regardless of methodology, moves through recognisable phases. Understanding where initiation sits — and what it must accomplish before handing off to planning — is foundational.
The initiation phase produces three things that nothing downstream can substitute for: a clear project purpose that all key stakeholders have genuinely agreed on, a realistic assessment of whether the project is worth doing, and a project charter that documents the mandate. Miss any of these and the project enters planning on borrowed time.
Step 1 — Establish a clear project purpose
Before a charter. Before a kickoff meeting. Before a single task is listed. The project needs a purpose — and the purpose needs to be real, not political.
Christiansen is direct about what a vague purpose produces: scope creep, confusion, and projects that drag on endlessly without delivering. He uses the example of a TV remote control: the goal was simple — make it easy to change channels and adjust volume. The technical team got excited. They added controls for external devices, colour settings, screen formats, sound profiles, lighting. The remote grew. It became complex. It stopped serving the original purpose. Nobody challenged the drift because nobody had anchored the team to a clear purpose at the start.
A concrete, defined project purpose answers three questions without ambiguity: What will change in the world when this project is complete? Who benefits, and how? How will we know we have succeeded?
Vague: "We need to improve customer satisfaction."
Semi-concrete: "We will reduce customer complaints by 10%."
Concrete: "We will reduce customer complaints by 15% by end of Q4 through improved service training and a new complaint management system." The concrete version is specific, time-bound, and measurable — but more importantly, it leaves no room for individual stakeholders to project their own interpretations onto it.
Step 2 — Feasibility: the honest conversation nobody wants to have
A feasibility study assesses whether the project is actually worth doing — not whether it sounds good in a slide deck, but whether it is financially viable, operationally achievable, and strategically aligned. Skipping this step is how the Airbus A380 happened.
Airbus planned to sell at least 700 aircraft to make the programme profitable. By 2019, they had delivered 234. The plane was technically extraordinary. The project goal — the largest passenger aircraft in the world — was clearly defined. But the market assumption was wrong, and nobody forced the honest conversation about whether the numbers held up before commitments were made. The A380 project shows how even a well-executed project can fail if the feasibility question was never properly answered.
A proper feasibility study addresses three questions:
- Impact: Will achieving this goal actually solve the problem or create the value it claims to?
- Cost: What will it cost, and is the return worth it? If the project is too expensive relative to its value, it should not start — regardless of how attractive it sounds.
- Risk: What could go wrong? What assumptions are we making that might be incorrect?
In practice, feasibility studies are often commissioned by the same people who want the project to proceed. This is the same dynamic that produces business cases with optimistic revenue projections and thin risk assessments. The Unicorn project manager's role is to ensure the feasibility conversation is honest — even when honesty is politically inconvenient. Especially then.
Step 3 — Map your stakeholders before anything else
The stakeholder map is not a kickoff deliverable. It is a prerequisite to everything else. Before you write the charter, before you define scope, before you build the vision board — you need to know who has a stake in this project, what they actually want from it, and how they are likely to behave when things get difficult.
Christiansen identifies three primary stakeholder groups: the organisation, the project team, and the customer. Within those groups, individual stakeholders bring very different motivations. A Chameleon on the project board sees a career opportunity. A Rooster in the technical team sees an interesting problem to solve. A Honey Bee sees a stable assignment. Understanding which type each stakeholder is determines how you communicate with them, how you structure their involvement, and what you need to watch for when pressure builds.
This article references the political dynamics — Chameleons, Roosters, the Monkey King, Honey Bees, Parrots, and the Unicorn PM — that run beneath every project. Full guide: Stakeholder Management and Monkey Poker →
Step 4 — Write the project charter
The project charter is the project's founding document. It formally authorises the project, establishes the project manager's authority, and creates the documented baseline that everything downstream refers back to. Without a charter, the project manager has no formal mandate — and no formal mandate means no defence when the first Chameleon tries to expand scope in the second month.
A project charter does not need to be long. It needs to be clear. Every element serves a purpose:
- Project title and purpose — one clear statement of what the project will deliver and why
- Scope statement — what is included and, explicitly, what is not
- Objectives — measurable, time-bound, agreed by all key stakeholders
- Stakeholder list — key parties, their roles, and their authority level
- Project manager authority — what the PM can decide, and what requires board approval
- High-level timeline — major phases and milestones, not task-level detail
- Budget envelope — approved spend, contingency, and escalation thresholds
- Risks and assumptions — what we know, what we're assuming, and what we're watching
- Sign-off — explicit approval from the project board and sponsor
When a Chameleon insists a feature was "always part of the project," the charter shows exactly what was agreed. When a Rooster argues the scope needs to expand, the charter shows what sign-off is required. The charter does not prevent Monkey Poker. Nothing does entirely. But it makes it structurally harder to play, and it gives the project manager a documented reference when they need to push back.
Step 5 — Build the vision board and apply MoSCoW
The project charter documents the formal mandate. The vision board communicates the project's goals visually — in a format that is immediately understandable, emotionally engaging, and persistently visible throughout delivery.
Every element on the vision board is tagged with a MoSCoW priority: Must have (non-negotiable core), Should have (important but not vital), Could have (nice to have if budget allows), and Won't have (explicitly excluded from this version). This tagging serves a political function as much as a planning one — it makes it structurally difficult for stakeholders to argue that a "Could have" feature is urgent, because the priority label is documented and visible.
Run the MoSCoW prioritisation as a stakeholder session. Expect disagreements. Document them. Where stakeholders disagree on a category, note it on the board. Those disagreements are the early warning signals for where Monkey Poker will emerge under pressure.
Step 6 — Choose your project method
Choosing a methodology is not a philosophical exercise. It is a practical decision based on what the project actually needs: how well-defined the requirements are, how experienced the team is, how often the customer needs to be involved, and how much flexibility the timeline allows.
Christiansen's practical observation: the choice of methodology matters less than most people assume. The PRINCE2 hierarchy, Agile ceremonies, and Waterfall gates all provide structure. What they cannot provide is the will to succeed, honest goal-setting, and a team that is genuinely committed. A well-run project with a simple method beats a badly-run project with a sophisticated one every time.
Step 7 — Define and protect scope
Scope definition is where the vision board's MoSCoW categories become an operational boundary. The project scope is the formal statement of what the project will and will not deliver — connected to the objectives in the charter, traceable to the Must haves and Should haves on the board.
Scope definition has two parts that matter equally. The first is what is included. The second — which most project managers understate — is what is explicitly excluded. Without a documented "Won't have" list, every excluded item becomes a negotiation point the moment a Chameleon decides they want it.
"Could have goals are the most common source of scope creep — the uncontrolled expansion of project scope without corresponding adjustments in time, resources, or budget. Because of this, could have goals require special attention and firm boundaries."
— Henning Christiansen, Project Management: The Red Pill
Step 8 — Risk assessment and initial risk register
Risk assessment at the initiation phase is not about predicting every possible problem. It is about identifying the assumptions that could be wrong — and the known dependencies that could break the project before it reaches its first milestone.
Every goal rests on assumptions: that the market exists, that the technology works as expected, that the key stakeholder will stay supportive, that the vendor will deliver on time. Write the assumptions down. Then ask: what happens to the project if this assumption is wrong? That question surfaces the highest-priority risks before the project model has even been built.
At initiation, the risk register is deliberately high-level: category (technical, financial, political, external), probability, potential impact, and initial response. The register will deepen through planning. But the discipline of naming risks at initiation — including stakeholder-level political risks — is what prevents them from becoming surprises.
Step 9 — Resource and team planning
Who is on this project determines what it can deliver. Not in an abstract skills-matrix sense — in a very concrete sense. The TV remote team added features because those features were interesting to the people building it. Nobody on that team had been assigned based on what the project needed; they had been assigned based on availability.
Resource planning at initiation establishes: who is available and when, what skills the project actually requires (not just generic "development" or "design"), what the skills matrix reveals about gaps, and who owns which deliverable. Tasks should be allocated based on three parameters: what each team member finds motivating, what they professionally contribute, and what skills the project requires. Distributing both engaging and routine work across the team creates fairness, builds ownership, and prevents Roosters from monopolising the interesting assignments.
Step 10 — The kickoff meeting
The kickoff meeting is not a briefing. It is the moment when the project becomes real for everyone involved — and the project manager's first opportunity to set the tone for how communication, conflict, and decision-making will work for the duration.
A well-run kickoff meeting covers:
- Project purpose — why this exists, who it serves, what success looks like
- Scope and MoSCoW priorities — what is in and explicitly what is out
- Roles and responsibilities — who owns what, who decides what
- Methodology and process — how the project will run: phases, gates, sprint cadence if Agile
- Communication rhythm — how often, through what channels, to whom
- Change management process — how changes are submitted and evaluated
- Risk awareness — the most significant risks already identified and how they will be watched
Watch who asks what. A Chameleon will ask about visibility and recognition opportunities. A Rooster will challenge the technical approach or suggest improvements. A Monkey King will be distracted or absent. The kickoff meeting reveals the stakeholder dynamics you will be managing for the next twelve months. Pay attention.
Step 11 — Establish reporting and communication rhythm
Reporting is not a bureaucratic obligation. It is one of the project manager's primary political tools. Regular, accurate, proactive reporting creates the paper trail that protects the project manager when things go wrong, and it prevents the information vacuum that Chameleons and Roosters fill with their own narrative.
At the start of the project, establish: what gets reported, to whom, at what frequency, and in what format. Distinguish between internal team-level communication (daily, informal, digital) and external stakeholder reporting (weekly or milestone-based, formal, written). Both serve different functions and have different audiences.
Written reports are the legal and formal backbone of the project — they document decisions and create accountability. Digital meetings add tone and expression that text cannot. Face-to-face conversations reveal what neither can: the real attitude of the person you are talking to. A reporting plan that relies exclusively on written updates is a plan that will miss 93% of what is actually happening.
What to do — and what to avoid
- Establish a concrete, measurable project purpose before writing a single task
- Complete an honest feasibility study — including a real cost-benefit assessment
- Map stakeholders before defining scope: know who is who before the game starts
- Write a project charter and get explicit sign-off from the project board
- Build the vision board with MoSCoW labels and document all disagreements
- Choose your methodology based on the project's actual needs, not current fashion
- Define what is explicitly out of scope — not just what is in
- Identify political risks (Chameleons, Roosters) in the risk register from day one
- Allocate resources deliberately: match skills to needs, distribute both engaging and routine work
- Use the kickoff meeting to observe stakeholder dynamics, not just transmit information
- Establish a reporting and communication plan before the project starts moving
- Don't start planning before the purpose is agreed by all key stakeholders
- Don't treat the business case as the feasibility study — they serve different functions
- Don't skip the stakeholder map because "everyone knows each other"
- Don't write a charter without explicit sign-off — verbal agreement is not a mandate
- Don't leave "Could have" items undefined — they become scope creep ammunition
- Don't choose methodology to impress stakeholders — choose what fits the work
- Don't let a Chameleon's enthusiasm for a feature substitute for a proper impact assessment
- Don't assume the kickoff meeting created alignment — follow up individually within the week
- Don't build a communication plan that relies entirely on written updates
- Don't skip the risk register because "we'll deal with problems when they arise"
How the Unicorn PM starts a project
Start with purpose, not process
The Unicorn project manager does not begin with the charter template or the methodology framework. They begin by asking: why does this project actually exist? And they keep asking until they get an honest answer — not the political answer, not the aspirational answer, but the real one.
Know the game before the game starts
Unicorn PMs map the stakeholders before the kickoff. They know who is likely to be a Chameleon (career-motivated, will expand scope for visibility), who is a Rooster (expertise-driven, will prioritise interesting problems over project goals), and who is a Monkey King (rarely visible but dangerous when activated). This knowledge shapes every communication decision made from the kickoff forward.
- Share credit deliberately — even with those who haven't fully earned it. Investing in relationships at the start is the cheapest investment a project manager makes.
- Document everything that matters at initiation — not because bureaucracy demands it, but because the paper trail is the political shield for every difficult conversation later.
- Make the Honey Bees visible from the start. The people who will quietly do the actual work deserve recognition from day one — not just at the end when it is easy.
- Set the communication rhythm before anyone asks for it. Proactive communication is always cheaper than reactive damage control.
Starting a project in Proglar
Proglar is built around the initiation disciplines described in this article. The project model connects the vision board's MoSCoW priorities to tasks and resources, so every decision traces back to the agreed purpose. The stakeholder record captures each party's interests and communication preferences before the first sprint begins. The change register is live from day one — every request logged, assessed, and decided with a documented rationale before any work begins.
When reporting is connected to the project model in real time, the project manager walks into every board meeting with current data rather than memory. When the risk register is linked to the task structure, early warning indicators surface automatically. The rhythm that Unicorn project managers build manually, Proglar builds into the infrastructure of the project.
Start every project right
Proglar connects your project purpose to your tasks, your stakeholders to your communication plan, and your risk register to your model. Everything in one place from day one. Try free for 30 days.