Project management is not project management is not project management
The 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 IT? IT has developed new approaches. What can they teach construction? What can aerospace teach the others, and what can they learn?
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 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 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.
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 ever 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).
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 all have competing needs. DIMHRS, the Defense Integrated Military Human Resources System effort to consolidate all US Department of Defense military personnel on one Human Resources and pay system, is a perfect example. Each branch of the US military has different pay and human resources 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, then 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 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.
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. Climate and weather difficulties add to the challenge.
In IT, technology changes so quickly there is a need to get the product out the door quickly—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.
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.
- 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 exhibits next summarize 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.
|Project/Program Management Element||Aerospace Best Practices||Comments|
|Requirements||Automated tool to assess quality||NASA homegrown tool and commercial products available|
|Metrics/key indicators||Key metrics defined and monitored, such as growth in weight and/or lines of code (GAO, 2008)||For space systems, weight growth is often among the highest drivers of cost growth. For software, unanticipated software complexity, often indicated by increases in the number of lines of code, can portend cost and schedule growth.|
|Evaluation & review/key junctures||Reviews at key junctures: preliminary design review, critical design review, and production review (GAO, 2008)||Reviews provide backward and forward look and help focus on realistic accomplishments|
|New technology||Research conducted before program start to ensure that technologies are mature and proven to work as intended (GAO, 2007)||Technologies should be at the point of being tested in a relevant or operational environment prior to committing to an acquisition program.|
|New technology||More ambitious technology efforts deferred to corporate research departments until they are ready to be added to future increments (GAO, 2007)||A technology development environment is more forgiving and less costly than a delivery-oriented program environment. Events as test failures, new discoveries, and time spent attaining knowledge are considered normal in R&D.|
|Communications||Concurrent engineering platform established with key partners||This improves the data exchange and collaboration among risk sharing partners|
|Governance / program audits||Stakeholder communication survey early in audit||Raises visibility of concerns making audit more risk based|
|Testing||Variety of testing and evaluation tools and techniques, such as prototyping (GAO, 2004)||Validates a product's performance early and throughout development|
|Monitoring & control||Earned value management techniques (GAO, 2004)||Tracks a project's progress and assesses its ability to meet cost and scheduling goals|
|Human resources||Integrated product teams (GAO, 2004)||Brings together in a single team the different functions needed to design and manufacture a product, such as engineering, finance, test and evaluation, and manufacturing|
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 companies. 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 COMET (Conceptual Modeling 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).
|Project Planning & Definition Element||Construction and Oil & Gas Best Practices (FIATECH, 2003)||Comments|
|Business/ facility/project planning|| ||Leaders: Bechtel & Chevron on Lessons Learned|
|Conceptual process/facility design|| ||Leaders: Bechtel & Toshiba on standardized design|
|Detailed process/facility design|| ||Leaders: Chevron on interface resolution|
|Detailed engineering design|| |
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 nine 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
|Project/Program Management Element||Best Practices||Comments|
|Time management||Logging time spent on each task/activity, whether for projects or operations||Enables analysis for continuous improvement|
|Development||Using rapid, agile, development approaches||Improves ability to deal with changes in requirements|
|Development||Continual access to the customer/user/client||Obtain rapid feedback and show results|
|Testing||Use of testing standards, e.g., IEEE 829||Improves quality|
|Configuration Management||Managing the specific configuration of each module in a development application||Goal is to ensure compatibility with other modules as development continues|
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 its 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, 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. FIATECH (Fully Integrated and Automated Technology). San Antonio, TX.
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. (May, 2008). Zero changes in capital projects: Is it possible? PMI EMEA Congress 2008, Malta.
Snyder, C., & Parth, F. (2007). Introduction to IT project management. Vienna, VA: Management Concepts, Inc.
Schmitt, E. (1992, January). 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
Originally published as a part of 2010 PMI Global Congress Proceedings – Melbourne