Published here February 2013

Musings Index

Thoughts on a Global System for Categorizing Projects:
Have we really learned anything new?

I find it well worth my while keeping my eye on the well established thought leaders in the project management field. Two such people are friends of mine, Dr. Russ Archibald and Bob Youker. Their latest pronouncements prompted a number of thoughts that seem appropriate for one of my "Musings". These pronouncements appeared in the annual publication of the International Project Management Association. My thoughts were conveyed by Email as follows.

~~~~~~~~~~

Hi Russ,

I hope that your yearend activities are going well? And that 2013 will exceed your expectations!

For some time I have been meaning to comment (briefly) on your paper A Global System For Categorizing Projects in the 2013 Annual Publication of Project Perspectives[1],[2]. I know that the subject of categorizing projects has been a pet topic of both yours and Bob Youker, for some years.

You start out your paper with the observation:

"Most organizations recognize that the projects they fund and execute fall within different categories, but the discipline of project management has not fully recognized that different types of projects often exhibit different life cycle models and require different methods of governance: prioritizing, authorizing, planning, executing and controlling."

Aside from the fact that this sentence has 47 words, this is a huge thought-provoking sentence for the issues that it encompasses.

For example:
The first part, "the projects they fund and execute fall within different categories" is absolutely true for those organizations faced with selecting a limited number of projects from a whole set of opportunities because of limited resources. This activity falls under the heading of "Project Portfolio Management".

Then follows "but the discipline of project management has not fully recognized that different types of projects" suggests that "the discipline of project management" encompasses "Project Portfolio Management" (rather than the other way round!). I can see that project management associations, consultants and others have a vested interest in expanding their business territory and I have no problem with that. However, I think it is a pity to muddy the waters by also calling this larger territory "Project Management". That's because, according to PMI, project management is currently defined as: "The application of knowledge, skills, tools, and techniques to project activities to meet the project requirements". That is to say, it refers to the management of a single project.

I strongly believe that this separation is necessary because the knowledge, skills and compass of project portfolio management are quite different compared to managing a single project. Think in terms of the difference between, say, the disciplines of civil engineering and structural engineering under the general umbrella of "Professional Engineering". The problem is that, as yet, we do not have a suitable label to encompass the larger domain. Even program management is defined differently.

This extended use of the label "project management" is already causing confusion in the efforts by ISO supporters to establish standards of "governance" for "Project, Program and Portfolio management". That descriptor should, of course, be described as "Portfolio, Program and Project Management Governance" because governance is downwards and not upwards!

Then there is the question of "different types of projects often exhibit different life cycle models and require different methods of governance: prioritizing, authorizing, planning, executing and controlling." Of course they do, why should anyone be surprised? I suspect that there are as many different examples, as there are different "categories" or "Different Types of Project" as Bob Youker sets out to show in his paper. More to the point, I suspect that there are as many different examples as there are different companies within each industry practicing the art of project management simply to satisfy their own particular corporate control requirements. And that's a lot of examples!

However, I believe this aspect would be much simplified if we only applied the well-known principles of work breakdown structure to the problem. That is, at the first level of breakdown, we first drew a distinction between "Managing the Project" and "Managing the Technology". Indeed, most industries recognize this intuitively by assigning two separate individuals to a project for this purpose. For example, in civil works, a project engineer works with a project manager each with these respective responsibilities and, incidentally, with about equal status. A similar case can be made for large IT projects where the project manager works side by side with a project systems architect.

Moreover, even the PMBOK Guide identifies two major categories of processes in a project, namely: "Project Management Processes" versus "Product-oriented processes" and goes on to state:

"This standard describes only the project management processes. Although product-oriented processes are outside the scope of this standard, they should not be ignored by the project manager. Project management processes and product-oriented processes overlap and interact throughout the life of the project."[3]

Not that this concept is new by any means. It was, after all, promulgated by Dr. John Adams when he wrote Chapter 3 of the very first Guide to the Project Management Body of Knowledge published back in 1996, seventeen years ago![4]

Further, I think we should draw a clear distinction between "project management", as in "managing the project" as just described, and "project governance". Project governance has to do with the control needs of the organization that owns the project. These control needs are reflected in the design of the project life span and, once again, will be different for each organization.

With these distinctions in mind, I believe that it can be shown that the managing-the-project components will be largely similar amongst virtually all projects, while managing-the-technology will be essentially unique to the organization in question.

After all, it is the product that is unique, not the project management (processes). If this is true, then the analysis of the managing-the-technology should be a separate exercise. It may also be of limited use except for comparisons within individual industries.

However, having said that, it should not be overlooked that the style of management applied must be appropriate to the type of technology involved, that is, the types of skills that must be employed in the creation of the resulting product. If the wrong skills are employed, whose fault is that? Obviously, we could pursue this approach further and perhaps discover that the so-called high-failure rate of projects is due at least in significant part to a management-of-the-technology failure rather than to a management-of-the-project failure.

This at least would help to simplify your findings that:

• "What is 'best practice' within one project category is not necessarily the 'best practice' in another category", and
• "The factors that are important to success or failure in one project category are, in many cases, very different from those in another project category."[5]

With best regards,
R. Max Wideman

~~~~~~~~~~

Does anyone have any disagreement?

Home | Issacons | PM Glossary | Papers & Books | Max's Musings
Guest Articles | Contact Info | Search My Site | Site Map | Top of Page