Project management is not project management is not project management

Abstract

A Guide to the Project Management Body of Knowledge (PMBOK Guide®) explains project processes at the 50,000 meter level. At a more detailed level processes change radically. The construction industry has been doing project management longer than any other industry. What can they teach Information Technology (IT)? IT has developed new approaches. What can they teach construction? What can aerospace teach the others, and what can they learn?

Background

Effective project management processes are developed to work around the constraints in every industry and to take advantage of what is easy to do. In the construction industry, the overall requirements are developed by the architect who designs a product that satisfies the client requirements. The detailed engineering requirements are then derived from the architectural requirements and the resulting structure, e.g. building, bridge, road, hospital, or mall is built to those detailed specifications. Overlapping phases of design and construction are sometimes used, though with varying success rates. In construction and oil & gas, the waterfall approach works fairly well. You cannot add an additional 10 stories to the top of a building after construction has begun (although people have tried).

In IT, change requests are “easy” to implement, and since the advent of the internet, a waterfall planning approach has consistently failed. So IT project managers have taken to more agile methods, where cycles are much shorter and the users are brought in as much as possible for feedback.

In aerospace, much major development pushes the envelope on what is technically possible. Project management approaches must deal with highly risky development and manage project execution when some technology development simply doesn’t work. Many aerospace projects are done incrementally, with subsequent development projects dependent on how successful earlier projects were. What can project managers from IT, construction, oil & gas and aerospace learn from each other? That is the question this paper will address.

Commonality of All Project Practices

The nine knowledge areas of the PMBOK Guide® should be applied to any project, whether in construction, oil & gas, information technology, or aerospace. For large projects in any of these domains, the Program Standard should also be applied as these “projects” are usually programs. The $10B Jubail Export Refinery project that Saudi Aramco and Total France are developing now is truly a program and not a project. The Program Standard references the PMBOK Guide® Project Standard knowledge areas where applicable, so the PMBOK Guide® should be viewed as fundamental for projects and programs. The fourth edition of the PMBOK Guide® includes a process for requirements collection, and as we shall see, this process varies substantially among the different domains in real life.

Of course there are key variations among projects in different domains. In IT software projects, there is often relatively little procurement, and the largest cost is technical resources. In software and hardware projects, there is a need for systematic testing, an area not addressed by the PMBOK Guide®. A leading practice is to use IEEE (Institute of Electrical and Electronics Engineers) 829 for Software Testing as a supplement. (Snyder, Parth, 2007)

In construction and oil & gas, there are extensions to the PMBOK Guide® that provide guidance in the management of Claims, Financial, Safety, and Environmental. Management of these areas are critical to the success of any construction program, whether a commercial building or an oil refinery. There are also a few additional project management processes for construction.

All domains require varying levels of integration. In aerospace, systems engineers perform this work. They may also identify gaps between requirements and resources so that they can be reconciled through effective trade-offs before product development. When multiple firms are used to develop different parts of an aerospace product, a lead systems integrator is designated to coordinate the overall effort. Similarly, in construction and oil & gas, a lead contractor often directs and integrates the work of other Engineering, Procurement & Construction (EPC) contractors. And in IT, a systems architect leads the overall design to ensure consistency.

Many of the different development approaches we see relate to how easy it is to gather detailed requirements, and how “changeable” those requirements are. In construction we will see that requirements tend to be well-defined early in the project and difficult to change after construction work has begun. In aerospace, the detailed requirements often cannot be defined until an R&D effort has been made to see if the technology is even feasible. In IT, detailed user requirements can be difficult to collect but the users find it easy to change the requirements even late in the development effort.

Constraints - Aerospace

The differences among the different domains in the application of project management is largely a result of the different constraints of each industry. Aerospace is truly “rocket science” so programs push the envelope on technology. This advances the state of the art, but when the technology doesn’t pan out, can result in a high failure rate. The A-12 Avenger program is one of the better known failures, where billions were spent to develop a radar-invisible spy plane, but not even a prototype was developed. It took an analyst skilled with earned value management techniques only one day to figure out the cost curve escalation would quickly eclipse the entire US Navy budget. The Pentagon cancelled the contract with McDonnell Douglas Corporation and the General Dynamics for failing to “design, develop, fabricate, assemble and test the A-12 aircraft within the contract schedule.” (Schmitt, 1991).

The large budgets and funding constraints in aerospace have led to the use of stage gates at specific points: System Definition Review, Preliminary Design Review, and Critical Design Review. These reviews can provide decision-makers with the information in order for them to reliably gauge whether there is a sufficient business case for allow the program to proceed. Exhibit 1 shows the planned timeline for reviews on NASA’s Ares I and Orion Programs. The contractor is Lockheed Martin (GAO, 2008).

Timeline for Ares I and Orion Critical Reviews (in fiscal years)

Exhibit 1: Timeline for Ares I and Orion Critical Reviews (in fiscal years)

If the program is funded by multiple arms of the military, this imposes significant restraints on the project.. Designs are usually compromised if multiple parts of the military are involved because they have competing needs. DIMHRS, the Defense Integrated Military Human Resources System is a perfect example of an effort to consolidate all US Department of Defense military personnel on one Human Resources and pay system. Each branch of the US military utilize different pay and human resource policies. Without harmonization of policies, four systems must be developed rather than a single system. So it is no surprise that after over 12 years, the DIMHRS program is not yet producing paychecks for all 1.4 million active US military personnel. Year-to-year government funding is a significant constraint on a multi-year project as spending cannot exceed the monies appropriated.

Constraints – Construction/Engineering/Oil & Gas

In theory, construction has a solid design approach. The client tells the architect what they want, the architect builds a model defining the specifications, the specifications are then put out for tender, an engineering firm is selected, the firm takes the model and develops detailed engineering and performs the construction. The high-level requirements usually don’t change once work has begun. This is the general rule. Of course, there are exceptions: the Sydney Opera house, Scottish Parliament’s Holyrood building, and the Abu Dhabi National Sports Stadium now being built are prime examples. Variations on the traditional construction approach include “Design-Build” where one firm provides architectural, engineering and construction services and “Construction Manager at Risk”. In “Construction Manager at Risk”, a firm provides consulting services though both design and construction phases, providing communications and continuity from design into construction.

In practice, the approach is often compressed into overlapping phases as shown in Exhibit 2, motivated by the possibility of reduced financing costs, faster occupancy and speedier contractor payments. Multi-year development efforts are subject to changes in the economic environment that may reduce or negate the profitability of the construction product or be subject to the whims of the financial funding entities. For a construction project, reducing the time to market can mean lower risk.

Traditional and Overlapping Phases Approaches in Construction

Exhibit 2: Traditional and Overlapping Phases Approaches in Construction

Megaprojects, exceeding $1 Billion USD, often use multiple contractors from many different countries and the workforce can number in the thousands. The Jubail Export Refinery project has a planned need for 30,000 workers. Larger projects are already being planned. This necessitates development of temporary facilities and managing a heterogeneous unskilled labor force. Climateand weather difficulties add to the challenge.

Constraints – Information Technology

In IT, the technology changes so quickly there is a need to get the product out the door before it is regarded as obsolete. Once the software product is integrated into the business processes of an organization, whether it is obsolete will not be of primary importance. The need for speed has resulted in several techniques: the Agile development method which uses an iterative approach is one. Another approach is software “releases” that provide new functionality. Anyone who uses the browser Firefox, and has had their version “updated” has experienced the phenomenon of releases. Successful IT project durations are likely to be measured in weeks or months rather than years.

A well-designed system often has configuration parameters, allowing changes to be made to how the system operates without new coding. This can provide rapid changes to functionality and business process flexibility.

The downsides in IT include the difficulty in gathering user requirements from multiple users. Most users do not know what they want until they can see something in front of them – and they then determine that what they see is not what they want. This visualization challenge is not limited to users. Project sponsors can also request changes to functionality leading to rework.

Another difficulty is that the labor force is educated in programming but not in formal systems methodologies. Very often developers dislike processes and formal methodologies, viewing them as creative restraint. The challenge for the project manager is to demonstrate the value of process to the team, and ensure procedures are followed.

Best practice – Aerospace

Highly complex products can only be built if the specifications are clear and unambiguous. Aerospace can be very good at defining and documenting requirements. NASA has even developed a software tool to read a requirements document and flag potential issues. It provides specific measures on the clarity of the requirements:

  • use of imperatives, e.g. shall, must, responsible for, etc.
  • continuances
  • directives
  • options
  • weak phrases, and
  • incomplete statements.

Correct usage of specific words and phrases are considered to be indicators of the document’s quality as a specification of requirements.

Each domain has some recognized best practices from which others may learn. The exhibit below (Exhibit 3) summarizes some recognized leading practices categorized by domain and project/program management element. Some practices such as use of integrated or cross functional teams is a recognized best practices across all domains.

Recognized leading practices - Aerospace

Exhibit 3: Recognized leading practices - Aerospace

Best practice – Construction and Oil & Gas

Certain contracting firms are outstanding at one of the most difficult tasks in a project: estimating. Bechtel, an engineering and construction firm, is one of the most expert in this process. Constructing power plants is one of its core strengths. The cost of piping in power plants can sometimes exceed $42,000 per meter. Accurate estimates are essential. To provide estimates of material quantities that are both rapid and accurate, Bechtel developed a prototyping tool named COMET (Conceptual Modelling and Estimating Tool). COMET uses a hierarchical database of objects to enable rapid 3D modeling of a prospective project. Users can quickly access thousands of model components for all properties of any component in the model. COMET can route nearly 1,000 pipelines along with power cables and electrical raceways in less than five seconds and generate an accurate list of the quantities of materials needed in minutes. The data is used to establish a highly reliable cost estimate. (Hoppe, 2001)

Recognized leading practices - Construction and Oil & Gas

Exhibit 4: Recognized leading practices - Construction and Oil & Gas

Design reuse can dramatically lower the cost in construction projects. ExxonMobil saved $400 million when using the same design for two FPSO Platforms (Floating Production Storage Offloading) built 9 months apart. (Gumz, 2008). Bechtel has taken the concept of standardized design and applied it to power plants. It offers about 10 standard power plant models, each of which includes a set of process drawings and physical models along with associated performance and cost data. These standard designs are stored electronically, enabling rapid modification and configuration to a specific customer requirement. This process significantly reduces the delivery time and cost of power plants. Egypt’s first privately owned power plant, Sidi Krir, was completed using a standardized design. The project was completed within budget and schedule in December, 2001 (Ulrich, 2001).

Best practice – Information Technology

Recognized leading practices – Information Technology

Exhibit 3: Recognized leading practices - Information Technology

Cross Industry Applicability

Leading practices in one domain are sometimes adaptable to others. Stage gates have been adopted by programs in all domains: aerospace, construction, oil & gas, and information technology. Short duration IT projects are an exception. Another leading practice that is used by multiple sectors is the Preliminary Definition Rating Index (PDRI). The building version is used by construction, and the industrial plant version for oil & gas programs. A major California utility, Southern California Edison, has created their own version specifically for IT projects. NASA’s requirement analysis tool is certainly applicable to IT project requirements.

Summary and Conclusions

So what have we learned? Leading project management practices that are used in one domain, such as aerospace may be applicable to other domains, such as IT, construction, or oil & gas. Project managers should not focus solely on only their own industry sector to gain knowledge, but instead be aware of best practices in the entire field of project management. Current and best practices research is usually inexpensive and a good investment of your time (Eglene, 2003). Although subject matter expertise is essential to running to project, learning more about project management can be done without in-depth industry knowledge. The best project managers will take up the challenge.

Eglene, O. (2003) Conducting Best and Current Practices Research: A Starter Kit, Center for Technology in Government. Retrieved on November 9, 2009 from http://www.ctg.albany.edu/publications/guides/conducting_best/conducting_best.pdf

Hoppe, J.B. (2001, August) Tale of the COMET. Bechtel Briefs. Retrieved on January 2002 from http://www.bechtel.com/pdf/brief0801.pdf

FIATECH (2003, March) Capital Projects Technology Roadmapping Initiative. Austin, Texas: FIATECH (Fully Integrated and Automated Technology)..

Government Accountability Office (GAO) (2004, January) Best Practices: Using a knowledge based approach to improve weapons acquisitions. Retrieved on November 9, 2009 from http://www.gao.gov/special.pubs/d04386sp.pdf

Government Accountability Office (GAO) (2007, August), DOD is Making Progress in Adopting Best Practices for the Transformational Satellite Communications System and Space Radar but Still Faces Challenges, Retrieved on November 9, 2009 from http://www.globalsecurity.org/space/library/report/gao/d071029r.pdf

Government Accountability Office (GAO) (2008, April), Ares I and Orion Project Risk and Key Indicators Measure Progress,. Retrieved on November 10, 2009 from http://www.gao.gov/new.items/d08186t.pdf

Gumz, J. (2008, May). Zero Changes in Capital Projects: Is it Possible? PMI EMEA Congress 2008, Malta.

Snyder, C. and Parth, F. (2007) Introduction to IT Project Management. Vienna, Virginia: Management Concepts, Inc.

Schmitt, E. (1992, January 8) Pentagon Scraps 57 billion order for attack plane, New York Times, January 08, 1991. Retrieved on November 11, 2009 from http://www.nytimes.com/1991/01/08/us/pentagon-scraps-57-billion-order-for-attack-plane.html

Ulrich, T. (2001, April) Bringing Power to the People. Bechtel Briefs. Retrieved on January 2002 from http://www.bechtel.com/pdf/brief0401.pdf

© 2010, Joy Gumz
Published as a part of 2010 PMI Global Congress Proceedings – Washington D.C., U.S.

Advertisement

Advertisement

Related Content

  • Project Management Journal

    Navigating Tensions to Create Value member content locked

    By Farid, Parinaz | Waldorff, Susanne Boche This article employs institutional logics to explore the change program–organizational context interface, and investigates how program management actors navigate the interface to create value.

  • Project Management Journal

    Getting Past the Editor's Desk member content locked

    By Klein, Gary | Müller, Ralf To reach acceptance, every research paper submitted to Project Management Journal® (PMJ) must pass several hurdles. This editorial aims to declare the editorial process and reveal major reasons for…

  • Project Management Journal

    Investigating the Dynamics of Engineering Design Rework for a Complex Aircraft Development Project member content locked

    By Souza de Melo, Érika | Vieira, Darli | Bredillet, Christophe The purpose of this research is to evaluate the dynamics of EDR that negatively impacts the performance of complex PDPs and to suggest actions to overcome those problems.

  • Project Management Journal

    Coordinating Lifesaving Product Development Projects with no Preestablished Organizational Governance Structure member content locked

    By Leme Barbosa, Ana Paula Paes | Figueiredo Facin, Ana Lucia | Sergio Salerno, Mario | Simões Freitas, Jonathan | Carelli Reis, Marina | Paz Lasmar, Tiago We employed a longitudinal, grounded theory approach to investigate the management of an innovative product developed in the context of a life-or-death global emergency.

  • Project Management Journal

    Narratives of Project Risk Management member content locked

    By Green, Stuart D. | Dikmen, Irem The dominant narrative of project risk management pays homage to scientific rationality while conceptualizing risk as objective fact.

Advertisement