|
Published here November 2016
|
|
What Have We Learned from Our Efforts to Dissect "Project"?[7]
We have learned that:
- Projects do not exist in nature. They exist only as "artificial constructs"
within the confines of some organizational structure that has decided to assign
a segment of work intended to deliver some specified outcome. This "project" approach
is adopted because it has "proved its worth". The essence of a project is its
team-of-skills approach. However, a single person with the necessary skills can
conduct a project on his or her own.
- In technical terms, the word "project" is not as simple as it appears. A project
is essentially a process that is typically constrained by limited resources, time
and money, and a sophisticated project can be extremely complex. In its very basic
form, a project consists of a "planning" process followed by a "doing" process,
known as implementation or execution.
- It has a start that is sometimes difficult to identify, or is set arbitrarily,
but the finish is determined by the successful delivery of the required deliverable,
i.e. the delivery of some outcome, product, service or result of benefit to the
project's sponsors. However, this delivery must also include any subsequent delivery
obligations together with the completion of all administrative work, such as closing
of accounts and so on. Note, however, that if at the end the customer is not satisfied,
the project can hardly be said to be "successful".
- Not all projects represent the endgame. They can be "enablers" providing a
vehicle for a subsequent project to create the final end product of value. This
is typical of "Program" management for example. The exact sequence of activities
in the project process, especially at the corporate control level, (in other words,
the project's life span,) depends largely on the "Area of Project Management Application"
e.g., construction, administration, Information Technology, healthcare, and so
on.
- Because of the "newness" of the required deliverable, the project is subject
to uncertainty, which may be a risk, but can also be an opportunity, and often
both. Much of this "risk" could arise from poor management. However, the risk
is more likely to be in the product's technology, the environment in which the
project is undertaken, the environment in which the product is expected to perform,
and the use to which the product is actually put.
- Ideally, a project should be launched on the basis of a justifying Business
Case. That is, a Business Case that sets the direction, the expectations, and
the ultimate measures of success. Of course, a project may be stopped before completion,
i.e. abandoned for some good reason, but that does not stop anyone from referring
to it as a "project".
- However, almost all of the foregoing descriptions are included in the essential
understanding of "process".
7. The source
of the following remarks is the observations collected in our previous paper:
Defining the word project… here: maxwideman.com/papers/defining_project/intro.htm
|
|
The
Need for a Specific Definition of "Project"
