Last post I laid out the “Manifesto for Action”. I want to establish a broad and inclusive concept of project management that looks at fundamentals and avoids sectarian labels. The first step towards this goal is to define a set of conceptual tools that avoid labels, fixed perspectives, or vested interests.
These tools will enable a broad-based analysis and discussion about projects.
The first of these conceptual tools is a revised definition of the “project”. In this multi-part post, I explain a simple and scalable definition of a project that can apply to projects of all kinds.
In this post, I’ll start with the top-level overview of this definition. I’ll dig deeper in future posts in this series.
Why is it important to have a simple definition of “Project”?
The most obvious use of agreed definitions is to improve communication between stakeholders. Lynda Bourne says it all in one of her yarns on this topic. (We’ll come back to those yarns later).
“The simple fact is if you cannot define something precisely, you have real problems explaining what it is, what it does and the value it offers, and this lack of definition/understanding seems to be a key challenge facing the project management community.”Dr Lynda Bourne (2016) – “Seeking a definition of a project”
The domain of project management in its broadest sense has spawned an amazing diversity of perspectives and viewpoints. Over much of the last century, the practice of “organised human endeavours” has seen the almost continual emergence of new theories, movements, methodologies and toolsets to produce a complex and dissonant landscape.
If we considered only the unhelpful and inefficient divisions between the “traditional” project management domain and the agile domain, that would be enough motivation to clarify and simplify. If only that were the total of our problems: the problem extends far beyond just that dichotomy.
To establish new conceptual tools to improve our understanding and practice of project management, we need to start right at the beginning and clear away as much of the complexity as we can.
So let’s start with the current situation.
The current situation: 40+ definitions of ‘Project’
Do we need 40 or more definitions for the term “project”?
Look through the definitions in Max Wideman’s “Project Management Glossary“, in which he lists 34 of them. Pick up any book on project management: you’re just as likely to find a new one as find one of Max’s. Not only does the collection highlight the wide diversity of definitions, but Max also provides useful editorial commentary and an interesting analysis of the origins of many of these terms.
Most of these terms are similar; some are interesting or even weird. 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 only derive from the plan-based or “traditional” project management perspective.
Are all these definitions 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. That’s all you need to describe a project and to differentiate projects from other kinds of human activity. This definition includes all traditional projects, agile initiatives and any other kinds of endeavours to which we want to apply project management perspectives, techniques and tools.
Superficially, it is like the original PMI definition, but it takes a different approach.
First, let’s look at its components. Then we’ll look at what we’ve removed.
Components of the Definition
In its common interpretation, an “endeavour” is just an activity or initiative. But deep in the term’s history is its derivation from the old French verb meaning “to must or have to”. An endeavour is so much more than people just “having a try”. An endeavour is an activity for which people take responsibility, both in execution and completion.
This is a key aspect of projects and one that we will revisit.
A key tenet of traditional thinking on project management is that a project is temporary. PMI called this the automatic “death sentence” that sets up when creating the project.
But a project may or may not live on after it achieves its target. A project need not be temporary.
What is important is that the sponsors of the project set it up specifically to achieve the outcome. We will look at why this is important in a future post in this series.
“Produce” has the sense of “to cause (a particular result or situation) to happen or exist.” This as defined in the Oxford English Dictionary. Nothing particularly novel about this.
I use “outcome” at a high-level because different stakeholders think 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; i.e the changed behaviour enabled by the deliverables.
Outcome aligns with “value,” which is a separate topic we will cover in future posts.
Traditional project management narrative places much emphasis on the need to create a unique or novel “product, service or outcome“. We’ll go into this issue in a later post to describe why it is unhelpful or even misleading.
A project needs to create a “specific outcome”, which is not necessarily unique or novel. 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 organisation’s history or project’s context that could predict an attempt on such an outcome.
Differentiated. the outcome is “differentiated” when its stakeholders identify it for specific actions. The project thus treats this instance of a non-unique outcome differently from other similar “outcomes” within its context.
Where are all the other elements?
All the other elements of those 40+ definitions are in fact not “definitional.
Terms such as “unique product” or “structured methods” or “resources” or risk even “start/finish” are unnecessary.
These elements are very important to some projects, but they don’t define a project in its core sense, because their presence and/or importance in any individual project is not a given.
We don’t want to lose sight of these elements because they inform a typology of projects that is very important to successful project management.
One of the least exercised skills in project management is tailoring, which we will address in future posts.
Legacy aspects of traditional definitions
Most of the non-definitional elements of projects can inform the project type, but not all. Some elements we need to remove completely, including:
- Comparisons of projects to “Business as Usual” (or “BAU”) activities, either directly or indirectly.
- The concept that an initiative is only a project if practising project managers recognise an endeavour as a project. This form of definition was always subjective (at best) and suspect (at worst).
We don’t normally find these two aspects in definitions explicitly. We find them in the surrounding narrative and analysis of definitions, typically when looking at examples of different activities to test them against one or more definitions.
We will return to these legacy aspects later in the series.
Three elements of projects that are definitional but aren’t in the short version of the definition above are:
- Human endeavour: It’s a given that people deliver projects.
- Project context: Every project is “hosted’ somewhere. Each project is initiated by and gets resources and funding from some entity or context, e.g. an organisation or social structure.
- Stakeholders: that stakeholders have control over project initiation, structure, and strategy is self-evident.
If we include these implied and 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.”
I’ll most often use the short version:
“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.
This definition applies to all types of projects, methodologies, perspectives and viewpoints. It includes both traditional or agile, formal or informal, technology, organisation or culture.
We will dive into these concepts in more detail part 2 of this series.