What is a project? Part 4: Non-definitional elements

by | Feb 23, 2020 | Project Management Concepts | 0 comments

This post is the fourth post in a series that presents a new definition of “project”.

In my last post, I looked at several definitions of a project, including the PMI definition, to identify components that were redundant.

In this post, I drill into why they are not definitional but are useful in other ways.

Remember, our new definition is (in full):

A human endeavour that is created within a context to produce a specific outcome, as, when and how determined by its stakeholders.

The short form is:

“an endeavour created to produce a specific outcome.”

Elements in Project Management Definitions

Analysing the ~34 definitions in Max Wideman’s Glossary yields over 200 terms, including the sample below.

  • new product or service or a novel undertaking
  • one-time-only initiative
  • novel process or undertaking
  • existence of constraints
  • use of human and physical resources
  • presence of risk
  • use of structured or systematic processes
  • pre-defined plan
  • control and execution
  • start and finish date
  • elements of the “iron triangle”: defined scope, time and quality (and their many variants)

These 200+ terms break down into seven major categories:

Type / Nature OfOccurs in # Keyword
project structure66
project context17
control and management12

(Look out for a future post with the full analysis)

What’s wrong with these terms?

What’s the problem with including all these common and obvious terms in our definition of a project? These are all terms with which project managers are familiar.

The problem is that none of these terms in and of themselves determines whether an endeavour is a project or a non-project.

Ask the following questions on each term:

  • If we remove a term, do we still have a project?
  • Is this term present in non-project activities?
  • How does the term help us discriminate between a project and any other activity?

For example, consider the term “budget” used to mean a measure of the resources used during project execution. Any business activity requires resources. Even if we define “budget” to imply a level of pre-definition, commitment and approval, the concept is not unique to projects.

Even within the subset of projects that have budgets, there is a wide range of budgetary devices and structures. There are many ways of obtaining getting approval for the budget and to consume it during project execution.

We most certainly need to consider budgets in project execution, but they do not define a project.

Is every one of the 200+ elements mandatory for all projects? Or do they only apply to particular kinds of projects? Or only apply to certain perspectives on projects?

The definition of “project” that I’ve proposed includes only those terms I believe discriminate projects from non-projects.

These terms are project attributes

How can we use the non-definitional terms that we’ve identified?

Almost all the 200+ project management terms we’ve identified are still fundamental to how we manage projects. They represent potential aspects, elements or components of the full set of all potential projects.

These elements are not present in all projects. They may be present in one form or another, or they may be present to a greater or lesser degree.

This full set of elements are attributes that describe any specific project or class of projects. There are three broad groups of project attributes:

  1. Functional attributes
  2. Non-functional attributes
  3. Contingent attributes

Functional attributes

Functional elements are present or absent from a project, but most don’t vary in their degree. Examples are:

  • Resources: All projects consume resources, but different projects may have different types of resources
  • Start and finish date: Although this might seem obvious, it’s actually not very clear. Every activity starts and ends at some point, but our perspective changes based on what are we classify as the project start and finish? Some projects have a very narrow definition. For example, they may only start on approval of a scope. Or they may finish immediately on handover of the project solution.  Other projects emerge gradually with no clear starting point or have very nebulous finish dates.

Non-functional attributes

Many of the attributes are non-functional, in that they are present to a degree with quantitative measures on a scale rather than “present” or “absent” from a project. Examples include:

  • Risk: Every activity on the planet involves risk. The issue is the nature of the risks and their probability. The aggregate degree of risk across a project is highly variable in multiple dimensions.
  • Uniqueness or novelty of the product or service: As I outlined in the previous post, the outcome does not have to be unique, just distinct, discontinuous or differentiated. However, the nature of the outcome and its degree of uniqueness or novelty plays a large part in planning and executing a project.
  • Onetime only initiative: The use of “onetime” in any definition of “project” is just a hook for the broader legacy concept that projects cannot be repetitive or else they become operations. In reality, it doesn’t matter if we do the same project repeatedly as long as we have a specific outcome to deliver each time. But this attribute informs planning and execution because the degree of “onetime-ness” requires variation in the project approach.
  • Constraints: As with risk, all human activities have constraints. So from a definitional perspective, the existence of constraints is redundant. However, the nature of the constraints and their degree of influence on the project informs both planning and execution?

None of the above attributes has a definitional purpose. But all the above inform the conception, planning and execution of all projects.

Contingent attributes

The presence or absence of “contingent” attributes dependent on other properties and we cannot determine them fully in advance.

  • Use of structured or systematic processes: The project management community puts great emphasis on the conflation of the concept of “project” with the use of “structured or systematic processes”. This is unsurprising. But is the use of structured or systematic processes a differentiator of projects from non-projects? Do only projects use systematic or structured methods? Is it impossible to run a project and be unstructured or unsystematic? I think the answer to all three questions is “No!”.
  • Resources: All projects consume resources, but so do all other human endeavours. The question of the type and the number of resources needed on any specific project is heavily contingent on almost every aspect of the project under management and not something that can entirely be determined ahead of time. Not in a definition. Also, whether a project has all the required resources is not definitional. Many projects suffer from under-resourcing: the project team simply has to make the best of what they have and report back any implications of schedule or output quality that may result.
  • Fully defined objective: most projects do not fully pre-define their objectives even when it is possible to do so. And the way goals are defined varies between different types of projects.

These various attributes don’t help us with the definition of the term “project”, but they help us in determining what kind of project we have.

A Typology of Projects

Projects exist in a vast range of forms and types. Each project is unique.

As we analyse the context and nature of any project, we must use all the relevant attributes to determine what type of project it is and therefore determine our project strategy.

These attributes inform a “typology” of projects that is useful knowledge to help us construct our approach to project management, right from the very beginning.

Tailoring, the lost art in Project Management practice

If you accept that each project is unique, but fits within a typology, then we need to create a unique project management approach for every project that we manage.

In my experience, the concept of “tailoring” a methodology has dropped out of common usage. Either we force project teams to use a corporate standard, from which little deviation if allowed, or the team ends up in conflict over which methodological religion to follow.

Tailoring is the art of adapting a methodology (or selecting which elements of a methodology to use) to construct the specific approach for each project, according to needs.

Even if any adaptation is allowed, it is frequently only the ability to select alternates from a pre-defined set, based on a simplistic “T-shirt size” categorisation.

The lack of tailoring imposes standardised life-cycle concepts onto each project without the critical assessment of which life-cycle.

This practice is not recent, as evidenced by the lament below.

“Any form of life cycle is a project management structure imposed on system development. To contend that any life cycle scheme, even with variations, can be applied to all system development is either to fly in the face of reality or to assume a life cycle so rudimentary as to be vacuous.”

Daniel McCracken & Michael Jackson 1982 – “Life Cycle Concept Considered Harmful” quoted in Poppendieck 2008 – “Expanding Agile Horizons The Five Dimensions of Systems”


If we look at the many terms included in a definition of “project”, very few of them are necessary to the core definition.  However, these terms represent attributes of projects within a typology.

Because all projects are unique, the ability of a project team to assess a project according to attributes is essential when defining a tailored project approach.

What’s next? We turn our attention to two legacy concepts that influence the definition of a project, but which are irrelevant or unhelpful or both.

Stay tuned.