The Triple
Constraint
Quality. Speed. Price. Pick two. Advertising
Agency Lobby Sign |
 |
All projects, regardless of
size or complexity, are bounded by a Triple Constraint of time,
resources, and output.
The triple constraint is usually
visualized as a triangle with each constraint placed at a corner of the
triangle. The area of the triangle is the space within which
the project is done. This is sometimes called project scope. |
 |
Time |
The Time constraint encompasses
all of the time limitations on the project: When it must be delivered, the time
demands on the people who must be involved, the time demands on the equipment
that must be used, the time constraints placed on the project by management,
etc.
Schedule is the most common driving constraint on
most projects. You may be able to deliver a less-than-optimum output if you
deliver it on time. While this may seem to be an extension of the We
never have time to do it right but we always find the time to do it over
mentality, there may be other factors involved. For example, the deadline for
a project is not usually just pulled out of the air. If you ask some
questions about it, you will likely find that the deadline is related to some
other business need. For example, a process project may need to be implemented
by a certain date in order to link up with the delivery of material to be put
through the process. A new-product development project may need to be completed
to allow the product to be introduced at a national trade show. (It's funny,
but those trade show people are really sticky about their dates and they won't
delay the show because your product isn't ready.)
Of all of the constraints placed on projects,
the deadline for delivery is usually the least flexible. This does not,
however, mean that the way in which the time from the initiation of the project
to the deadline is used is also inflexible. On most projects, the amount of
time that can be devoted to the work is flexible, based on the importance the
organization places on completion of the project. |
Resources |
The Resource constraint encompasses
all the limitations placed on the project that involve either money or the
things money can buy: Material, outside expertise, machinery and equipment,
space, and most of all, the time and expertise of the members of the project
team.
If you think of resources as the
currency you can spend to accomplish your project, then the most
common denomination of that currency will be other people's time. Most project
leaders in businesses today do not control the budgets for their projects. In
many cases, they don't even know what the financial constraints are. Likewise,
they do not usually have control over the things that money buys such as
outside experts, equipment, raw materials, and space. This doesn't mean project
leaders can't influence these expenditures. However, they usually don't have
direct authority over them. |
Output |
The Output constraint encompasses
all the requirements placed on the final output of the project. This includes
all of the performance and quality characteristics: What must the output be
able to do or provide when it is delivered.
Of all the constraints placed on projects, this
is generally the most difficult to define clearly at the outset. This is not
to say that it is impossible, but it will require work and negotiation to
insure that the deliverable at the end meets the expectations set at the
beginning. Chapter 2: Project Pre-work, has several tools to help clarify and
define project output.
Back to Index
|
Excerpt from Chapter 2:
Project Pre-Work |
Researching the Need
A problem well stated is a problem half solved.
Charles F. Kettering 1876-1958 American Electrical Engineer and
Inventor |
 |
Whatever approach you choose to take (or whatever approach is
dictated by circumstances) is appropriate as long as it allows you to reach
some level of understanding of each of the issues listed above. You should
realize, however, that you will probably end up with an imperfect understanding
of one or more of them. This is, unfortunately, the nature of many in-house
projects - you must begin (and, in some cases, complete) the project with one
or more of the major issues undecided. The goal here is for you to develop the
best understanding circumstances will allow.
The following process is designed to provide a
structure for project pre-work. Some situations are very straight-forward and
do not require extensive pre-work analysis. Others are ill-defined, poorly
thought out, or more complex. Yet others have numerous possible solutions or
outcomes, any one of which might address the issue. This pre-work process will
guide you through defining the problem and some of the requirements of any
solution to it, and assessing overall project risks. In addition, for those
projects with multiple possible deliverables, there are three optional steps
you can complete to help with developing options and alternatives, analyzing
which option will best solve the problem, and assessing overall project
risks.
Many in-house projects are the result of someone
(inside or outside the organization) expressing a desire to have something
developed that will make their lives easier. This may seem like a simplistic
view of the situation but, when all the fancy language and specifications are
stripped from many project requests, they sometimes boil down to, If I
had this, I could do my work better, be more successful, have more free time,
make my boss happy, etc. These are the projects that usually fall into
the problem category. People are usually looking for a personal
benefit from the project. They want the problem solved. In these cases, you
can look for the benefits they expect and develop a project that will provide
them.
In other cases projects result from a desire to
take advantage of an opportunity rather than solve a problem. Most
product-development projects fall into this category as do many technology
upgrades and a fair number of the "quality of work life" projects such as
employee-benefit program upgrades, some training-development projects, etc.
Oddly enough, most organizations are more willing to do a more thorough job
on the pre-work for opportunity projects than on
problem-solving projects.
Some organizations seem to have an aversion to
going through this process for either type of project. They would rather see
something get started rather than spend time trying to detail why
and how it should be done. If yours is such an organization,
getting the answers to some of these questions may be difficult. However,
just because it isn't easy doesn't mean you should skip it. Get as much of the
information as you can and think through the rest - from the customer's point
of view. The structured process described here should help you through this
activity.
This project pre-work process involves five
required steps and two optional steps. The two
optional steps come into play when you have a project with several possible
answers and need some help determining which option to pursue. The steps are
(the optional steps are indented): |
- Define the problem or opportunity
- Determine Needs and Wants
- Rank Wants according to their importance and gain agreement among
stakeholders
- Write the project goal statement
- Develop options to deliver the desired outcome
- Compare options to Needs and Wants
- Assess overall risk
Back to Index
|
Excerpt from Chapter 3:
People Skills for Project Leaders |
Introduction
Managing requires setting aside one's ego to
encourage and develop the work of others. It requires a big
picture and team perspective rather than an individual-achiever
perspective. Sara M. Brown President, Sara Brown
& Associates |
 |
People are the key to any project. People will make the plans,
perform the work, solve the problems, track the progress, deliver the output.
Some skills in working well with people are critical for any successful project
leader. So, before getting too deeply into project planning and implementation
processes, a discussion of working with people on the project team and others
within the organization seems appropriate.
In-house project leaders usually work with
borrowed resources - people who are already scheduled by their managers to do
something else - almost always something unrelated to the project. In most
cases, the people working on your project will not report to you in the sense
of being your subordinates. You don't manage them. You don't write their
performance reviews. You can't grant them raises, bonuses, or promotions.
They work for someone else. You only have them on loan.
In situations like this, you can't manage
people in the traditional sense of telling them what to do and expecting that
they will do it. You need to lead them. You need to get them to perform
through influence rather than authority.
The material in this chapter covers a wide
range of people topics. Not all of them will apply to every
situation. However, the chances are quite good that you will eventually use
all of them sometime during your career as a project leader.
In this chapter, we will look at several
aspects of working with people, individually and in a project environment.
There are six topics that will be discussed: |
- The Development and Use of Power and Authority
- Motivation
- Leadership
- How Teams Grow and Change Over Time
- Negotiation
- Communication
Back to Index
|
Excerpt from Chapter 4:
Project Planning |
The Process of Planning is the
Important Thing
The plan is nothing; planning is
everything. Dwight D. Eisenhower 1890-1969 34th President of the United
States |
 |
If you are a just do it kind of person, planning may
be a strain. But, it is impossible to overemphasize how important it is. In
developing a project plan you are trying to identify and document: |
- The actual work that needs to be done.
- The appropriate sequence of that work.
- Which tasks can be done in parallel, which must be done sequentially,
and which can overlap.
- When the individual tasks should start and be finished.
- Who should be doing what, when.
- Where and when significant decisions or approvals will be needed and
who the decision-makers are.
- Where problems are likely to occur, what impact they might have on the
project, and what to do about either preventing or mitigating them.
- Which tasks need to be watched more closely than others.
- What deliverables are being created along the way and how to know if
they're any good.
- Which tasks need greater detail in the plan than others.
- When and how the final deliverable of the project will be handed off
to the customer.
At
the beginning of a project, all of this is, to some extent, unknown. What is
known is usually not in sufficient detail or depth to be of much use in the
day-to-day management of the project. Figuring all of this out is the purpose
of project planning.
Project planning, at least at the beginning, is
usually a sloppy, chaotic, stop-and-back-up-and-try-it-again kind of process.
There is usually some confusion about the work to be done. There will likely
be conflicting ideas about how complex or simple it will be. You'll find
different opinions about what things need to precede other things, what things
can't even be started until other things are finished and what things are
otherwise interdependent. There will be questions about who needs to do what,
when. Disagreement about what constitutes a major task versus a sub-task or
minor task is likely. You and the team will probably experience multiple
paranoid fantasies about what is likely to go wrong and what can be done to
prevent it. A highly rigid planning process will only make determining all of
this (and everything else you need to know before you get deeply into your
projects) more difficult.
In most cases, good project plans are the result
of a repetitive process - planning that is done in layers. The
layers are created in successive passes through the plan. In the
first several passes, flexibility is the key. If you try to finalize pieces
of the plan too early, you'll find that you have forgotten pieces; others are
out of their correct order; details are missing; etc. Project plans are almost
never set in stone. At best, they're set in semi-firm Jell-O®.
The chances that some part of the plan will need to be changed as the project
progresses are almost 100%. In fact, including plan review points
as part of the plan is a good way to make sure that the plan continues to
reflect the realities of the developing project. |
PROCESS TIP
Try to assemble some members of the project team to help with the
planning |
Project planning is best done
by at least some members of the project team as a group activity. It can be
done by a single person, but the process presented here is intended for,
and usually results in a better end product when done by, a group. This is
really a case of several heads being better than one. Multiple perspectives
on the project will give you a much better chance of creating a
comprehensive project plan that takes into account all of the aspects of
the project.
This doesn't need to be a huge group.
At the very least, try to have one other person involved
in the planning. Two or three additional people (with information and
expertise related to the project) are even better. Remember, most projects
will involve issues and tasks with which you are not totally familiar. You
will likely need input from others whose expertise is different from yours.
This will go a long way toward developing a plan that actually reflects the
needs of the project. |
|
Back to Index |
Excerpt from Chapter 5:
Project Implementation |
Status Reports
Information may be accumulated in files, but it
must be retrieved to be of use in decision-making. Kenneth J. Arrow Nobel
Laureate in Economics |
 |
Obviously, an integral part of monitoring and measuring is some
form of regular, documented status reporting from team members. You could rely
on your ability to contact everyone on the project team on a regular basis and
depend on your memory and some notes to always ask the right questions - this
is not recommended.
If you can hold regular team meetings, this is
an ideal forum for getting these updates. However, even if you have team
meetings - where everyone gives a verbal update on their activities - you
still need to have something in writing. You need a document trail of the
progress of your project. This is one of the absolutely essential pieces of
project documentation.
It is also important that status reporting be
done on a regular basis. Frankly, a weekly schedule is probably the best. If
your project has a long lead time and lots of extra time, you could let this
slip to bi-weekly - again, not recommended. Tasks left to themselves for any
extended period of time have a disturbing tendency to get off track. If you
let a task proceed for more than two weeks without checking on it, the chances
that it is drifting off track are better than 50/50 (sometimes much better).
Status reporting is not that hard and it should be done weekly. You can
stimulate and simplify the process for your team by providing them with a
fill-in-the-blanks format for activity. |
Status
Report |
| Fill in
the appropriate project information. Note the Reported by and
Interval Since Last Report lines. |
 |
 |
 |
 |
 |
 |
Project: |
 |
Date: |
 |
 |
 |
Project Leader: |
 |
Reported by: |
 |
 |
 |
Project Sponsor: |
 |
Interval
Since Last Report: |
 |
 |
|
 |
|
| This is the area for reporting
progress on project work. |
 |
 |
 |
 |
 |
Activities/Accomplishments: |
Since your last Status Report, what have
you accomplished on your project work? |
 |
|
| This area is for documenting
problems or opportunities encountered. |
 |
 |
 |
 |
 |
Challenges/Discoveries: |
In working on the project, what problems
did you encounter and what discoveries did you
make? |
 |
|
| Here is where actions taken
on problems or opportunities should be explained. |
 |
 |
 |
 |
 |
Actions on Challenges/Discoveries: |
What did you do about these problems
or discoveries - actions taken, results achieved, people informed,
etc.? |
 |
|
| This is the forecast for the
next period of project work. |
 |
 |
 |
 |
 |
Planned
Activities: |
What are you planning to accomplish
prior to your next scheduled Status Report? |
 |
 |
|
 |
Status
reporting is an excellent application for e-mail technology. It is not a
replacement for face-to-face meetings with team members, but it is a good way
to collect the written version of the report. If you use e-mail to collect
team-member status reports, compiling and summarizing the main points from
your team and adding your own status update is an excellent way to create an
overall project status report. This can then be sent to management, customers,
and other stakeholders.
Whatever process you use, the key is consistency
and regularity. Status reporting should become a process that is part of every
project you do. It is your primary source of information for decision-making,
problem-solving, tracking, and controlling your projects. |
Back to Index |
Excerpt from Chapter 6:
Project Closure |
Documentation and Training
Through training your employees and you can have a
greater degree of confidence that the work will progress through a pattern
that you designed. William F. Cone Manager of Professional Development,
Hughes Aircraft |
 |
Some documentation of the project's output is needed for virtually
every project. This can be as simple as a written description of the
characteristics of the project output - what does it do - or it can be as
complex as an operating manual containing detailed instructions about how
to use the project output.
Whatever the documentation needed, it should be
written in the customer's language and terms. Keep in mind the people who
will be using the project output and document it in terms that they can
understand and use.
The output of many projects, particularly
process-development projects, requires some degree of training to be carried
out during the implementation process in order to fully meet the customer's
needs. This training should be fully developed as a part of the project
deliverables. Training can be conducted by project-team members (as in the
case of many internal process projects and some software projects), or it
can involve training by others (as in the case of product or service projects
requiring outside-customer training by customer support personnel, or even
by a third-party training vendor). These projects usually require
participation by members of the project team in training the trainers.
As with project documentation, training
materials can be simple or complex. They should also be written in customer
terms and should provide sufficient information for the customer to
effectively use the project results.
Negotiations around these issues should focus
on whether the documentation and training meet the needs of the customer and
management. Adjustments may be necessary. |
PROCESS TIP
Get documentation and training development started early |
It is very important to
identify the need for customer documentation and/or training early in
the project planning process. Documentation and training materials don't
just happen. There can be extensive tasks involved in
developing them and these tasks need to be integrated into the overall
project.
One important thing to keep in mind is
that the project output does not need to be complete before documentation
and training materials can begin to be developed. Involve the people
creating your documentation and training programs early on in the
project. They can begin to outline their materials as soon as the
overall shape of the output has been decided upon. Then, throughout
the project, they can update and refine their work as the output
develops, finally delivering their work output at about the same time
as the rest of the project.
The last thing you need to happen is to
have the project deliverable sitting around for several weeks while the
training and documentation people try to catch up with it because they
were brought into the process too late in the project. |
|
Back to Index |
Excerpt from Chapter 7:
Process Tips for Distributed Projects |
Introduction
|
 |
There is a relatively new
phenomenon that is emerging in some
organizations. Distributed teams (virtual teams, multiple-location teams,
whatever you want to call them) are becoming much more common. These working
groups (they rarely become real teams) are geographically diverse. They
share some specific characteristics that impact how projects are done by
them. They need to communicate over long distances. They infrequently (if
ever) meet in person. They frequently are in different time zones and may
even be in different countries. This is not an ideal project environment.
But, more and more companies are putting projects together with this type
of dislocated group. If you find yourself with one of these projects, you
will need to take special care with the communication systems and the
general project-management processes for your group. Think of this chapter
as one big Process Tip for working in this dislocated environment.
First of all, many of the processes described
in this book won't work as well for you - at least not exactly as they've
been described. For example, the whole Post-It® Note planning process
becomes a bit difficult to use when everyone is in a different city.
Likewise, a team meeting by conference call is not going to work the same
way as a meeting where everyone is in the same room. The following are some
very general tips for dealing with some of the more obvious problems of
working on a project with a distributed team. |
Back to Index |
Excerpt from Chapter 8:
Process Tips for Multiple Projects |
Prioritization
|
 |
Now having made that depressing
statement, there are some things
that you can do within your projects to help avoid creating your own
prioritization problems. The first is to recognize and deal with this issue
of some things being more important than others. One tool that can help with
this is the Priority Matrix. |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
Requirement |
 |
Priority #1 |
 |
Priority #2 |
 |
Priority #3 |
 |
Priority #4 |
 |
Priority #5 |
 |
Priority #6 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
|
In
its simplest form, a Priority Matrix lists requirements down the left and
assigns a priority to each. The key is: There can only be ONE activity at each
priority level - just one number one, one number two, one number three, etc.
Using this tool forces you to make judgments about the relative importance of
each activity.
An example of a completed matrix is shown below.
This example shows the six major features, characteristics, or constraints of
a particular project. One might surmise that each of these is considered
critical to the overall success of the project. Unfortunately, some of them
are in conflict. The problem is to determine the relative ranking of each item
so that the project leader and the project team can make informed decisions
when the inherent conflicts begin to cause problems as the project proceeds.
This is not a decision that can be made by most project leaders without input
from management and other stakeholders. However, the decision still needs to
be made. The Priority Matrix can be a tool to help guide the discussion and
force a decision. |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
Requirement |
 |
Priority #1 |
 |
Priority #2 |
 |
Priority #3 |
 |
Priority #4 |
 |
Priority #5 |
 |
Priority #6 |
 |
 |
 |
Hit Marketing
price point
+/- 5% |
 |
 |
 |
 |
 |
 |
 |
X |
 |
 |
 |
 |
 |
 |
 |
Do not exceed
the resources allocated |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
X |
 |
 |
 |
Meet the
deadline |
 |
X |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
Complete the
prototype in time for the trade show |
 |
 |
 |
X |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
Keep all work
in house - no outside resources |
 |
 |
 |
 |
 |
 |
 |
 |
 |
X |
 |
 |
 |
 |
 |
Meet every
functional specification in the first iteration |
 |
 |
 |
 |
 |
X |
 |
 |
 |
 |
 |
 |
 |
 |
|
Here
is one way to interpret this information: |
- Meeting the deadline is the most important thing. Everything else takes
second place to that.
- Directly related to meeting the overall project deadline is meeting the
interim deadline of having a prototype ready for presentation at a trade
show. If these were the only things that the team needed to worry about,
this project would probably move ahead rather smoothly. Everything would
be geared to meeting these two deadlines.
- The third most important requirement is meeting every functional
specification. Nice to say; may be hard to do. If every specification
must be met by the prototype, the need to mobilize and focus resources to
meet that deadline could be a real problem.
- Now, let's complicate things by adding the requirement of meeting a
projected cost/price point that has been established by another department
(possibly without input from the people who will be doing the actual
development).
- Fortunately, the resource constraints are far enough down this list to
provide the possibility of either getting more in-house resources to help
with the work or, as a last resort, sending some of it outside.
|
The
real key to using this tool effectively is getting the buy-off of the people
who make the ultimate decisions about your project. This is a tool that should
be developed and discussed as early in the planning process as possible.
Unfortunately, if you simply ask the question: Which of these
requirements is most important? you are likely to get a response like:
They're all equally important. This is not much help. One way
around this is to develop a series of questions that might go something
like this: |
- If we have a situation where we can't meet the deadline without
additional resources, which would you prefer: That we miss the deadline
but keep the resources in check, or that we get whatever resources
necessary to meet the deadline?
- If we can meet most of the functional requirements within the deadline
and resource constraints to meet the trade show date, but there is one that
will require significant extra effort, which do you prefer: That we get the
resources necessary to complete it or that we let the prototype go without
that feature and work toward getting it done for the final product?
- If we are getting close to one of our deadlines and simply can't hit it
with the resources available in house, should we miss the deadline or bring
in the outside resources necessary to hit it?
|
Phrasing things in
this either/or format can force a decision and result in the establishment of
fairly realistic priorities. |
Back to Index |
Excerpt from Appendix A:
Project Planning and Management Checklists |
Needs Analysis
Activities |
 |
 |
 |
 |
A project leader has been selected. |
 |
The project's Customer has been identified. |
 |
The problem to be addressed by the project
has been defined. |
 |
Needs have been identified and verified. |
 |
Wants have been identified and weighted. |
 |
Alternative solutions have been developed. |

 |
Alternatives have been compared to Needs and those not
meeting all identified needs have been eliminated. |
 |
Alternatives have been screened through the Wants. |
 |
Risks have been evaluated. |
 |
The best alternative has been selected. |
 |
The constraints have been identified. |
 |
Time (starting date, due date, any significant milestone
dates). |
 |
Resources (people, materials, money). |
 |
Output (performance or quality characteristics). |
 |
A project Sponsor has been identified and
has agreed to support the project. |
 |
Stakeholders in the project have been
identified. |
 |
The core members of the project team have
been identified. |
 |
The first draft of the project goal has
been completed. |
 |
Connection of project goal to organizational goals has
been established. |
 |
Preliminary planning has been completed. |
 |
Planning resources have been requested. |
 |
Project goal has been approved. |
 |
Priority of the project has been
established. |
|
 |
Back to Index |
Excerpt from Appendix B:
Project Planning and Management Forms |
Project
Proposal |
 |
 |
 |
 |
 |
Project: |
Date of Proposal: |
 |
 |
 |
Proposed Project Leader: |
Proposed Due Date: |
 |
 |
 |
Proposed Project Sponsor: |
 |
 |
| Related Projects |
 |
 |
Preceeding Projects: |
 |
Completion Date(s): |
 |
Responsible Person(s): |
 |
 |
 |
Succeeding Projects: |
 |
Start Date(s): |
 |
Responsible Person(s): |
 |
 |
 |
Parallel Projects: |
 |
Completion Date(s): |
 |
Responsible Person(s): |
 |
 |
| Project Description |
 |
 |
Problem or Opportunity to be addressed by this project |
 |
Detail |
 |
 |
 |
Business Purpose of this project |
 |
Detail |
 |
 |
 |
Expected Impacts/Effects of this project |
 |
Detail |
 |
 |
 |
Project Deliverables |
 |
Detail |
 |
 |
 |
Key Milestones (based on deliverables) |
 |
Detail |
 |
 |
 |
Major Constraints and Key Assumptions |
 |
Detail |
 |
 |
 |
Items/Issues specifically excluded from this project |
 |
Detail |
 |
 |
 |
Resources Expected for this project |
 |
Detail |
 |
 |
 |
Estimated Total Person Hours |
 |
Detail |
 |
Estimated Cost |
 |
Detail |
 |
 |
Instructions:
Not every project will require all of this information. Complete
the appropriate sections. Include or reference any additional detail
needed for a complete understanding of the proposed project. |
|
 |
Back to Index |