Project Management

Agile Approach, Or Rubber Baseline?

From the Game Theory in Management Blog
Modelling Business Decisions and their Consequences

About this Blog


Recent Posts

This Blog Is Exactly Like (Strikethrough) Kinda Like (Strikethrough) Sorta Like…

“Elementary, Dear PMP® Holder”

Mighty Morphin Power Skills

Innovation: The Ultimate Change Agent

Change Control Anomalies Baked Into The PM Cake

I’m old enough to remember when risk management (no initial caps) first wormed made its way into mainstream PM guidance. One of its funniest manifestations was an assertion that, if a given project could assert that it was really, really not risky, then many of the conventional Cost/Schedule performance measurement systems should then be considered superfluous, and therefore not mandated for government work. Of course, non-risky work didn’t need all of that high falutin’ risk analysis performed, at least when it came to making the case for the imposed level of rigor of the Project Management Information Systems (PMISs) applied to the work. Essentially, the early forays of risk management (no initial caps) into the PM world worked to undermine its overall utility, a vehicle for sending those pesky Critical Path and Earned Value zealots packing.

Flash forward to the introduction of Agile/Scrum Project Management. I believe that one of the main reasons that Agile/Scrum received such quick and broad acceptance in the Information Technology (IT) PM world was due to the fact that it addressed a widespread problem in that arena, that conventional configuration management/ change control techniques were inadequate for software engineering scope. A typical Baseline Change Control Board, made up of senior project and customer managers, would meet only once per month. Then, if a Baseline Change Proposal/Request (BCP/BCR) wasn’t considered acceptable by every member of the BCCB, it would be back to the proverbial drawing board to address the concerns of the Board, and a re-submission, to be considered next month. Agile/Scrum represented a way around such an ossified process. The people who were in a position to approve relatively minor baseline changes – the kind that happen all the time in IT projects – could do so in near real-time, and the new scope could be pursued in a far timelier manner, all without inviting the stigma of having a rubber baseline.

What’s a “rubber baseline?” It’s the bugaboo of us traditional PMs, the equivalent of this line from Shakespeare’s Henry VI, Part I:

Is this the Talbot, so much feared abroad
That with his name the mothers still their babes?

To have a rubber baseline means that you can change cost, or schedule, or (by implication) scope informally, almost at will. Variances magically go away, and, with them, the integrity of your project’s cost/schedule measurement systems. To the generation of PMs who still think that quoting Shakespeare is hip, to unknowingly engage a rubber baseline is to self-identify as completely inept, and to do so knowingly is to “smile, and smile, and be a villain.” (Hamlet, Act I, sc. V).

Interestingly, even though Agile/Scrum was originally developed for Information Technology projects, many other sectors have adapted it, including manufacturing. Even so, this approach may not have delivered on its highly-touted potential. According to one source, 75% of IT executives believe that their projects are “doomed from the start.”[i] Naturally, one has to wonder what the proximate cause of this sense of inevitable doom could be – is it hardware? Lack of talented personnel? Sub-standard coffee delivery service? Or could it be … the Project Management approach?

Since both Agile/Scrum and the implementation of a rubber baseline have in common a weakening (or even elimination) of the Configuration Management/Baseline Change Control process, what could we say separates, or distinguishes them? Let’s use the Game Theorists’ favorite tool, the payoff grid:


PM is Virtuous

PM is Villainous

Appropriate Agile/Scrum

1A: It’s all good.

1B: No needed oversight, meaning real mischief.

Rubber Baseline

2A: PM is inept, if he’s “virtuous” but using a rubber baseline.

2B: Massive potential for massive chicanery.

Members of GTIM Nation will quickly observe that the only okay scenario here is 1A. All of the others represent trouble, either because the project is being run by someone who doesn’t have the awareness that he shouldn’t be using a rubber baseline and, therefore, is likely to crash the project based on sheer ineptitude, or because he’s a villain who has successfully circumvented the very cost/schedule performance measurement systems that would alert his superiors when the project is in trouble. Don’t misunderstand – I’m not arguing against the use of Agile/Scrum in all cases. The brutal truth of the matter is that traditional approaches to maintaining baseline integrity had become moribund for projects being executed in a fast-moving environment, like Information Technology, and some change had to come on this front in order to keep PM relevant in those business situations.

But to remove all of the guardrails of traditional Configuration Management/Change Control, in the name of granting the PM more latitude of action, simply invites a management environment where “you’ll never find a more wretched hive of scum and villainy.” (Yeah, that’s from Star Wars. Were you expecting more Shakespeare?)

[i] Retrieved from on January 12, 2022, 16:47 MST.

Posted on: January 12, 2022 08:32 PM | Permalink

Comments (2)

Please login or join to subscribe to this item
Agile/Scrum and the implementation of a rubber baseline have advantages of flexibility in projects with fuzzy parameters like mining projects with geological incongruence. The projects should be completed within budget and schedule.

Please Login/Register to leave a comment.


"It's kind of fun to do the impossible."

- Walt Disney