Effective Engineering e-Newsletter – 11/4/2004
This is your monthly e-Newsletter from Effective Engineering Consulting
Services (www.effectiveeng.com).
If you would like to receive Effective Engineering e-newsletters as
they are published, please send an email to e-newsletter@effectiveeng.com,
and we will add you to our distribution list.
Comments and suggestions are welcome and encouraged!
eN-041104:
Project
Planning: Plan Based On What You Do Know, and On What You Don’t!
By Tom Dennis – President, Effective Engineering [tdennis@effectiveeng.com]
When you sit down to
start planning your next project, you lay out the tasks that will need to be
undertaken and completed, the time expected to be required for each task, the
resources that will be required for each of these tasks (and the availability
of those resources), the sequences in which these tasks must be done, and the
dependencies these tasks have on other tasks.
From this, and other considerations, a timeline can be developed,
milestones can be identified, deliverable dates can be estimated, and the
anticipated outcome of the project as a whole can be projected.
The natural approach is to base the project planning effort on what you
know will be required. However,
if you base your project plan solely on what you know, you may well be headed
for trouble at the outset of your project.
There are other considerations that you don’t fully know that you
need to take into account, and it’s best to consider them from the outset.
What you don’t know can hurt you.
So how can you plan based on what you don’t know?
I suggest you break your planning effort down into four categories – known
knowns, unknown knowns, known unknowns, and unknown
unknowns. By thinking in
these terms, you can more fully account for likely situations that will arise,
and build such situations into your project plan.
I will discuss each of these categories, and how to utilize them in
your planning efforts.
Known Knowns:
These are the things you know you need, and you know what they are.
These are what you normally base your project plans on.
You know these tasks must be done, you know about how much time is
needed to complete each task, you know who needs to perform these tasks, you
know the sequences in which they must be performed, and you know what tasks
depend upon other tasks to be completed.
Your last project required all of this information, and you are
comfortable assuming that your next project will be carried out with similar
knowledge and forethought. You feel comfortable saying to yourself (and others) that
since I did this before and it worked, I feel comfortable assuming that
similar planning considerations will lead to a successful project effort this
time. Of course, we all know what
happens when we “ass/u/me”; we make an “ass” of “u” and “me”.
That’s why we want to move beyond the known knowns.
Unknown Knowns:
These are things you don’t know you need,
but when you learn that you need them, you know what they are.
An example may be that you don’t know you will need a specific
software module, but you know how to account for that module, including how
long it will take to add it, who needs to be involved, when it needs to be
done in the sequence of tasks, what other tasks will depend on it, and what
other tasks it depends upon. You
may kick yourself for forgetting to include this task, but when you realize
that it is required, it is not a big thing to incorporate it into the overall
plan, and to quickly recognize the impact to the deliverables, and to let
everyone know what it means to the overall impact (benefits and costs). The key during the planning effort is to very carefully
review the requirements (remember when we said that requirements are so
important! See eN-041007
– Quality By Design!, eN-030703
– Product Definition: Define What It Is and What It Isn’t!,
and eN-030619 –
What Do Your Customers Really Want?), and identify to as thorough
a degree as possible what is required and account for it in your project plan.
It is often better to include too much in your initial plan and then
drop tasks that won’t really be needed than it is to add tasks once the plan
is in place, being followed, and being depended upon by others outside your
organization (like sales for example to plan for revenues coming in from this
project!).
Known Unknowns:
These are the things you know you need, but don’t know specifically what
they are. An example here is that
you know that your product must go out for agency certification (e.g. UL and
FCC), and you know how long that typically takes and account for it in your
plan, but you plan for success and don’t really know or account for the
impact if your product fails. Another
example is that you know that a certain feature is essential to your
product/project, but in an area that is completely new to the company, so you
have no experience to base an estimate of time, resources, or dependencies on. You plan based on your best estimate, but you know that
estimate is really a crapshoot. The
key during the planning effort is to have as much information as possible
about the risks associated with each task, and to take these risks into
account. One way may be to add
some contingency into these tasks assuming that something but not everything
will go wrong; this can give you dates with some, but not all risk accounted
for. Another way may be to
incorporate early finish and late finish intervals for tasks that are “known
unknowns”; this may provide more accuracy, but can get very messy from a
scheduling perspective. Risk
assessment is a large topic area that deserves and will receive special
treatment in a later e-Newsletter.
Unknown Unknowns:
These are the things you don’t know you need, and when you learn that you
need them, don’t know what they are. It
is very difficult, if not impossible, to account for “unknown unknowns” in
your project planning efforts. Often
the best you can do is to hold some brainstorming sessions with others to
identify areas where things could go wrong, reasonable and unreasonable.
Ask people to get creative in what could happen; this can actually be a
lot of fun. At this point,
don’t talk about solutions – only problems.
Then, after defining all of the possible Armageddon scenarios, discuss
what would be the likely impact for each of these catastrophes, and what could
be done to address them and how. Next,
try to order the list, in terms of the probability of such a catastrophe
occurring, in terms of impact to the company should such a catastrophe arise,
and other orders that make sense. Finally,
think about whether any of these potential catastrophes should be accounted
for in the project planning efforts, and if so, how.
Even if none of these are accounted for, you have at least done some
thinking about what could happen and what the plan of attack would be in such
an event. This could be worth its
weight in gold later on, when time and market pressures may prevent clear
thinking on how to address such problems.
Putting it all together:
OK, what does all of this really mean to your planning efforts.
Primarily it means to think beyond what you know.
Don’t become complacent because this is the third time you’ve done
such a project. Think outside the
box to include things you don’t know – likely, possible, or absurd.
By thinking about what you don’t know, you can do a much better job
in putting together a project plan that has a much higher probability of being
achieved. And this means better
products, delivered on time!
Copyright ©
2004
Effective Engineering Consulting Services, All Rights Reserved
