Effective Engineering 
                Consulting Services
   
                                           "Helping Engineering Excel!"

Home
Our Premise
The Problem
Our Promise
Our Approach
Our Deliverables
Case Study
Our Results
e-Newsletters
Our People
Contact Us
Photos

 

Back to e-Newsletter Archives:

 Effective Engineering e-Newsletter – 7/3/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.

eN-030703:

Product Definition: Define What It Is and What It Isn’t!
  By Tom Dennis – President, Effective Engineering [tdennis@effectiveeng.com]

Have you ever worked on a development project that has seemed doomed from the very outset, almost like one out of a Dilbert cartoon?  One where features and functions are vague and seem to change from one day to the next?  One where decisions are made and then are repeatedly overturned, and where work is done and then undone?  One where what is being worked on at any given moment is questioned continuously and where people are shifted from one “priority task” to another and then to another?  Such a project is incredibly frustrating to be associated with, and generally stems from a poor product definition and poor change control procedures.  As the saying goes, “Well begun is half done”; the counter to that saying is “Poorly begun is never done”.  The importance of a strong foundation when starting a project cannot be overstated.

In order to build the right product, you have to know what you’re building.  The initial document that spells this out, or is at least supposed to, is a Marketing Product Definition document, or one with a similar name.  The intent of such a document is to define the features and functions of the product to be built.  At the early stage of a project, this is generally a fairly high-level definition, specifying in fairly broad terms what the product is and does.  It’s intent is to provide sufficient information for the requirements to be taken to the next level of specification.  When not done at all, a project will proceed with no real sense of direction.  When done poorly (which happens all too often), it gives only a vague sense of definition and/or direction, leaving what the product really is open to individual interpretation (a dangerous proposition).  When done reasonably, this document gives a clear definition to all of what the product is.  When done really well, it not only defines what the product is, but also what it isn’t.  By defining what a product isn’t as well as what it is, it prevents people from heading off-track in directions that were not intended.  All efforts should be made to provide a really excellent product definition document, clearly defining what the product is, and what the product is not.

This product definition document sets the foundation upon which the product will be based.  A firm foundation provides a stable platform to build upon; a flimsy foundation leads to a platform that can later collapse.  While this document is typically called the Marketing Product Definition document, this does not mean that Marketing should prepare such a document in a vacuum.  Quite the contrary, it is critical that many viewpoints be represented in coming up with the product definition.  Most critical is to properly define what the customers really want (see eN-030619 – What Do Your Customers Really Want?).  Make sure that current and prospective customers are asked, and asked in the right way; ask what they will want in the timeframe when the product will actually be available.  Once the customers’ needs are properly represented, then other organizations need to be involved.  Marketing (including product management), yes, but also sales, engineering (including development, test/quality assurance, usability, performance, technical documentation, etc.), customer support, field engineering, business development, manufacturing, finance, and others should be involved to ensure their unique viewpoints are properly represented. 

Marketing then controls the drafting of this document, appropriately incorporating the diverse viewpoints, with the greatest weight given to the customer viewpoint.  However, it must be a sensible and coherent document that will satisfy customers.  Trying to make the document be all things to all people seldom works.  Once drafted, this document should be sent out for review, to get the comments from others involved and to reach consensus.  As stated above, this document should cover not only what the product is and does, but also what it isn’t and doesn’t do.  Clear expectations are essential; everyone needs to be singing off the same sheet of music.  The document should be a crisp, concise, and complete as possible.  After comments have been reviewed and discussed, and consensus has been reached, this document should be formally signed off by all relevant parties.  This ensures everyone has formally bought-in and establishes a written baseline.  Once completed and signed-off, the next stages of the development process can proceed.

How are the inevitable changes that come along to be handled?  It cannot be a haphazard, ad-hoc process to accept some and reject other changes.  A formal change control process is essential.  Feature creep can be deadly to projects, particularly if timely delivery is important, and it is always important! [see eN-021121 – Late Projects Kill Companies!]  The typical request for a new feature is, “But it’s only a minor change to add this, and it won’t take any time, really.”  While this may or may not be true for one isolated feature, the impact of many “minor features/changes” can add up to a very major impact.  “There is no such thing as a small change” is generally as true a statement as “There is no such thing as a free lunch.”  This is where the baselined Marketing Product Definition document comes in.  Impedance must be added to any change.  A “costs/benefits” analysis should be mandatory for any requested change or feature, minor or not.  A change committee must then weigh carefully and sign-off on accepting the “cost” of the change in order to get the “benefit” of the change.  Usually the “cost” means more time, more people, or reducing or eliminating features already included in the baselined document, all very significant things to consider.

If the product definition is solid, and proper change control procedures are followed, then the odds of a successful project and a successful product are significantly enhanced.


Copyright © 2002-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