Chapter 2. Project Management Evolution
The engineering and, more significantly, the IT professions have heavily influenced the evolution of business project management. As a new profession, information systems looked to other professions for guidance and for models to assist in formalizing and establishing best practices. Given the dominance of hardware engineering and research in the early days of computing, it is not surprising that many of the initial models for development and management were drawn from engineering and construction. The classic product and system development lifecycles and methodologies were drawn directly from the product development cycles of construction and engineering. The evolution of formal methodologies first discussed in the North Atlantic Treaty Organization (NATO) conferences [2] during the late 1960s was based on the concept of phase-by-phase progress through the processes of analysis, design, construction, test, and implementation.
Most important, the first formal models of project management in information systems also reflected those developed in the defense and construction industries. As discussed by James Adams (1991), the development of technology as we know it can be traced from around 10,000 years ago. Although there is evidence of crafted implements such as fire- hardened spears as far back as 400,000 years , the Neolithic period marked the move from hunting and gathering to domestication of animals and farming. With this shift, the development of human-designed implements (engineering) began to accelerate and, by 3000 B.C., the Egyptians had developed sophisticated technologies such as boats, wheels, plows, and sewage systems. The construction of major buildings such as the pyramids and large canal works was common. The management of these major engineering works was undertaken by people such as Khufu-onekh, who designed and built the Great Pyramid, and Imhotep, who designed and built the Pharaoh tombs. Similar large projects were being undertaken during the same period in Mesopotamia, China, and Greece. By the end of the Roman Empire, technology and engineering had a "base of ingenuity, craft, art, empirical relations and, some quantitative reason" (Adams, 1991). However, it wasn't until some 4,000 to 5,000 years later during the Industrial Revolution that the move from guilds of craftspeople to professional societies such as the British Institute of Civil Engineering (1818) began to occur. The formalization of teaching, knowledge, techniques, measures, and behaviors associated with professional societies was complete in all areas of engineering by the early 1890s, but the formalization of the management of complex engineering projects did not emerge until some 60 years later in the 1950s. Project management in other industries had also faced the difference between technical management and project management briefly discussed in our Introduction and explored further in later chapters. Until the 1950s, the management issues in engineering such as cost estimation, change control, scheduling, management and direction of resources, contract negotiation, and so on were undertaken by the project's architect. However, the management of both the technical aspects and the overall project by the same person often led to a conflict of interest. A dramatic example of this conflict of interest can be found in the Sydney Opera House project. Joern Utzon was awarded the contract to design and build the Opera House in 1959. Some nine years later, Utzon had not produced any architectural construction drawings and he resigned after a series of heated discussions with the new Minister of Public Works, Sir Davis Hughes, who stated to the New South Wales Parliament in 1966 that "If the complete control of the Opera House was left in the hands of Mr Utzon, the building would never be completed" (Hughes, 1993). After Utzon's resignation , an engineering management team completed the project in 1973. Hughes maintains that Utzon was overwhelmed by the technical difficulties associated with the construction of the large shells and cost control, schedules, and other project management concerns were basically ignored. During the late 1950s and early 1960s, the integration and development of a body of project management were driven by difficulties faced by the U.S. Department of Defense. Most of the concepts came from major projects such as the Manhattan Project (the building of the atomic bomb), the Polaris, and the 688 submarine projects under Defense Secretary Robert McNamara and implemented by Admirals Raborn and Rickover. The predominant approach to project management mirrored the construction industry, in that the management of defense projects was undertaken by the technical experts. However, the underlying issue of conflict of interest existed in these projects as well. As documented brilliantly by Richard Rhodes (1995), until the Manhattan Project clearly separated the overall management of the project's budget, schedule, and mission under General Groves and the technical management of the project under Robert Oppenheimer, the project to build the atomic bomb was facing failure. The concept of project management as a separate discipline is now well established in engineering. In contrast to the Sydney Opera House, the construction of the new Federal Parliament House in Sydney was managed by a specialist project management group with clear separation of management and technical roles. We return to this concept in the next chapter. However, this brief examination of the history of project management enables us to identify the fundamental myth that is the foundation of traditional project management: Business and engineering projects are the same type of projects. This is one of the most enduring of the traditional project management beliefs. The analogy between engineers constructing a building, a bridge, or a ship and a business or IT professional building a new product is often used by advocates of software engineering and traditional project management. The well-known waterfall model of system development in which design does not commence until formal specifications are signed off on by the client is a direct "copy" of the traditional engineering models. As shown in Figure 2.1, there are few, if any, parallels between building business processes, products, or software and building skyscrapers. [3] The dynamic nature of business project construction is in complete contrast to the "stable" process of building. In addition, as documented by Chris Meyers (1993) and many others, the building, automotive, chemical, and many other engineering groups are moving to iterative and concurrent development models, abandoning the waterfall model to be first to market.
Figure 2.1. Engineering versus business projects  |
EAN: 2147483647
Pages: 136