The central irony of the PMBOK Guide is that one of the most influential project management documents ever produced was never meant to become what many practitioners later made of it. It was not intended to be the whole body of knowledge. It was not intended to be a universal project management methodology. It was not intended to be a memorization manual for certification candidates. It was not intended to turn project management into a checklist exercise. Yet, over time, the PMBOK Guide has often been treated as all of those things.

William R. “Bill” Duncan’s role in this history matters because he was not merely adjacent to the document. He was the Director of Standards for PMI during the development of the 1996 PMBOK Guide, and he is identified by PMI’s own publications as the primary author of that first edition.^[1] That edition gave the profession much of the structure that later generations of project managers came to recognize: knowledge areas, process groups, inputs, tools and techniques, outputs, and a more formal explanation of how the pieces of project management relate to one another. It was a major act of professional organization. But it was also a more modest act than later users often assumed.

The first important point is historical. Duncan did not create project management, and he did not create the idea that PMI should document a body of knowledge. PMI’s work on standards reaches back to its early standards and accreditation efforts and to the 1987 document titled The Project Management Body of Knowledge.^[2] What Duncan and the Standards Committee did in 1996 was different. They reshaped, clarified, reorganized, and retitled the material. That retitling was not cosmetic. It was conceptual. The 1996 preface explicitly states that the title was changed to emphasize that the document was not itself the PMBOK. The full project management body of knowledge was larger than any one document could contain.^[3]

That distinction is not academic. It is the heart of the matter. The PMBOK, properly understood, is a body of knowledge that resides in the practice, study, teaching, and refinement of project management. A guide to that body of knowledge can organize part of it. It can describe commonly accepted practices. It can create a shared vocabulary. It can support certification and professional development. But it cannot contain the field. The moment a guide is treated as the field itself, professional discipline begins to decay into textual obedience.

Duncan and his colleagues were clear about this before the 1996 edition was finalized. In a 1994 Project Management Journal article, Duncan, J. Davidson Frame, and Eric Jenett addressed confusion about the relationship among the PMP exam, PMI publications, and the PMBOK. Their position was direct: the PMP exam was not supposed to test PMI publications as a closed canon; it was supposed to test project management knowledge. The PMBOK was not merely a document; it was a broader concept.^[4] They rejected the idea that professionalism could be built on memorization and argued that a competent project manager should be able to apply knowledge to new problems, as one must do on an actual project.^[5]

This is a stronger professional claim than many later certification practices have allowed. A profession is not defined by the ability to repeat authorized language. A profession is defined by the ability to make sound judgments under varied conditions. Law, medicine, accounting, engineering, and project management all depend on shared knowledge, but none of them can be reduced to a single book. Duncan’s view of the PMBOK Guide fits that model. It was meant to support professional judgment, not replace it.

The 1996 document itself reinforces this interpretation. Its stated purpose was to identify and describe a subset of the PMBOK that was generally accepted, meaning applicable to most projects most of the time and supported by widespread consensus about its value. It also stated that generally accepted did not mean universally required. The project management team remained responsible for determining what was appropriate for a given project.^[6] That sentence is one of the most important safeguards in the entire PMBOK tradition. It preserves context. It preserves tailoring. It preserves responsibility.

The guide also had a second purpose: to provide a common lexicon. That was no small thing. Project management was, and in many ways still is, a young profession with uneven terminology across industries. Construction, software, pharmaceuticals, government, telecommunications, defense, finance, and internal business change all use project language differently. A shared vocabulary helps practitioners communicate across those boundaries. But a vocabulary is not a method. Knowing the language of project management is not the same as managing a project.

The 1996 edition’s process structure should be read in that light. Duncan and the Standards Committee chose to describe the knowledge areas through component processes, each with inputs, outputs, and tools and techniques. The stated reasons were practical. The process format emphasized relationships among knowledge areas, allowed changes to be incorporated over time, and aligned with the broader standards movement’s attention to business processes.^[7] The structure was not intended to make every project manager march through a universal sequence. It was intended to show how management work interacts.

That is why Duncan’s later frustration with the misuse of process groups is so important. In his 2019 LinkedIn article “Process Groups Are Not Phases,” he objected to the common practice of treating Initiating, Planning, Executing, Monitoring and Controlling, and Closing as if they were project life-cycle phases.^[8] His objection was not pedantic. It went to the practical heart of project management. Product-oriented work has its own life cycle. A software project may move through requirements, design, development, testing, release, and transition. A construction project may move through concept, design, procurement, build, inspection, and turnover. A business process project may move through discovery, analysis, redesign, implementation, and stabilization. The process groups are management activities that occur within and across those product-oriented phases. They are not the phases themselves.

This distinction matters because confusing process groups with phases makes project management less useful. If “planning” is treated as a single phase, then the planning required for requirements work, design work, development work, testing work, implementation work, and transition work becomes artificially compressed into one conceptual bucket. Reality does not behave that way. Real people doing real work in real time must keep initiating, planning, executing, monitoring, controlling, and closing at appropriate levels throughout the life of the project. Duncan’s complaint was that the PMBOK Guide had recognized this from the beginning — devoting a section of the 1996 text and two diagrams to the relationship between phases and process groups — yet practitioners and authors kept flattening the distinction.^[9]

This is also where the PMBOK Guide’s greatest strength became one of its vulnerabilities. A well-structured model can illuminate practice. But once a model becomes iconic, people begin to protect the model instead of examining the work. Process groups became diagrams. Diagrams became teaching devices. Teaching devices became exam-prep memory structures. Memory structures became false life cycles. A guide intended to organize professional thought became, in too many hands, a substitute for observing the actual project.

Duncan’s 1998 article on whether the PMBOK Guide was a standard adds another useful layer. He concluded that the answer depends on what one means by “standard.” The PMBOK Guide could be considered a standard if understood as a reference approved for common and repeated use. But it was not a standard in the sense of a mandatory requirement, technical specification, or precise compliance regime. Duncan also distinguished descriptive, normative, and prescriptive standards, placing much of the PMBOK Guide in the descriptive and normative categories rather than the prescriptive one.^[10] In other words, the guide could help a practitioner compare, structure, and decide. It was not a project management law book.

This point has practical consequences. When organizations treat the PMBOK Guide as a mandate, they often create compliance theater. They ask whether the template has been completed instead of whether the project has been understood. They ask whether the process has been followed instead of whether the project is still worth doing. They ask whether the vocabulary is correct instead of whether the stakeholders are aligned, the scope is stable enough to act on, the risks are real, and the schedule describes work that can actually happen. That is not project management. That is bureaucratic substitution.

The later PMBOK journey reflects the profession’s struggle with this problem. Earlier editions became associated with process, structure, and knowledge areas. The seventh edition moved sharply toward principles and performance domains. The eighth edition, according to PMI’s current description, retains the principles and performance-domain foundation of the seventh while simplifying and clarifying them and reintroducing process groups as focus areas.^[11] That movement suggests an unresolved tension: project management needs both structure and judgment. Too much process becomes mechanical. Too much principle becomes abstract. Good practice requires both.

Duncan’s later comment about the title of the PMBOK Guide is therefore revealing. In a LinkedIn discussion about recent editions, he argued that the real problem was the title A Guide to the Project Management Body of Knowledge. In his view, neither the process-based content nor the principle-based content had ever fully matched that title. He said he would have preferred something closer to A Guide to Project Management Practice.^[12] That is a profound retrospective clarification. It suggests that the deepest error may have been allowing the guide’s title to carry more epistemological weight than the document could bear.

A “body of knowledge” sounds comprehensive. A “guide to practice” sounds selective, contextual, and usable. The former invites canonization. The latter invites application. Duncan’s professional instinct seems to have been closer to the second. The PMBOK Guide was meant to help project managers see the field, speak with one another, and apply generally recognized practices with judgment. It was not meant to exhaust the field or relieve the practitioner of responsibility.

Here the argument must confront its strongest objection, because a position worth using is one that has survived its best critics. A school of project management scholarship — associated with Svetlana Cicmil, Damian Hodgson, Lauri Koskela, and others — would say that the modesty this essay wants to recover was never really present, and that to look for it is to misunderstand what a standard is.^[13] On this view, no standard is neutral. The act of codifying “generally accepted practice” disciplines behavior regardless of the codifier’s intent. It defines what counts as competence, what gets audited, what a manager must be prepared to defend. Duncan’s careful reservations — that the team remains responsible, that the guide requires nothing — are, on this reading, exactly what every standard says while still constraining the field it claims only to describe.^[14] The rigidity that followed was therefore not a betrayal of the 1996 guide. It was the guide doing what standards inevitably do. The misreading was not a misreading at all; it was the standard’s true social function finally becoming visible.

This is a serious objection, and it deserves a serious answer rather than a dismissal. The answer is that it proves too much. If codification inevitably and completely produces rigidity, then no standard could ever leave room for judgment — and the question of intent would be meaningless, because every author’s purpose would be overwritten by the same iron logic.^[15] But that is not what the historical record shows. The 1996 document did not merely gesture at practitioner judgment as a pious formality. It built the reservation into its structure. It reserved the determination of what is appropriate to the project management team, and it described the process groups as overlapping activities rather than sequential phases, precisely so that the document could not be read as a march through fixed stages. These are not the moves of a text indifferent to how it would be used. They are the moves of a text trying, however imperfectly, to inoculate itself against its own misuse.

The decisive evidence is Duncan himself. A standard whose author can watch his work being misapplied, name the misapplication, and argue against it for more than twenty years is a standard whose design and whose reception were never identical. One cannot betray an intention that did not exist. The critics are right that standards exert power; they are wrong that the power is total. The 1996 guide carried within it the resources to resist its own ossification — and the tragedy is not that those resources were absent, but that they went largely unused. That is a stronger claim than nostalgia. It does not ask the reader to imagine a modesty the document lacked. It points to the modesty the document contains, and asks why the profession declined to honor it.

The lesson for today is not that PMI is wrong, or that the PMBOK Guide is useless, or that standards are inherently dangerous. That would be too easy and too crude. The PMBOK Guide has given the profession a shared language. It has helped project managers explain their work. It has supported certification, training, academic programs, organizational maturity, and cross-industry communication. It deserves respect for that achievement.

But respect is not submission. The mature practitioner does not ask, “What does the PMBOK make me do?” The mature practitioner asks, “What does this project require, and what guidance from the PMBOK Guide helps me think clearly about it?” That is a different posture. It keeps the guide in service to the work. It keeps the project manager responsible for judgment. It keeps the project connected to the business need that justified it in the first place.

That, in the end, may be the most useful way to read Duncan’s contribution and his later criticism. He helped give project management a structure, but he did not intend structure to replace thought. He helped name processes, but he did not intend those process names to become life-cycle phases. He helped professionalize a field, but he did not intend professionalization to become memorization. He helped produce a guide, but he did not intend the guide to become the body of knowledge itself.

The irony is that the PMBOK Guide became powerful enough to be widely adopted, but also simple enough to be widely misread. That is not a reason to discard it. It is a reason to handle it with more discipline. A guide is most valuable when it guides. It becomes dangerous when it governs without context.

The best way to honor Duncan’s original contribution is not to freeze the 1996 edition in amber. It is to recover the professional modesty embedded in it. The PMBOK Guide is a map, not the terrain. It is a vocabulary, not the conversation. It is a reference, not a replacement for experience. It is a professional aid, not a substitute for judgment.

The PMBOK Guide should be read, taught, criticized, and used from that position. It should help project managers manage reality, not escape from it. And when discussing PMI, certification, standards, or the future of project management, that should remain the touchstone: a practical standard became, in many hands, a substitute for practical judgment. The work now is to put judgment back in command.

---

Endnotes

1. William R. Duncan is named as Director of Standards on the title page of the 1996 A Guide to the Project Management Body of Knowledge, issued by the PMI Standards Committee, and is identified by PMI’s own publications as the primary author of that edition. ↩
2. The 1996 edition’s cataloging note and preface state that it supersedes PMI’s 1987 Project Management Body of Knowledge document; PMI’s body-of-knowledge work grew out of its earlier standards and accreditation efforts. ↩
3. The 1996 preface states that the title was changed to emphasize that the document was not itself the PMBOK and that no single document could contain the whole project management body of knowledge. ↩
4. Duncan, J. Davidson Frame, and Eric Jenett argued in 1994 that the PMP exam was intended to test project management knowledge, not merely PMI publications, and that the PMBOK was a concept rather than a single document. ↩
5. The same 1994 article rejected the idea that professional competence could be built on memorization and emphasized applying project management knowledge to new problems. ↩
6. The 1996 PMBOK Guide defined its purpose as describing generally accepted project management knowledge applicable to most projects most of the time while leaving responsibility for appropriate application with the project management team. ↩
7. The 1996 preface explained the choice to describe knowledge areas through component processes, including inputs, outputs, tools, and techniques. ↩
8. Duncan’s 2019 LinkedIn article “Process Groups Are Not Phases” criticized the common practice of treating process groups as project life-cycle phases. ↩
9. In that 2019 article, Duncan noted that the original 1996 edition devoted roughly a page and a half of text (section 3.2) and two diagrams to explaining the relationship between phases and process groups, describing the process groups as overlapping activities occurring throughout each phase rather than as phases themselves. ↩
10. Duncan’s 1998 PM Network article distinguished different meanings of “standard” and argued that the PMBOK Guide was not mandatory or prescriptive in the compliance sense. ↩
11. PMI’s current description of the eighth edition says it retains principles and performance domains from the seventh edition while simplifying and clarifying them and reintroducing process groups as focus areas. ↩
12. In a later LinkedIn discussion, Duncan argued that the title A Guide to the Project Management Body of Knowledge had always been part of the problem and suggested that something like A Guide to Project Management Practice would have been more accurate. ↩
13. Svetlana Cicmil, Terry Williams, Janice Thomas, and Damian Hodgson, “Rethinking Project Management: Researching the Actuality of Projects,” International Journal of Project Management 24, no. 8 (2006): 675–686, argue that traditional project management literature describes what practitioners should do while neglecting the lived actuality of projects. ↩
14. Damian Hodgson and Svetlana Cicmil, “The Politics of Standards in Modern Management: Making ‘the Project’ a Reality,” Journal of Management Studies 44, no. 3 (2007), and the related chapter “Are Projects Real? The PMBOK and the Legitimation of Project Management Knowledge,” in Making Projects Critical (Palgrave, 2006), treat the PMBOK as an instrument that constitutes the project as a governable object rather than neutrally describing one. ↩
15. Lauri Koskela and Gregory Howell, “The Underlying Theory of Project Management Is Obsolete,” Proceedings of the PMI Research Conference 2002, 293–302, reconstruct the theory implicit in the PMBOK Guide — citing Duncan 1996 as its canonical statement — and argue that this foundation must be replaced by a wider and more powerful theoretical foundation. ↩

© Allen Evitts