Effective Engineering e-Newsletter – 7/31/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-030731:

Development Methodology: Too Little, Too Much, or “Just Right”?
  By Tom Dennis – President, Effective Engineering [tdennis@effectiveeng.com]


When Goldilocks sampled the three bears’ porridge, she found one too hot, another too cold, and the third “just right”.  Similarly, when she tried out their beds, she found one too hard, another too soft, and the third “just right”.   Development methodologies are similar.  They can be created with too little process, with too much process, or with the “just right” amount of process.  The key is finding out what is “just right” for your organization.  You’ll find that what’s “just right” for your organization is unique and different from other, even very similar, organizations.

In small organizations, the tendency is toward too little methodology – often very little or none.  In large organizations, the tendency is toward too much methodology – a very formal, highly detailed process with very little flexibility.  In medium-sized organizations, it is generally somewhere in between.  Striking the proper balance is a difficult, but critical task that will determine the success an organization finds in effectively developing new products.

What are some characteristics of too little methodology?
Too little development methodology often leads to bedlam, anarchy, and a free-for-all atmosphere.  There is no uniformity of direction; everyone is moving fast, but often in different directions (Brownian motion) (see eN-030102 – Poor Company Vision Clouds Everyone’s View).  People all feel they know what’s really best, and do their own thing independently of others.  There is a “cowboy mentality”.  No one effectively leads (or everyone tries to lead), and few want to follow.  Milestones are not effectively set, and schedules are for losers (see eN-030116 – Poor Product Vision Blinds Engineering, and eN-030130 – A Poor Product Roadmap Gets Everyone Lost).  This can actually seem exciting and even intoxicating initially, but after a short time, people begin to get frustrated because the goals are not clear and little meaningful work is really being accomplished. 

When new people come on board, they have a tough time getting up to speed because there is often very little, if any, documentation, and the new people have to draw heavily on people already deeply involved in the development, distracting them from their current work.  This has the true, but often counter-intuitive, effect that adding people causes more delay rather than speeding things up (see eN-021219 - Too Many Cooks Spoils The Broth!).

The net result of too little development methodology is a disorganized effort on an unclear goal, and usually leads to late project delivery, poor product quality, and high development costs, some of the hallmarks of ineffective engineering (see eN-021107 – Ineffective Engineering Costs You Time, Money, and Customers!).

What are some characteristics of too much methodology?
Too much development methodology occurs when an excessive amount of time and effort is spent defining the process everyone should be following rather than working toward the goal of effectively developing the product.  Typically the process itself is highly documented, laying out what should be done, by whom, and in what order.  Books are written telling everyone exactly how to carry out the process, and how to monitor and track adherence to the process.  Large efforts are devoted to monitoring and tracking every little activity, creating and reporting metrics for everything.  These efforts concentrate on seeing to it that the right process is being followed every step of the way, with little effort being made to see if what is being developed is the right product (see eN-030619 – What Do Your Customers Really Want?).

Too much process stifles innovation, mires people down in unnecessary details, and leads to process for process’ sake.  An inordinate amount of time is often spent in meetings to verify that the process is being properly followed.  If people don’t follow the process precisely, they get penalized; if they don’t develop the right product, that’s often of less concern.  Projects that succeed often do so in spite of the burdensome processes, not because of them.  This becomes another source of ineffective engineering, although coming from the opposite extreme.

What are some of the characteristics of “just right” methodology?
“Just right” development methodologies streamline the development process, adding the right amount of process to make sure everyone is working toward the same goals and working closely together.  It applies a uniform, but not a burdensome, approach for people to follow. (see eN-030227 – It’s Your Responsibility to Know Your Role In Implementing the Vision and Roadmap).  Specific roles and responsibilities are assigned (see eN-030327 – Do Jobs Right – Assign the Right People!).  Unnecessary tasks are minimized (see  eN-030313 – Move the Rocks and People Travel Faster).  Everyone moves in the same direction, playing from the same sheet of music, concentrating on what needs to get done in the right way at the right time.


Clearly, we all need to aim for the “just right” development methodology.  But keep in mind that this is not static.  It changes over time, and with the size, nature, and maturity of the organization.  As an organization grows, the level of intercommunications required among the development team grows, and the need for more formal elements of a development methodology grows as well.  You want to have enough methodology to move everyone forward together with excitement and commitment, but not too much such that it will stifle creativity and impede the real work.  What’s “just right” today, won’t be “just right” tomorrow.  What’s “just right” for your organization won’t be “just right” for another very similar organization.  What’s “just right” for one project won’t be “just right” for another project.  Diligence and flexibility is key to finding the “just right” mix for you, and constant attention and adjustment will allow the “just right” development methodology to evolve as your organization evolves.  Keep your eye on the prize, and the “just right” amount of development methodology will become apparent.


Copyright © 2003 Effective Engineering Consulting Services, All Rights Reserved