PHASES OF PROJECT MANAGEMENT EVOLUTION

Intermingled with the basic management thought evolution was a corresponding evolu- tion of project management thought. We somewhat arbitrarily start this history in the mid-1940s when large, time-critical projects exploded on the scene as a result of World War II.

Stage I: The first major epoch of modern project management came in the mid-1940s.

The atomic bomb Manhattan project and other complex military programs added much insight into methods for completing this class of complex project endeavors.

Evolution of Project Management • 17

In the period following World War II, these methods were translated into formalized and documented approaches. Military projects continued to push the technology enve- lope into the 1950s and pressure to improve technical project management continued. Many credit the activities surrounding the successful design and implementation of the highly complex contractor-developed nuclear submarine project in the 1950s as the beginning of broad nonmilitary acceptance of a model-driven approach to project man- agement. This was reflected in the popularization of well-known network management methods such as program evaluation and review technique (PERT) and critical path method (CPM), which have proliferated into all industries since this time. These early planning and control models were initially able to be used only in large organizations because high-priced computing resources were required to manipulate the models. Further proliferation of these models had to wait until low-cost and robust computer processing technology emerged in the 1970s.

Stage II: The 1970s and 1980s brought tremendous expansion in hardware and soft-

ware technology offerings. Proliferation of minicomputers broke the cost barrier for operational modeling and this opened the door for improving planning and tracking of project status. General knowledge of the CPM-type network model existed, but there was still minimal understanding of the underlying management processes required to effectively utilize the model. Also, during this period, vendors sold “canned” method- ologies claiming that they would solve the project problem, but they seldom did. By the 1980s, the United States was in an economic boom and the key requirement for organi- zations was more toward speed of delivery than efficiency or quality. Slowing down that effort to sort through internal process improvements was low on the priority list.

A second constraining factor during this period was the organizational rethinking of the central IT department that up until now had held the keys to computing power. The period around 1970 ushered in smaller computing devices (minis and personal devices) that opened up user-based computation needed to make some of the project manage- ment tools acceptable and usable. Over the next 15 years, there was a deluge of software produced for this environment and from this the masses started becoming computer literate. However, for one living through this era it seemed that little conceptual project management theory progress was made as organizations were moving from the central mainframe computers controlled by a single department to a more distributed hardware environment with a “do whatever you want by yourself” mentality. Software maturity was outrunning the infrastructure necessary to support it with usable data. During this period, academic organizations and consultants published concepts, theories, and man- agement strategies that would have moved the project discipline further along, but the general project audience was not yet convinced that project management added value to the result. Many looked at management software and the other defined documentation as requiring too much overhead and some feel to this day that the current models are not appropriate for the task. The favored development model during this period was one based on speed of product delivery and purchasing software from third parties. The lat- ter strategy was thought to take away many of the needs for project management since “the code was already written.” Subsequent massive system development failures with attempts to install these “prewritten” systems uncovered another view. That is, there is more to successfully executing a project than loading code to a computer or buying some vendor’s management tool. So, by the end of the 1980s, there was a new level of project management understanding. More “silver bullets” emerged, but none solved the issue of poor project outcome results.

Stage III: As history transgresses into near present time, one often feels that the

problem is understood and the answer is close. In this spirit, the 1990s are viewed as a period of maturation and proliferation of information tools, techniques, and user lit- eracy. Small and powerful desktop devices solved the modeling capability issue and the Internet solved many of the information distribution constraints. However, neither did much to improve the organizational discipline regarding the management of projects.

Desktop tools such as Microsoft’s Word, Excel, and Access turned millions of com- puter aficionados into what looked like programmers and the project world become flooded with small pockets of disorganized data. These new capabilities improved the look of documentation, but the underlying processes were not appreciably improved.

Another evolutionary thread emerged during this period in the form of improved software packages. During this wave, major mission critical systems were being replaced by suites of integrated commercial software packages as a strategy to cut computer expenditures. Names such as SAP, Peoplesoft, Oracle, J.D. Edwards, Lawson, and others became familiar terms. In many cases, this “silver bullet” solution failed to materialize and the results sometimes bordered on catastrophic for the organization. Once again the primary reason for many of these failures was not the lack of purchased product quality, but the underlying process for selection and implementation—that is, a gap in a process that could have been viewed as a project requiring project management prin- ciples. Also, because these projects represented such a large resource commitment, there was an attempt to manage them in a professional way and yet they still failed to meet expectations of budgets, schedules, and functionality. Something was clearly not work- ing right! The one item of good news coming from these failed initiatives was that the projects involved large segments of the organization and this uncovered one of the miss- ing issues in project—that is, communications.

As a result of these experiences, the use of formal reporting processes and metrics related to project execution began to be recognized as a requirement and senior man- agement became more interested in this aspect. Prior to this, the prevailing lack of com- puter literacy by management and the lack of appropriate project status metrics allowed projects to run under the radar of management scrutiny until the project was completely out of control. There was now a growing awareness that some type of prerequisite man- agement process must be in place prior to embracing a complex highly technical under- taking, whether that be hardware, process, or software. Organizations that failed to understand this continued to believe that project management was simply an overhead and added cost for no benefit. By the mid-1990s, there was growing management recog- nition that the project environment within various organizational segments could not be allowed to go uncontrolled any longer. Also, project costs were now being captured and were recognized as a major component of the capital budget in many organizations. This stimulated the requirement for more rigorous project justification.

In parallel with the improved understanding of project success variables came an increased awareness of project activity in general. As project disaster data began to be published, it highlighted that poor project performance was a general phenomenon and not one limited to local initiatives. As an example, the popular press chronicled a $1 bil- lion overrun for the new Denver airport basically caused by a project management error. Also, various large governmental projects and Boston’s Big Dig tunnel had similar results. Once recognized, these reports became common fare for news reporting. The public was now in tune with the issue and these daily status notes opened the door to increased sen- sitivity regarding the need to deal with the problem.

Evolution of Project Management • 19

During the 1960s through the 1990s, organizations attempted various management strategies to improve project results. Looking back on these efforts, they were lab experi- ments quite similar to the Hawthorne research—looking in the wrong place for the answer. Many root causes for failure were identified, but true fixes did not emerge on a broad scale. Around this time organizations such as the PMI became involved in search- ing for solution techniques and they pioneered the concept of a general project manage- ment model. Also, the Y2K (Year 2000) phenomenon became widely discussed around 1998 and prognosticators predicted doom if all computer software was not repaired by the end of the decade. For the first time, global technical projects were perceived to require completion of their mission on time and within scope. For all these reasons, the latter 1990s ushered in a worldwide recognition of project management. The technical and maturation events described in Stage III provided a broad view of what project management is and what it can contribute. We would be naïve to suggest that the prob- lem is now ready for solution, but it is widely documented and discussed by industry and academia. So, we then enter Stage IV which is more of a current trend view.

Stage IV: The key philosophical question at this point is to forecast where the current

trends will take the topic and in what time period. One view is that the current identi- fied trends will continue to broaden across all organizations in essentially unaltered state. That is, new products, hardware, software, and telecommunications technology all driving the same processes but using the new tools. Also, it seems reasonable to pre- dict that the global population in general will become more literate with these tools and technologies. At the same time, the project environment will continue down the trail of increasing complexity and its methodologies will likely become more embedded in the fabric of everyday organizational work processes.

Certainly, one exacerbating theme through this period is the dynamic nature of international organizations involvement in domestic projects. Just as the project management model began to synthesize a workable set of tools and concepts for the organization, the operational model was disrupted. Specifically, the globalization of organizational processes is now a reality and is being stimulated by the existence of cheap foreign labor sources. This in turn has led to increased outsourcing to third par- ties. These initial outsourcing initiatives involved relatively simple organizational pro- cesses and were marginally successful during the 1990s, but the trend continues to grow with some new approaches and a better understanding of how to manage such ventures. One of the major positive contributors to this is the increase in functionality and lower cost of international Internet telecommunications, which has in turn opened up new vendor opportunities for distributing knowledge work. This has allowed the emergence of smaller niche vendors who do one function very well. In some cases, these specialized vendors are often able to take over an entire business process at less cost than it could be operated internally. Each of these niche solutions changes the internal process of the organization and potentially changes the project management protocols related to those vendors. The number and scope of such activities is forecast to continue to increase.

Recent experience indicates that these niche vendors can be successful in the mar- ketplace as a result of their economies of scale and specialized skill level, but once again we also see a trend that requires more complex project management techniques as the business process becomes fragmented across multiple organizational groups. As a result of these outsourcing trends, critical operational activities are being performed exter- nal to the consuming organization. One potential risk issue raised by this trend is the impact of an external vendor failure. This was a much more controllable situation in the

traditional structure, but now can have a significant impact on the organization and the project. Because of the complexity and loss of internal skills, a reverse migration of these processes becomes quite difficult. For this reason, risk management in such an envi- ronment takes on increased importance. A further risk extension of the contemporary trend for outsourced vendors is that they often reside in another country—an uncom- mon practice prior to the late 1990s. Today, a full complement of service providers exists in locations such as India, Pacific Rim, China, South America, Russia, and others. These new technical entities continue to increasingly extract work from local U.S. organiza- tions and basically change the project management landscape.

With the industry trends partially outlined above, there is an increasing need for more formalized and effective project management across the collaborative partner domain. Any new management processes hosted in this way must be compatible with the evolving business requirements of a global work force. As a result, planning, control, communication, and team collaboration are more critical processes in the contempo- rary environment. Experience has shown that the road to project success involves more than manipulating technology and tools. Success is clearly driven by proper manage- ment of the human element and the subsequent implementation of the output created by the project. In some ways, the project management tools are morphing into more of an operational management concept.

To support these contemporary organizational needs, a strong project management orientation is needed and it will have to be sensitive to producing value for the orga- nization and not just installing new products and processes. Organizations have now become sensitive to the issue of selecting the right project to start with. That often adds another layer of management to the traditional project view. These organizations are demanding quicker cycle times to customer demands along with more complex visions. In order to gain respect, the project management function has to be seen by the enter- prise management as delivering value. One threat in such an environment is for man- agement to say “if project management can’t deliver this, I’ll find another way.”

History has shown that time pressure can cause planning to be ignored (i.e., plan- ning is overhead). Project management theory is built on the basic concepts of planning and control; so it is going to be up to the profession to show value in a formal plan- ning-oriented model. The dilemma with this is how to go fast and not make costly mis- takes versus going slower and accomplishing the technical goals. Management wants to know how much formalization will cost and how much value it brings. That is difficult if you do not measure the process and learn from that along the way. Resolving this conundrum remains one of the toughest challenges of this period. To support this goal, there is a growing interest in new approaches to development now going under titles such as “agile,” “extreme,” spiral, critical chain, and other names. These new schools of thought focus more on speed of delivery and customer satisfaction. To date, many traditional managers have resisted most of these methods because they tend to move forward before a firm vision of the deliverable along with schedule and cost is defined. The underlying belief is that lack of planning increases the future level of scope change and in turn makes the project cost more and may in fact then take longer to complete. There is insufficient proof for either side of this debate, but both appear to have posi- tive and negative value positions. The result of this may be to conclude that each option focuses on different goal sets (e.g., schedule, customer satisfaction, cost, etc.). One of the more obvious potential benefits of the lower initial planning approach is customer

Evolution of Project Management • 21

satisfaction; however, the negative issues of management visibility and control are left to be dealt with. The key to future success in this arena is to find a proper blend of predefinition versus the increased customer satisfaction from a better match to their requirements. In the current traditional environment, most management groups will not approve a project without some reasonable view regarding the future project’s func- tionality, resource commitment, cost, and schedule. This suggests at least some degree of planning to satisfy these requirements.

Collectively, all the contemporary trends in the project environment will bring new challenges to management philosophy. Certainly, the combination of business pressure for increased speed of delivery, increased use of purchased services and commercial off the shelf (COTS) packages, outsourced service providers, and use of offshore vendors impacts many aspects of the traditional project management model. This new envi- ronment will require an improved set of tools and strategies to navigate these initia- tives successfully. As a result of these dynamics, the subject of project management will remain under great conceptual stress, but will also be more recognized as a key require- ment to success. Obviously, the skill requirements for this class of project will be greater than those found in most organizations today. As a result of these trends, one should not plan on a status quo approach to this subject over time. The new generation of PMs must evolve as the organizational environment evolves to employ the new strategies.