Project Post-Gazette, November Issue, Volume 2013, Issue 11. http://projectgazette.com/ppg_201401a_003.htm
Cheryl A. Wilson, PMP, PMI-RMP, CCEP
We have reported that the project failure rate for IT projects has increased over that past 2 decades. Currently, surveys put this failure rate somewhere in the range of 70% of all IT projects fail for one reason or another. In fact, recently, a newscaster reported that the errors on the website for the Affordable Care Act were normal as “All IT projects usually fail.”
Why should we accept project failure as the norm for our projects, and thus leads us to ask the related question, “is poor project management ethical?”
Failure on IT projects can be avoided by understanding the concept that MCLMG calls “Deliverables Centered Project Management”. While many project managers (PM) know that a project has deliverables, many do not understand their importance and central preeminence. Deliverables are the only reason for a project to be chartered or brought into existence. Without deliverables, there is no project. Therefore, since deliverables are the reason for projects in the first place, how is it that some project teams do not know what are the deliverables of the project to which they are assigned?
It then becomes the responsibility of the PM to ensure the team knows what the deliverables are towards which their efforts and skills will be directed. The first action taken when a project is in trouble is to revisit the deliverables to determine if the project is following the plan towards the production of the projects “fit-for-use” deliverables.
Incompetent project management leads to confusion from team members, unclear direction and eventually troubled projects. Knowing the projects deliverables and constraints seems like a basic part of good project management, right? It is actually more common than you would think that an inexperienced PM does not know what the basic parts of the project are.
One reason this happens is many inexperienced PM get too caught up in the details and never look up to see the big picture — the reason for the project to exist in the first place.
All projects have the following attributes:
- A definite timeframe for its completion,
- Confinement by primary constraints (scope, time, cost, quality, and risks), and
- Requirement to produce unique, “fit-for-use” deliverables.
This definition is a more specific than most bodies of knowledge currently utilize; however, it covers all the true and mature aspects of projects as they are implemented today. The attribute that is left out from most definitions is the second one of being confined by the project’s primary constraints. The project management discipline now realizes that all projects are bounded by these constraints, and the balancing of these constraints is an important responsibility of PM.
These project attributes lead to the following questions:
- Why are we doing the project?
- What are the boundaries of the project due to the defined project constraints?
- What are the project deliverables?
- What is the work to be performed to produce fit-for-use deliverables to the customer?
No matter how complex or large your project is, if the PM cannot go back to the basic questions: what are the fit-for-use deliverable and the scope of the project, then the PM and the team has the tendency to veer off course down the path towards project failure.
An inexperienced PM can get surprised when they become aware that the project’s schedule is 4 weeks behind or the customer refuses to sign off on the deliverables. Many times the PM will tout off all the risks they see when in retrospect the risks are not risks at all, but unskilled PM effort. In an attempt to draw attention away from themselves, the PM creates a reason for their poor planning based on events that could not have been seen and therefore mitigated. Some of the reasons for the failed project might contain a good portion of factual information; however, the PM tells the story in a manner that supports their position that they were the victim of unforeseen events.
We have all seen poor project planning or unfocused planning leads to wasted resources, team member conflict and eventual project failure. I chuckle at the times that team members come to me as the Risk Manager and ask me to put the PM on the Risk Register as a project risk with the mitigation plan of needing more training for the PM!!
MCLMG offers some simple fundamentals for coaching inexperienced PM:
- The PM must understand the fundamentals of “fit-for-use” deliverables to realize the basic requirements of the project.
- The PM must adopt the concept of a deliverables centered project management methodology and teach the entire team how to understand this concept.
- The PM must understand the project’s primary constraints (scope, time, cost, quality, and risks), and how they must be kept in equilibrium in order to produce the defined ‘fit-for-use’ deliverables.
- The PM should understand the importance of risk management in the reduction of uncertainty that surrounds decisions through the application of valuable information.
I hope this article will challenge you as a PM to ensure you are not playing the victim or blaming unknown risks for less than adequate project management skills. Many times admitting to yourself that you need additional training as a PM is the first step towards improving your project success rates.