“Are You A Good Disruptive Influence, Or A Bad Disruptive Influence?” (Munchkins giggle)

 

To continue to paraphrase the Wizard of Oz near-quote above, Dorothy’s answer in the PM universe would be “I’m not a disruptive influence at all! Disruptive influences are old and ugly!” (more munchkin giggling). Of course, Glenda goes on to educate Dorothy on the subject of moral duality in the near-locales of the Emerald City, which is something she will need to understand for the rest of the movie. I would like to do something analogous with GTIM Nation, just not with Glenda’s maddeningly sugary voice and inflection.

Naturally your typical PM will seek to avoid disruptions in their projects – unfortunately, disruptions are part and parcel of the profession, and it’s the PM’s job to deal effectively with them. But, much like witches in Oz, not all disruptions should be assumed to be wicked. I’m willing to bet that more than a few of my readers have been involved with projects where the technical approach to the scope was sub-optimal (or maybe even wretched in the extreme), but management was convinced it was the only way to perform the work. They launched the project with enthusiasm and energy, but even early on there were signs that things might not go as planned. Some conflicts within the team emerged, but were viewed as being a natural part of the Forming – Storming – Norming – Performing cycle. A few activities then started falling behind, but they were within the variance threshold, so no executive action was invoked. Quick question (#1): are these trends representative of a good disruptive influence, or a bad one? Don’t answer right now, but we’ll return here in a moment.

Then, something more dramatic happened: a senior technical project team member abruptly left after an altercation with the PM. The rest of the team hated to see her leave, but the separation was described in an e-mail blast as her “pursuing other opportunities.” I’ll pose the question again (#2): was this incident a good disruptive influence, or a bad one? Again, don’t answer yet.

After a few months a rookie Project Controller, naïve in the nature of office politics, calculates the Variance At Completion at more than 25% over budget, and announces the same at the project review where a senior manager is in attendance. This senior manager asks to see the Variance Analysis Report, which happens to be chocked-full of fluff terms and meaningless jargon; nor does it offer a succinct get-well plan. Again, the question (#3): is this a good or bad disruptive influence?

The exec, who has been around more than a few similar projects, calls for an immediate review of the cost/schedule performance data, even as the PM insists that the variances can be made to go away with a Baseline Change Proposal – or two, or maybe even, at the outside, three. In the historical data he sees that the poorly performing tasks have been showing difficulty for some time, but only recently broke the Variance Analysis Threshold, leading to the anodyne VAR. And, most telling of all, the recently-departed senior technician had been the Control Account Manager (CAM) for the activity. Is this (#4) a good disruption?

Now a risk event strikes the project, one that was thoroughly described in the risk analysis, and has had an impact consistent with that analysis. The Configuration Manager files a contingency BCR, and it is being reviewed by the Baseline Change Control Board. However, the customer’s representative on the board isn’t sure that this incident is risk-based, but might be caused by poor performance, and is slow-walking the BCR. Same question (#5).

Finally, the troubled task impacts the critical path, and the entire project’s forecast completion date is pushed back. The calculated Estimate at Completion (EAC) remains stubbornly at the 25% overrun mark, and it can’t be BCRed away as the project passes the 50% complete mark, as complete spent tops 62%. At this point the project is clearly in trouble. Here are my two questions: (1) which disruptors were to blame? And, (2) which ones were “bad,” and which were “good”?

The project was undertaken with a poor technical approach, which meant that it was probably doomed from the start. The following “disruptors” had, as their material (if not proximate) cause, this wrong-headed approach: disruptions 1 – 4 should be considered good, since they were pointing at the bad initial technical approach. The savvy PM would not have attempted to minimize or hide the causes underlying these disruptions; instead, he would have heeded the information they conveyed, re-evaluated whether or not the selected project strategy was the right one and, if it wasn’t, immediately entertained and/or employed alternatives. Disruptor #5 was the only bad one, coming, as it did, at the time that the project team was least able to isolate its negative impact as a causal factor of the overall project’s woes. Nor did Disruptor #5 provide any information or insight as to what the best approach alternative might be, since most catalogued risk events are generic enough (bad weather, increased vendor costs, etc.) to happen to any project, regardless of the efficacy of the selected technical approach, though one could easily argue that the demonstrably wrong approach significantly increases the odds of a project-ruining event.

After the Wicked Witch of the East experiences the disruptive influence of having Dorothy’s house fall on her, Glenda, being a “good witch,” advises Dorothy to “follow the yellow brick road.” This little piece of advice is repeated an additional fifteen times (by my count) prior to Dorothy arriving at a crossroads and meeting the Scarecrow. Here’s my challenge: decide now how many good disruptive influences will happen on your project before you accept the information they convey, and evaluate alternatives to your approach.

It just might save you an encounter with flying monkeys.