Managing a large project can be an exciting,
career-enhancing event. But it can also be a
confusing, discouraging and messy business. There
is a team involved, usually not big enough; a
budget involved, also not big enough; and a plethora
of things that have to get done. You have to
deal with differing skill sets, differing time
schedules, differing motivations and the vast
difference between the time it "ought" to
take to accomplish a task and the time it really
takes. Effective project design can add cohesiveness
and direction to this otherwise unwieldy undertaking.
But project design itself can be fraught with
problems.
Strategic Project Design is not generally
taught in project management classes and focuses
on different things. It emphasizes the results
to be produced rather than the methods of achieving
those results. It focuses on the purpose, the
vision and the deliverables of a project, not
the activities, processes and means. Dealing
with activities is important, but in this approach
activity planning comes after the framework
is put in place.
Training Yourself
This newsletter will explain the structure
of each piece of the Strategic Design process
and how to implement it. Of course, no one
will become a master of managing projects
by reading this newsletter, but it is a solid
starting place for understanding the process.
Mastery will come from repeatedly applying
the principles discussed here to the designing
of real-world projects.
• Even though the design elements are
presented here in a linear fashion, this is
not necessarily a linear process. All sorts
of tangentially related things will pop into
people’s heads during the design session,
and a certain amount of discipline is required
to keep it from getting confusing. It is useful
to keep a flip chart handy as a "parking
lot" for ideas. They can thus be put aside
without being dismissed or forgotten.
• Communicate, communicate, communicate.
If you have questions about the project—what
makes it important, what resources are available,
anything that seems against the direction of
the company, anything that seems to provide
little value for the effort—ask your
boss or your boss’s boss, anyone you
need to ask to get clarity. Clarity is one
of the most powerful tools you can have.
The Future
As Charles Smith asserts in The Merlin Factor1
, "what you choose for your future is
more important than what you know about your
past or present capabilities." "The
Merlin Factor" is named for the magician
of King Arthur’s court who was said
to have been "born at the wrong end
of time [...and who lived] backward from
in front." Merlin’s actions were
thus informed by a future that other people
could not see.
Smith writes that "[l]eaders who use
the Merlin Factor, identifying themselves with
a particular visionary future, likewise act
on behalf of that future in the circumstances
of the present." It is this reverse temporality—starting
with a future (vision and objective) and working
back to the present—that is at the root
of the Strategic Design process described here.
Strategic Design
Strategic Project Design has four key components.
Vision—The overall context for the project;
the answer to the question, "Why are we
doing this?" or "what makes this
worth doing?"
Objective—A broad statement of the end
result; the answer to the question, "What
are we doing?"
Conditions of Satisfaction—Specific,
measurable conditions which must be met in
order for the project to have been completed
successfully. The answer to the question, "How
will we know the project is a success?"
Milestones—Specific, measurable results
which must be achieved along the way to each
Condition of Satisfaction. The answer to the
question, "What interim results must we
achieve, by when, to realize the Conditions
of Satisfaction?"
Vision
Vision is the answer to the question, "Why
are we doing this?" or "What makes
this worth doing?" The vision connects
the project to something bigger or more important
than the project itself.
Example: A project
to redesign the billing practices in a British
telecommunications company
initially looked to the staff of the billing
department like a directive from above. "We
have to do this because the boss told us to," the
team said. From their perspective, the solution
to the company’s billing problems was
simply to add staff to the billing department.
Early in the project design session, however,
the following facts came to light.
• Customers were
only getting one correct bill out of twelve.
• One-third of
their staff was devoted to fixing billing
problems.
• The processes
had been developed ten years ago, when the
company was young.
• They had experienced
phenomenal growth in the three years prior
to this meeting; so
rapid that all the systems were taxed to the
limit.
By virtue of articulating
clearly the current state of affairs in the
billing operation,
the billing staff realized that just adding
headcount would have resulted in a continued
waste of people’s time fixing problems
caused by antiquated systems.
This allowed them to
see the legitimacy and urgency of the project.
Their vision became
To Set the Company Up for a Successful Second
Decade. The effect of this vision on the billing
staff was dramatic. For the first time, they
saw themselves as the key to the company’s
future. Their project to redesign billing systems
became compelling and exciting.
Any large and long-term
project requires such a vision. If you don’t
see a compelling reason for doing your project,
then you should
ask a lot of probing questions until you are
convinced that the project is important.
A vision can provide you an environment within
which to operate, a small bubble of the future
in which your project can be realized and on
behalf of which you can take action.
An articulated vision
can operate as a haven for you. It can be
a place to which you can
return; something you can remember that will
straighten you out and get you back in action.
After the billing department’s project
design session, the staff went back to work
in their old environment with all the same
old problems to deal with. But they went armed
with their vision so that when they lost sight
of the reason for the project, they could bring
it back into view.
Objective
The objective is a short, straight-forward
statement of the intent of the project. Let’s
return to the billing example. The vision
of the project was inspiring to the staff
but it wasn’t useful for telling other
people what they were doing. The objective
they came up with was, "Rebuild the
entire billing system so the same resources
can be three times as effective."
This is short and concise
and tells the whole story in a nutshell.
It gives the listener
the general idea, and provides a basis from
which to ask more questions. Most people will
refer to the project in terms of the objective.
The billing project was referred to as the "Rebuilding
Billing" project.
Conditions of Satisfaction
Conditions of Satisfaction (COS) are specific,
measurable results that describe the successful
end point of a project—a snapshot of
the necessary conditions at that moment.
In other words, if the conditions are achieved,
the project will have succeeded, and if not,
it will have failed.
It is important that
all essential elements are considered. This
includes deliverables
that are easy to describe or measure and those
that are less tangible. One project I worked
with had a condition that there would be no "skeletons
in their closet." This was further defined
as "following each and every company policy
and ethical practice." The project participants
knew that they could probably achieve the result
if they overspent or cheated in some way, and
they were not willing to do that.
Other examples of actual Conditions of Satisfaction
are:
• Achieved a
72% good or excellent rating on the customer
satisfaction index in the Spring
1995 survey.
• The Manufacturing
Cost Of Goods Sold (COGS) is $.26 for the
third quarter.
• The monthly
finance reports are delivered by the 8th
of the month.
• Only one item
number is used to refer to any given product
no matter where it is
in the manufacturing cycle.
You are creating a future here. Not just any
future, but the one in which your project is
a success and on behalf of which you will be
acting.
Imagine yourself on
the day of the projects completion. You have
succeeded. How do you
know? Keep asking that question until there
is nothing missing. Periodically, read the
list of conditions (you should end up with
4–7 of them) out loud and then ask "Have
we (state the objective) or is something missing?" This
exercise will clear heads, quiet arguments
and crystallize the end point of the project.
You have to be careful about scope creep here.
These are minimal Conditions of Satisfaction.
Only include what must happen for the project
to be successful.
How? vs. What?
The entire framework of a project design is
based on "What?" questions. "What?" questions
focus completely on results, not on process
or methodology. "How?" questions
focus on process, method or means. Creating
the objective, conditions and milestones
is almost exclusively results oriented. You
are defining the results, the end points,
the deliverables.
Each part of the project
design must be measurable, but it is not
always evident what measure to
use. For example, if you have a customer satisfaction-related
Condition of Satisfaction, it is not enough
to say "We will have 100% customer satisfaction." You
must further clarify how you will know. Does
the company have a customer survey it uses
every year? Are you going to phone a sample
number of customers and survey them? Are you
going to count complaint calls? Numbers of
abandoned calls? Using a how question, you
are further defining what you will measure.
There is a Time to ask How?
Allow these "How?" conversations
until you have clarified the measurement issue
and then STOP!
Another reason for
briefly engaging in "How?" questions
is to allow people to satisfy themselves that
a result is achievable.
Aside from these exceptions, "How?" questions
should be held until after the milestones are
complete and the team members accountable for
the milestones are discussing their strategies
and plans.
Milestones
Milestones are often confused with Conditions
of Satisfaction. Milestones are specific
interim results that must be produced by
a particular time in order to produce a Condition
of Satisfaction.
Milestones differ from Conditions in that
milestones are stepping stones to the Condition.
A rule of thumb: if a result must be completed
prior to some other task, it is a milestone
and not a Condition of Satisfaction.
Milestones create a
framework for the achievement of the project.
At this point, you have a clear
idea about the end of your project, but no
sense of the smaller steps to get from here
to there (or, in the "Merlin" way
of thinking of it, from there to here). Milestones
make the project clear in scope, make it more
tangible, and reveal most of the resources
you need. Also, they can reveal breakdowns
you may encounter beyond those that are immediately
obvious.
To create milestones: Create milestones for each Condition of Satisfaction
separately.
Start with each end result and work backwards
asking the question, "What must happen
before that can happen?"
You will not be able to do this in a completely
linear fashion, because that is not how people
think, but starting with the end result will
yield a more linear thought process than starting
at the beginning.
The discussion to determine milestones can
be a brainstorming session of sorts. It happens
in streams of consciousness which sprout other
streams of consciousness. It is a give and
take conversation in which the connection between
the future and the present becomes real. It
should be allowed to flow freely.
The discussion is not without discipline,
though. The tendency will be to discuss the
details of each milestone. Keep the conversation
focused on the results to be produced.
After most of the milestones have been listed,
make sure they are in order and put dates on
them. Some of the milestones will fall into
natural groupings. Efficiencies will reveal
themselves, as will resource needs and leveraging
opportunities. And, perhaps most importantly,
it will become clear who must be involved,
either for their decision-making capability
or for their expertise.
Often, during the process of defining the
milestone time-lines, you will find that one
of the Conditions of Satisfaction you had defined
is actually a milestone of another one. In
other words, you must complete one before you
can start work on the other.
For example: At a recent
project design for an IS project, "new servers installed" and "new
software installed and tested" were both
defined as Conditions of Satisfaction. As the
team established milestones for installing
the software, they realized that the servers
had to be installed before they could install
the software. Therefore, installing the servers
was a milestone for installing the software,
not a Condition of Satisfaction.
If we hadn’t
done the milestone process, the dependency
would have been discovered when
the folks accountable for installing the software
went to work on their piece of the project.
Sample Milestones: If you had a project of increasing employee
satisfaction by a minimum
of 20% by the next survey on X date, one Condition
might be, "an 80% participation rate in
the survey."
The milestones might be as follows (each needs
a completion date):
• Get a count
of employees at each site.
• Designate a
site sponsor for each survey site.
• Have a meeting
of site sponsors to determine a plan of approach.
• Create and
implement a plan to communicate with the
employees.
• Provide training
for the site sponsors in introducing the
survey.
• Have the site
sponsors contact the site managers to create
partnership and get
buy-in.
• Create convenient
methods of filling out and turning in the
surveys which maintain
confidentiality.
• Conduct the
survey.
• Collect the
surveys.
This is neither the "right" set
of milestones, nor the only way they might
be ordered. But you can see the logic of the
flow of events.
The best way to create
milestones is in a meeting of the entire
project team. If this
isn’t practical, the next best approach
is to assign the creation of milestones to
the groups of people or individuals who will
be responsible for achieving the various conditions.
The least desirable approach is for just one
person—the project manager or any one
person on the project team—to create
the milestones.
And then...
Once you have finished the milestones, it is
time to assign accountabilities, create groups
or committees, get alignment on dates from
groups, establish a communication protocol,
and design a way to work out breakdowns or
issues that arise during the project. Each
person or group accountable for a Condition
of Satisfaction will design their own strategies
and plans for achieving their milestones.
In some companies, there are other elements
that must be produced before a project can
be considered fully designed. These may include
the budget, risk assessment, or linear responsibility
charts. These are much easier to create if
you have first completed the process described
above.
This approach has been used effectively in
both large and small companies, for huge, strategic
projects as well as small departmental ones.
Practice it, use it, and it will serve you
well.
Final Note
The final document resulting from the Strategic
Project Design process is for use by the
team working on the project. If others must
review or sign-off on it, revisit the Conditions
of Satisfaction to insure they are meaningful
to the reviewer. You might need to re-write
any internally focused conditions or at least
distinguish them from the externally oriented
ones. But work from the ones you like best.
Ultimately, it must empower you and the team!
(Handy Reference Guide)
Vision – The
projects high-level purpose. It is not always
measurable but it is always
inspiring.
Objective – A
short statement of the intent of the project
or what you are out to
accomplish. There might be some overlap with
the Conditions of Satisfaction.
Conditions of Satisfaction
(COS) – The
set of specific, measurable results that describe
the successful end-point of a project—a
snapshot of the exact minimal conditions in
that moment. In other words, if these conditions
are achieved, the project is a success, and
if not, it has failed.
e.g., With the objective: "to be the
most successful widget maker in the world," a
Condition of Satisfaction might be, "to
have $8 billion in sales next year in widgets." Ask
the question, "If I sell $7.9 billion,
will I have failed?" If the answer is "yes" then
you have a COS. If "no," then keep
looking until you find the minimum amount needed
to declare the project a success.
Milestone – A
milestone is a result that must have been
reached along the way to
achieve a COS. Milestones are created from
the end result, walking back to the present
from each COS and are only the key points along
the way. Each COS has two or more milestones.
A milestone might be
the result of a process or activity but it
is not the process itself.
If your objective is "to have $8 billion
in widget sales next year," a milestone
might be "to have $4 billion in sales
by the 2nd quarter." It would not be a
milestone to "review sales on a daily
basis." That would be a process in the
service of increased sales, but not a milestone.
|
