Project Scuedules Are Still Monolithic Code

A mature approach to project interdependencies is required Thesis A mature approach to project interdependencies is required today, over and above the well-known issues of resource leveling. Syllogism Schedules start with estimates. Usually these are highly arbitrary, inaccurate, and typically underestimated. Effort is a number often pulled out of the air, due to constraints of time to prepare and a keen eye toward winning the bid. Multiple organisations involved in any single delivery will have process dependencies among them. Each organisation has only part of the overall schedule Organisations do not communicate well between each other. This becomes worse when the organisations are separate companies. Organisations do not communicate issues well among each other, often concealing issues until it is too late for the other organisation to plan for change. Thus when schedules slip, it often comes as an unpleasant surprise. The higher you go in an organisation, the greater the surprise. During the process of each organisation’s independent view of the overall schedule, the business sponsors will refine their needs by approving changes to scope (change requests). These are typically sensitive to the business case (e.g. opportunity cost), but not sensitive to impact on delivery schedule. Engineers (used in the general sense) refine the estimates as they discover more detail about the project requirements. Administrators refine their view of the schedule by adding more deliverable documents. Human churn will refine the schedule by impacting the validity of estimates of required effort, adding time for recruitment and learning effort. Therefore Schedule dependencies and inter-group communications costs always increase at a hidden rate, to the point where the difference between baseline and schedule is not only broadly skewed, but becomes perceived as difficult (if not impossible) to correlate the two or to forecast a result. Commentary This makes executives edgy and desirous of outsourcing anything they possibly can, in the interests of being able to fix their costs and not spend valuable executive calendar space on non-core items. Whereas this seems like a good idea to the leather-chair set, it is not the best way to contain costs and can make delivery even harder to predict. Project schedules are, in fact, in a state analogous to the development of computer program code in the 1960’s, before the structured techniques permitted control over the logarithmic expansion of costs that monolithic programs imposed in both development and maintenance. Just as multiple programmers would have to edit a shared program in the past (think – no modules, just cut a bit here, add a bit there… then go through the nightmare of regression testing) modern project managers have to integrate a number of disparate development schedules into one single monolithic structure based on a common calendar that all must share. All the issues mentioned in the syllogism above that skew projects – let’s call them DC (Dependencies and Communications) are having the same effect as the dreaded GOTO had on the monolithic program code of the past. They make the overall project a very uneven affair, fraught with crises, unhappy employees and unhappy executives and costs that often expire the business case before anyone realises they’ve been had. Similarly to the monolithic code metaphor, different organisations will have their own fragments of the overall schedule to manage. There will be overlap as they apply faulty or out of date estimates they suspect the other organisation will apply (if they think of it a all, which is not as common an event as one would wish) . Inaccuracies become project noise, just like unfactored code becomes noise in a program. To solve the issue with code, engineers changed the way they did business. Monolithic code evolved into modular code, which evolved into structured code, which evolved into object-oriented development. The imposition of refinements in structure evolved to the point where people could bang out a good piece of code in a very short time, knowing they would not be putting other bits of code out of joint in the process. Can we say that about today’s project management schedules? No, we cannot. We have applied some structure, some templating, some controls, but in the large view we’re still doing the equivalent of many hands editing the same program listing. Tasks are very similar to lines of code. Let’s continue the metaphor, shall we? Imagine if we could apply the evolution Monolithic-->Modular-->Structured-->OOD to project schedules… would we be able to achieve the same economies of project delivery that the coders evolved? Imagine little boxcars as below, each schedule element containing many task steps, all running on the common rail of the calendar. Let’s ignore parallelism at the moment, although that can be accommodated by the model: [Sched1]..DC..[Sched2]..DC...[Schedn] --O—O-- --O—O-- --O—O-- <--Note the clever ascii wheel graphics ;-) I’d like to call these individual schedule fragments “Boxcars”[1]. The metaphor still holds true if you consider the coupling between each Boxcar as a highly elastic set of forces that send sinusoidal impacts back and forth up and down the line, similar to the starting of a large train with lots of differently weighted rolling stock. It’s always chaotic as you first start. Get the balance wrong, or the couplings too elastic and the resonances never stop and throughout the entire journey enormous amounts of energy are used up changing direction. I told you the metaphor held up, didn’t I? It still works even if you have multiple tracks. You just add couplings side to side, and the whole complex rubber-bands its way forward. It would be much easier, more subject to control, if you simplified the couplings a bit, wouldn't it? Would it be possible to move project schedules down the same path as structured code went, to modular schedules, structured schedules, or further refinements in structure? I think it's worth thinking about what sort of structure would improve the decomposition of the grand schedule, would improve the communications between the disparate elements. So think about it. Call it the Boxcar Approach for want of something better. [1] In respect to the seminal work of IT humour by the Firesign Theatre, “I Think We’re All Bozos On This Bus”. Don't know when it was copyrighted, but it was, and it was published somewhere in the punch-card era. It will be in some boomer's record collection.