Archive for the 'PMBoK' Category

"Project Quality Management must address the management of the project and the product of the project"

(p.180, PMBoK, 3rd edition)

In an earlier blog entry, I presented the Nine Wastes of Mismanaged Projects, according to Lean Project Management gurus (Howell, Macomber, Koskela, Bodek). I said then that I saw a 10th waste adversely affecting project success: Not Managing Perceptions. Today, I will briefly explain why I believe that not managing perceptions is a major project waste, and why it has to be taken care of for our projects to be successful.

The sentence from the PMBoK quoted above is one of the most important messages on successful project management. It means that project quality, a strong indicator of project success, does not only depend on the physical characteristics of project deliverables, it also depends on HOW they were delivered. It means that a project is not only a destination, it is also a journey. It means that in matters of quality, BOTH the journey and the destination are important.

Read the rest of this entry ¶

The vast majority of projects involve a few people and take a few months. PMI and Prince seem to ignore that majority…but not Ron Rosenhead. Ron offers project management consulting and advice for accountants, attorney, librarians, and other professionals. He offers an approach based on a stripped-down version of Prince. Still, it may be more than these people need.

"Soft" is what makes projects successful.

Ron makes it easy for the motivated service professional to be successful with projects. He offers introductory material, a course-by-email, and an eBook, Deliver that Project. I've just finished reviewing the eBook. Attorneys and accountants will find it to be comprehensive. Most projects don't need more than Ron is advising.

I found one thing missing. Projects of all sizes and complexity depend on successful conversations for coordination. We act like conversations are the soft stuff of projects. For some reason "soft" is not important. Too bad. In my experience, "soft" is what makes projects successful. For those of you who are open to exploring the "soft" side of projects, have a look at these project meeting protocols. And, subscribe to Ron's email course while you're at it.

I read the following quote from Walter Bagehot in Time Magazine's end-of-year farewell to John Kenneth Galbraith.

"One of the greatest pains to human nature is the pain of a new idea."

The quote reminds me of the theory-trap we are in with projects. So with this posting I am updating my Notes on the Underlying Theory of Project Management is Obsolete.

While our tools are ever more sophisticated and there is more project management training, our project results languish. The new idea — projects are conducted in an unfolding network of commitments — challenges the very nature of what people do today in the project setting. The PMI is going to great lengths to teach people the old ideas.¹ In essence saying, "Just get good at doing what we've been telling you to do all along and your projects will come out just fine." Following that teaching with certification is producing a world-wide paradigm that is having the affect of blinding practitioners to alternative ideas (theories). In the face of that, the agilists are dealing with the pain of their new ideas; so are those adopting lean construction. Read the rest of this entry ¶

1. The PMI is succeeding. Membership has swelled from under 100,000 in 2002 to over 300,000 going into 2007. Attendance at conferences is at an all time high. And a cottage industry including top universities has grown to prepare project managers for the certification, CPM®. [ ⇑ back ]

Previous in series

In the last two weeks, three people have recommended Scott Berkun's The Art of Project Management to me. (They hadn't seen my posting the Art of Scott Berkun.) While I was impressed with the book when I read it last summer, I hadn't picked it up since. Now I have. I'm even more impressed.

Two years ago, Boston University said that the PMBoK® only represents 1/3 of what a project manager needs to know to succeed, Project Management: Art and Science. The art of project management is generally not taught and not well-described. 18 months later Scott's book filled that gap. The Art of Project Management is a handbook for developing yourself as a project leader. Notice my shift in terms from manager to leader. I'm taking my cue from comments Scott made in an online forum¹, "It's what I wish someone had told me when I started leading projects." Of course there are management tasks on projects, but what people need most from us is leadership. Here are five chapter titles to give you a sense of what he means by leadership: Read the rest of this entry ¶

1. BlogCritics Review [ ⇑ back ]

've been looking lately at the PMBoK®. In our work here in the New South Wales Department of Commerce we have a model of projects according to 7 parameters and I'm getting
someone to 'map' the PMBoK 9 areas of knowledge to our 7 'key success factors'.

Project management models neglect the fact that projects are humanistic endeavors: done by and for people, and thus are constrained primarily socially.

Our 7 are: service delivery (being that we're in public administration), affordability, sustainability, governance, risk, change (the change the project will bring about) and stakeholders (related to 'change').

I've taken a look at other models of project management recently and am coming to the conclusion that the (mechanistic) models are generally flawed because they concentrate not on the project, but on 'project management' as though this activity of bringing projects to fruition has an independent importance. They also neglect the fact, in my view, that projects are humanistic endeavors: done by and for people, and thus are constrained primarily socially.

I looked at Max Wideman's website where he summarises the state of project management in the 90s writing about how its expanded since the 70s:

"… Conceivably (project management) could still be expanded further by such potential additions as stakeholder management, cash flow management, data management, document storage and retrieval management, management of cultural differences, and even vocabulary management … With a little imagination, and research reading, one could add several more, such as critical chain buffer management,[27] customer relations management, issues management, public relations management, and even knowledge management[28] itself — the list seems almost endless."

Not only is this an example of thinking that seems to be more Fayol than Flores (or even more Fayol than Ford!), but it misses the point of what PM is. It's surprising that PM in traditional thinking gets hooked up on the secondary game, and simply seems to take to itself more and more descriptors which are about the project manager more than the project.

[As I write this I also am calling to mind what Mintzberg writes about management proper. Management as I understand his analysis is about facilitating productive relationships. That entails a heap of 'managements' of course (of finance, people, stakeholders, change, training, meetings, etc) but that's the fundamental organisational responsibility of a manager. refer, e.g. Mintzberg, H, The Manager's Job: Folklore and Fact, HBR March-April 1990 p163ff]

You could go on forever saying that project management includes [something] management, but that would achieve nothing more than statements of the bleedin' obvious and not be of any great help.

It helps me to think of project management as being about three things:

1. defining the outcome that is to be achieved (finished product, organisational change, etc by a certain time for a certain cost: quality of performance is implied in the basic requirement),
2. facilitating activity to effect the outcome (getting the right people, resources and knowledge to work in an effective co-operative sequence), and
3. taking steps to avoid or prevent harms to the outcome (ie risk, change and stakeholder management, and developing metrics to forewarn of potential problems to allow corrective action to be taken).

It goes almost without saying that the project manager role is to achieve the identified outcome with the minimum expenditure of resources and within the minimum time possible. Any trade-offs which have to be managed must be done so to maximise the 'outcome position' agreed by the 'community of intention' (the project team and its stakeholders) for the benefit of the 'community of interest' (the project recipients, users or customers).

It is merely trivial to say that this entails 'time management', 'communication management', 'issues management' or any other particular 'management', because the project manager is looked upon to do what ever is required to effect the outcome, administering and managing the project as appropriate; and that's the main demand upon the project manager. The project management models are strong on the administration and management minutiae, I think, without providing a theoretical or practical core value for project management.

Project management is facilitation of communities of productive intent to achieve desired outcomes.

As a corroborating illustration, a production manager in a factory doesn't define his/her role as a whole bunch of 'managements' to effect production, but as doing that which is necessary to effect production. Project management can be seen, I think, as production management where the purpose is one product which is somewhat individually characterised with respect to the relationships it affords with its 'community of interest' (those who will be affected by the project) and those it requires of its 'community of intention' (that is those doing the project, those who are its 'owners' and those who are its 'customers'). To be less abstract, compare a building to a toaster, or a public policy innovation to buying photocopier paper.

Like general management, project management is facilitation of communities of productive intent to achieve desired outcomes. With 'projects' noted as being more customised than routinised, relying on a temporary community for their realisation rather than an established or semi-permanent one.

But on the other hand, most projects have similarity with other projects. When I worked as an architect (registered), I did every project more or less the same: talked to the client, analysed needs, produced a 'brief', did a design, documented it, got approvals, estimated it, called tenders, and administered the contract. It was more like production management with the 'box' we produced changed to meet customer needs. The production system itself was almost identical each time.

Projects@Work - No-How: Can You Manage by PMBoK?: "A checklist of standards does not a methodology make. You need to go beyond what should be done on your project and figure out how it should be done."

This is a good article by Mark E. Mullaly, PMP on PMI, PMBoK®, and project management.

BUCEC Introduces Project Management Competency Model; Failure To Consider "Art" Called Major Factor In Project Failure

A major reason projects fail is that organizations typically think of project management as a science, not as an art, according to research from the Boston University Corporate Education Center (BUCEC).

BUCEC's model divides project management skills into three major categories - technical, personal, and business and leadership. The nine technical skills were previously identified by the Project Management Institute and are incorporated into the Project Management Body of Knowledge (PMBoK®). They include the ability to manage project integration, scope, time, cost, quality, human resources, communications, risk and procurement.

The other two thirds of the model - personal, and business and leadership - focus on the art. Personal characteristics identified by the model include achievement and action, helping and human services, impact and influence, managerial, cognitive and personal effectiveness. Business and leadership skills include a "big picture" focus, business acumen, organizational savvy and a productive work environment.

This is an important step. Boston University is a leading provider of PMP certification preparation training. That training typically focuses on the 9 technical areas of the PMBoK®. For BU to call this one third of what is needed to be successful will redirect the way companies are investing in their project management skill development. Let's hear it for BU!

Over a year ago I published a series of postings on the critical path method that produced all kinds of comments and emails from readers. I collected those postings into a two-page article that I published on this site as CPM: Fool Me Once, Fool Me Twice. Shortly thereafter, Greg Howell caught some article in ENR on CPM. It was the usual stuff about project managers just need to learn how to use the CPM tools. In an unpublished letter to the editor (with a copy to me) he replied this way:

"CPM is the tool for you if you believe what you know is more important than what you can learn, and if you prefer being "In Charge" to getting the project done, and if out-of-date plans are more useful than a team prepared for action."

Without promising the project is full of delay. That is waste. And it leads to more waste.

While I see what he is saying, and I think the phrasing is clever, many people might not get why he says it. Greg is indirectly pointing to the stasis of the use of the CPM tools. People don't have the habits or the inclination to keep the CPM schedules up-to-date. Little variations and missing task status can throw a CPM schedule out of whack. Soon people lose confidence and ignore the schedule.

Another key issue has to do with the authorization of work. The PMBoK® says something like, "Work is authorized by the schedule." Authorization is not the issue. Coordination among the team is the issue. Team members depend on the completion of work (prerequisites) so they can begin their work. But beginning work is the easy part. Other team members want to know when you will finish your work. They, just like you, want a promise. Without promising the project is full of delay. That is waste. And it leads to more waste.

Team members can make promises on the work they will perform informed by a CPM schedule. That would be wonderful. But we don't see that behavior. In fact, we see, as Greg so aptly puts it,

"The usual project meeting is a commitment-free zone." The CPM schedule is just one of the excuses for not doing what needs to be done."

What do you prefer? I don't know anyone who would identify with Greg's characterization. And teams need some guidance of overall sequence of work. Bob Huber, Scheduling Manager, The Boldt Company, suggests The Marriage of CPM and Lean Construction in his paper co-authored with Paul Reiser presented at last year's International Group for Lean Construction's 11th Conference. He urges people to use CPM at a high level rather than a detailed task level. Further detail is left to the people performing the work. The result is a CPM schedule that is easy to keep up-to-date and doesn't have swings in it from week to week. People will use that schedule.

Bill Duncan, original author of A Guide to the Project Management Body of Knowledge (PMBoK®), wrote a concise article, METHODS AND MEANS: For Good Measure, in the May/June Projects@Work journal. Bill covers the bases providing both a context for measuring project success and guidelines for developing useful metrics that matter.

I suggest we step back from the usual success criteria of cost schedule, and customer satisfaction. While performance in these areas matter, they are the result of doing other things well. Try these:

• What is the point or mission of the whole project? We might describe it as design and build something, or we could describe the mission in terms of the overall value created for the customer. Why the latter? Because even project missions can be expected to change over the project life. The customer learns, the team learns, circumstances change, and life happens.
• What is the reliability of task completions? When team members' work completes as expected others' work is released as planned.
• How are we doing learning and adjusting to the ever-changing project circumstances? Are we innovating? Are people growing in their roles? Is the customer getting more value than expected?

Take another look at your project measures. Focus on the variables not just outcomes.

The editors at Project Management World Today argue in their April editorial The Case of the Missing Domain that project managers struggle in a context-free project management process.

When business people take an interest in projects they ask different questions from project managers.

Any manager in a business organization these days will ask "(W)hen will this project be completed, and how much will it cost when it is?" as a start, but will also ask: "(H)ow will this project meet it's business goals, what risks are there to the business process? What value is delivered when we're done here? What does done mean?"

Those questions provide the context for shaping future action.

The author questions the relevance of project management that is context-free.

Missing is the acknowledgment that a "process" oriented approach is not sufficient. Putting the processes of PMBoK® to work in a context is not only necessary it is mandatory for the profession. But what context? Software development? Construction? Hard goods manufacturing? Aerospace? All have unique context dependent needs.

Concluding the PMBoK provides little value to the process of software development.

The editorial argues that practitioners want methods but aren't finding them.

(A)s a non-method, PMBoK leaves the PM professional without the tools to move forward. Methods are the means to problem solving. Without methods, the discipline of project management is simply a list of processes — it is context free.

People will continue to translate knowledge into methods and practice with or without the PMI.

There's been quite the discussion of Koskela's and Howell's papers in the NewGrange listserv group. Unfortunately, there's no archive of the discussion that you can read. I'll just say that people have very strong opinions about the value (or lack) of the K&H papers. The participants of the discussion group are experienced, well-versed, project professionals. One member is the leading author of the PMBoK®. After four days of debate, argument, sniping, and not listening to one another (IMO), I couldn't stay on the sidelines any longer. The following is my letter to the group. (Sorry for the length.)

Email to NewGrange. Subj: Re: Lean Construction and Traditional PM

I don't know where to start…so how 'bout I jus' offer a "stream of unconsciousness" (as one participant characterized my blogging) without the [snips] (references to specific postings).

I can echo many arguments on both (all) sides. I learned in Engineering Economics that one can justify many investments against a poor current case. Business is in a project age as Claude Emond puts it, yet our company systems, our formal education, and our vernacular all harken to days of the industrial revolution.

The usual case in companies I see is projects that are poorly initiated…unclear objectives, no one acting as a customer, late to staff, competing demands for team members, and piss-poor project leadership. The project uses some form of project software (MS Project or P3) operated by a computer jockey often detached from the team. We inappropriately characterize this situation as "traditional PM". It is bad management. Period.

Having said that, there are plenty of examples of well-managed companies, who take care initiating projects, providing appropriate staffing, and competent leadership who are dissatisfied with the results they get with other than agile approaches. (I don't want to get shot for calling it "traditional".) You may all be surprised to learn that the leading companies using the Last Planner were already leading companies in their markets. When asked why did they try something so different from the status quo they'll tell you their customers were dissatisfied with the waste; their investors were dissatisfied with the risks and returns; employees were burning out; and along the way people died building buildings.

[pause while I confront that reality again]

Even the well-managed firms deliver projects late, over budget, missing some key aspect of customer satisfaction, and the employees get hurt. We've been facing this for decades, centuries, millenniums. The broad population in the industry is resigned about those conditions. Did you know that construction represents 10% of the industrial workforce and 40% of the industrial accidents? Can you guess what percentage of those accidents are preventable? OSHA will tell you over 80%.

[let's pause again]

I won't go into the history of lean construction nor the more generalized lean project delivery. Suffice it to say it has its roots in the Toyota Production System which traces its roots to Henry Ford. Let me just say that the leading companies practicing a lean approach to project delivery were already getting their projects done on time. Not always on budget, but on time. They were already the safe companies enjoying experience modifier rates 30% or more better than the average. These firms are now delivering one project after the other on time or early AND at or below budget AND safer than ever before. The largest Danish contractor has been keeping records. They've found comparing 500,000 hours reported on lean projects with 500,000 hours reported on projects doing it the conventional way they are getting their projects done earlier (one to two months), cheaper (anywhere from 10% to 20%) and much safer (over 60% fewer lost time accidents). All of this is related.

I won't try to present the explanation in this five-minute email. Koskela and Howell spent considerable time writing their papers and still they have trouble explaining. Suffice it to say something very different is going on when projects are delivered in a lean fashion. Might complex adaptive systems offer an explanation? Yes, but still incomplete. Might lean thinking principles show the phenomena? Only partially. Linguistic action? That, too. CCPM? I wish. Here's my hunch…yes, it's a hunch, or maybe just an inkling…our deterministic reductionist approach to projects is the limiting condition. New theory must embrace both the uncertainty that is the project milieu and the unpredictable, serendipitous, richness of the human condition when interacting one with the other.

Call me an optimist. New theory will lead us to easier, more rewarding projects in the project age.

Today I complete my comments of the paper The Theory of Project Management: Explanation of Novel Methods
by Lauri Koskela and Greg Howell. The authors are careful to use the phrase underlying theory to denote that project management theory is not explicit. The authors make their inferences of theory from the practices and behaviors of prescribed project management.

Making inferences is tricky business. We can never be sure that what we say is right or wrong. So, we make our case. Later, all we can do is assess the relative usefulness of the inferences when we set out to act in accordance with them.

K&H use the word obsolete as their summary characterization of the effectiveness of current theory in use.

Obsolete: Outmoded in design, style, or construction. Superseded.

To call underlying theory obsolete is only to say that there is indication that it falls short in producing what is desired and something better is available. K&H are out to uncover better theory.

The authors place high value on theory. Not higher than being effective in action…explicit theory provides the opportunity for examination, measurement, learning, innovation, and resulting effectiveness of action. Like many others, the authors have been dissatisfied with the results of projects conducted along the lines of traditional or conventional practice.

>Their investigation of theory took them to the PMI PMBoK® as the obvious repository of theory. Reading their first paper I see their disappointment in the absence of explicit theory in the PMBoK® for guiding practice.

I know the authors. They would like nothing more than to engage in serious inquiry with project management theorists. So I Googled 'project management theorist' to see what I'd find. Max Wideman came out at the top of the list. Coincidentally, K&H have recently engaged in conversations with Max. Perhaps we'll see Max write about those dialogs. Max too calls for a need for explicit theory in a series of papers on First Principles. Redo the Google search to investigate others.

The authors chose an unfortunate point to break their text to insert Table 2: The underlying theories and assumptions of project management. Without carefully reading one might be left with the impression the contents of the table are the intended evidence to support their claims. In fact, the authors only name their sources of evidence without offering it in this paper. Those sources are:

1. the plausibility and consistency of the theory in itself;
2. empirical validity;
3. competing theories; and
4. alternative methods based on competing theories

The authors never claim their inferences of theory and assumptions represent evidence.

Why write about all this? Some say it's just pickin' a fight. I say why not write about it? Projects routinely take too long, cost too much, and fail in often significant ways to satisfy the customer. Scrum is one response to that dissatisfaction. Lean project delivery using Last Planner® is another response. Both approaches are producing good results. So…what's the fuss? Let new theory emerge.

Lauri Koskela and Greg Howell (K&H) argue successfully that current theory is obsolete in their paper The Underlying Theory of Project Management is Obsolete. However the authors may be limited in producing a new theory by exactly the same background paradigm that makes current theory obsolete. K&H seemingly accept the machine metaphor as appropriate for projects. Machines can be perfected; machines can by optimized; machines persist in spite of changes to the environment.

The machine metaphor conceals the nature of a project.

In accepting the metaphor they make three mistakes.

1. They accept "project management is a special instance of production" discussing inadequacies of theory in the production terms of "flow" and "value generation".
2. They continue to see planning, execution, and control as separate processes as proposed in their Exhibit 2. Ingredients for a new theoretical foundation of project management.
3. Their "Discussion" (section) misses the presence of people and all that is entailed by having the everyday influence of learning, innovation, relationships, and complex ever-changing behaviors on a project.

The machine metaphor conceals the nature of a project. Current theory is activity-centric as are machines. The usual practices of optimizing machines is by understanding it by component..breaking it down into smaller and smaller elements. This is the same practice employed in producing project work break-down structures. We've learned enough about reducing the waste of the materiel processes. We need to put our attention on a more significant waste…the under-employment of people on projects. We need practices that are systems-oriented and people-centric to produce project organizations that can respond to and enable learning, innovation, relationships, and effective action.

Where can we look for guidance? I am encouraged by the work in other fields (not projects or production) on autonomic systems, complex adaptive systems, and biomimicry. I also see the relevance of living systems thinking (Margaret Wheatley, A Simpler Way and Turning to One Another), community (Derek M. Powazek, Design for Community), and sustainability (William McDonough and Michael Braungart, Cradle to Cradle). I doubt current operations theory will provide a unifying theory for projects. Instead, I suspect we will see a convergence of thinking that will lead to new theory.

Consider this my leaping off point. Where this will go who knows!

Previous in series Next in series

Lauri Koskela and Greg Howell (K&H) do a marvelous job of capturing the experience of projects on page 11 of The Underlying Theory of Project Management is Obsolete:

"The deficiencies of the theory of the project and of the theory of management reinforce each other and their detrimental effects propagate through the life cycle of a project. Typically, customer requirements are poorly investigated at the outset, and the process of requirement clarification and change leads disruption in the progress of the project. The actual progress starts to drift from the plan, the updating of which is too cumbersome to be done regularly. Without an up-to-date plan, the work authorization system transforms to an approach of informal management. Increasingly, tasks are commenced without all inputs and prerequisites at hand, leading to low efficiency or task interruption and increased variability downstream. Correspondingly, controlling by means of a performance baseline that is not based on the actual status becomes ineffective or simply counterproductive. All in all, systematic project management is transformed to a facade, behind which the job actually gets done, even if with reduced efficiency and lessened value to the customer."

The first step in reform is talking about theory. What is a project?

Most projects do eventually complete. We can thank project participants for their "in spite of it all" approach. We see project participants acting contrary to the stated practices and standards of the organization and in so doing they deal with the problems of the project.

K&H show us the problems are not:

• incompetent management (and we could use more competence)
• low productivity from unmotivated workers (and interest in improving would help)
• customers who can't or won't make up their minds (and knowledgeable customers are easier to work with)
• poor practices of project scheduling (and it's not a computer issue)
• poor practices maintaining schedules (and we could use more staying in touch with what is happening)
• risk management (does anyone know what I'm even talking about?)
• scope creep (and we certainly can help our customers better understand what they could be asking for)
• add your favorite reason here (or two or three)

The problem with projects is the insufficiency or obsolescence of the underlying theory. There's plenty of work for us all to do to reform project theory and practice. The first step in doing that is talking about theory. What better place to start than at the beginning…what is a project?

Let's bring down the facade and the misery and waste that go along with it. Thank you Lauri and thank you Greg for getting us talking.

Previous in series Next in series

In Koskela's and Howell's (K&H) paper The Underlying Theory of Project Management is Obsolete they describe thermostatic control is the principal espoused (or inferred) theory of control on projects. Examples:

Thermostatic control locks us into a naive plan…uninformed by the world that has unfolded.

• Cool above 72° and heat below 68°.
• Returning from the South Pole navigating between sets of markers.

Thermostatic control is based on some decision/choice of what is right, or best, and then invokes corrective action when conditions vary from that stated norm.

What's wrong with this theory? You just can't set it and forget it. Unlike temperature or path, there is no one correct path on the project. The path to completion shifts throughout the project. Sure, we have a good idea of what must be done to finish, but the sequence can change and some of the tasks will fall off while other required actions will be discovered. Thermostatic control at best locks us into a naive plan…uninformed by the world that has unfolded.

Execution and control combine as performers rely on their intuition and experience.

The good news is we find the theory-in-use doesn't conform to the espoused theory. In response to out-of-date plans a