Monday, January 2, 2012

The New System Dilemma

...Or, how to roll out a new system and stay alive.

When rewriting a system/ subsystem, there's never a way to satisfy all your customers.
Usually, the organization expects you to rewrite everything to work exactly the way it worked before, with better performance and completely revamped UI/ GUI, at a fraction of the original system cost. Not to mention all the new features.

This sound absurd doesn't it? Well it doesn't. This is exactly what you've told them when asking for their approval to rewrite the whole thing.

So you're in a rough spot now.

You are expected to deliver the new system soon, the whole project is in a delay and not too stable anyway, and the organization still considers the old system, which is stable, mature and field proven (Though it costs a lot to maintain), as its best solution - Urgent market needs call for more personal to work on the current system, and your team is at risk to be 'vandalized' for those proposes.

In my 15 years of working in high tech, I've experienced many millions of dollars burn over such projects. Ambitious complete rewrites, sometimes trying to squeeze hundreds of work years in (Usually) tenth or less of the time.
It's always the same story: Take your best managers and engineers out of the daily cycle, isolate them and expect miracles to happen. Wait one, two years, and when the whole thing collapses, go into salvage mode, and try to incorporate as many components as you can in your products.
Sometimes the whole system goes to waste... Along with your best managers and engineers.

So what can you do to turn the tables?

Your first target should be 'setting your foot at the door'. This means deciding on your first customer, and focusing on the specific needs and goals of that one specific. Don't try to implement the whole organization's needs at once - Focus on your first rollout. This way you'll be able to roll out in baby steps, rather than go out with a bang... You'll also be able to minimize your risks, and gain the time to stabilize your new system. Set expectations with your first customer, let them know exactly what they're getting, and more important - what they're not getting. Which features they will miss, and why.

Your second target should be getting your organization's cooperation with the rollout. Some of those people might not have been involved with your 'incubator' project. Some of them might even think that the current system is much better. How do you get them to be on your side? Start involving them with the final decision making and scoping. Get their engagement by exposing all the cards in your deck. Partner with them, because you won't make it without them. This might even mean brushing up on your political skills...

Once your first, even if minor, rollout is successful, and the organization is on your side, you'll have enough breathing room to actually finish your project, and moving it on to the regular maintenance cycle.