PMI Definition

There’s not much difference between mine and the PMI’s. But there are two main elements that I have removed:

the concept of “unique.”

the reference to “product, service.”

We’ll look at each of these below.

Uniqueness

The problem is that only a subset of all project outcomes is truly unique. PMI acknowledges this by allowing a certain level of repetition to apply to “unique” outcomes. But the problem is that the PMI is very vague on the level of repetition acceptable in a “unique” result.

This might seem like nit-picking but something is unique or not unique.

If you will allow a certain repetition in the result, then you had better be able to give a number or some other means of quantifying “repetition” to enable users of the definition to differentiate between “projects” and “not projects”.

The idea of “uniqueness”, even though it is vague, is a legacy element of older definitions that we’ll analyse in future posts.

Everything that PMI seems to have intended with the explicit concept of “unique” and the vague notion of acceptable repetition I achieve with the three types of specific outcome: distinct, discontinuous and differentiated.

The specific outcome formulation also includes many more situations as projects and so contributes to our view of a broad definition of “project”.

Product and Service

Referring to the terms “product” or “service” in the definition includes very specific types of outcomes. The term “result” is presumably included as a catchall phrase to cover outcomes that are not products and services. But there is no need to subdivide “outcome” at the definitional level. Otherwise we have included a hidden rule that defines why these are the top-level subdivisions of “outcome”. Why do we not also include “construction” or “policy” at this top-level as well?

The singular
“outcome” replaces all these alternatives and is complete and comprehensive.

Examples of more complex definitions

Here are two examples of complex definitions from Max Wideman’s Glossary:

“A novel undertaking or systematic process to create a new product or service the delivery of which signals completion. Projects involve risk and are typically constrained by limited resources.”

and

“A process or undertaking that encompasses an entire set of activities having a definable starting point and well defined objectives the delivery of which signal the completion of the project. Projects are usually required to be accomplished within limited resources.”

Common Elements

These definitions include many common elements of project management, depending on your perspective. These include:

new product or service or a novel undertaking

one-time-only initiative

novel process or undertaking

existence of constraints

presence of risk

use of structured or systematic processes

start and finish date

The question is whether these elements help or hinder our understanding and use or the definitions. The answer is that they don’t help because they aren’t definitional.

Elements not definitional

Firstly, while we can take issue with these definitions at some level, none of them is flat out wrong in a project management sense. We can all recognise aspects of the projects we’ve worked on in their wording. The problem is whether all projects and project types would fall under these definitions. I don’t think that they do.

Secondly, many elements are included for tactical reasons and imply or ‘stake out’ particular territory.

“Nevertheless, almost all the definitions quoted as examples from the Glossary are biased by some vested interest or predetermined agenda to suit its surrounding context. –

Lastly, is each element or clause necessary to the definition? Can you remove any of them and still have a project? Or does every single project have to have every definitional element? If not, then what rules determine which elements we can leave out?

I think the answer is that you can remove most of them and still have a project. It might not be the “kind” of project you were thinking about, but it still is a project.

Conclusion

If we look at the many terms (or elements) in a typical definition, very few of them are necessary to the core definition. However, they are essential to the typology of projects.

This broad and straightforward definition of a project is “backwards compatible” in principle, i.e. it doesn’t automatically invalidate any existing, more specific definition. We determine the validity of those definitions based on whether they correctly describe a type of project that applies to a subset of projects.

In my next post, I’ll explain why these non-definitional elements can be excluded from the definition of “project”.