About six months ago, I watched a friend attempt to launch a new product to a market segment that was hungry for a timely solution to a problem. He worked for over a year on the product with a strong, well-funded team. Timing was everything. Anything late would mean failure. The launch was late. The project failed.
We talk about project failure and the many ways we can define what failure means. A professional project manager will typically use scope, time and budget as the key critical success factors. Others might use the adoption of the product as a key success factor. Others might consider the project’s contribution or lack thereof to the culture of the organization to be a key success factor. Regardless of the method you use to judge project failure or success there are many reasons that a project will land on one side or the other of success.
I see 3 key reasons that I believe account for most of the project failures we see out there. Today we start with #1.
Lousy requirements.
I joined the PMI in 1995. When we talked about project failure back then no one mentioned lousy requirements.
In 2005 we saw the creation of the International Institute for Business Analysis [IIBA] which contributed to the new recognition that strong user requirements analysis was critical to the success of any project. Since then the IIBA has helped to establish a worldwide recognition for what I believe is the number one reason projects fail.
This past year the PMI established a new certification: PMI Professional in Business Analysis (PMI-PBA)®, recognizing the importance of this phase of every project.
Back in the day we rushed too quickly into the solution development when we should have spent time in the analysis of what our customer really wanted and needed especially in areas of emerging technology. The role of the business analyst is critical in this scenario as he/she helps the customer not only understand what they really need but to help them understand what is possible.
When I describe the role of the business analyst to audiences I can summarize with the sentence “the business analyst ensures that when we build it, we build it right the first time”. A solid requirements phase at the start of a project will ensure that everyone is on the same page from the start. Project managers should stop talking about versions 1.0 through to 5.0 and talk about getting it right the first time. Lousy requirements contribute to late delivery, over budget results and, predictably, projects that miss the mark on customer requirements.
Next week we look at my #2 reason projects fail… poor change management processes.
Images courtesy of www.freedigitalphotos.net
