Much has been made of the issue of project baseline integration. And when I say “much,” I mean virtual tons of pixel ink that need not have been sacrificed on the altar of this suspect quality metric. One of those guidance-generating organizations that I consistently refrain from naming has made baseline integration pretty much the basis for assessing the quality of any Critical Path Methodology schedule network in its relation to the same project’s Earned Value Management System time-phased budget.
For those members of GTIM Nation who are unfamiliar with what I’m talking about, here’s a quick primer. For (what are considered to be) highly robust Project Management Information Systems, the development of the Performance Measurement Baseline (PMB) is a big deal. A typical sequence involves defining the scope fairly precisely, and then decomposing it into a Work Breakdown Structure (WBS). Once the scope has been defined down to the Work Package level, the estimators, schedulers, or both are brought in to excessively pester the WP managers as to (in the case of the former) which resources are going to be needed to complete the activity, and (for the latter) how long it’s expected to take, which activities need to be completed prior to the start of the one under the microscope, and is the WP manager aware of which activities need this one to complete prior to starting? If both the estimator and scheduler are either not present or not the same person, this is the first opportunity for “baseline integration” to become an issue. Some “experts” will insist that the cost estimate must be derived first, and then loaded into the CPM software for time-phasing. Others will insist that the schedule be established first, and then resources added (from an organization-wide and approved Master Resource Dictionary, no less) to derive the cost estimate. I have seen adults shouting about this very disagreement. No, I am not making this up.
Of course, even if the relevant (and even the irrelevant) parameters of the two baselines line up at the start, this only means the PM’s problems are just starting. You see, most estimating packages assume an annual adjustment to rates to accommodate inflation; however, Master Resource Dictionaries can be updated at any time, usually quarterly. After three months, the cost estimate as represented in the estimators’ version of the Cost Baseline suddenly doesn’t exactly match the time-phased budget as represented in the Schedule Baseline. The baselines aren’t integrated! It’s PM Armageddon!
If GTIM Nation thinks this is an absurd state of affairs, wait ‘til I tell you about what happens when a Baseline Change Proposal (BCP) is submitted. Assuming the BCP is reasonable, its changes to the Cost and Schedule Baselines are expected to happen almost immediately. This means an almost instantaneous and thorough update to those documents that retain information on the affected Work Packages, and the Cost Accounts that they impact, on up the WBS chain. A short list of these documents includes:
- The affected WPs themselves, including
- Scope description
- Cost estimate
- Schedule parameters
- Selected method of ascertaining percent complete
- Their “parent” Control Accounts
- The WBS Dictionary
- The risk management plan
- The Change Control Log
- The Contingency Budget (if applicable)
- Cost Performance Reports
- Schedule updates
- Variance Analysis Reports…
…and I’m not joking about this being the short list. The kicker? None of it changes cost and schedule performance system quality. None of it. I can prove it.
Let’s do a little thought experiment, shall we? Posit that a project has both a Cost Baseline and a Schedule Baseline, loaded into an EVMS and CPM software, respectively. But, while these two software platforms could communicate with each other, they don’t, because the head of the Cost Performance analysts can’t stand the head of the Schedulers, and vice versa. Let’s further assume that the Earned Value baseline is wildly optimistic, with its Estimators placing the Budget at Completion at $5M (USD). In reality, the project will come in at $10M, but the Cost guys are spending too much time pranking the Accountants, and can’t be bothered to cross-reference their estimates. Conversely, the Schedulers are spot-on with their original Critical Path Network, and show a project completion date of the Start Milestone plus one year. The baselines aren’t even remotely “integrated,” and any comparison of their parameters will quickly reveal this.
So, our little thought experiment project gets underway, and three months along both the Cost and Schedule teams pull status (i.e., glean the percent complete of each WP from their managers). Everybody’s on-schedule, so the overall project’s percent complete is compiled at 25%. Since 25% of the project’s actual time has gone by, the Schedule Team doesn’t have to explain any surprises. Conversely, the Cost Team is comparing their Earned Value (BAC * % Complete, $5M * 0.25, or $1.25M) against a cumulative actual cost of $2.5M. Flawed as it is, the Cost Baseline is now reflecting an Estimate at Completion, based on the derived Cost Performance Index of 0.5, of an overrun of $5M, accurately forecasting the $10M total cost. The fact that the Cost Baseline and Schedule Baseline were wildly inconsistent with each other had no impact whatsoever on each system’s ability to predict the projects ultimate at-completion parameters. Indeed, to assert that the baselines must be in complete agreement is to insist that an EVMS and a CPM Schedule Network cannot be independently operating on the same project, which is clearly absurd.
Now, don’t get me wrong – I’m not saying that the Cost and Schedule Baselines ought not to be completely consistent with each other. What I am saying, though, is that, should they disagree in part (or even entirely), it does not represent a cataclysmic loss of system quality.