A project is a sequence of unique, complex, and connected activities that have one goal or purpose and that must be completed by a specific time, within budget, and according to specification.
This is the commonly accepted definition of a project and tells you quite a bit about it. This is a good place to start this discussion but I will improve upon it later with a more business-focused definition. To appreciate just what constitutes a project, take a look at each part of the definition.
A project comprises a number of activities that must be completed in some specified order, or sequence. An activity is a defined chunk of work.
Chapter 5 expands on this informal definition of an activity.
The sequence of the activities is based on technical requirements, not on management prerogatives. To determine the sequence, it is helpful to think in terms of the following inputs and outputs:
The output of one activity or set of activities becomes the input to another activity or set of activities.
Specifying a sequence based on resource constraints or statements such as “Pete will work on activity B as soon as he finishes working on activity A” should be avoided because this establishes an artificial relationship between activities. What if Pete wasn't available at all? Resource constraints aren't ignored when you actually schedule activities. The decision of what resources to use and when to use them comes later in the project planning process.
The activities in a project must be unique. A project has never happened exactly in the same way before, and it will never happen again under the same conditions. Something is always different each time the activities of a project are repeated. Usually the variations are random in nature — for example, a part is delayed, someone is sick, or a power failure occurs. These are random events that can happen, but you never are sure of when or how, and what impact they will have on the schedule. These random variations are the challenge for the project manager and what contributes to the uniqueness of the project.
The activities that make up the project are not simple, repetitive acts, such as mowing the lawn, painting the house, washing the car, or loading the delivery truck. Instead they are complex. For example, designing an intuitive user interface to an application system is a complex activity.
Connectedness implies that there is a logical or technical relationship between pairs of activities. There is an order to the sequence in which the activities that make up the project must be completed. They are considered connected because the output from one activity is the input to another. For example, you must design the computer program before you can program it.
You could have a list of unconnected activities that must all be complete in order to complete the project. For example, consider painting the interior rooms of a house. With some exceptions, the rooms can be painted in any order. The interior of a house is not completely painted until all its rooms have been painted, but they may be painted in any order. Painting the house is a collection of activities, but it is not considered a project according to the definition.
Projects must have a single goal — for example, to design an inner-city playground for AFDC (Aid to Families with Dependent Children) families. However, very large or complex projects may be divided into several subprojects, each of which is a project in its own right. This division makes for better management control. For example, subprojects can be defined at the department, division, or geographic level. This artificial decomposition of a complex project into subprojects often simplifies the scheduling of resources and reduces the need for interdepartmental communications while a specific activity is worked on. The downside is that the projects are now interdependent. Even though interdependency adds another layer of complexity and communication, it can be handled.
Projects have a specified completion date. This date can be self-imposed by management or externally specified by a client or government agency. The deadline is beyond the control of anyone working on the project. The project is over on the specified completion date whether or not the project work has been completed.
Projects also have resource limits, such as a limited amount of people, money, or machines that are dedicated to the project. These resources can be adjusted up or down by management, but they are considered fixed resources by the project manager. For example, suppose a company has only one web designer at the moment. That is the fixed resource that is available to project managers. Senior management can change the number of resources, but that luxury is not available to the project manager. If the one web designer is fully scheduled, the project manager has a resource conflict that he or she cannot resolve.
Chapter 6 covers resource limits and scheduling in more detail.
The client, or the recipient of the project's deliverables, expects a certain level of functionality and quality from the project. These expectations can be self-imposed, such as the specification of the project completion date, or client-specified, such as producing the sales report on a weekly basis.
Although the project manager treats the specification as fixed, the reality of the situation is that any number of factors can cause the specification to change. For example, the client may not have defined the requirements completely, or the business situation may have changed (which often happens in projects with long durations). It is unrealistic to expect the specification to remain fixed through the life of the project. Systems specification can and will change, thereby presenting special challenges to the project manager.
Chapters 4, 9, and 11 describe how to effectively handle client requirements.
The major shortcoming of the definition of a project I have been discussing thus far is that it isn't focused on the purpose of a project, which is to deliver business value to the client and to the organization. So lots of examples exist of projects that meet all of the constraints and conditions specified in the definition, but the client is not satisfied with the results. The many reasons for this dissatisfaction are discussed throughout the book. So I offer a better definition for your consideration.
3.145.50.124