How to not fail

Through my career, I have seen many projects succeed and a few fail.  Naturally, the ones that failed were, in no way, my fault.  That probably goes without saying.

As I look back on the ones that failed, I can see the ingredients that made them fail.  I can also see what measures were put in place to avoid those landmines in other projects.  I’d like to identify those landmines so you can avoid them too.

  1. Requirements:  How long will it take you to make a “polly-wally-doodle”?  Wrong.  Try again.  Wrong.  Try again…
    You can’t possibly give a correct answer because you don’t really know what I want.  You don’t have any idea of the scope or my expectations for quality, or platform(s).  There are an infinite number of ways to answer this question wrong and only a few ways of answering it right.  To be successful, you need to isolate one of those right ways.  It is best to do as little development/programming as possible before you know the answer.  Because each time you get a wrong answer (closer/no cigar), you will have to rewrite some/all of it.  That is time-consuming and wasteful.  More than that, if you miss the mark with your final product, the project will fail, outright.
  2. Architecture:  In any technology, there are some things that are easy, hard or impossible.  Hopefully, you don’t accidentally pick one of the impossible things as part of your solution.  It is also best to avoid the hard ones.  So, how will you know if you have picked a bad one?  Well, the easy ones are the ones you’ve done before.  Anything else has the potential to be hard or impossible.  Those are also called “unknowns”.  You want to turn “unknowns” into “knowns” by making a mini-model that demonstrates the technology.  Get that done first, before you do anything else. Never ever EVER leave it till the end and hope you will figure it out.  You won’t be lucky and Murphy’s law will burn you hard.
    When you are working on your small model, if you can’t figure out how to do *any* one single-thing, then cut your losses and punt on that piece.  Use your remaining time to find an alternative and prove that instead.  Don’t proceed until you have resolved all of your unknowns and proved the elements of your architecture with a working mini model.
  3. Bugs:  Every project gets launched with bugs.  If your project goes out bug-free, then you probably took WAY too much time to develop and test it (unless it is a Mars rover or pace maker or something life & death).  Make sure you have good error handling and logging.  When those bugs happen, you need a “black box” to tell you when, where, who, how much etc.  Bug tracking saves lives (metaphorically speaking, of course).
  4. Testing: Yeah, I know.  I hate testing too.  I put it right up there with eating veggies and doing exercise.  I hate it, but I know how good it is for me.  So, stop being whiney and do it really well, because once it is done, you will feel awesome!  To make it go more smoothly, make a test plan.  Then you can pace yourself and have accountability for what you tested.  Maybe you can even rent a temp to work the plan.  Writing a plan is not nearly as bad as working the test plan.  You know I’m right.
  5. Contain the scope:  I call this “first get it done, then make it better”.  Focus on completing the required parts before adding improvements.  As you write the program, you are going to have lots of excellent ideas about how to make this thing really extra cool.  Put those things on a second list and discipline yourself to not do those things until the original work is done.  The cool stuff is a distraction and experience will tell you that it is a timeline killer.  Likewise, any new features that show up (from other people), must go on the “then make it better” (delay) list.  This is like eating your veggies before you get dessert.  If you eat the dessert first, then you will be too full to eat the veggies, but you are never too full for dessert.  So, no cake till you clean your plate, mister!

If you can nail all 5 of these, you will probably never find yourself in hot water.


About Tim Golisch

I'm a geek. I do geeky things.
This entry was posted in IT Psychology, Methodology. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s