This post is the 2nd of four yarns covering a revised definition of the concept of a “project”.
If you recall, our new definition is:
“an endeavour created to produce a specific outcome.”
In my last post, I outlined a revised definition of a “project”. That post:
- gave a summary of the definition; and
- sketched out the reasons it removed elements included in older definitions.
In this post, we look in more detail at the main elements of this definition:
The project context is not explicit in the definition but is a vital implied reference point. The project context is the boundaries and constraints within which the project operates. Project context is most often the organisation that hosts the project. Common examples are:
- business enterprise,
- government body,
- professional association, or
- 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. Whatever context generates the project, gives resources and receives the outcome, is the context.
I chose the word “endeavour” carefully over terms like “initiative”, “process”, “venture” or “activities”. Endeavour has been criticised as being weak – merely “an attempt to do something”
But the word “endeavour” derives from the French verb “to must or have to”. It means “people taking responsibility for something”. Endeavour requires commitment, which is 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.
The use of “outcome” is high-level because different stakeholders think that projects should produce different types of things.
Some perspectives of project management see a project 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.
This leaves the definition open to these different perspectives.
In addition, the project outcome must be a “specific outcome”.
An outcome is specific if it is:
- discontinuous, or
Let’s look at those terms in more detail.
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
- one of the projects distributing the polio vaccine.
A distinct outcome can be something quite small, e.g. landscaping a garden or building a child’s treehouse.
Last, consider a project home, 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.
A project outcome is discontinuous when nothing in the history of the project context could predict the outcome. The outcome is demonstrably different from anything the host organisation has produced in the past.
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.
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 is treated the same.
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 a subset of these otherwise similar outcomes is treated differently? 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 gave 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 new two constraints: its identity and the delivery time (one day, not ten days).
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”.