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/17/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-030717:

Write It Down and Sign It Off!
  By Tom Dennis – President, Effective Engineering [tdennis@effectiveeng.com]

At the start of efforts on new product or a product improvement, people generally gather together to brainstorm about what that new product should be.  Most critical, of course, is to recognize what customers want, and to incorporate that into the product definition (see eN-030619 – What Do Your Customers Really Want?).  Beyond that, this is a time for a variety of diverse views to be raised, discussed, and for decisions to be made.  These decisions should include not only what the product is, but also what it isn’t (see eN-030703 – Product Definition: Define What It Is and What It Isn’t!).  This is a valuable time, and the effort should be as thorough and complete as possible, since this will set the stage for the ensuing development process.  Generally, the outcome of such discussions is verbal agreement, but this is not always followed up with a written document specifying the details of what decided, and even when it is, such a document is not always signed off by all of the key parties involved.  Writing it down, and signing it off is imperative!  Failure to write it down and sign it off can, and usually does, spell doom to that product development effort.

Why must it be written?
A written document specifies what decisions have been made, and often why (the rationale behind the decisions).  It defines what is included in the product and project, and what is not included.  It is the baseline that states what will and what won’t be done.  This avoids confusion, and creates a common piece of “sheet music” that everyone can play from.  Further, this forms the “contract” that people will work from.  As elsewhere in life, if it isn’t written in the “contract”, it doesn’t really count.

What happens when it’s not written down?
Memories are often selective, and fade with time.  If the product definition is not written down, different people’s “firm memories” of feature definitions or decisions made will be different.  Definitions/decisions made at the time will tend to morph into slightly different to vastly different definitions/decisions.  Arguments will tend to arise, and people will start to engage in the “blame game”.  By having a written document, all of these problems can be avoided.  Further, with time, new information will come to light that will suggest changing the product definition.  New features will be suggested, and these will continue to arise with time (creeping features).  By having a written document stating what the product is and is not (at least at the time of the writing), the impact of such changes can be properly assessed and intelligent decisions can be made on making changes based on facts and not on opinions.

Why must it be signed off?
When you have to review a document and comment on it, you will try to do a diligent job on such a review, but you will give it only the time you really have to spend on it.  When you have to sign your name to that document, it means that you are taking ownership in the document, and you will take more seriously exactly what you are signing up for.  If you are one of the “owners” of the document, then you realize that you will be held accountable for that document and the ensuing product/project, further increasing the importance of that document on your priority list.  If you’ve signed your name to a document, you have signed up for the commitments made in that document, and there is little wiggle room to say you didn’t understand what you signed up for.

What happens when it’s not signed off?
If people have not signed off on a document, you can clearly predict the cries of, “If I was aware of that requirement, I would never have agreed to it”, or “When was that ever part of the product definition”, or the like.  The sense of ownership and accountability will simply not be there.  As was the common saying during the cold war, “Trust, but verify!”  You can generally trust people, but having them sign-off on documents verifies their concurrence.

Who should be involved in writing and signing off?
All affected parties should be part of the initial discussions, the review and revision process for the written document, and in signing off on the document.  In this way there are no surprises, and everyone buys in and signs up for the commitments made.

What happens when it is signed off?
A signed off document becomes the baseline document for all further work on that product/project.  It means that everyone who has signed off has signaled their commitment to the features, functions, milestones, timelines, etc. included in the document.  Any changes to the product/project can be measured from this baseline, and a costs/benefits analysis can, and should, be created for each change.  All parties who signed off on the document should likewise sign off on any change, recognizing and agreeing to accept the costs (usually time, cost, price, features, etc.) in return for the benefits.


I have concentrated here on the Product Definition document, which is clearly a key document in the early stages, and serves as a foundation document for what will follow.  However, this is only the first in a line of documents, including Product Requirements, Project Plans, Test Plans, Documentation Plans, etc.  All of these documents should go through a similar process.  Remember, for all of them, WRITE IT DOWN, and SIGN IT OFF!


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