Sample Chapter

Chapter One

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.

Unique Activities

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.

Complex Activities

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.

Connected Activities

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.

One Goal

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.

Specified Time

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.

Within Budget

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.

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.

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:

* Scope

* Quality

* Cost

* Time

* Resources

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

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.

* 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.

Cost

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.