Number 1 Reason Large IT Projects Fail

Each industry has its unique challenges, particularly when it comes to managing mega projects and understanding why they sometimes fail. I have learned a lot from my failures over the years and in return would like to help you succeed. In my years plus experience this is the number #1 reason large IT project sometimes fail miserably!

The Screen Door

There’s a story that comes to mind, and once you hear it, you’ll quickly grasp the importance of starting every project with a solid strategy. 

I was walking down the dock one day and came across two guys hard at work on a screen door. One was discussing the materials—debating between metal, strong plastic, and polymer screens—while the other was focused on different techniques to keep the screen tightly fitted to the frame. I was genuinely impressed by their effort. They were sweating, laboring, thinking, analyzing, and collaborating with intensity. It was a scene that inspired me and gave me a renewed sense of purpose in my own work.

The next week, I walked the same path down the dock and saw the same two technicians, only this time, they were sitting casually on the edge, chatting about fishing. Scattered around them were pieces of the screen door. Curious, I asked them what happened. They looked up and, with a shrug, said they were finished. When I asked why, they casually explained that the screen door was meant to be installed on a submarine!

This is something I see all too often in large projects. At the outset, the team is enthusiastic, eager to dive in, and ready to get to work. They’ll throw their energy into anything that seems productive. Stakeholders, equally impatient, want the project done yesterday and need to see action. 

But here’s the problem: when you work on a large-scale endeavor without a solid strategy, the team ends up working harder, not smarter. Important tasks are overlooked, and time is wasted on building components that, ultimately, serve no purpose. When the realization hits that their efforts were misguided, morale drops, and the project loses momentum.

To avoid this, large projects should begin with a well-defined strategy, one that is agreed upon by the top-tier stakeholders. This is not just about outlining goals but about having a clear roadmap for how to achieve them. Once the strategy is in place, the work should be broken down methodically—consuming the elephant one bite at a time, so to speak. 

The key is not to get overwhelmed by trying to understand and analyze every small detail upfront. Instead, map out the major components of the project, and use a just-in-time approach for requirements and development. Trust me on this one as things will change and you will be glad no time was wasted on detailing out too far into the future.

That means gathering and refining details as needed, just before the work on each part begins. This allows the team to stay flexible, focused, and able to adapt as the project unfolds. The result? A project that progresses steadily, with each piece fitting perfectly into the larger whole, and a team that remains engaged and productive throughout the journey.

The Project Charter

Setting a clear project strategy is one of the most important steps to ensure the success of any project, particularly large and complex ones. One of the essential tools in this process is the Project Charter—a document that defines the key aspects of a project and serves as a guiding framework from start to finish. It aligns stakeholders, defines expectations, and provides a solid foundation to manage the project effectively.

"Without a solid strategy, your project can end up like a screen door on a submarine—impressive effort, but in all the wrong direction!"

Let me break down the different components of a Project Charter, why each is important, and how they align with the Agile Manifesto principles. 

BTW, I have never had a large project to fail that had a solid Project Charter.

Key Components of a Project Charter

1. Project Purpose or Justification:

   • Why it’s important: This section answers why the project is being undertaken. It lays out the business case, explaining the strategic goals or problems the project will address. It helps the team understand the project’s value and the driving force behind it.
   • In Agile: The Agile Manifesto emphasizes delivering business value early and continuously. The project purpose in the charter aligns with this by setting clear business objectives right from the start, ensuring that the team remains focused on delivering outcomes that matter.

2. Project Objectives and KPIs (Key Performance Indicators):

   • Why it’s important: Objectives define what success looks like for the project. The KPIs provide measurable targets that allow the team and stakeholders to track progress and performance against the objectives. Without clear objectives and KPIs, it’s difficult to know if the project is on track or delivering the intended value.
   • In Agile: In Agile, continuous feedback and adaptability are core principles. Defining KPIs in the Project Charter supports this by providing clear, measurable goals that can be regularly assessed and adjusted based on the team’s velocity and feedback loops during sprints.

3. Scope Statement:

   • Why it’s important: This section defines the boundaries of the project—what’s in scope and what’s out of scope. A well-defined scope prevents scope creep, where uncontrolled changes can derail timelines and budgets. It sets clear expectations for what the project will and will not deliver.
   • In Agile: While Agile projects welcome change, they still need a clear initial scope to provide direction. The Agile mindset of responding to change works well here—teams can adjust scope through backlog refinement, but the charter helps ensure that the original strategic goals are still respected.

4. Roles and Responsibilities:

   • Why it’s important: Defining who is responsible for what is crucial to avoid confusion and ensure accountability. Roles such as Product Owner, Scrum Master, and team members need to be clearly defined, along with their specific responsibilities. This ensures that every aspect of the project is owned by someone.
   • In Agile: The Agile Manifesto emphasizes self-organizing teams and collaboration. Clearly defined roles help the team understand who makes decisions, who prioritizes the backlog (Product Owner), and who facilitates the process (Scrum Master). Agile thrives on collaboration, and clarity on roles fosters that.

5. Stakeholder Identification and Engagement:

   • Why it’s important: Stakeholders include anyone who has a vested interest in the project—executives, customers, team members, or regulatory bodies. Understanding their needs, expectations, and communication preferences ensures that the right people are informed and involved at the right time.
   • In Agile: Agile puts a strong emphasis on customer collaboration over contract negotiation. By identifying stakeholders early and engaging them throughout the project, Agile teams can maintain a tight feedback loop, adjusting priorities based on the latest stakeholder inputs.

6. Milestones and Deliverables:

   • Why it’s important: Defining key milestones and deliverables gives the project structure and ensures that progress is tangible and can be tracked. Milestones mark critical points in the project, while deliverables represent concrete outputs that can be reviewed and assessed.
   • In Agile: While Agile focuses on iterations rather than predefined milestones, deliverables still play a key role. Each sprint delivers a potentially shippable product increment, and milestones can be tied to larger features or releases. The flexibility of Agile allows the team to shift priorities between deliverables as needed.

7. Budget and Resource Requirements:

   • Why it’s important: A clear understanding of the project’s budget and required resources ensures that the project is financially viable and that the necessary people, tools, and infrastructure are available. Resource planning helps prevent bottlenecks later on.
   • In Agile: Agile doesn’t focus heavily on upfront resource allocation, but having a high-level understanding of resource needs allows for better sprint planning. Agile’s iterative approach also enables teams to adapt quickly if resource constraints emerge.

8. Risks and Assumptions:

   • Why it’s important: Identifying potential risks upfront helps teams mitigate those risks early. Assumptions clarify any uncertainties that the team is working with and establish the boundaries for what is considered true or known at the project’s outset.
   • In Agile: Agile supports a risk-tolerant environment where teams can adapt to changing conditions. However, highlighting key risks in the Project Charter ensures that the team is aware of potential challenges and can plan sprint goals accordingly to minimize the impact of risks.

9. Project Governance and Approval:

• Why it’s important: This section outlines how the project will be governed and who has the authority to approve major decisions, such as scope changes, budget adjustments, or project cancellations. It ensures the project stays aligned with strategic goals.
• In Agile: Governance in Agile projects can be more flexible but still needs defined rules for decision-making. Having clear governance helps the Scrum Master and Product Owner manage the flow of the project effectively, ensuring alignment with the stakeholders while preserving the Agile principle of empowering teams.

How the Project Charter Works with the Agile Manifesto

The Agile Manifesto prioritizes individuals and interactions, working software, customer collaboration, and responding to change. A well-crafted Project Charter doesn’t contradict these principles—instead, it provides the foundational structure that allows the Agile team to work efficiently and flexibly.

• Individuals and interactions over processes and tools: The Project Charter defines roles and responsibilities, encouraging collaboration and ensuring that communication flows smoothly between team members and stakeholders.

• Working software over comprehensive documentation: The Project Charter focuses on defining goals and measurable outcomes (KPIs), rather than endless documentation. It aligns the team with what needs to be delivered and provides just enough structure to guide the project.

• Customer collaboration over contract negotiation: A good Project Charter emphasizes stakeholder identification and engagement, ensuring that customers and other key players are involved in decision-making throughout the project lifecycle.

• Responding to change over following a plan: The Agile Manifesto’s emphasis on flexibility is enhanced by a Project Charter that sets high-level strategic goals while allowing for adaptability through iterative sprints, dynamic backlog prioritization, and just-in-time requirements gathering.

Conclusion: The Value of a Project Charter in Agile Projects

The Project Charter provides the strategic framework to ensure the project starts on solid ground. It’s a living document that defines why the project is being undertaken, what success looks like, and who is responsible for what. In an Agile environment, the Project Charter offers the structure needed to ensure alignment with key stakeholders while maintaining the flexibility to adapt and evolve as the project progresses. This combination of clear strategic intent and Agile’s iterative approach allows teams to remain focused, deliver value early, and adjust to feedback, leading to more successful outcomes.

"A solid project strategy, guided by a clear Project Charter, provides the foundation for agile adaptability and long-term success."

A Project Charter can be as simple as notes on a napkin or as detailed as a multi-page blueprint—just make sure it fits your organization's maturity, or you'll be over-engineering the screen door for your submarine, ha!

Sample Project Charter from SmartSheet.