Wednesday, September 21, 2005

Get it in production...

Mostly when you're implementing a software system, you're replacing existing software. Be it a COBOL application, a pen and paper process, something people do on a calculator, or in a spreadsheet. Software usually isn't doing something new. Just replacing the old. This helps you prioritize.

Your goal is to be in production. Yesterday. On the first day of the project you should be PANICKING that you aren't in production yet. You're losing money everyday. Software in development has a present value of exactly $0.

This means really hard decisions when prioritizing stories. Here's some rules:

1) If you're rewriting a system - your new system shouldn't be able to do as much as your old system before going into production.

Your old system has a bunch of unused features. Ditch those. If you only use a feature in a couple of places, consider a work-around.

2) Your new system doesn't need to do anything new. Unless you're about to be sued, there are no risks in putting in a system that does exactly the same thing. And if you're about to be sued it has nothing to do with the software.

You're rewriting because the technology is outdated: meaning hard to update and buggy. See if the new system solves that problem first, before slapping all sorts of new features in it.

3) If you have a work-around OUTSIDE the system, keep it outside the system. You will lose almost nothing adding it to the system afterwards, if it holds up production - you're losing money.

4) Now look at what you've asked for. Find a way to just replace a piece of the system at a time. If you can break it into 3 or six months bits, you'll be a lot better off. Don't screw yourself.

Continue to panic about getting into production. If you ever stop panicking, you are screwed.

NOW YOU'RE IN PRODUCTION. You know a lot more.

You can evaluate whether or not you were successful in replacing your old system. Was it easier to get into production? Was it less buggy? Make your decision about whether or not to proceed.

WHEN you do go into production as a customer: INSIST INSIST INSIST that you see all the automated tests that cover the bugs you discover in acceptance testing. At least you won't have to worry about these during your next acceptance test.

If it's not less buggy and harder to get into production - decide whether to improve it or ditch it. Thank god you didn't waste a pile of money implementing all those new features.


Start implementing the rest of the features. Make sure your next release is no more than six months away. Create as many of them as you can handle.

1) Implement all the things you are missing and everyone is bitching about.

Wow Feedback. Get it into production. If it's more than 6 months get it into multiple releases.

2) Implement your workarounds that you are currently using. You'll be solving real problems. Multiple frequency x average length of task. The higher the number the higher the priority.

Easy equation for prioritization. Only six months of features. No more. Get it into production.

3) Implement the new cool stuff.

You are now free to prioritize anyway you like, remember though you'll have some more of #2's popping up.


Post a Comment

<< Home