Project Management as an Asset Delivery Option The set of high-level sequence of activities, referred to as processes and now collectively known as project management, has been employed for product development for well over 6,000 years. Ancient examples include stone and metal tools and weapons in addition to fire and the wheel. Evidence for the project management processes, which are different from the "scientific method" in so far as they do not repeat, but have a defined start and a defined end, have been around for at least 5,000 years. Examples include Stonehenge, the Pyramids of Giza, Great Wall of China, the Cathedrals of Europe, the Suez and Panama Canals and include the Burj Khalifa and Saudi Arabia's Kingdom Tower. At the very highest level of detail, there is near universal agreement that there are five processes for every project, namely:
- Initiation
- Planning
- Executing
- Controlling and;
- Closing
Worth noting is that these processes are not just unique to Projects. These same high-level processes apply at each phase of the Asset Life span, they apply for each and every project, and they eventually apply down to the Control Account and even the Work Package and Activity Level. The actual documentation to initiate, plan, execute, control and close at each level, changes depending on the level of granularity. In other words, these processes repeat at all levels (granularity) from the highest levels of the WBS down to the lowest levels, even though they are different in content at each level. This is another feature that the PMBOK Guide has somehow glossed over, but that the Guild of Project Controls has recognized and explained. Figure 11 shows how the five processes relate to one another as a group. We also know that not only is there considerable confusion between the process groupings and the phases of the asset life span. More importantly, at the level where the work is actually executed, the processes to "Initiate, Plan, Execute, Control and Close", as a control account or work package, are very different from one another. Take for example, the processes to "initiate, plan, execute, control and close" a commercial flight from City A to City B, which is the classic example of projectized operations. This is not even close to the processes to "initiate, plan, execute, control and close" the removal of an inflamed appendix, another example of projectized operations, let alone the "engineering, procurement and construction" (EPC) of a new bridge. The processes at the level where the work actually happens are also "unique" for a given application, or context. This means that project management, at this level is obviously not a transferable skill set. The processes to design, procure and construct a bridge are not going to help the pilot who is responsible for conducting his/her preflight requirements, take off and navigate the plane to its destination, and then close out the flight plan upon arrival. Looking again at Figure 8, another important point worth reiterating is that the project management processes are already embedded into the training to become a doctor, lawyer, engineer, teacher, carpenter, electrician, plumber, butcher, baker or candlestick maker. Therefore, what sense does it make to provide training only in project management unless that training is application or context specific? Put another way, who in their right mind would believe that just because an individual was a great IT project manager that he/she could become the project manager to engineer, procure and construct a bridge? Surely the absurdity of that should be self-evident? Or, to drive home the point, would you hire an IT project manager to build your dream home because he/she was successful in the world of IT. Or would you seek out a contractor or construction project manager, with a track record of building the kind of homes you were looking for? To summarize, the tools and techniques may be similar, but the processes telling us when and how to use the tools and techniques are application or context specific. This means that project management cannot and should not be viewed as a generic skill set, and project management training, competency development, assessment and certification, licensing or credentialing should be viewed in that context. At some point, we need to forget the marketing hype and promises from the various professional societies and apply some "common sense".
17. Guild of Project Controls (n.d.) Module 1, Figure 12, last accessed 02/10/2019 planningplanet.com/guild/gpccar/introduction-to-managing-project-controls.
|
"Trial and Error", "Scientific Method", or "Agile"
