Subscribe
“Hangman” is a game having a lot in common with project management. The goals are identical, i.e., figure out what the stakeholder(s) in control wants/means without them telling the project manager (PM) directly. The noose of the triple constraint tightens as the PM and team try to decipher just what is needed and they miss the mark.
There IS a substantial difference between Hangman and managing a project. In Hangman determining the word or phrase (scope) the controlling player has in mind is all that is required. 500-325 dumps With a project there is a chance for triple jeopardy since the PM and team must not only get the scope correct, they must also make sure there are sufficient resources left in terms of time and money to actually implement the scope. There is a way to not only survive but also succeed in such situations.
Terminology – Constraints vs. Principles
The first thing needed is a distinction between what is desired and what actually works. The term itself, “triple constraint,” implies boundaries of some sort. There is value in taking this term apart.
Rather than say, “The triple constraint means scope, time, and budget” stakeholders would be better served by stating, “There is a scope constraint, a time constraint, and a budget constraint placed on the project.” Why? Simple. Scope, time and budget refer to three of the nine principle sets in project management with the other six being communications, human resources, procurement, quality, risk, and integration.
“Principles” means there is a balanced interplay among all the variables and stakeholders in the project. Constraint means an arbitrary limit being placed on the project. It is called arbitrary because it is made in isolation with the responsibility for integrating being passed along illegitimately to others usually down the power chain.
That sounds like a pretty strong use of “illegitimately.” However, it does apply since the responsibility for a constraint stays with the person who makes it especially if he is the power broker.
Wishes and Business Cases
A constraint, then, is essentially a wish to make something so. What works better is examining what is realistic based on the business case. That business case needs to be grounded in reality. For example, if the project is to open a low-risk savings account then having a “budget” constraint of 1-3% interest rate is reasonable. 100-101 dumps On the flip side, if I am demanding 12% return with the same low risk then I am working from a wish list. The demand will be illegitimate if a PM in charge of investing the money is punished for failing to find a secure 12% savings account. It gets even worse if the wish of having the high return investment includes being able to withdraw any time without penalty (schedule constraint).
Stated more positively:
When needs are derived from realistic business cases rather than wishes, a bridge can be built between the business case and associated project principles comprising scope, time, and budget.
Going back to the previous blog, Rainmaker, building that bridge requires incorporation of other principle sets. In the next blog we will explore those principles with the goal being generation of a balanced relationship with realistic boundaries between scope, time, and budget. It involves the creation of something far more elegant than a triple constraint.
—