0

In my last post, I outlined a revised definition of a “project”.

In this post (the second of four), I look in more detail at the main elements of this definition.

If you recall, the revised definition of “project” is:

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

the shorter version

“an endeavour created to produce a specific outcome.”

Let’s look at the elements of the full definition in more detail.

Human Endeavour

Human

It’s not only a given that people deliver projects, but the neglect of the human aspect of projects is the biggest creator of project impairment in most projects.

Endeavour

I chose the word “endeavour” carefully over terms like “initiative”, “process”, “venture” or “activities”.

In its common interpretation, an “endeavour” is just an activity or initiative, that some commentators see as too weak to define a project.

“Another fundamental problem with the basic PMBOK definition is the concept of an ‘endeavour’. The definition of endeavour used as a noun is: an attempt to achieve a goal; as a verb it is: try hard to do or achieve something. But, ‘making an effort to do something’ is completely intangible; projects involve people!”

Lynda Bourne (2016) – “Seeking a definition of a project”

But the word “endeavour” derives from the French verb “to must or have to”. It does not avoid the involvement of people. It means “people taking responsibility for something”. An endeavour requires commitment and implies accountability. These attributes of human engagement are surely a necessary part of projects.

Also, “endeavour” isn’t specific about a particular structure or approach. Nor does it have some specific definitions, like “process”. This is useful in an inclusive definition.

Created To

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. It is the project stakeholders who decide the project’s continuity, not a methodology. See more about Stakeholders towards the end of this yarn.

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.

Project Context

The project context is the multi-dimensional set of boundaries and constraints within which the project operates. Whatever context generates the project, provides direction and resources and receives the outcome is the context.

The project context is most often the organisation that hosts the project, and common examples are:

  • A business enterprise
  • A government body
  • A professional association, or
  • A social, religious and cultural organisation.

But the project context could be many other things: e.g. a social group, or a family, or even society at large.

It is a vital concept that no project is context-free.

To Produce

“Produce” has the sense of “to cause (a particular result or situation) to happen or exist.” (Oxford English Dictionary) We use “produce” in this sense and there is nothing particularly novel about this aspect of projects.

However, as we will see in more detail in a later post, the “production” term in this definition is the placeholder for the entire implementation approach and execution.

It is not the outcome that is unique and non-repeating, but the project’s production process. The set of resources, tasks, and all the variations of elements in the project context. This uniqueness of production gives projects a distinct identity, not the outcome. We’ll look at this different perspective of the outcome below. I’ll unpack the uniqueness of the production process in a future article.

Specific Outcome

Outcome

Using the term “outcome” is incorporates the different perspectives on projects and what they produce. Some perspectives see the outcome of a project as the deliverables that directly result from project activities. E.g. in a computer software project, the outcome of the project is the software together with ancillary deliverables such as training, documentation and documentation.

Other perspectives see the outcome of a project is the change that the sponsors intend to result from the delivery and use of those deliverables, i.e. the changed behaviour that the deliverables enable.

Whilst I lean more to the enablement vision of a project, the deliverables-based perspective is not invalid. Each has its pros and cons. Therefore, the definition of a project must be open to these different perspectives.

Specific

In addition, the project outcome must be a “specific outcome”.

An outcome is specific if it is:

  • Distinct,
  • Discontinuous, or
  • Differentiated.

Let’s look at those terms in more detail.

Distinct Outcomes

A project outcome is “distinct” when it is unique within its context. Or it can be distinct if it is like other outcomes but has key differences from other similar outcomes within its context.

The outcome need not be large to be distinct. Examples of large and distinct projects include:

  • the Manhattan Project,
  • the 3-Gorges dam project or
  • the project that developed the polio vaccine.

A distinct outcome can be something small, e.g. landscaping a garden or building a child’s treehouse.

Last, consider a project home design that a company builds many times over based on the same design. Different customers in different locations with slight construction variations are still distinct within their context. The context for each project home is the builder + customer + location, plus other more minor different attributes.

Discontinuous Outcomes

A project outcome is discontinuous when nothing in the project’s history or context could predict the outcome. The outcome is demonstrably different from anything the host organisation has produced in the past. It could be the type of outcome or the non-functional aspects of the outcome, e.g. volume, size, or technical complexity

Think of a builder of project homes who embarks upon a project to build a large multi-storey building. Or a manufacturing plant that produces petrol car engines deciding to design an electric car engine. Or a mining operation that comfortably ships 10 tonnes per day setting a goal to ship 1000 tonnes per day.

Differentiated Outcomes

To understand a “differentiated outcome”, let’s first look at “undifferentiated outcomes”. For example, the products manufactured in a factory or loan applications processed by a bank.

Each of the items processed in these situations is “undifferentiated”. Regardless of minor differences, each item gets the same treatment.

Let’s take the example of loan application processing. Loan applications processing deals with large numbers of almost identical items. Unique attributes of each application could include value, suburb, and existing loan details.

But each unique attribute as part of a generic class.

A loan from Mr and Mrs Solomon follow the same process as one from Ms Smith. Process logic changes the processing pathway based on these attributes. But all applications with the same characteristics follow the same pathway. For the sake of the example, let’s say the average processing time is ten working days. Thus, the Solomon and Smith applications are both likely to take ten working days to complete the process.

But what happens when we give a different treatment to a subset of otherwise similar outcomes? Such treatment gives the outcome an identity and makes it distinct (or even discontinuous). Such outcomes are “differentiated” from the others.

Take our loan application processing example. Imagine if the Director of Loans rings a supervisor in the processing centre and gives them specific instructions. She says “find the Solomon application and get it approved by tomorrow”.

In this situation, the Solomon loan application becomes differentiated. It has two new constraints: its identity and the delivery time (one day, not ten days).

And thus we have a project.

Stakeholders

At the beginning of this yarn, I highlighted the issues associated with poor recognition of human aspects of project management.

Another issue in most definitions of projects (and the practice of project management) is the almost equally flawed understanding of the influence of stakeholders.

Stakeholders are the actors within the project context who influence project initiation, structure, strategy and execution, all the way through to the final assessment of project completion and success.

Most narratives about project management either assume or prescribe that a methodology, process or life-cycle structure is the strongest influence on the project. This seems to be the primary reason for traditional definitions to include so many life-cycle and practice-related elements.

In a paper from way back in 2002, Patrick Weaver and Lynda Bourne were a lot closer to a better definition of a project than Lynda’s 2016 paper. They started with the PMI’s base definition and added stakeholder awareness, as follows:

“a project is a temporary endeavour undertaken to create a unique product, service or result which the relevant stakeholders agree shall be managed as a project

Weaver and Bourne 2002 – “Project Fact or Fiction (Will the Real Projects Please Stand Up)”

Adding stakeholder awareness was an insightful and smart step to improve the PMI’s definition. The problem occurred when they constrained the stakeholders’ decision-making and made their 2002 definition self-referential.

Lynda Bourne walked back this definition in her 2016 paper, but I think she walked it back too far because she removed the stakeholder awareness aspect completely.

Stakeholders will decide what stakeholders decide, and the results may or may not fit within the traditional definition of project. Stakeholders determine the “as, when and how” a project is delivered, based on a range of influences. It is not a given that the stakeholders will always and only think in terms of PMI or APM!

Conclusion

This definition isn’t that much simpler than the basic PMI definition. But it is much simpler than the other 35 in Max Wideman’s collection. This definition also removes one problematic and paradoxical element of the PMI definition. That is it removes the idea of a “unique product or service” that can also be repeated an unstated number of times. We’ll cover this more in the last of the posts on “What is a Project”.

There is more to cover in this new definition of a “project”.

Stay tuned.