The Unruly Spawn of Change Control

 

According to a paper by Michael Bloch, Sven Blumberg, and Jurgen Laartz, large Information Technology projects run 45% over budget, are 7% late, and deliver 56% less value than predicted.[i] Kind of reminds me of a couple of my nieces and nephews. Anyone familiar with IT project management has little reason to doubt their findings – many so-called traditional project management techniques seemed to lose at least some level of efficacy, just as traditional parenting techniques tend to fail when employed with a certain type of child. When they were originally introduced to software project management, Change Control techniques seemed an odd fit, not because of the failings of the techniques, but due to the unruly nature of IT projects.

In traditional project management, when a contractor sets out to build a building, ship, airplane, dam, or what have you, the original baseline with its three components – scope, cost, and schedule – were pretty much assumed to be an accurate capture of the project’s outcome, expressed in terms of deliverables, resources needed to meet those deliverables, and how long it would take, respectively. However, when IT projects began to grow in size and complexity, this otherwise useful premise simply had to be discarded. With few exceptions, software engineers could not have a crystal-clear, detailed vision of what their end-products would be like by the time they hit the commercial market. Software developers who had hoped their code would end up in an Ivy League school’s research lab could end up seeing entire blocks of it in graphic shoot-‘em-up games. Even software projects with relatively stable formulaic or quantification underpinnings would be susceptible to variances in available data feeds, or more intuitive ways to convey their outputs, not to mention considerations for the people who were actually hands-on-keyboards, using these systems. Something had to be done about Change Control.

So, along came the Agile and Scrum variants of project management. The interesting thing about Agile/Scrum is that the first element of traditional PM they discarded was traditional parenting (strikethrough) Change Control. In an project environment where the scope could be expected to change dynamically, the old process of writing up a change control notice or Baseline Change Proposal, documenting the precise nature of the change to each of the three baselines, complete with before and after resource-loaded Gantt Charts, and submitting such a package to the several tiers of approval was simply too staid to be workable. Instead, changes could be proposed, evaluated, approved, and set into motion in the course of a single daily meeting. It was as if the two kids could get away with disobeying, the one because the parents couldn’t catch them (Agile), and the other because all of the kids in the house were engaged in the exact same Change Control-defying behavior, and the parents (strikethrough) traditional PMs were outnumbered (Scrum). Problem solved, right?

Well, not so fast. With a lessening of the rigor involved in changing the baseline, the PM’s worst enemy, scope creep, had far more opportunities to encroach upon (and subsequently ruin) IT projects.  Why? Because once everybody was okay with – let’s call it what it is – rubber baselines, the next legacy element of PM that could be dispensed with, cost and schedule performance systems, was also soon dispensed with. It’s really too bad, too, since it didn’t have to be that way. I actually did a webinar for PMI’s IT Special Interest Group (IT-SIG), in August of 2008, on how Earned Value Management Systems could be easily upgraded to keep up with an Agile/Scrum project.

From where I’m seeing these trends, the answer, I believe, is to update the Earned Value and schedule performance measurement systems to be applicable to rubber baselines (strikethrough) Agile/Scrum projects, so that their at-completion cost and schedule forecasts can come in to play. If the IT project so engaged is on a path to overruns or delays, the PM can know about it in time to do something about it. If not, she knows she has some latitude to indulge scope creep (strikethrough) dynamic changes to the scope baseline before overruns or delays become likely.

And, lastly, the parents will know in time to respond when their unruly kids are headed towards the tattoo parlor.