The CIO Code

Does anyone remember just how hard it was to give birth to their children? I think it’s safe to say, if our memories were accurate, we’d have a lot fewer kids. . . The same selective memory applies to system conversions. Here are some lessons learned that might help your next system conversion be a little less painful.

As hazardous as it is to undertake any ambitious software development project, systems conversions can be especially dangerous. On the one hand, rebuilding a system offers a promise of skipping some of the growth pains that occurred as the original system was deployed. On the other, if expectations about the new system are not managed carefully, the new system is likely to be even more problematic than the original roll-out. Even if the process is smoother than the original, people’s selective memory is likely to raise the stakes.

 Here are some thoughts to achieve Predictability and Understanding in a system conversion.

Step 1: Right thinking

Before you take any steps, get your head on straight. The functioning system is only a representation of what the system will be. It is not the full picture of what needs to be done. One person’s experience of the system will not be the same as another’s, so you need to do as much work to understand what goes on outside the system as you would have to build the system originally. You may know what the “system does” just by looking at it, but you don’t know “how people use the system.” The principle of Understanding in this case is that it is more important to understand the people than it is to understand the system.

One way to think of the existing system is as a functional prototype. It provides invaluable information about system behaviors, but it does not tell you anything about human behaviors. You still need other kinds of supporting documentation to understand those human behaviors.

Step 2: Take the right steps

If you think of a system conversion as any other system development project that has the advantage of a working prototype, you have a head start on Understanding, but you are a long way from being done. You still need to complete all the other tasks you would on any other system to achieve common Understanding:

• Involve executive stakeholders to determine the priority of existing functionality;
• Establish a defined list of features that will be converted;
• Involve end users to understand how they use the system. You don’t need wireframes, but you will need use cases;
• Make sure people understand that if a task doesn’t make it into a use case, it won’t end up in the new system; it is the end user’s responsibility to validate that the feature list is complete; and
• Involve technical stakeholders in the requirements process, including architects, programmers, and quality assurance personnel.

Step 3: Negotiate and set expectations

Predictability dictates that an enormous amount of details will need to be negotiated before any development commences. As requirements are being gathered, it is critical to know and manage expectations with regard to the new system. Some of the details to work out are:

• Does the graphical user interface need to be an exact match?
• If the graphical user interface doesn’t need to be an exact match, are there specific areas that do?
• Does the functionality need to be exact, or is it possible to introduce innovations to reduce the number of steps for a process?
• If the functionality does not need to be an exact match across the board, are there specific areas that people are more sensitive to?
• What do we do with existing system defects? Do we fix them? Do we log them for later resolution?

You’ll achieve a measure of predictability if you firm up these answers before you start.

Step 5: Plan releases with use cases in mind

In planning release cycles, make sure to prioritize development efforts to anticipate dependencies. Studying use cases carefully will help avoid scenarios in which areas of functionality are completed but cannot be released because dependencies have not been completed.

Step 4: Proceed “Agilly”

As with all system development projects, expect change. The principle of Predictability is not to see the future, but to make sure we are prepared to make decisions when we need to. Make sure you have project infrastructure to identify change and adapt. Deploy these strategies to keep teams in alignment:

• Show converted functionality early and highlight areas of difference. Doing this early will help teams modulate expectations.
• Build the system iteratively so that the impact of change can be assessed in small increments instead of large ones.

Step 5: Plan your roll-out strategy

The test of Predictability will happen during the system roll-out. As with other systems, it is helpful to have a pilot group that is more savvy and tolerant to help with initial release. There are always surprises, so make sure your first audience can appreciate them.

Expect some additional challenges to your roll-out, including:

• Resistance to change: in general, change is “bad,” so expect people to be unhappy just because something is different; make sure you give your audience enough time to become familiar with the system before letting them reject it.
• Missing functionality: Most likely, there will be areas of the new system that were missed in the original specifications. Usually, these are alternate paths, boundary conditions, or work-arounds that people have become familiar with but could articulate in their use cases. Prepare your audience for this likelihood and plan to make modifications as issues arise.
• Defects: As well as a system can be tested, there will be defects in the system that were not present in the old system. Set expectations around this regarding the number of defects that is “acceptable.” You can use calculations regarding Mean Time to Defect to project an acceptable level of error. If fewer defects were reported than the threshold, you can be a hero. If there are more, the reaction will still be more favorable than if the expectation is “zero.”

To summarize: don’t shortcut the software development lifecycle just because you have an existing system. Make use of the existing system to clarify expectations, but make sure you capture requirements like any other system. Involve your stakeholders and set good expectations, and you’ll achieve great success. Who knows: people might actually WANT to remember this one! 

I’d love to hear from you what lessons you’ve learned to help succeed at system conversions.