The Change Control Canary In The PM Coal Mine

 

This blog’s title, of course, refers to the pre-1986 (!) practice of keeping caged canaries in coal mines to serve as detectors of carbon monoxide or other dangerous gasses[i]. The canaries would pass out or die before the humans, serving as an indicator that immediate evacuation was called for, and leading to its clichéd use as a critical leading indicator of something potentially really bad being imminent.

Meanwhile, Back In The Project Management World…

So, what can a cursory review of the development of Change Control (ProjectManagement.com’s theme for November) over the years tell us about macro-trends in Project Management guidance? Plenty. Consider first my oft-stated three criteria for PM Information System’s output to be valid:

• The information must be timely. Old management information ages like milk.
• It must be accurate. Inaccurate management information is worse than useless, since it can actually be misleading.
• Finally, it must be relevant. Any energy or time devoted to collecting the data, processing it into irrelevant information, and delivering said irrelevant information is not only wasted, but could have been used pursuing its valid, relevant counterpart.

Now consider what happens when an ossified, overburdened Change Control process actually processes a Baseline Change Proposal/Request (BCP/BCR). Baseline Change Control Boards (BCCBs), which typically meet monthly, review the BCPs submitted to them, including the plausibility of the reasons given for the change, the reasonableness of the new cost and schedule estimates, and any other particulars that go into such go/no go decisions. If any of the above proves unsatisfactory, the proposing contractor has essentially one of two choices: clean up the verbiage and numbers in the BCP, and re-submit for next month, or continue to manage on the existing, unchanged baseline. I think it’s safe to say that a mutual understanding between the customer and contractor of the scope, cost, and schedule baselines meets my third criterion, and is highly relevant. So, what does the rejected BCP scenario mean for the other two criteria for our PM Information Systems? It damages system validity, since having to re-submit the BCP next month means that the performance data stemming from the at-least-somewhat obsolete baseline isn’t going to be timely, and continuing to manage against a baseline that should have been changed already means that its performance data won’t be accurate.

I also think it’s safe to say that this no-win scenario in the conduct of many BCCBs led to perhaps the biggest deviation from traditional PM practices represented in Agile/Scrum, which really doesn’t have Baseline Change Control “Boards” per se. By assigning specific roles and processes to classes of PM participants from both the contractor and client sides of IT Projects during daily meetings, Agile/Scrum allows for formal, documented, and approved near-real-time changes to the projects’ baselines. Interestingly, Information Technology (IT) projects led the way in Agile/Scrum development and adaptation, probably stemming from the report that up to 45% of them overrun.[ii] When you are in an industry where 45% of project work comes in over-budget, and you develop an advancement to PM science to address this pressing issue, and one of the first and biggest changes you make to the whole PM shebang is to do away with the traditional Baseline Change Control Board, including the overall Change Control process, what does that say about the state that said Change Control process had attained? What it tells me is that this was one area where traditional PM practices had become so overburdened with rules and guidance that it was becoming a hinderance to successful project execution, at least for IT projects.

So, if we use the areas where Agile/Scrum deviated from the more traditional PM techniques and approaches as a leading indicator of where those traditional techniques and approaches may have become moribund, or even obsolete, what are some of the other areas where such deviations took place? Long-time members of GTIM Nation know where I’m headed with this: Agile/Scrum does not have a risk management (no initial caps) component. (Incidentally, on a lark I did an internet search on the term “risk management (no initial caps),” and had a good laugh when this blog came up as the fifth hit.) My takeaway from all this is that, if traditional PM approaches and techniques taken as a whole wish to become more useful and widely embraced, two great places to start would be to streamline the Change Control process, and minimize the risk management (no initial caps) stuff in its entirety.

‘Cuz who wants to share a mine shaft with a dead canary?

[i] See https://www.smithsonianmag.com/smart-news/story-real-canary-coal-mine-180961570/.

[ii] Retrieved from https://www.mckinsey.com/business-functions/mckinsey-digital/our-insights/delivering-large-scale-it-projects-on-time-on-budget-and-on-value on November 29, 2020, 20:53 MST.