iil_logo_white.png

The IIL Blog

LinkedIn Newsletter | Join our Email List

SHARE THIS

The Evolution of Project Management

The Evolution of Project Management

We have all attended project management workshops, conferences, and symposiums. We have read books and journal articles on various project management topics. What we ended up learning was about the present state-of-the-art of project management and what the future might look like. But sometimes, it is nice to reminisce about the past and see some of the major changes that have gotten us to where we are today in project management.

Private Sector Project Manager Selection

The birth of modern-day project management is most frequently attributed to the engineering community, mainly aerospace and defense. When the Department of Defense (DoD) decided to expand the need for more technical projects following World War II, pressure was placed upon the aerospace and defense community to develop expertise in project management.

The starting point was the selection of individuals to function as project managers. Since almost all of the projects were technical in nature, two criteria were established for someone to be appointed as a project manager (PM). First, the PM was expected to possess a command of technology rather than merely an understanding of technology. Second, the PM was expected to possess superior writing skills.

Finding engineers with a command of technology was easy. Most of the early PMs possessed a master’s degree or Ph.D. degree in a technical discipline. This appeased DoD. Unfortunately, the same PMs often were quite poor at writing reports. Most contractors solved the problem by creating technical writing departments that reviewed all reports prepared by PMs before sending them to the clients. It was not uncommon for someone from the technical writing department to sit beside the PM when a report was needed, take dictation, and write the report for the PM.

In the 1970s, I presented a paper at a technical conference. The paper had to be approved first by my company’s technical writing department and then by corporate legal to make sure that company propriety information was not included in the paper. At a PMI® conference I attended later in the 1970s, almost 80% of the papers were presented by engineers or people working for engineering companies.

Public Sector Project Manager Selection

In most government agencies, PMs were seen more so as project monitors rather than project managers. There was no career path for PMs, nor were there job descriptions. The assignment as a government project monitor was seen as an add-on to one’s normal job. Government agencies had templates for writing government job descriptions for various assignments and pay grades, but not for project management nor project monitoring assignments.

Quite often, an assignment as a government project monitor or project manager was believed to be a non-promotable position. This was especially true in the military ranks. Promotions were more prevalent through the line organizations causing government personnel to avoid project assignments. Government personnel were reluctant to attend project management courses which could encourage superiors to keep them in project management assignments longer than they wish.

Client/Stakeholder Collaboration

In the early years of growth, the aerospace and defense contractors were marketing- and sales-driven companies. In other words, the sales force believed that they “owned” the DoD clients once the contract was signed and that all communications with the clients must go through the sales personnel. Salesmen wanted to maintain control of communications so that they could share in any bonuses that were forthcoming from successful projects. When the client asked the salesman a technical question, the response was almost always, “I’ll get back to you with an answer.” This annoyed DoD because they wanted the right to talk directly to the PMs if they had questions and to get an immediate answer rather than waiting possibly weeks for a response from the salesman.

The aerospace and defense industry contractors soon changed the collaboration approach and allowed the PMs to communication directly with DoD. One aerospace company fired almost their entire sales force that were opposed to this new practice and told the PMs that they would now assume the responsibilities previously held by the sales force for marketing and selling future business to DoD.

While senior management in the contractors’ organizations were somewhat pleased with how project management was progressing, there was one significant issue that concerned senior management. There was an inherent fear that, by allowing the PMs to communicate directly with the client, the engineering project managers would make decisions that were reserved for senior management to make, especially business decisions. Many of the PMs had never taken and business-related courses during their college days. As such, executives did not trust the PMs to make certain decisions.

The solution was the creation of a project sponsor position. Sponsors were appointed from the senior levels of management. The PMs were allowed to make most technical decisions, but all business-related decisions had to be made or approved by the project sponsors.

Communications with DoD agencies were handled primarily by the sponsors. The PMs were often restricted from talking to the stakeholders unless the sponsors were present.

Private Sector Project Sponsors

In the private sector, as stated previously, sponsors were assigned from the senior levels of management and with the responsibility of making most of the business decisions. There were several reasons for using senior managers as sponsors. First, government agencies wanted some sort of guarantee that senior management would be looking at the projects on a regular basis to make sure that the government’s best interest was being considered. The names and resumes of executives were included in responses to requests for proposals. Many executives, however, actually refused assignments as a sponsor for fear that, if the project failed, the result could seriously impact their career plans and promotability.

Executives convinced government agencies that they would be the sponsors when, after the contract award, sponsorship was intentionally moved down to middle-management levels without officially notifying the clients. Executive sponsorship was merely eyewash for government agencies. Executives attended project review meetings with the government agencies to make it appear that they were functioning as active sponsors rather than as invisible sponsors.

Second, government personnel responsible for awarding the contracts only wanted to collaborate with executives they believed were at the same organizational status level even though there could be a significant salary differential. Once again, contractor sponsorship activities were designed around the personal interests of individuals rather than for the best interest of the projects.

Private sector sponsors defined project success in financial terms and repeat business opportunities. Based upon the size of the customer base, sponsors were often given special titles to impress and appease the government agencies. Sponsors often made promises to clients to conduct additional work or testing at no added cost to the client. Pressure was then placed upon project teams to fulfill the promises made without having sufficient funding.

Public Sector Project Sponsors

In government agencies, especially on military projects, military personnel were often assigned as sponsors. Most military personnel disliked the assignment. First, if the project failed, it could be the end of the military officer’s career. The military officer could even be demoted. Second, there were no job descriptions for military personnel on how they should perform as a sponsor. Third, military officers knew that large cost overruns were possible. This could necessitate that the military officer appears before Congress and request additional funding. Requests for additional funding could be viewed as a project failure, again creating the risk of a limited career path. Many military officers acting as sponsors took it upon themselves to approve cost overruns, and then quickly requested transfer to another assignment, thus leaving their replacement with the responsibility for coming up with the additional funding.

Some military officers that were close to retirement viewed cost overruns as an opportunity. They would work out an under-the-table arrangement with the contractors that, if they approved the cost overrun, the contractor would guarantee them employment after they retired.

Massive Cost Overruns

Government contracts were seen as an ongoing revenue stream for contractors. Most of the projects involved innovation, R&D, and creativity. As such, the requirements were often poorly defined and could be based upon just an idea that needed to be elaborated during the execution of the project.

The solution to poorly defined requirements was the use of cost-reimbursable rather than fixed-price contracts. This allowed contractors to spend more money than the target established in the cost-reimbursable contract award. Project teams viewed this as an opportunity to generate more income. The hidden agenda of many project teams was to see if they could exceed the specifications rather than meet specification requirements, regardless of the cost. The result was often cost overrun that could easily exceed 400%.

The Vice President for Engineering in an aerospace company attended a seminar I conducted. After the seminar was over, the vice president offered me a job in his firm stating:

“We bid on numerous government contracts. Generally, we underbid the contract to improve our chances of winning the bid. Once we win the contract, we look for ways of increasing the scope so we can push through many scope changes. The job I am offering you is to review all of the requests for proposals (RFPs) we receive from government agencies and tell us how many scope changes we can push through if we grossly underbid our cost when responding to RFPs. The greater profits come from the scope changes rather than the initial contract.”

Monitoring and Control Documentation

All the DoD contractors began developing their own project management policies, procedures, forms, templates, checklists, and guidelines. While this seemed like the right thing to do for the growth of project management, DoD needed the documents to be somewhat aligned to DoD’s decision-making practices as well as the contractors’ needs.

The real serious issue occurred with status reporting practices. Almost all of DoD’s contractors had their own way of reporting project status. DoD personnel had to read through hundreds of different types of status reports to determine the status of the projects. DoD needed standardization in performance reporting.

In the late 1960s, DoD created the earned value management system (EVMS) and mandated that all contractors report status using the EVMS. The EVMS focused on three metrics, namely time, cost, and scope. DoD knew that more metrics would be needed to determine the true status, but metric measurement techniques had not advanced to the state where they are today. Most of the decisions that DoD personnel had to make at that time involved primarily time, cost, and scope.

During the 1970s and 1980s, DoD prepared guideline documents on how to prepare a work breakdown structure, statement of work, transition templates from design to testing to production, and other such documents. With very few textbooks on project management available in the marketplace, these guideline documents provided companies with ways to improve their project management processes. The guideline documents were eventually helpful in the preparation of new editions of the PMBOK® Guide.

Methodologies and Life Cycle Phases

With the growth in the number of DoD contracts, and the need for more collaboration, DoD needed more alignment between contractors’ processes for managing projects and DoD’s monitoring and control requirements. DoD was willing to allow each contractor to establish their own methodology, which was almost always the waterfall approach, and to use their own life cycle phases.

However, DoD did establish certain “gates” for government decision-making and requested that these DoD gates be part of each contractor’s project management methodology in addition to any other gates the contractors wished to use. DoD’s gates were heavily oriented to decision points for the continuation of funding for projects.

Project Management Education

As mentioned previously, PM selection in the contractors’ organizations in the early years was heavily based upon engineering knowledge and writing skills. There were some courses offered using the guideline documents prepared by DoD and other government agencies. However, the most common course taught at almost every aerospace and defense contractor was EVMS for standardization in status reporting practices.

In 1958 and 1959, Program Evaluation and Review Technique (PERT) was created to meet the needs of managing schedules. The Specials Projects Office of the U. S. Navy, concerned with performance trends on large military development programs, introduced PERT on the Polaris Submarine Weapons Systems Project in 1958.

Many educators began equating PERT as a form of project management. Textbooks on management science and operations research had chapters on scheduling techniques, but the title of the chapter was “Project Management.” Aerospace and defense contractors began teaching PERT and EVMS, but once again PERT was identified as project management.

Emphasis in project management education in the early years was heavily oriented toward the quantitative side of project management. In the private sector, very little emphasis was provided for human behavior because the real authority on projects rested with the sponsors. PMs had no authority over the resources assigned to their projects. Resource assignments were considered as temporary, and the PMs had no direct input in the workers’ performance reviews. Workers were considered as project expenses, and the goal of the PMs was to remove the workers as soon as possible from the projects to keep the costs down. PMs relied heavily upon functional managers to keep their workers engaged and motivated in the project.

In the 80s the Project Management Institute awarded its first Project Management Professional (PMP) certification. It was an 8-hour exam that included EMVS, PERT, and other topics. The 90s saw the first Standard for project management, the Guide to the Project Management Body of Knowledge, aka, the PMBOK® Guide. The first PMBOK® Guide presented 5 process groups, 9 knowledge areas, and 37 processes for managing projects. With this structured approach and certification, project management education took off. It is a key competency for business success and the need for educated professionals continues to grow.

A Shift Towards Project Leadership

In the 2000s the role of the project manager shifted again. There started to be an expectation that project managers should have both business acumen and leadership skills. Many project managers became involved in developing business cases and proof of concept for projects that had yet to be approved. PMs brought their technical knowledge and writing skills and coupled them with market research and business skills to evaluate the merits and potential pitfalls of projects.

This began to elevate the position of PMs from one that was purely technical or administrative to a more strategic perspective. The availability of training in the technical aspects of project management was very popular, but more and more people were realizing that what made project managers stand out was their ability to work effectively with people. This included working with the project team by employing skills such as team development, empowerment, facilitation, and motivation. It also included working with stakeholders by employing emotional intelligence, communication skills, and stakeholder engagement.

The Introduction of Agility

In the late 90s there were many stories of large-scale project failures, specifically in the IT space. Most IT projects were considered failures in one or more of the areas of scope, schedule, cost, and fitness for use. Systems development projects, especially those with a large software component, would spend years gathering requirements, designing, and building a system that would be plagued by changes and completely outdated by the time it was launched. Because technology was evolving so rapidly, almost every IT project was out of date by the time it was completed.

To meet the specific needs of working with software development, a new way of working on projects was needed. To address this need, in 2001 a group of 17 people got together at a lodge in Utah to share information and come up with a more effective way to deliver software projects. They walked away with a shared set of values and principles that are documented in the Agile Manifesto.

The four agile software development values are:

  1. Individuals and interactions over processes and tools
  2. Working software over comprehensive documentation
  3. Customer collaboration over contract negotiation
  4. Responding to change over following a plan

These four values are accompanied by 12 principles. By looking at the values it is obvious to see how different this way of practicing is from the traditional way of practicing. The traditional (AKA, predictive) methods were very grounded in processes and tools, whereas Agile projects don’t negate processes and tools, but they value individual and interactions more. Agile projects value responding to change over following a plan. This is 180 degrees different than in predictive projects.

Teams that adopted Agile ways of working often did not have a project manager. Many of the teams were self-organizing and were mutually accountable for the outcomes. They might use a scrum master to manage the process and support the team, but the team is accountable for planning the work, determining how to work, and making sure their way of working is effective and efficient.

Moving into a Hybrid Approach

Over the past decade or so, Agile ways of working have represented the greatest growth in our profession. Team empowerment, stakeholder engagement, and transparency have become prevalent in predictive as well as Agile projects.

The current trend is to embrace both ways of working and utilize a hybrid approach that can be applied to any project. Therefore, it is important to be comfortable in a structured predictive approach that works for projects with known, stable scope, as well as an Agile/adaptive approach that works for projects with evolving or unknown scope and requirements.

Thus, we can see how today’s practices are standing on the shoulders of giants from a focus on military and engineering projects, to embracing leadership skills and moving towards more adaptive ways of working.

We are a profession of millions of professionals, with a history of creating change and transformation – where will we go next?

About the Authors

Dr. Harold D. Kerzner, Ph.D., is Senior Executive Director at the International Institute for Learning, Inc., a global learning solutions company that conducts training for leading corporations throughout the world. 

He is a globally recognized expert on project, program, and portfolio management, total quality management, and strategic planning. Dr. Kerzner is the author of bestselling books and texts, including the acclaimed Project Management: A Systems Approach to Planning, Scheduling, and Controlling, Thirteenth Edition. His latest book, Project Management Next Generation: The Pillars for Organizational Excellence, co-authored with Dr. Al Zeitoun and Dr. Ricardo Viana Vargas, delivers an expert discussion on project management implementation of all kinds.

Cyndi has over 20 years of experience leading international project teams, consulting, developing courses, and facilitating training. She has received several awards, including the PMI Fellow Award in 2018 and PMI’s Distinguished Contribution Award in 2009. Cyndi is passionate about turning chaos in order, engaging with awesome teams, solving problems, and facilitating achievement.

Disclaimer: The ideas, views, and opinions expressed in this article are those of the author and do not necessarily reflect the views of International Institute for Learning or any entities they represent.

 

Agile & Scrum 2023 Online Conference Logo

Scroll to Top