Beaten To Death By Butterfly’s Wings

 

In blogs published earlier this month, I asserted that Program Management was more than just up-scaled Project Management. Probably the best proof of that premise has to do with the metaphorical first thing that Project Managers do versus what Program Managers do: the first thing the Project Manager does is create a Work Breakdown Structure (WBS) by systemically decomposing the project’s scope. The first thing the Program manager does is assemble similar projects into a portfolio where those projects can be coordinated on the basis of resource needs, customer/ market share strategy, and the use of acquired technology or expertise in performing analogous work. By definition, then, the work of decomposing the scope into a WBS and the work of assembling Scopes of Work (SOWs) into a portfolio (tearing apart vs. putting together) are very different, if not polar opposites.

This dichotomy has several implications for the new Program Manager, not the least of which has to do with Metcalf’s Law. Metcalf’s Law, also known as the Butterfly Effect, is the idea that, in large networks with many nodes, small variations in some nodes can have a cascading effect on the entire network, leading to very large (or even cataclysmic) impacts on nodes relatively distant from them. Its common interpretation is captured by the question “If a butterfly flaps its wings in Brazil, does that cause a hurricane in Texas?” (hence the nickname “Butterfly Effect.”)

The Project Manager has some tools to deal with this phenomena that don’t necessarily work well at the Program level. For example, once the project’s scope is decomposed into the WBS, the WBS index serves as the structure for re-assembling it. The work’s cost and duration are estimated, based on the scope description at the lowest level of the WBS. In addition to duration estimates, the professional Project Manager will define the schedule logic – which activities need other activities to be completed prior to starting – and load the whole shebang into a Critical Path Methodology software package. With the project’s critical path calculated, the PM becomes informed of which activities, even small ones, if delayed, will push out the overall project’s completion date, just as the Earned Value system informs her of which activities are in resource difficulties, and are potential candidates for help from the project’s reserves.

The following mental exercise is bit layered, but follow me on it. On Project A, an activity on the critical path goes long, and pushes out a subsequent activity that requires a specific set of personnel and equipment unique to the organization. Project B was counting on these same personnel and equipment, and had scheduled the same one week after Project A was supposed to be done with them. With Project A’s delays, suddenly both of these projects need the same personnel and equipment at the same time. Unless these projects’ schedules, both baseline and status, are in the same CPM engine, this salient little fact won’t come up unless some insightful project controls specialist recognizes it, and alerts their PMs. Without some accommodation, now both projects are in danger of coming in late.

Consider that the previous example was based on a problem that is nominally tracked in Project Management software. What do you suppose happens in those instances where the cause-and-effect chain is not nearly as linear as the version captured in critical path methodology? One example that pops to mind has to do with the customers involved in the previous example. The Program Manager, who has near-miraculously been warned of the impending project conflict by our intrepid project controls specialist, thinks he has a solution that will minimize the negative schedule variance inherent in the double-booked resources, with each project taking a 5% hit, perceived as recoverable by each project, if nothing else goes wrong. However, as his attention is drawn to ensuring that both Projects A and B pursue schedule recovery, he fails to realize that Project A’s scope is something of a one-off, unlikely to lead to similar work, whereas Project B’s scope is ground-breaking, and good performance could easily lead to more and bigger projects being let in the same arena. Levelling the negative schedule hit among the two projects has suddenly morphed from an optimal solution to the second-worst, with having Project B taking the entire hit being the worst (note how, had our intrepid project controls specialist not notified the Program Manager of the conflict, this would have been the default strategy).

Also note how this particular example is really not that complicated. In reality, the number of parameters and data points, both knowable and not, that could easily render a given strategy completely useless (if not actually destructive) increases geometrically as the projects are assembled into programs. As noted in our example, market share considerations rarely enter into the typical Control Account Manager’s (CAM’s) day-to-day decision-making, but to ignore them is fatal to your typical Program Manager. And that’s just one threat among many.

Despite what the risk management-types will tell you, it is impossible to get out in front of the nature of the cascading effects of Metcalf’s Law; and, even if it were possible, stochastic ranges and confidence intervals are utterly useless pieces of information. The logical approach is to develop a robustness of response for those instances where events unfold in such a way as to add difficulties to attaining your projects’ – and your program’s – goals.

The only alternative is to remain vulnerable to the potentially devastating effects of butterfly’s wings.