Last post I laid out the “Manifesto for Action”: my goal for a broad and inclusive concept of project management. In this post, we define a set of conceptual tools. These tools will enable a broad-based analysis and discussion about projects.
The first of these conceptual tools is the foundation stone of project management: the “project”. In this multi-part post, I layout and explain a broad, scalable and generic definition of a project.
I’ll lay out the top-level proposition this post and dig deeper in future posts in this series.
The current situation: 50+ definitions of ‘Project’
Do we need 40 or 50 definitions for the concept of a project?
There really are this many. Look through the definitions in Max Wideman’s “Project Management Glossary“. This collection highlights the enormous range of formulations for this one term. And Max provides an interesting analysis.
Most are similar, and some are interesting. But they all use many elements that are not definitional. Most seem to pack as much as possible into the definition to nail down to some specific vision. These definitions are only from the plan-based or “traditional” project management perspective.
Are we talking about the same thing?
A simple definition of a project
Creating a definition of “project” is very simple. Remove all the complications, project attributes, constraints, and methodological vested interests. And this is what you get:
An endeavour created to produce a specific outcome.
It’s that simple.
Let’s look at the components.
An “endeavour” is something that people take responsibility for completing.
The “endeavour” is “created” specifically for this purpose. The project may or may not be live on after the target is achieved.
“Produce” has the sense of “to cause (a particular result or situation) to happen or exist.” This as defined in the Oxford English Dictionary.
I use “outcome” at a high-level because different stakeholders think that projects should produce different things. Some perspectives of project management see a project that produces deliverables. Others believe that the outcome is the change that the project intends to make; the changed behaviour that is enabled by the deliverables.
Outcome aligns with “value” which is a separate topic we will cover in future posts.
An outcome is “specific” when it is distinct, discontinuous or differentiated.
Distinct. when the outcome is unique or differs from other similar outcomes
Discontinuous. the “outcome” is discontinuous when it transcends past norms. Or when nothing in the project’s history that could predict an attempt on such an outcome.
Differentiated. the outcome is “differentiated” when its stakeholders identify it for specific actions. It is thus treated differently from other similar “outcomes” within its context.
We need nothing more than this to define a project and to build on this definition towards other definitions, such as “project manager”.
Where are all the other components?
If you mean the typical components of the other 50+ definitions: the answer is that we don’t need them. Terms such as “unique product” or “structured methods” or “resources” or even “start/finish” are unnecessary.
They don’t need to be in the definition because they aren’t definitional.
We need none of these to form the definition of a project.
There are two elements of definitions that we need to remove. These two elements originate in the early stages of project management.
Firstly, any comparisons to “Business as Usual” (or “BAU”) directly or indirectly. This comparison may have been critical when newly created project management needed to differentiation itself from other branches of management.
Secondly, we need to remove any need for practising project managers to recognise an endeavour as a project. This form of definition was always subjective at best and suspect at worst. How can their opinion be definitional? Project managers get their training the narrow set of constructs that give rise to many of the 40+ definitions,
Three aspects of projects that are definitional but aren’t in the definition above are:
- Human endeavour: It’s a given that people deliver projects.
- Project context: Every project is “hosted’ somewhere: it is visualised, resourced and funded by something, e.g. an organisation.
- Stakeholders: The idea that stakeholders have control over project initiation, structure and strategy is self-evident.
Including the unstated, self-evident elements, the full definition is:
“A human endeavour that is created in a context to produce a specific outcome, as, when and how determined by its stakeholders.”
but the definition that I’ll use moving forward is:
“An endeavour created to produce a specific outcome.”
This broad and straightforward definition of a project is “backwards compatible.” It doesn’t invalidate existing definitions. If they are already valid, they are just more specific cases.
We will dive into these concepts in part 2 of this series.