April 12, 2012 at 9:54 pm #158631
April 12, 2012 at 9:57 pm #158703
OK here’s mine to kick this off.
- Value is not adequately defined from the customer’s perspective.
- A lack of systems thinking throughout the program/project.
- Trust and communication breakdowns.
April 16, 2012 at 12:32 pm #158701
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
April 16, 2012 at 12:39 pm #158699
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
April 16, 2012 at 1:06 pm #158697
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
April 16, 2012 at 2:28 pm #158695
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:
- there is not a strong definitive charter signed by all levels of leadership and management.
- 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.
- a rigidly hierarchical organization is place. The flattened organization with free and open lines of communication to all levels is most agile.
- there is not a fleshed out communication plan that aligns to the project plan that aligns to the charter.
April 16, 2012 at 4:05 pm #158693
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!
April 16, 2012 at 5:15 pm #158691
Please elaborate: “A lack of systems thinking throughout the program/project.”
April 16, 2012 at 6:13 pm #158689
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.
April 16, 2012 at 6:34 pm #158687
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.
April 16, 2012 at 6:37 pm #158685
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?
April 16, 2012 at 6:39 pm #158683
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.
April 16, 2012 at 6:40 pm #158681
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!
April 16, 2012 at 7:45 pm #158679
Peter G. TuttleParticipant
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
April 16, 2012 at 7:53 pm #158677
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.
April 16, 2012 at 7:58 pm #158675
Love this list Peter. When you say ‘lousy communications’ what are some specifics that come to your mind about ‘worst practices’ with that?
April 16, 2012 at 8:16 pm #158673
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.
April 16, 2012 at 8:32 pm #158671
Peter G. TuttleParticipant
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
April 16, 2012 at 9:16 pm #158669
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.
April 16, 2012 at 9:39 pm #158667
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.
April 16, 2012 at 9:52 pm #158665
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?”
April 16, 2012 at 10:35 pm #158663
April 17, 2012 at 1:19 pm #158661
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.
April 17, 2012 at 3:28 pm #158659
I had never visited the Facebook page before! I ‘liked’ it so I’ll get updates.
April 17, 2012 at 3:45 pm #158657
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.
April 17, 2012 at 3:47 pm #158655
None of these sounds like reasons to me…
April 17, 2012 at 3:51 pm #158653
April 17, 2012 at 3:56 pm #158651
Kind of pricey at a time of budget cuts.
April 17, 2012 at 5:07 pm #158649
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.
April 17, 2012 at 6:52 pm #158647
I like it Paul. You aren’t perhaps a fellow lean/agile enthusiast, are you?
April 17, 2012 at 6:53 pm #158645
Commitment, not just compliance. Love it Greg, thanks!
April 17, 2012 at 7:16 pm #158643
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.
April 17, 2012 at 8:05 pm #158641
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!
April 18, 2012 at 3:33 pm #158639
April 18, 2012 at 3:34 pm #158637
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
April 23, 2012 at 7:39 pm #158635
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
April 23, 2012 at 9:38 pm #158633
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.