The answer to the title’s riddle is, of course, change itself, but besides being a play on words, I think it points to a larger truth, one that has the capability of influencing the way that PM-based business models are formulated. Because when we talk about Change Management (ProjectManagement.com’s theme for October) we’re not really discussing managing change per se. “Change” cannot be managed, at least not from a PM perspective, since change happens in the future, and the future does not exist. Rather, what we PM-types mean when we discuss Change Management is altering the plans (“baselines”) that we had set in-place prior to the start of a project, alterations that typically require a significant amount of scrutiny prior to approval, and integration into, those same cost, schedule, and scope baselines. Such scrutiny is warranted due to … well, let’s load everything into the Game Theorist’s favorite analysis tool, the payoff grid, shall we? Consider:
|
|
1. Change Proposal Not Proposed/ Furthered |
2. Change Proposal Proposed/Furthered |
|
A. Change Proposal Is Valid |
Project poison. |
It’s all good. |
|
B. Change Proposal Is Not Valid |
It’s all good. |
Customers will have heartburn with this. |
As per custom, we’ll dispense with the all-good scenarios first. If a Change Proposal isn’t called for, and it is not submitted (B 1), it’s all good. Similarly, if a BCP is indicated, and one is filed (A 2), again, everything’s okay. Things only get gnarly with the other two scenarios.
In Scenario B 2, a BCP is submitted before the Baseline Change Control Board, but it really should not have been. Unscrupulous PMs (not GTIM Nation members!) have been known to submit a BCP seeking additional budget or time added to the schedule for reasons that don’t really pertain to unpredictable, uncosted changes to the original baselines, including:
- Poor performance,
- Inaccurate original estimate,
- Subcontractors’ poor performance,
- Inaccurate performance measurement systems leading to the illusion of poor performance,
- Misinterpretation of the particulars of the Scope Baseline, or…
- Did I mention poor performance?
Customers issuing Firm Fixed Price contracts don’t have to worry about any of this, but pretty much all clients issuing Cost Plus contracts (or their derivates) do have to be concerned, lest they end up paying for their contractors’ errors. Avoiding Scenario B 2 is essentially the raison d’etre of Baseline Change Control Boards, who can be counted on to ferret out proposed changes that are being advanced that have even the slightest whiff of being driven by the above-bulleted reasons. Unfortunately, there is no objectively reliable Litmus Test for when a given Baseline Change is solely due to an unforeseen change in the Scope Baseline which, in turn, drives higher costs and longer durations. It’s rather subjective, leading to the need for a relatively high level of PM expertise on the BCCB – otherwise, poorly-performing Project Teams are in a good position to take advantage.
However, as odious as B 2 is to customers, from the PM’s point of view Scenario A 1 has to be considered even less desirable. In those situations where the Scope Baseline is being changed informally, with no Baseline Change Proposals/Requests being submitted, a condition known as Scope Creep enters in. The clearest example I have witnessed first-hand had to do with an environmental engineering project, where the customer would regularly ask the PM to “just” add one more analysis, or “just” expand the reliability study. Soon the calculated Estimate at Completion jumped above the Budget at Completion, and wasn’t coming down in subsequent reporting periods. I finally had to approach the PM, and told him “For cryin’ out loud, the next time (your customer) comes to you and asks for ‘just’ one additional item, tell him ‘I’d be happy to do that, and I’ll have the cost estimate ready for you tomorrow.’” Sure enough, another request came in, and the PM had an estimate prepared. “I had no idea it would cost this much!” the customer complained, completely ignoring the fact that, low cost or high, he should not have been leveraging the PM’s willingness to stay on his good side to extract non-baselined performance from the Project Team. The informal scope addition requests did stop, though.
There’s a reason Scope Creep is often identified as the number one danger to completing projects on-budget, on-time. PMs are often under Mariannas Trench-level pressure from their home organizations to expand the project base, and keeping existing customers happy is axiomatically asserted to be far easier than attracting new ones. Scenario B 2 guardrails entail entire BCCBs standing ready to enforce boundaries. Scenario A 1 protections are typically borne by just the PM.
And I have a sense that, for as long as PM remains a distinct management discipline, the threat of Scenario A 1 unfolding will never change.




Community Champion