There's a tremendous opportunity to increase organizational performance and value by improving our projects' success rates.

Technology isn't rocket science anymore. The Millennial and Gen Zer generations have a pretty good grasp of technology and are comfortable with it.

Technology isn't the culprit in most project failures. Organizational dysfunction causes most project failures.

History tends to repeat or mirror itself when it comes to projects. Industry research points to the same general reasons as to why projects fail. Yet, we never learn our lessons. Why?

Three critical actions before a project begins are to:

  • Find who has solved a similar problem in the past and understand their solution.
  • Orient business team members on the project process and its pitfalls, risks, and nuances, particularly those who haven't engaged in technology projects.
  • Encourage team reflection and discussion on why projects fail and encounter trouble from an industry perspective and specific to your organization, what signs to look for, and possible resolution steps.

Know Nine Unique Insights about Projects

Use Project as a Verb

Shift your mindset about projects from noun to verb. Projects propel your organization from its current state to a future state of compelling business benefits.

Understand Project Anatomy

Projects are about effectively managing:

  • Scarce organization resources
  • Commitments
  • Expectations
  • Cross-functional relationships
  • Risks, issues, and decisions

Most projects fail as a result of sociological issues, not technology.

Consider Project Constraints

Traditional project thinking addresses three constraints:

  • Cost
  • Time 
  • Scope

Time can't be replenished. Manage time first and aggressively; the other two will work out just fine.

Engage with Technology

Business teams must stay engaged throughout the project, not just the initial planning and requirements activities.

Design, development, testing, and deployment are critical business engagement cycles to increase outcome quality.

Step to Outcomes

Establish aggressive but achievable milestones to track project progress and health.

Missed milestones are warning signs that your project has deeper troubles to address ASAP.

Undertake as Sociological Endeavor

Projects are more a sociological process than a technical one.

Most projects fail because of people (used collectively in this context to mean teams, constituents, leaders, organization, and culture) and their inability to influence the System they're working within, not technology.

Minimize Transitions

Projects have too many transitions that create knowledge "traps."

  • Large projects may have up to 35 transitions between teams, and roles, e.g., generalist and specialist.

Transitions cause knowledge to be:

  • Obfuscated
  • Lost in translation
  • Not shared

Minimize the number of  transitions by:

  • Getting the right resources engaged early.
  • Minimizing the number of specialist roles by encouraging more versatile generalists.
  • Ensuring resources remain consistent during project work by reducing turnover.
  • Using knowledge transfer and management deliverables to support transitions.

Choose Right Approach

The approach selected for your project should mirror the known facts of your problem domain understanding.

  • A higher degree of facts and fewer assumptions support a more significant resource commitment, e.g., approve a new capability or major enhancement project using one or two resource commitment approval gates.
  • Likewise, fewer facts and more assumptions support a smaller resource commitment, e.g., approve a feasibility or discovery project to increase knowledge and surface facts and understanding before committing to more significant resource commitments.

Reduce Project Proliferation

Many organizations approve more projects than leadership can effectively and efficiently manage.

  • Leadership bandwidth is at a premium.
  • Focus leadership and teams on the most compelling and impactful projects using discipline and assessment rigor during project filtering and approval processes.

Learn From History

Know Time-tested Symptoms of Failure

Project fiascos have been reported, studied, researched, and analyzed for decades.

Failed and troubled projects continue to occur at alarming rates despite well-documented, consistent reasons for failure.

  • Most reasons given are symptoms, not root causes.
  • Some studies report that only 30% of projects are successful.
  • Different definitions of success, failure, and trouble may distort the statistics and trends reported.
  • Nonetheless, there is broad agreement across top-tier research and consulting firms that project failure and trouble are unacceptable.

Organizations keep repeating the same thinking, organizing, behavior, and actions that trigger failure and trouble.

As Martin Cobb, former Treasury Board of Canada Secretariat, said:

"We know why projects fail, we know how to prevent their failure -- so why do they still fail?"

Develop Insight to Failure -- 12 Failure Findings from Project Autopsies

Pursuing aggressive goals, leading-edge change, and differentiated innovation may occasionally fail. That failure is good as long as lessons learned benefit future initiatives.

Most failure is bad, enabled by:

  • Losing touch with reality.
  • Poor problem domain knowledge.
  • Large and convoluted scopes of work.
  • Poor execution and team synchronization.
  • Team dysfunction.
  • Absence of transparent and accountable organization.

No organization is immune from failure. Public, private, large, and small organizations have experienced project failures, some well-documented by the news media.

Collectively, the annual global cost of project failures exceeds $1 trillion. Some analysts estimate the cost of project failure could be as high as $6 trillion when indirect costs, such as staff turnover, health, new learning curves, and opportunity costs, are added.

Avoid 7 Common Mistakes

Projects fail to deliver expected outcomes for a variety of reasons.

  1. Inadequate due diligence
  2. Vague project roles and accountability
  3. Poor communication
  4. Factless plans
  5. Overly focusing on scope versus outcomes
  6. Poor behavior and performance that go unchecked
  7. Losing sight of reality

Perhaps the biggest reason is not dealing with or facing reality. Not facing and resolving "unpleasant realities" promptly is the downfall of many project teams.

Consider Historical Laws and Principles

Law/Principle Description
Brooks's Law Adding staff to an already late project may make it even later.
Pareto's Law A minority of causes, inputs, or efforts usually lead to the most results, outputs, and rewards.
50/5 Law Typically, 50 percent of an organization's projects will add less than 5% to its revenues and profits.
Glass's Law Increasing the functionality of an application by 25% doubles its complexity.
Institutional Imperative Rationality frequently wilts to meet the cravings of leaders or imitate peer companies' behavior, aka best practices.
Time is the Scarcest of Organizational Resources Capital is replenishable in well-run organizations.

Scope is easy to add.

Organizations can't replenish time.
The Law of Proximity An organization can't create value unless it's engaged in and influencing its System.

Know the Real Reasons Why Projects Fail

Find the Elusive Silver Bullet

Unfortunately, there aren't any easy fixes or silver bullets.

Project failures are more complex and deep-rooted than industry pundits proclaim.

  • Findings such as lack of user involvement and executive support, poor definition of requirements, etc., fall short and shallow.
  • Why would executives authorize millions of dollars for projects and not support their success? It seems to be at odds with rational thought.

Catastrophic failures are usually enabled by more than problem, action, behavior, event, or circumstance, regardless of industry and product.

Stuck in Conventional Thinking

Over the past several decades, industries have invested in software development life cycles, professional certifications, management consultants, and undergraduate and graduate education programs.

Those investments have had a nominal impact on increasing project success rates and delivering business outcomes cost-efficiently.

Disregard Relationship Gaps

Historically, the relationship between business and IT teams in many organizations has been tenuous.

Today, many business professionals and teams hesitate to engage their IT teams in business initiatives.

Nurturing relationships between those teams is a critical behavior promoted by Capability Thinking® to increase the performance and value of technology investments.

Lack of Discipline in Thinking, Organizing, Behavior, and Action

Poor discipline practices in many organizations and teams may be the most significant barrier to realizing consistent project success.

Here are just a few examples.

  • Unclear organization and roles
  • Fuzzy visions and outcomes
  • Dependence on intermediaries
  • Poor role casting
  • Abdication of responsibility
  • Allowing accounting policies to circumvent reality
  • Succumbing to institutional imperatives
  • Loss aversion

Shift Your Mindset

Influence Institutional Dynamics

The real reasons many projects fail may be related to what Warren Buffett and Charlie Munger call the institutional imperative.

Employ Critical Project Processes

Here are some examples of practices that promote project success:

  • Thoroughly understand problem/opportunity space
  • Specify clear project roles and accountabilities
  • Promote crisp, transparent communications
  • Develop a fact-based plan of action

Use these Ingredients for Success

Employ 12 proven practices on your projects:

  • Establish business sponsorship and ownership
  • Define a clear business solution
  • Create a concise business case
  • Establish a "no blame" culture
  • Create fact-based plans
  • Establish the proper organization and cast the right people in roles
  • Follow a straightforward process for monitoring and synchronizing ongoing work
  • Leverage your organization's technology standards and assets
  • Choose the right person to be the project manager
  • Quantify your project plan and progress
  • Use proven Decide, Design, Develop, and Deploy methods
  • Design your project plan to deliver more frequent, smaller releases versus one mega-release

Shift your Thinking -- Drive Pragmatic Behavior

Transition from traditional project thinking to creative and pragmatic actions that are:

  • Simple to implement.
  • Based on business sense and principles.
  • Inexpensive.

Examples include:

  • Shift from larger to smaller projects using more releases.
  • Move slices of critical project activity, such as design and testing, earlier in the project process.
  • Use images and diagrams to communicate concepts and solutions to supplement text.
  • Conduct before-action dialogues early and at critical milestones to avoid relearning lessons and creating rework.

Make a Difference

Strong business engagement and ownership are often the difference between project success and failure.

Relate to Analogies -- Projects Model Other Systems in Form and Complexity

Building a House

Contrary to popular thought, there are many differences between building a house and developing a software application.

Physical and Visual

Building a home is a much more physical and visual process than building an application.

  • Human senses (touch, sight, hearing, smell, and taste) are invaluable in guiding and completing the home-building process.
  • Application building only leverages a subset of those senses. Humans accustomed to using all their senses to carry out their daily lives are somewhat a “fish out of water” when engaged in software-building activities.
  • Capabilities need to leverage the use of human senses for software-building methods to be successful.


The process, experience, and standards of building “dwellings” are much more mature than building applications. That results in repeatability, predictability, and success rates not found in application building.

  • “Dwelling” construction has been learned, refined, and passed down over 400 generations. Application software construction has been passed down slightly over two generations. Note: 30 years is used to represent one generation.


Another key difference is the competency and skill development approach used for building houses versus applications.

  • Building construction workers learn their trades by attending technical schools and hands-on apprenticeships, which represent on-the-job learning through practice and repeatability and expert mentorship and coaching.
  • Organizations remain challenged to provide the best on-the-job learning, skill, and competency development, which may be the more critical aspect of becoming an experienced and expert technology practitioner.
  • Practice and repeatability, combined with mentoring and coaching, produce experts--something many organizations struggle with.

Methods and Standards

One more area of difference is in methods and standards. Building construction methods and standards are much more mature and consistently applied than in software building.

BOM Complexity

Another takeaway is that the bill of materials (BOM) used to build application software is more voluminous than the BOM used for home construction.

Pre-built Components

Another takeaway is home building leverages pre-built components and solutions, whereas many software initiatives opt to develop everything from scratch, including knowledge.

Project is Theater

Project is drama at its best. It has protagonists, antagonists, and a cast of characters.

Comparing a project to drama may seem an odd analogy to use about achieving successful project outcomes.

Projects are about people and relationships. A project void of the right people and good relationships breeds failure.

Aviation System -- Managing Complexity

The aviation delivery system is more complex than technology project delivery. Yet, it's far less failure-prone than technology projects.

The aviation industry has significantly reduced its failure rates since 1959.

Technology project failure rates have remained generally the same since the early 1990s.


Aviation safety impacts human life. Most technology projects also impact humans, though many not from a life-threatening perspective. So the aviation industry must engage in stringent and expensive risk mitigation, investigation, and learning.

Improvement Opportunities

With that said, industries can invest more in reducing technology failure rates.

More broadly, sharing experiences and lessons is one-way industries can improve technology success rates.

  • Applying lessons from the past can yield improvements to technology project success rates.
  • Establishing a library of common failure causes organized by themes, such as flawed assumptions, human errors, organizational lapses, pre-existing failures, and unintended effects.
  • Evolving beyond the "historical" approach of examining past failures to a proactive approach focuses on detecting risk and implementing mitigation strategies before failures or serious trouble occur.

The transition to prognostic analysis requires a greater emphasis on acquiring, sharing, and analyzing project success data across industry communities.

Organizations should establish and work closely with their peers to leverage data from across industry communities to identify emerging and changing risks and proactively adopt thinking, organizing, behavior, and action enhancements to mitigate them.

It's good project practice to reduce the problem and solution complexity to the extent possible, but we can manage complexity using the right structures, processes, learnings, and people.


The organization and roles between corporate staff and line business teams are similar to franchisor and franchisee.

Franchising is a mechanism to rapidly scale a concept, such as product, retail, service, or other.

Attributes of franchising include:

  • Simplicity -- the product, retail, or service concept is simple both from a delivery perspective and consumer understanding.
  • Standardization -- In other words, the concept is cookie cutter. It can be relocated and replicated repeatedly, using the same standards, supply chain, and support infrastructure.
  • Localization -- Local ownership and locations engage local constituents and customers.
  • Corporate -- A corporate franchisor provides the methods, systems, procedures, supplies, and other support that a franchisee needs to succeed.

Projects are like a franchising concept within an organization.

  • The franchisor represents one or more corporate staff, e.g., finance, IT, etc. They often engage in projects as corporate governance.
  • The franchisee is the project, sponsored by one or more local departments.
  • The franchisor invests in standard tools, software, technology, and delivery methods that franchisees can leverage.
  • The franchisor also provides capital and operating expenses, through approved authorizations, to the franchisees.
  • Often, the franchisees are people that corporate governance members don't personally know. The only form of credibility that most franchisees possess is that they successfully passed the scrutiny of HR, Procurement (for contractors), and hiring managers to be employed or retained by the franchisor's organization.

Top Ten Reasons why Franchises Fail

Here are the top reasons why franchises fail (sources: allBusiness; Franchise Advisory Centre).

  1. Lack of Business Skills
  2. Underestimating the Commitment
  3. Inexperienced or Incompetent Staff
  4. Wrong Location
  5. Unaffordable Rent
  6. Insufficient Working Capital
  7. The Decision Is Emotional, Not Pragmatic
  8. Inability to Compete with Nonfranchise Competitors
  9. Lack of Franchisor, aka Corporate, Support
  10. The Franchise System Is Flawed

Do any of those sound familiar?

Team Sport -- Golf

Most of us think of golf as an individual sport. But it's also a team sport.

Many American players have historically emphasized individual aspects more than the team. I don't blame them. They earn their livelihood in the sport as an individual, not team athletes.

The most talented, modern-day American players have been challenged to engage in the sport as team players.

European players have shown more adeptness and camaraderie at team play than their American counterparts. European teams have been regularly winning Ryder Cups against USA teams, even though USA players are higher ranked and generally recognized as better individual golfers.

Recent U.S. teams of new and younger players are shifting the trend by winning. Are Millennials and Gen Zers more adept at being team players? 


  • Individual talent matters in team endeavors, but it isn't always the key determinant in winning.
  • Many projects engage top individual talent but fall short in achieving desired outcomes.
  • The ability for talented individuals to learn and adapt to be capable team players shouldn't be a given on any project. Prepare and reward people for winning as a team.

Set your Team on a Path to Success

Produce Great Software

Don't forget that application projects must produce great software to deliver differentiating and impactful business outcomes.

Understand SDLCs Conceptually

Conceptually, software development life cycles have four cycles of work:

  1. Decide
  2. Design
  3. Develop
  4. Deploy

The difference between structured, aka waterfall, and agile is how those cycles are organized, sequenced, executed, and staffed.

Understand Structured Approach

Organizations and projects that value predictability and risk mitigation use structured approaches.

Understand Agile Approach

Organizations and projects that value responding to change use agile approaches.

Structured Agile
Progress in top-down, serial sequence Progress using spiral, iterative sequence
Deliver full functionality and features over time Rapidly deliver slices of functions/features
Deliver large-scale enterprise initiatives over more extended periods, making accommodating change more challenging Deliver rapid value and quickly respond to change

Choose Structured or Agile -- What's Best?

Use the following dimensions when deciding between structured and agile approaches:

  • Complexity
  • Criticality
  • Culture
  • Change
  • Competency

More on SDLCs

Know Three "Cs" of SDLCs

There's more to a life cycle than just the four work cycles:

  • Cycles represent major milestones -- Decide, Design, Develop, and Deploy
  • Channels represent the type of work, such as Business Process/Application, Organization, and Technical
  • Control represents the project management methods. Projects often spin out of control when absent sound management practices

Relate to Analogy -- Structured SDLC

Structured software development life cycles are like trains:

  • Real workhorses -- carry a lot of people, baggage, and freight, aka scope
  • The terrain/scenery slowly changes
  • The larger they are, the slower they move
  • The tracks have many curves and twists that require deceleration
  • Switching tracks can be tricky and consumes time
  • Traffic control is critical
  • The journey takes longer, but it eventually gets you to your destination

View Agile SDLC

Project movement is constant, iterative, and fast-paced using agile methods.

Improvisation and pivots are critical competencies for success.

Relate to Analogy -- Agile

Agile frameworks are similar to an aircraft powered by a jet engine:

  • They're fast
  • They accommodate varying passenger and freight loads without sacrificing speed and efficiency
  • Incremental delivery is constant, with each increment represented by an intake blade on a jet engine that's constantly spinning to achieve speed and outcomes

Relate Capability Thinking® and SDLCs

Capability Thinking promotes new thinking, organizing, behavior, and action paradigms integrating structured and agile frameworks/methods to create agile business capabilities.

Recap and Reference

Critical Takeaways About Projects

Reduce the risks associated with project work by educating yourself and your team on basic project fundamentals.