Back in early to mid-1990s, when NSFNET was making the transition to the modern internet, I was just finishing up my second assignment as an IT project manager and transitioning to a full-blown Program Executive Office (PEO) Business Manager and CIO at a major Naval Systems Command. The expanded potential of a more open internet was on everyone’s mind and, on the positive side, on how barriers to previously stove-piped data could be broken down in order to drive optimization of the use of that data (after processing it into useable intelligence). The next step was then to use that information, which was opened to a larger audience that previously was excluded from it, and to juxtapose and integrate it with other essential data (processed into intelligence) to provide insights not previously realized.
Here we are almost 20 years later and I am disappointed to see in practice that the old barriers to information optimization still exist in many places where technology should have long ago broken this mindset. Recently I have discussed cases at conferences and among PM professionals where the Performance Management Baseline (PMB), that is, the plan that is used to measure financial value of the work performed, is constructed separately from and without reference to the Integrated Master Schedule (IMS) until well after the fact. This is a challenge to common sense.
Project management is based on the translation of a contract specification into a plan to build something. The basic steps after many years of professional development are so tried and true that it should be rote at this point: Integrated Master Plan (IMP) –> Integrated Master Schedule (IMS) with Schedule Risk Assessment (SRA) –> Resource assignments with negotiated rates –> Develop work packages, link to financials, and roll-up of WBS –> Performance Management Baseline (PMB). The arrows represent the relationships between the elements. Feel free to adjust semantics and add additional items to the process such as a technical performance baseline, testing and evaluation plans, systems descriptions to ensure traceability, milestone tracking, etc. But the basic elements of project planning and execution pretty much remain the same–that’s all there is folks. The complexity and time spent to go through the steps varies based on the complexity of the scope being undertaken. For a long-term project involving billions or millions of dollars the interrelationships and supporting documentation is quite involved, for short-term efforts the process may be in mental process of the person doing the job. But in the end, regardless of terminology, these are the basic elements of PM.
When one breaks this cycle and decides to build each of the elements independently from the other it is akin to building a bridge in sections without using an overarching plan. Result: it’s not going to meet in the center. One can argue that it is perfectly fine to build the PMB concurrent with the IMS if the former is informed by the latter. But in practice I find that this is rarely the case. So what we have, then, is a case where a bridge is imperfectly matched when the two sections meet in the middle requiring constant readjustment and realignment. Furthermore, the manner in which the schedule activities are aligned with the budget vary from project to project, even within the same organization. So not only do we not use a common plan in building our notional bridge, we decide to avoid standardization of bolts and connectors too, just to make it that more interesting.
The last defense in this sub-optimized environment is: well, if we are adjusting it every month through the project team what difference does it make? Isn’t this integration nonetheless? Response #1: No. Response #2: THIS-IS-THE-CHALLENGE-THAT-DIGITAL-SYSTEMS-ARE-DESIGNED-TO-OVERCOME. The reason why this is not integration is because it simultaneously ignores the lessons learned in the SRA and prevents insights gained through optimization. If our planning documents are contingent on a month-to-month basis then the performance measured against them is of little value and always open to question, and not just on the margins. Furthermore, utilization of valuable project management personnel on performing what is essentially clerical work in today’s environment is indefensible. If there are economic incentives for doing this it is time for project stakeholders and policymakers to end them.
It is time to break down the artificial barriers that define cost and schedule analysts. Either you know project and program management or you don’t. There is no magic wall between the two disciplines, given that one cannot exist without the other. Furthermore, more standardization, not less, is called for. For anyone who has tried to decipher schedules where smiley-faces, and non-standard and multiple structures are in use in the same schedule, which defy reference to a cost control account, it is clear that both the consulting and project management communities are failing to instill professionalism.
Otherwise, as in my title, it’s like knocking on wood.