Chapter OneWhat Is a Project?
Things are not always what they seem. —Phaedrus, Roman writer and fabulist
CHAPTER LEARNING OBJECTIVES
After reading this chapter, you will be able to:
* Define a project, program, and portfolio
* Understand the scope triangle
* Envision the scope triangle as a system in balance
* Prioritize the scope triangle for improved change management
* Apply the scope triangle
* Manage the creeps
* Know the importance of classifying projects
To put projects into perspective, you need a definition — a common starting point. All too often, people call any work they have to do a "project." Projects actually have a very specific definition. If a set of tasks or work to be done does not meet the strict definition, then it cannot be called a project. To use the project management techniques presented in this book, you must first have a project.
Defining a Project
DEFINITION: PROJECT 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.
Sequence of Activities
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.
CROSS-REFERENCE 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:
* What is needed as input in order to begin working on this activity?
* What activities produce those deliverables as output?
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.
CROSS-REFERENCE Chapter 6 covers resource limits and scheduling in more detail.
According to Specification
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.
CROSS-REFERENCE Chapters 4, 9, and 11 describe how to effectively handle client requirements.
A Business-focused Definition of a Project
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.
DEFINITION: PROJECT A project is a sequence of finite dependent activities whose successful completion results in the delivery of the expected business value that validated doing the project.
Defining a Program
A program is a collection of related projects. The projects must be completed in a specific order for the program to be considered complete. Because programs comprise multiple projects, they are larger in scope than a single project. For example, the United States government had a space program that included several projects such as the Challenger Project. A construction company contracts a program to build an industrial technology park with several separate projects.
Unlike projects, programs can have many goals. For example, every launch of a new mission in the NASA space program included several dozen projects in the form of scientific experiments. Except for the fact that they were all aboard the same spacecraft, the experiments were independent of one another and together defined a program.
Establishing Temporary Program Offices
As the size of the project increases, it becomes unwieldy from a management standpoint. A common practice is to establish a temporary program office to manage these large projects. One of my clients uses a team size of 30 as the cutoff point. Whenever the team size is greater than 30, a program office is established. That program office consists of nothing more than the management structure needed for the project. There will be a program director and one or more program administrators as support. The program administrators support the program manager as well as the teams. Even for teams of 30, there will often be a subteam organization put in place to simplify the management of the team. Each subteam will be led by a project manager. When the program is completed, the program office disbands.
Establishing Permanent Program Offices
A permanent program office is established to manage an ongoing and changing portfolio of projects. The portfolio consists of projects that have something in common — for example, all might be funded from the same budget, might be linked to the same goal statement, or might use the same resource pool. The permanent program office, unlike the temporary program office, manages a continuously changing collection of projects.
CROSS-REFERENCE Chapter 13 discusses the details.
Defining a Portfolio
A simple definition of a project portfolio is that it is a collection of projects that share some common link to one another. The operative phrase in this definition is "share some common link to one another." That link could take many forms. At the enterprise level, the link might be nothing more than the fact that all the projects belong to the same company. While that will always be true, it is not too likely the kind of link you are looking for. It is too general to be of any management use. Some more useful and specific common links might be any one of the following:
* The projects may all originate from the same business unit — for example, information technology.
* The projects may all be new product development projects.
* The projects may all be research and development projects.
* The projects may all be infrastructure maintenance projects from the same business unit.
* The projects may all be process improvement projects from the same business unit.
* The projects may all be staffed from the same human resource pool.
* The projects may request financial support from the same budget.
Each portfolio will have an allocation of resources (time, dollars, and staff) to accomplish whatever projects are approved for that portfolio. Larger allocations usually reflect the higher importance of the portfolio and stronger alignment to the strategic plan. One thing is almost certain: whatever resources you have available for the projects aligned to the portfolio, the resources will not be enough to meet all requests. Not all projects proposed for the portfolio will be funded and not all projects that are funded will necessarily be funded 100 percent. Hard choices have to be made, and this is where an equitable decision model is needed.
Your organization will probably have several portfolios. Based on the strategic plan, resources will be allocated to each portfolio based on its priority in the strategic plan, and it is those resources that will be used as a constraint on the projects that can be supported by the specific portfolio. Chapter 14 discusses the details.
Understanding the Scope Triangle
You may have heard of the term "Iron Triangle." It refers to the relationship between Time, Cost, and Scope. These three variables form the sides of a triangle and are an interdependent set. If any one of them changes at least one other variable must also change to restore balance to the project. That is all well and good, but there is more to this triangle.
The following five constraints operate on every project:
These constraints form an interdependent set — a change in one constraint can require a change in one or more of the other constraints in order to restore the equilibrium of the project. In this context, the set of five parameters form a system that must remain in balance for the project to be in balance. Because they are so important to the success or failure of the project, each parameter is discussed individually in this section.
Scope is a statement that defines the boundaries of the project. It tells not only what will be done but also what will not be done. In the information systems industry, scope is often referred to as a functional specification. In the engineering profession, it is generally called a statement of work. Scope may also be referred to as a document of understanding, a scoping statement, a project initiation document, or a project request form. Whatever its name, this document is the foundation for all project work to follow. It is critical that the scope be correct. Chapter 3 describes exactly how this should happen in its coverage of Conditions of Satisfaction (COS).
Beginning a project on the right foot is important, and so is staying on the right foot. It is no secret that a project's scope can change. You do not know how or when, but it will change. Detecting that change and deciding how to accommodate it in the project plan are major challenges for the project manager.
CROSS-REFERENCE Chapter 4 is devoted to defining project scope, and scope management is discussed in Chapter 7.
The following two types of quality are part of every project:
* Product quality — The quality of the deliverable from the project. As used here product includes tangible artifacts like hardware and software as well as business processes. The traditional tools of quality control, discussed in Chapter 3, are used to ensure product quality.
* Process quality — The quality of the project management process itself. The focus is on how well the project management process works and how it can be improved. Continuous quality improvement and process quality management are the tools used to measure process quality. These are discussed in Chapter 15.
A sound quality management program with processes in place that monitor the work in a project is a good investment. Not only does it contribute to client satisfaction, but it helps organizations use their resources more effectively and efficiently by reducing waste and revisions. Quality management is one area that should not be compromised. The payoff is a higher probability of successfully completing the project and satisfying the client.
The dollar cost of doing the project is another variable that defines the project. It is best thought of as the budget that has been established for the project. This is particularly important for projects that create deliverables that are sold either commercially or to an external customer.
Cost is a major consideration throughout the project management life cycle. The first consideration occurs at an early and informal stage in the life of a project. The client can simply offer a figure about equal to what he or she had in mind for the project. Depending on how much thought the client put into it, the number could be fairly close to or wide of the actual cost for the project. Consultants often encounter situations in which the client is willing to spend only a certain amount for the work. In these situations, you do what you can with what you have. In more formal situations, the project manager prepares a proposal for the projected work. That proposal includes an estimate (perhaps even a quote) of the total cost of the project. Even if a preliminary figure has been supplied by the project manager, the proposal allows the client to base his or her go/no-go decision on better estimates.