Launching Software Projects

posted Wed Apr 25 18:04:09 +0000 2007 - permalink

Launching software is rarely fire and forget. Even if you have another team designated to cover the maintenance of a project, odds are you will be fielding questions if that team was not an integral part of the development process. And sometimes software launches can take several months with a phased rollout. In a small development team, this is something you should at least be aware of if not trying to channel. (I mean, you are trying to keep to your schedule, right?)

What does this mean for your schedule and estimation? Generally, any project that makes a significant impact on your customers will probably have to be either a phased launch or well communicated. The definition of 'significant impact' will probably need to be researched in terms of raw numbers (and I mean SQL here), surveys (hopefully someone did these before you started the project), and general hallway consensus.

I like the Gang of Four's idea of 'smells' around a problem, and in this case let's look at some project launch smells. In my opinion, these are the common ones:

• Money. If it smells like it may make customers go somewhere else, or scare off potentials, by making it more difficult to deal with your company, expect a launch delay if research has not been done. This generally means you need to get a survey (how likely are they to move?) and talk to accounting to find out numbers on how big of an impact this may have and match that to some of your own queries. Odds are, development and QA may be complete but management may not decide to launch the project for several months.
• Manufacturing/Customer Relationship Process. This is extremely dangerous for launch dates. You have a whole host of issues, including manufacturing, shipping, your internal tools, possibly accounting (check with your controller to make sure) and messaging these changes to the end user. I highly recommend meeting on this early and often. Usually in growing companies, this will happen often which leads to disassociated subsystems. Look for places where you can consolidate subsystems and processes to save yourself time to make sure this new process also works for your customers.
• Online Process. This is generally low threat level (unless it's a complete website framework overhaul like we did late last year). If a process changes more than a few clicks, you'll want some help text for your existing customers.

Knowing the launch dates is an important part of leading the development process forward because it dictates when your maintenance cycle is going to occur -- and knowing when the likely times that priority one bugs are going to be submitted and interrupt your work is critical to ensuring you and your team have the proper time to work on your projects.