Why Do Projects Fail?

Home Forums Program and Project Management Why Do Projects Fail?

This topic contains 36 replies, has 13 voices, and was last updated by  Josh Nankivel 9 years, 5 months ago.

  • Author
  • #158631

    Josh Nankivel

    What are the primary causes of project failure?

    I have my list of maybe 3-5 primary reasons based on my experience.

    So in your experience, what causes projects to fail and how do we fix it?

    And don’t listen to Homer. He’s just a negative Nelly.

  • #158703

    Josh Nankivel

    OK here’s mine to kick this off.

    1. Value is not adequately defined from the customer’s perspective.
    2. A lack of systems thinking throughout the program/project.
    3. Trust and communication breakdowns.
  • #158701

    Steve Ressler

    1 – Scope creep

    2 – Lack of understanding of effort and/or feasability

    3 – Changing org interests – why this project may have been super important 3 months ago, now no longer interesting

  • #158699

    Peter Modigliani

    1. Scoping the project too big

    2. Not adopting Agile practices – Close user involvement in development; small, frequent capability deliveries; responsive to change; leverage portfolio level resources

    3. Too much oversight, complex policies, and restrictive statues to comply with

  • #158697

    Chris Hamm

    I would normally list “Communication” five times in a row here (for emphasis)

    • Communication – # 1 every time. Project Managers communicate infrequently, pushing information only when it is ready, only in one channel (e.g., email blasts). Communication should be frequent, multi-channel, and participatory.
    • Stakeholder Engagement – lack of effective project control & inclusion allows participants to ride along without commitment
    • Poor Requirements Definition – nobody pays attention to truly define them
    • Organizational Culture – resistance to change, risk aversion, lack of leadership
    • Organizational Structure – stovepipes
  • #158695

    Sandy Barsky

    I have been privileged to have worked for leadership that gave to me as both a project manager and program manager the tools with which to succeed. I must concur with the other posts, SCOPE CREEP is deadly to a project. From my experience projects COULD fail if:

    1. there is not a strong definitive charter signed by all levels of leadership and management.
    2. there is not a servant leader. True leadership relies on and fully supports those who plow the fields, and therefore can plant the seeds of the next great innovation/transformation.) project profile, the most successful projects are those with a strong charter yet that can “fly under the radar”, avoiding micro management.
    3. a rigidly hierarchical organization is place. The flattened organization with free and open lines of communication to all levels is most agile.
    4. there is not a fleshed out communication plan that aligns to the project plan that aligns to the charter.
  • #158693

    Richard Boly

    I would love to have each of you give your personal examples of learning from failure and have a great opportunity for you to do so.

    We are organizing the first government FAILFaire on May 7 at the Reagan Building in DC as part of the Excellence in Government Conference.

    If you dare to share, let me know!

  • #158691

    Bill Brantley

    Please elaborate: “A lack of systems thinking throughout the program/project.”

  • #158689

    Josh Nankivel

    Silos, and looking at little fiefdoms instead of end-to-end delivery of value to the end user.

    A specific example is the practice of decomposing larger system designs down into subsystems without regard for the overlapping functionality in those subsystems. I’ve written before about organizing teams and subsystems around functionality, because when you don’t you get silos and different teams trying to re-invent the same wheel.

  • #158687

    Josh Nankivel

    I think 2 on your list is huge – ensuring the requirements are well understood is an art and a science, and estimation hinges on getting the ‘understanding’ step right first.

  • #158685

    Josh Nankivel

    Ding ding ding! Agile and/or Lean practices can be applied in so many more projects than they are.

    Unfortunately, much of the momentum in government agencies is very resistant to this. Contract structures too, but even just the cultural shift that is necessary. I find teams are usually willing and even eager to adopt Lean/Agile ways of working, but work and contract management sees it as a fad that they shouldn’t concern themselves with.

    How do we fix that?

  • #158683

    Josh Nankivel

    Love it Sandy! Especially point 3 – I loathe what is essentially arbitrary levels of hierarchy…they just complicate things and get in the way of producing real value for the end user.

  • #158681

    Josh Nankivel

    Very cool Richard, I didn’t know about that event. I absolutely love it, I don’t think I’ve seen an event dedicated to highlighting failure, but it’s sorely needed!

  • #158679

    Peter G. Tuttle

    Here are a few of my favorites:

    1. Lousy communications

    2. Lack of collaboration

    3. Unrealistic expectations

    4. No support from leadership (beyond lip service)

    5. Lack of project alignment with the organization’s “true” mission or goals

  • #158677

    Josh Nankivel

    Love the point about stakeholder engagement – requirements can and should evolve over time, but if you want the project to keep up with the evolution of needs, that real-time engagement is essential.

  • #158675

    Josh Nankivel

    Love this list Peter. When you say ‘lousy communications’ what are some specifics that come to your mind about ‘worst practices’ with that?

  • #158673

    Bill Brantley

    Yes, I was waiting for the obligatory “Traditional Project Management – Bad! Agile Project Management – Good!”

    Gosh, I have asked this so many times in so many ways among agile practitioners but I will ask again:

    1) If one follows the agile project management methodology 100% then EVERY project one manages will be successful?

    2) What is the DOCUMENTED success rate of agile projects versus traditional projects?

    And, a new third question:

    3) How do I use agile project management methods to build a house and why would it be more effective and efficient than using traditional project management methods to build a house?

    I’m not arguing for either traditional or agile but as someone who believes that project management methods exist along a continuum rather than two extreme poles.

  • #158671

    Peter G. Tuttle

    Hi Josh: Lousy communications…hmm, where do I start? Here are a few danger signs:

    1. Use of half-truths or lies in discussions, requests, etc.

    2. Lack of timliness in responding

    3. Smoke-blowing instead of meaningful dialog

    4. Reliance on email exclusively, instead of all manners of commo

    5. Overly complex messaging

  • #158669

    Josh Nankivel

    I agree Bill, but coming from where I do with software systems projects, I can’t help but jump right to those methods/practices that should be used more often.

    1) No, of course not.

    2) What’s the DOCUMENTED success rate of traditional projects by themselves, really? I don’t put much stock in Standish, but I guess it’s the best we have?

    3) Lean, yes. Agile, no. And yes, Lean construction is more effective to the best of my knowledge than traditional construction management. IF it’s implemented well, just the same as anything else. Just because you say your organization is “Lean” doesn’t mean it is.

    I’ve seen some compelling case studies and my own experience with my teams has been positive for both lean and agile in software development. In the past I’ve read papers with studies for Ph.D. theses mostly, I’d like to see if there are any management journals who have tried to quantify this sufficiently, especially taking into account clear definitions of what is ‘success’ and what elements of traditional or lean/agile project management have been implemented well or poorly.

  • #158667

    Karen Waltermire

    1 – Not having time to organize thoughts and plan, plan plan. So, MAKE the time.

    2 – Yeah, scope creep and not having authority to say NO. So, find an advocate/business sponsor that will allow the PM to say No.

    3 – Keeping good people on a long project. Heck, I dunno how to solve this one.

  • #158665

    Josh Nankivel

    Great stuff Karen. The all-important ability to say NO hasn’t been mentioned so far I think, perhaps indirectly with the scope creep mentions.

    I can hear it now “Oh come on, can’t you just fit this tiny little thing in?”

  • #158663

    Karen Waltermire

    exactly!!! 🙂

  • #158661

    Allison Primack

    Here is the conversation happening on GovLoop’s Facebook on why government projects fail:

    Andrew Hughes Lack of documentation, Lack of client understanding of the outcome, Lack of time and preparation, Lack of experience by the chosen vendor. Lack of small business set asides, so we have to work under the umbrella companies which have no idea what they are doing in particular situations and projects… That sums all of it up don’t you think? If not, ask Homer…lol

    Matt Lane Underestimation of the scope of a project that leads to a budget that is too small to complete the project with its intended goals.

    Matt Lane And I suppose it is mostly situation-dependent.

    Jane Robinson actually…I believe there is something which occurs PRIOR to the above: lack of humility, especially if there is an early ‘success’.

    Andrew Hughes Lack of funding can be but its our job to accurately estimate that effort and as vendors disallow scope creep so that’s why I left it out.

  • #158659

    Josh Nankivel

    I had never visited the Facebook page before! I ‘liked’ it so I’ll get updates.

  • #158657

    Paul Boos

    Since I am in IT, here is where I see projects failing:

    1. Project Thinking vs Product Thinking: It is developed as a project with no thought as to the item to be developed as a product, which has a life beyond the end of the project. This often promotes problems 2&3, though they could also be independent.

    2. The Feedback Loop to the customer is too long; thus the delivery team has no assessment on how well they are to achieving the desired outcome in value.

    3. People are not treated as people; they are treated as resources. Strengths and weaknesses aren’t assessed and teams aren’t allowed to gel into anything cohesive.

  • #158655

    Paul Boos

    None of these sounds like reasons to me…

  • #158653

    Paul Boos

    I hope some other Govvies are reading this and want to fix it. If you do, please join us at the Govt Lean/Agile Software & Systems Conference (GLASScon): http://glasscon.org

    We’d love to get some contracting officers as ell as developers, managers, and PMs.

  • #158651

    Paul Boos

    Kind of pricey at a time of budget cuts.

  • #158649

    Greg Jaquez

    Buy-in to the “vision”. It doesn’t matter is the guy/gal at the top gives the “go” order. If the project is not supported throughout the rest of the command structure and the support structure, your project is either dead in the water or an exercise in futility. You have to communicate the purpose behind your vision to all who have stake and bring them into the fold at the earliest stages possible.

  • #158647

    Josh Nankivel

    I like it Paul. You aren’t perhaps a fellow lean/agile enthusiast, are you?

  • #158645

    Josh Nankivel

    Commitment, not just compliance. Love it Greg, thanks!

  • #158643

    Paul Boos

    Oh, just a little… 🙂

    I’ve helped organize the last 2 Agile Coach Camps here in the States and am helping with the 3rd one as well. You can find me at the Agile Development group I started here on GovLoop, at http://boosianspace.posterous.com and My Manifesto for Project Leadership at http://projectleadershipmanifesto.posterous.com I’m on Twitter at @paul_boos

    More seriously though, I chose those as the core reasons as many of the other reasons mentioned by other folks are symptoms to these underlying causes.



  • #158641

    Josh Nankivel

    I thought so, your response was very similar to mine – not looking at the whole value stream, not viewing value from the customer perspective, and trust/communication breakdowns. I’m going to check out your links now, cheers Paul!

  • #158639

    Paul Boos

    Oops, I gave out the wrong URL for the Manifesto: http://projectleadermanifesto.posterous.com/


  • #158637

    Paul Boos

    I also posted (Thanks to some prompting by Tobias Mayer) the following on my blog this morn: http://boosianspace.posterous.com/projects-teams-and-products-oh-my

  • #158635

    James Lewis

    I find the Agile vs Traditional debate very interesting. Many times, especially when hearing non-practicioners discuss PM, I find that I’m not so sure they know what they are talking about. Specifically, there are differences between Agile and Waterfall approaches to project management.

    Could some of the government PMs enlighten me… is it possible to have an “agile” traditional approach. what I mean is, can you use traditional or “waterfall” project management, but change the deliverables or work tasks to more tangible, measurable, shortened delivery (3-9 months)?

    I believe that this is what former CIO Vivek Kundra was talking about in his 25-point plan

  • #158633

    Josh Nankivel

    I think what you’ve described is progressive elaboration, which isn’t incompatible with traditional waterfall approaches commonly used in government.

    I will say though, that it’s not Agile.

    As far as time frames, if you go beyond a month ( I prefer 2 weeks) for your sprints, I’m not sure how that can be called Agile.

    Time frames aside, Agile is more about focusing on the product from the user’s perspective with things like user stories, behavior-driven development and test methods, etc. If your requirements are the standard “The system shall….” I don’t see how that can be called Agile either.

    As far as Lean goes, the continuous integration and focus on cycle times through the entire value stream from beginning to end make the 3-9 months or more delivery times completely non-Lean in my perspective.

    My teams and I are *trying* to do Lean within our own sphere of influence, but we are not really doing it unless it’s from beginning to end. We still have to do these major releases in the traditional 3-9 month cycles because of the way things are structured, and subsystems still aren’t integrated with the rest of the systems until the even more infrequent high-level system integration and test. Which means it could be a year or more before the end user can actually give feedback on some things, and interface issues are hidden until they grow larger and larger. Then we find them when we do the huge integration & test effort, which spawns all kinds of subsystem patch releases and more overhead.

    So in short, you can use some of the tools of Agile and Lean within a waterfall paradigm and contract model, but you certainly can’t get nearly the benefits intended, and I’d say you’re not actually doing Agile or Lean.

You must be logged in to reply to this topic.