As 2014 draws to a close, I find myself mulling through the various Top 10 lists that hit my inbox from LinkedIn groups like ProjectManager.net, Agile, Agile PMP, etc. These groups are great for information sharing and making new connections. But, as far as lists, it would seem that everyone is essentially carrying the same arsenal of lessons learned that got us burned in prior projects. Don’t get me wrong, lists are great, I particularly like these two:
Top Mistakes in Project Management
SOURCE: http://www.projectmanagers.net/i/top-mistakes-in-project-management/
Top 10 Reasons Why Projects Fail
SOURCE: http://www.slideshare.net/MariannaAlmakaieva/10-reasons-why-projects-fail-or-common-mistakes-to-avoid
But sadly, this year’s lists are no different than last year’s, and frankly they’re no different than the year before that. Actually, I think the list from 1914 looked relatively the same, too. This is telling me that the basic reasons for project failure haven’t changed, therefore we’re not doing our part to move the needle forward. I am reminded of a quote that I often revert back to:
”If you want something you’ve never had before, you have to be willing to do something you’ve never done before.” Bob Beaudine, The Power of WHO
The good news is that projects are failing at a much lower rate. According to the 2011 CHAOS Manifesto from the Standish Group, Waterfall projects fail an average of 29% of the time, while projects using Agile methodologies fail only about 9% of the time.
(SOURCE: http://www.onedesk.com/2013/01/waterfall-vs-agile/)
From an outright project failure standpoint, I think we can safely say that we have moved the needle by pushing our organizations to abandon the poorly performing Waterfall methodology. However, as these charts show, there is still some work to be done to address “Challenged” projects (projects which were delivered late, over budget and/or with less than the required features and functions).
So, what happens in these “Challenged” projects? In my experience, what happens is that the executive falls asleep at the wheel while the project team death marches to the end. When they wake up, they realize that what they asked for wasn’t what they meant or what they meant wasn’t heard correctly, or they don’t mean what they meant anymore because something changed. If the project team runs into this issue this far into the delivery process, then clearly some fundamental aspects of project management and project leadership were overlooked.
What dictates the quality of project delivery is the level of involvement. Leave a bunch of engineers to concoct their ideal widget and they will… they will develop the ideal widget for them. Leave a team to self-organize, self-select, self-rule… and they will perform these tasks in their best interest. Leave anyone in any situation to their own devices and they will exercise their own judgment. If the executive comes back in during the 11th hour and finds that they don’t like the result, well then who’s to blame? The team that built what they thought they were asked to build, or the executive that felt it better to prioritize something else rather than provide guidance and oversight to the team to make sure they built what they wanted?
So, how do we address this proactively? In my view, project managers or the project management teams needs to review a quick checklist to tell them if their project is in danger of being challenged.
- Is there a sponsor? Need this be said? If you don’t have a sponsor, the project team needs to be disbanded (released) immediately. Delete the project plan. Step away from the keyboard. You do not have a project and you should know better. Even that pesky pyramid project of ancient Egypt had a business sponsor.
- Is your sponsor engaged? It’s nice to have someone who is willing to fund the project, but it’s imperative that the person writing the check and accepting the deliverable is actively engaged in the project. If they can’t be actively engaged, they need to empower a proxy to own the deliverable. If they can’t do that, then call a spade a spade. This project isn’t important. Fold it up. And, stop for a second. If you get this far into the checklist and already have a series of goose eggs, then you need to take a pause and question the initiative and moreover your place in it. The rest of my checklist consists of basic PMI tenets that it seems people overlook. But risk, change and quality management mean nothing unless an engaged business team is leading the effort. We are project managers. We are there to get the job done. We rarely have the fortune, nor the business background for that matter, to question whether the initiative we are asked to lead is the right one. That is the sponsor’s job and if you cannot locate one or there isn’t one already established and leading the charge, then you should know in your heart and your gut that this project is on the path to train wreck status.
- What is the process for managing change? Change is inevitable. I can’t think of a single project where all was knowable at the onset of the project and nothing changed in terms of requirements or specifications during the course of the project. Because of this, a project without a sound change management processes in place is simply a project waiting for trouble to happen.
- Is traceability in place? I can’t really stress enough the importance of traceability in deliverable design. Traceability is largely used for technical implementations, but from my view, whether the deliverable is a product or a service, quality is reviewed based on the adherence of the final output to the original specification. I asked for the product to be able to calculate X and produce Y. Does it do that? If an unforeseen issue is detected in the quality control phases, you may need to be able to map back to the original requirement in order to figure out how to best resolve it without forsaking the originally intended functionality. You might even need to go back to the originator of that requirement and review the understanding and assumptions that requirement lead to. If you can’t trace your test cases back to the specification and the specification back to the original requirements then you have orphaned requirements. Not good. Why are you building a function that has no business requirement? This is Project Management 101. Don’t make this mistake.
- How are approvals captured? I recently engaged with a client of ours to take on a late stage deliverable for a key software implementation they are rolling out. When the person who was leaving the firm transitioned his documents to me, I noticed that one of the documents had recorded approvals of his content. “Awesome!” I said, “Where is the evidence of the approval?” “Oh!” He said. “It was all verbal.” Um… sorry… we don’t do verbal approvals in Project Management-land. I don’t care how much you trust your business users. Treat verbal approvals as an excuse to follow-up with said business user with an e-mail saying something to the effect of:
Dear <Business User>:
During our meeting today you verbally approved
<list out what they approved>
Please confirm that I have captured this correctly.
Your Friendly Project Manager
If you don’t do this, your project will successfully reach the end zone only to be thwarted by some business user with convenient amnesia. This may sound like a skeptical distrustful view of the world… but… well, it’s not that I don’t trust people, I just don’t believe they’ll remember what they said!
- Where’s the Quality Plan? No, no. Not your test cases. This is the plan that provides the strategy for preventing defects (Quality Assurance) and detecting defects (Quality Control). If the answer is, “our business users perform QC for us”, then please turn in your PMI card immediately, and grab a “Project Failure” sticker on your way out the door. Quality is paramount to deliverable acceptance. If you are not building quality into your process, you can’t expect quality to come out.
- What degree of confidence do you have in your team’s estimates? This isn’t a dig on your team. I’m sure they are wonderful people. However, the reality is that some people are better at estimating than others and you can rarely take in estimates without adding in some buffer. If you have that rare breed that gets it right all the time, awesome, set their discount rate to 0%, but in general I would add a 10% – 15% buffer to the estimates. Make it higher for some of the more junior members of your team.
- Has this project ever been done before? And as a corollary, what is the company’s history of fostering innovative projects? Businesses embark on completely new endeavors all the time. This is good! That means they are innovating. But, it’s also risky because there are no experts to lean on. PMI calls this “Expert Knowledge” or “Expert Judgment”. These are the advisors you can go to in order to gain insight into how long it will take to build something, they are part of the decision framework that needs to be in place in order to ensure that the right choices are made. But, they don’t exist in this environment. Different tools and techniques are required because you don’t have large swaths of expert knowledge to draw on. That being said, it might be a good idea to ask the executive team what happened to the project team on the last innovative project the company embarked upon. This will give you some insight into how the company approaches innovation and what their tolerance is for the precarious nature of research and development. If there is a scorched effigy of the last project manager hanging around the office you might want to pass on this opportunity…
As I stated earlier. In order for us to achieve something we haven’t achieved before, we are going to have to do something we haven’t done before. We are a culture of people pleasers and consensus builders. This has made us liked by our project teams, but unsuccessful in the board rooms. We need to push on our executives harder when projects are going off the rails and we need to demand a project environment conducive to success.
Let’s make 2015 the year that the right side of those pie charts became a smaller sliver!
Happy New Year!
Regards,
Jonathan P. Goldstein
McKinney, TX
