Quoting Bernard Mars’s article in Forbes, the 7 real reasons IT Projects fail are:
• Poorly defined (or no defined) outcome;
• Lack of leadership;
• Lack of accountability;
• Insufficient communication;
• No plan or timeline;
• Lack of user testing, or failure to address feedback;
• Solving the wrong problem;
Note that none of the stated reasons are technological; they’re ALL people and process related.
This article will focus on the “Poorly Defined (or not defined) Outcome" and “Solving the Wrong Problem."
But first, some geometry…
Triangle
One of the most basic things we learn about in project management is the triple constraint, also called the project management triangle. According to this triangle, we are aware of the vital importance that scope, cost and time have on project success.
The failure reasons mentioned above, “Poorly Defined (or not defined) Outcome" and “Solving the Wrong Problem", strongly relate to scope (or least with a poorly defined scope).
The pressure to define the scope at the beginning of a project is well justified by the need to know how much it will cost and how long it will take to be developed.
But let’s be honest here, even if the stakeholders are well engaged, the understanding of the value that can be delivered changes as the project moves forward. With a closed scope approach, changing the scope would be placing the project on a track to failure.
This means projects often move forward with a scope that doesn’t address the real problem or addresses it poorly.
Maybe a geometrical change can help…
Square
Imagine a square whose width is capacity and its height is time. This square is then filled up with scope during project execution.
With this approach, the sizing of the project is a high-level decision based on the capacity a team has to build upon an idea over a period of time.
Most importantly, the details of the project (scope) are defined over time, as the project is developed.
So, going back to the two failure reasons:
• The square way we can still have a poorly defined outcome, but we own that decision. We know that during the execution of the project we’ll be able to define the value we expect to get from each interaction, and, as the project moves forward we’ll be more prepared to understand its needs.
• If and when we realize we’re solving the wrong problem, it’s easier and cheaper to change direction and focus the team on solving the real problem instead.
Bottom line
Are we ready to sell and buy services delivered in squares and leave triangles behind?
