by Lynda Bourne
Project managers and processes go hand in hand. But are the processes of the past the right ones to guide future projects? And if project management is evolving beyond today’s generally accepted 40 or 50 processes, what should the next version of A Guide to the Project Management Body of Knowledge (PMBOK® Guide) look like?
The Evolution of Process as a Concept
To consider these questions, let’s start by looking at the way processes have evolved. The concept of describing the process needed to accomplish a task emerged as part of the development of scientific management in the early 20th century. Scientific study and careful analysis defined the “one best way” of doing the work and the time it needed. Shortly after, the application of learned experience entered into the equation as a way to improve the current “best method.”
By the 1950s the concept of a process with defined inputs, transformed by the application of defined tools and techniques to produce outputs, was firmly established in quality control and management. Process improvement was central to the rapid development of post-war industry.
During the development of the 1996 version of the PMBOK® Guide, PMI adopted processes as the best way to organize and explain the complex flow of information through the life of a typical project. The PMBOK® Guide came to embody “generally accepted good practices that apply to most projects, most of the time.” Over the years, the 37 processes in the 1996 version of the PMBOK® Guide expanded to 49 in the Sixth Edition (released in 2017). Through the editions, PMI has progressively increased the emphasis on the need to customize and tailor processes to meet the needs of each individual project. But is this enough?
The questions I want to ask in this post are:
In the past, processes were developed around the concept of transforming specific inputs in a defined way to create consistent outputs. Business processes define how the how work is done within an organization, to meet the needs of its customers. PMI’s approach to generalizing processes across a management discipline adapted this basic concept.
The idea was powerfully successful when most projects, most of the time, had similar characteristics. They were approved, planned, built and closed. The same approach was used in construction, engineering and most other industries that did projects in the 1990s—and the concept remained largely true for the next 20 years or so.
However, does this generality still apply in the current environment, where some projects still follow the traditional approach (e.g., construction/engineering), others use various iterative approaches, while others take a fully adaptive and agile approach?
Some core objectives are consistent across of all of these approaches. For example, they all use some form of schedule management to get the right people into the right place at the right time, adequately resourced to do the right work. However, the processes applied to accomplish this objective have very little in common. For example, resources are allocated to logically constrained activities by the planner in traditional critical path method scheduling, in agile resources choose which activities to include in their next “sprint.” Similar challenges exist across most, if not all, of the knowledge areas. Has creating processes that can work across all of the different delivery strategies become impossible?
Focusing on the next edition
This brings me to the second question. What should the next edition of the PMBOK® Guide look like?
As our profession rapidly changes and diversifies, it remains central to the development of the world’s economy. So how do you think the PMBOK® Guide can best evolve to maintain its preeminent position as the global reference defining the management of projects?
Your answers will help inform my next post looking at managing the accelerating rate of change in our profession.