Effective Engineering e-Newsletter – 7/5/2007

This is your monthly 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-07705:


Doing Things Right vs. Doing Things Over
  By Tom Dennis – President, Effective Engineering [tdennis@effectiveeng.com]


How is it that, time after time, people seem to believe they don’t have the time to do things right the first time, yet they will later make the time, usually at the cost of delaying a critical project, to do things over?  The reality is that taking the time to do things right the first time will virtually always, in the long run, take significantly less time and result in a higher quality product than it does to do things over.  By not doing things right the first time, you will not only inconvenience yourself (and look bad in the eyes of almost everyone), but you will greatly inconvenience and severely disrupt the lives of many others as well. 

Why do people make this mistake in the first place?  Clearly they don’t set out intending not to do things right.  They begin with only the very best of intentions, to do their jobs to the best of their abilities in the very best ways possible.  They will even often say to themselves, “this time I’ll do it right the first time and not get caught up in downstream problems.”  What changes that idealistic desire?  Pressure from a variety of sources is typically the cause.  Such pressure will often cause people to take “shortcuts”, or “force” them to get “something” out quickly that can be “refined” later.  We will examine the sources of pressure and how you can best stand up to these pressures.

One source of pressure is internal and not based on external forces at all.  You are asked to develop estimates of what it will take for you to accomplish a specific task.  How much time will it take, including dependencies on others and to others?  Being an engineer, you tend to be fairly optimistic, the task looks fairly straightforward, and you think you can complete this task in fairly short order.  In developing your estimate you think about the direct implementation of the normal functionality you are implementing and not of all the abnormal cases or error paths.  You provide an estimate that you think is reasonable without thoroughly thinking through all that really needs to be accomplished (see also eN-070503 – Sunny Day Scenarios).  Once you have provided your estimate you are now, rightfully, expected to deliver on your commitment, and you pride yourself on delivering on your commitments.  When you are actually engaged in the implementation, all of the things you didn’t think through, including the exception conditions and error paths, suddenly become self-evident, and you recognize that you didn’t allow the proper amount of time to actually implement all of these cases.  But by now you’ve committed to a delivery date and many others are dependent on your delivery.  So you make a decision to deliver “something” that can enable them to continue their work, even though what you are delivering is not really complete.  You tell yourself that what you have delivered is “good enough” for now and that you will have time to fix it before it will cause any real problems.  Of course finding that time will become a problem because you now have many other tasks to deliver and you’ve estimated the time it will take to complete them in much the same way you did with this task.  The net result is that you’ve delivered an incomplete “product” (and you know it), but now you’re even deeper in trouble because of this and even more similarly flawed deliveries.  You’ve created a crisis of your own making and you’re embarrassed to admit it and don’t see a way to correct the problems.  You’re afraid to admit your mistakes and to ask for help.

This is just one example of internal pressure that can lead to not doing things right the first time.  Internal pressure can also come from trying to meet team commitments so as to not let your teammates down, getting your task done quickly (even if incompletely) to beat your rival and show him/her up, trying to show off to your boss or others, trying to show that you are the best and the fastest or that you are not the worst or the slowest, simple laziness, or many other reasons.  Regardless, you are just fooling yourself, and you’re about to pay the price.  Unfortunately, you will also make others pay for your mistakes as well.

Another source of pressure is external.  This may be pressure from your boss or your peers to meet deadlines or stay on schedule, or to “show” progress, or to get “something” ready for a demo (see also eN-070405 – Showing Progress vs. Making Progress Syndrome), or similar reasons.  These pressures lead to making the same kinds of mistakes as with internal pressure, and after all, it is still your decision take the “shortcut” and to deliver “something” even though you know it is not right or complete.


So what should you do to avoid making such mistakes in the future?

First, you should resolve that you will not allow yourself to do this, and then stick to this decision.  It is your decision to do it right versus doing it over, and you should force yourself to always opt for doing it right.  Do not allow yourself to accept delivering half solutions or half-baked deliverables.  Setting this frame of mind in yourself, and not accepting less is often a very good start.

Next, take the time necessary to really think through what you are committing to, and don’t make “assumptions” that are not thoroughly thought through and reviewed (when you ass/u/me, you make an “ass” out of “u” and “me”!).  Be as complete as you can be when preparing your schedule estimates, and when you think you’ve got your estimate ready, go back and review it again, looking for flaws in your approach or assumptions.  Have you considered all of the exception conditions and error paths?  Have you included your dependencies on the deliveries of others and are they truly realistic?  Have you included your deliveries to all of the others who will really need them?  Where can things go wrong, and if they do, what are the ways around them?  You can never be perfect, but try to be as thorough and complete as you can (see also eN-041104 – Project Planning: Plan Based On What You Know, and On What You Don’t!, and eN-050303 – Project Management: When Bad Things Happen To Good Projects). 

While this may sound easy and straightforward, very often it is not.  It may require you to admit to your boss or others that you didn’t plan properly, or that you didn’t think things through, or that you need help that you didn’t anticipate.  Still, it is better to do this sooner rather than later.  The earlier in the process that problems can be identified and corrected, the less time wasted downstream trying to find and correct the problems (doing things over) and the higher the quality of the product.


The point of this discussion is that not doing things right the first time is a false solution, regardless of the reasons.  If what you’ve developed is not right, it will have to be made right at some point, and fixing what you have screwed up will almost always take longer than doing it right the first time, and will almost always adversely impact others along the way.  Your guiding principle, in product development and in life, should always be to do things right the first time!


Copyright © 2007 Effective Engineering Consulting Services, All Rights Reserved