|
| |
Back to
e-Newsletter Archives:
 Effective Engineering e-Newsletter – 10/23/2003
This is your bi-weekly 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-0301023:
Development Methodology: Failing to Plan Means
You Are Planning to Fail!
By
Tom Dennis – President, Effective Engineering [tdennis@effectiveeng.com]
Nike may tell you to “Just Do It !”, but in product
development, which by nature is fraught with complexity, uncertainty and
ambiguity at the outset, if you “Just Do It !” without first defining
WHAT you want to do, WHY and HOW you want to do it, and WHO will do it and WHEN,
you are destined to encounter problem after problem.
You will likely not deliver on time, will have quality problems galore,
will need to add staff late in the project (which will only make it later), and
will incur much higher development costs than if you “Just Do It Right the
First Time !”.
Where the last two e-Newsletters talked about the WHAT (see eN-030925
– Development Methodology: Requirements) and the WHY and HOW (see eN-031009
– Development Methodology: Architecture) of product development,
this e-Newsletter talks about the WHO and WHEN.
As with the others, this one also concentrates on the first stage of
development, Requirements & Architecture.
The WHO defines the specific allocation of resources for the various
tasks to be undertaken. The WHEN defines the time-related activities (i.e. the
timeframes, milestones, schedules, dependencies, etc., including WHO does what
WHEN) that must be met to accomplish the goal of delivering the product
development on time, with high quality, and within budget.
I’ll cover some more specifics of planning in another e-Newsletter, but
here I discuss the need for planning in general, and some of the frustrations
and rewards associated with planning.
When a new product is envisioned, a project plan must be established to guide
the process of turning that vision into a real product.
At the start no one really knows what’s required to make that vision a
reality. First, some meat must be
put on the bones of that vision – the product must be defined (WHAT), and the
architecture to support that definition must be designed (WHY and HOW).
Then it’s necessary to develop estimates of what it will take to turn
that vision into reality (WHO and WHEN), and a plan must be laid out to
accomplish this. What are the
various tasks that need to be carried out to convert a concept into a real
product? Who needs to be involved,
and when, in carrying out all of these various tasks?
How do all of these various tasks have to come together and when?
What tasks are dependent on other tasks being completed first or in
parallel? And so on.
The project plan must cover all aspects of development, including design
(hardware, firmware, software, mechanical, integrated circuit, etc.), test
(unit, module, integration, functional, system, customer, regression, black-box,
etc.), documentation (user, system integrator, etc.), performance (…),
usability (…), support (…), rollout (…), marketing (…), sales (…),
etc. You overlook any element of
the project at your own risk.
The project plan must be aggressive, but realistic, and should target a specific
delivery timeframe – the market window. If
the plan is too aggressive, such that no one really believes that the project
can be accomplished in the timeframes stated, you won’t get buy-in from the
troops. Engineers may go through
the motions, but their hearts won’t really be in it and the project will be
doomed from the start. The project
plan can’t rely on “sunny-day scenarios”, where everything must go
“just right” to achieve the schedule.
Nothing ever goes “just right”!
Problems will arise, and things will change.
Some degree of contingency planning needs to be incorporated to
accommodate some of the unknowns that will occur.
You may not know what will occur, but you do know that something will
happen that will impact the plans. You
should plan for it, to the extent you can.
On the other hand, if the project plan is a “piece of cake”,
engineers, being the strange beasts that they are [hey, that’s not an insult
– it’s the truth! I should know,
because I am one!], won’t really dig into it and will fritter time away on
other things (some work related, some not) since it’s such a “piece of
cake”. That’s why having a
plan that’s aggressive but realistic is essential.
Once you’ve laid all of this out, you must then determine whether it, in fact,
meets the required delivery date. If
you deliver the product in this timeframe, will it meet the market window? If it is acceptable, things can proceed.
If it’s not, then adjustments to time, people, features, functions, and
many other variables must be made to achieve a viable solution.
Each of those variations must be thoroughly thought through and the
impact on every other element of the plan, and of changes to them on yet other
elements, must be defined and agreed to. When
this is done, you must then get all parties involved (development, test,
documentation, marketing, product management, manufacturing, support, sales,
finance, etc.) to agree and sign off.
Whew!!!
And then you’ve finally got a project plan that’s a thing of beauty, and
that lays out everything that needs to be done, when, by whom, and with what
result. Right?! Well,
… no! When you’re finally “done”
and have a viable plan, and everyone agrees with it and signs off on it, … it
immediately becomes obsolete and must be adjusted to account for all of the
things you didn’t think of or for external events that are beyond your
control. What’s more, the project
plan will continuously change throughout the project, sometimes minute by
minute, and must be continuously monitored, updated, and adjusted.
What a great process, right?! On
the other hand, consider the alternative. If
you don’t go through this process, you’ll be working in the dark with no
means of knowing if you’re even heading in the right direction.
With this process, you follow a plan toward a destination (a completed
product) and make mid-course adjustments as needed. With everything that can (and often does) go wrong in a
complex product development, it is most definitely true that “failing
to plan means you are planning to fail !”
Copyright ©
2003
Effective Engineering Consulting Services, All Rights Reserved
Back to
e-Newsletter Archives:
| |
|
