WITH THE ADOPTION of PMI’s new bylaws, PMI’s standards development program has been restructured, and the position of Director of Standards eliminated. As a result, this column now comes to you as an opinion piece rather than as a statement of PMI’s position. The column also changes from bimonthly to quarterly and from one page to two—less often, more words!
This month I’ll address some potentially controversial topics: the proper use of the term project charter; critical chain project management; and dumb decisions by smart people.
Q. A key output of my organization’s project planning process is a project charter. It documents the project’s critical success factors and major deliverables. It also includes a high-level description of the work breakdown structure, the project schedule, and the technical scope of the project. We find it so useful that I was wondering why it isn’t covered in the PMBOK™ Guide.
Back by popular demand, questions and answers on some hot topics.
Although one of the stated purposes of A Guide to the Project Management Body of Knowledge was to “provide a common lexicon within the profession for talking about project management,” there are many organizations that still use different terms for practices that are described in the Guide. That seems to be the case here.
Your project charter sounds to me like a project plan that has been developed as part of an early project phase—a preliminary project plan. While your project charter bears some similarities to a project scope statement, the inclusion of a WBS and schedule suggests that your charter is developed toward the end of the planning process (see the linkages among the processes in Figure 3-5 on page 31 of the Guide).
It may be an oversight in how you posed your question, but I’m surprised that this key planning document doesn’t include the project’s justification. I find that losing sight of why we’re doing the project is one of the most frequent causes of project failure. I think the project justification should be featured prominently in the project plan.
William R. Duncan, PMP, is with Project Management Partners, a project management consulting and training firm headquartered in Lexington, Mass., USA. He is the former Director of Standards for PMI and was the primary author of the 1996 version of A Guide to the Project Management Body of Knowledge. Send comments on this column to [email protected].
In comparing your project charter to a PMBOK™ Guide-style preliminary project plan, I don’t see any real difference in intent, only in language. But I do think that the language issue is important. Using PMBOK™ Guide terminology in this case provides some real benefits: recognizing that this document is, in fact, a preliminary project plan, should encourage its developers to consider a broader range of planning issues during its development—especially the facilitating processes in the areas of risk, communication, quality, and procurement.
One of the things I like best about the PMBOK™ Guide is this idea that each process repeats within each phase of the project (first mentioned in Section 3.2 and then repeated in the introduction to each of the knowledge area chapters). Based on my experience working with clients to implement Guide-based project management, this approach is far more effective than trying to identify different processes and different names for the project management outputs of each phase.
This use of the term project charter to describe a preliminary project plan is not uncommon—it is often used this way by information systems organizations and occasionally in the area of new product development as well. The project team working on the update to the PMBOK™ Guide considered this terminology, but the fact that it is rarely used in engineering and construction or aerospace and defense weighed against it.
Your question, however, raises another: If your organization uses the term project charter for what the PMBOK™ Guide views as a preliminary project plan, what term do you use for the document the Guide calls a project charter? The purpose of the Guide’s project charter is to provide authorization from management to devote resources to planning the project—a charter is provided to the team while a plan is developed by the team. In the absence of such commitment, the planning effort is likely short-changed and the project certain to suffer as a result.
Q. I keep hearing that “critical chain project management” is the wave of the future. Your thoughts?
Critical Chain Project Management (CCPM) was very much in evidence at the 1998 PMI® Seminars & Symposium in Long Beach. Are there some good ideas being put forth by the advocates of CCPM? Yes. Are they new and innovative ideas? Not as far as I can tell.
CCPM has its antecedents in something called the Theory of Constraints (TOC). TOC borrows heavily from systems dynamics (developed by Jay Forrester at MIT in the 1950s) and from statistical process control (which dates back to World War II). The two key tenets—think in terms of systems with complex interactions rather than in terms of unidirectional flows, and find and fix the big problems first—are absolutely the right approach, but they are also old news to experienced project managers.
In applying TOC to project management, CCPM follows the same trend—some good ideas presented as new insights. Here are a few of the good ideas: make sure your schedule reflects resource availability and not just activity dependencies; don’t let people work on activities that aren’t ready to be worked on; and try to keep resources working on one activity at a time to avoid the overhead of context switching. But they aren’t new—all of them are at least mentioned in the PMBOK™ Guide and all of them are well documented in the project management literature.
Reader Service Number 5068
Presenting old ideas in a new light is a time-honored approach found in everything from ancient religious texts to Reengineering the Corporation. Some proponents of CCPM, however, have advocated for the “goodness” of their approach by depicting current project management practices as “bad.” I think that has the potential for causing some organizations to throw the baby out with the bath water.
For example, one advocate for CCPM argued that scheduling activities on their early start date would divert the attention of the “project manager and team from what must be done.” Just not true. Unless the network logic is improperly defined, scheduling activities to start on their early start date is absolutely the right thing to do—it is actually the result of using the critical chain approach! Under the same set of assumptions (full-time resources, resource-constrained scheduling, 50 percent probability of timely completion, don’t spend your float if you don’t have to), a critical chain schedule will be identical to a CPM “early start” schedule.
CCPM also asks for full-time commitment of resources. This approach will, in fact, improve an individual’s productivity, so do it whenever you can. Remember, however, that getting part-time resources assigned to your project full-time means that something else (another project, your organization’s day-to-day activities) will suffer. Make sure that these resource decisions are made appropriately.
I’ve also read material from several CCPM advocates that seems to confuse the process of mathematical analysis with the creation of a schedule. The former facilitates the latter, but they are not the same. Mathematical analysis (whether critical path or critical chain) is a method for calculating early and late start dates so that the scheduler can decide when to schedule each activity.
So, if you’re having trouble with your projects, CCPM may merit a look-see, but remember that there is little magic in tools and techniques. If you are applying the concepts in the PMBOK™ Guide properly, I doubt that CCPM has much to offer.
Q. My employer is thinking of outsourcing our product development department (which includes both project managers and technical staff) based on an analysis from our accounting department that it will save money. I contend that it will cost money, but I don’t seem to be able to get anyone to listen to me.
In essence, you accuse smart people (the outsourcing proponents, your accounting department) of making a dumb decision. My experience is that these situations usually turn out to be the result of the two sides working with different data. I believe it was Alan Kay of Apple Computer who said, “point-of-view is worth 50 IQ points.”
Try putting yourself in their position. Try figuring out why they are making these decisions. Here are some possibilities:
Outsourcing will convert a variable cost into a fixed one. If the economy turns down or you have a product failure, the company may be able to survive better long term even if it means higher current costs.
You aren’t communicating accurately. The accountants may think you’ve questioned their process when in fact you’ve questioned their assumptions.
You may be perceived as self-interested—trying to protect your own hide rather than having the organization’s best interests at heart. If that is the perception, whether it is true or not may be beside the point.
They may be focused on project costs while you’re concerned with life-cycle costs. A common example: less testing keeps development costs down (low project cost) but increases the cost of later fixes, customer ill-will, etc. (life-cycle costs).
You might try surfacing the issue by addressing it head on: “I’m really puzzled. I know you guys are smart, and this seems like a really dumb decision. Could you help me understand it?”
GOT A QUESTION about the practice of project management? Send it via e-mail to [email protected] or fax it to 781/862-9908.