There was an interesting article in the Washington Post (10/13/02) recently about the abandoned conversion of the DC government’s payroll system. If you live in the DC area, you may remember a few years ago when this system was being cutover–there were stories in the paper and on the local TV news about people not being paid, and how the system was a mess, etc. etc.
In a nutshell, they’ve spent $20 million to replace their 33-year-old system, and have decided to just keep using the old system.
That’s were it gets interesting. An additional $14 million has been spent moving BACK to the old system. What started out as a $900,000 contract to a local IT contractor has mushroomed; the original contract did not have to go through the normal purchasing approval process. The contractor got the job by "low-balling" (and thereby bypassing the approval process).
Then, they just kept expanding the scope and getting incremental change orders.
Oh yeah, and the guy who recommended the company in the first place-he’s now working as a consultant for the IT contractor.
This story got me thinking about system migrations and how painful they can be–both for those directly involved and for those affected by the conversion. In particular, the "Go-No-Go" decision can sometimes be the toughest decision that a manager makes in their entire career.. Although the "un-conversion" was poorly handled, the DC government’s decision to abandon their conversion wasn’t necessarily the wrong one.
Think about a cutover decision you have looming front of you, or one you’ve made recently.
Have you addressed every major issue? Do you have a systematic way to assess go-live readiness and reduce potential risks? Do you understand the system’s impact on its users? By "users", I don’t just mean the actual end-users of the system. I’m talking about everyone who’s affected by the system conversion: employees, customers, vendors, etc. Have you communicated on a regular basis with them to let them know they may be affected? Have you set a special means (i.e. toll-free number, web pages, email addresses) for them to communicate and resolve any problems?
Sometimes the best decision during the conversion is not to convert at all. I consulted with an organization that ended up filing for bankruptcy 18 days after converting, and had to run and support BOTH systems for another year before they finally liquidated. Had someone made the tough call to pull the plug on the conversion, they could have saved themselves (and their creditors and shareholders) a lot of time and money.
Sometimes a delay (or switching from a full cutover to a piecemeal migration) helps to solidify everyone’s product knowledge and the user community’s confidence in the new system. Sometimes the impact is so profound that you simply can’t cut over everything at once. I consulted with an organization that was migrating their timekeeping system as well as their payroll system. I wrote a program to convert their timesheets from the old timekeeping system to their new system, so they didn’t have to re-enter the timesheets during parallel testing (we knew that part of the new system worked). This ended up working so well that they went live with the new payroll system, but kept their old timekeeping system running for another 6 months until they could re-energize and focus on the conversion of the timekeeping system.
In your conversion efforts, make sure you’re making an informed go-live decision. Anyone who’s charged with making the "do we or don’t we" decision needs to have HONEST input from his/her team, including the consultants. If it’s not going to work, speak up!