I wrote an article a few months ago about the importance of securing contingency reserves, so I didn’t expect to return to this topic so soon. However, earlier this week a discussion thread on Projectmanagement.com prompted me to write one more.
In that thread, the contributor asked which methods could be used to meet milestone dates when all schedule contingency had been stripped out by a client. The project manager is well aware of the risks of proceeding without contingency, but the client is adamant.
Contingency exists to protect a project’s success criteria from the impacts of realized negative risks. In any project schedule, the likelihood that each activity lying on the critical path for achieving a milestone will be on time or early gets progressively smaller as the number of activities and parallel non-critical network paths increases.
This is the rationale supporting Rule #74 in One Hundred Rules for NASA Project Managers: “All problems are solvable in time, so make sure you have enough schedule contingency, if you don’t, the next project manager that takes your place will.”
So when something goes wrong with one of those critical activities and it appears that the milestone date can’t be achieved, what do we do then?
If it isn’t possible to negotiate a reduced scope with the client, the schedule compression options of crashing or fast tracking could be considered assuming we have sufficient discretionary dependencies, effort-driven activities exist, or funding is available to attempt one or both of these tactics. But we must remember that there is always a cost associated with such techniques, either in terms of increased expenditures or increased risk.
This is closing the barn door after your prize-winning stallion has raced off into the sunset.
Being unable to secure schedule contingency is just one example of risk management failure. It is also an example of project management weakness as described by Neal Whitten almost twenty-five years ago.
But it goes beyond this.
Practitioners have argued about the need to recognize project management as a profession. If so, a core require is professional responsibility on the part of practitioners of a profession which is why PMI identifies Responsibility as one of the four values within its Code of Ethics.
When we knowingly accept an action from a client or sponsor which puts our projects in harms way, is this demonstrating responsibility? Is it sufficient to merely have the risks introduced by this action captured in a risk register, communicated to stakeholders and even signed off by the right governance bodies? Risk acceptance is a valid risk response strategy, but is it appropriate when faced with a high probability, high impact risk?
If we want to demonstrate professional responsibility, once we have have exhausted our attempts to influence the client, we need to escalate to an appropriate authority who will support us in doing the right thing. And if no such support is willing or available, we need to decide whether proceeding against our better judgment is a bridge too far.
If we don’t draw a line in the sand when it comes to the values and principles of a PM role, do we deserve to have project management considered a true profession?