Effective Engineering 
                Consulting Services
                                           "Helping Engineering Excel!"

Our Premise
The Problem
Our Promise
Our Approach
Our Deliverables
Case Study
Our Results
Our People
Contact Us


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!


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:


Society of Professional Consultants


Copyright © 2002-2013 Effective Engineering Consulting Services, All Rights Reserved