This is part 2 of a multipart series on changing core technologies in software systems and software-based services. Part 1 discussed the costs of change. This discusses the risks of change.
No change comes without risk. There is always risk, no matter how small. The risks can be broken down into a few main categories:
- technology risk
- project & delivery risk
- business risk
- operational risk
Some of the technology risks are obvious: this is a new product or device that you and your staff are unfamiliar with. You will find things that don’t work as you would have expected, and this can have an impact on your product or service. You will have to find ways to work around behaviours that are unwanted or unexpected (but may be “as designed” for the product) or problems that exist in the technology. Some of the more subtle risks, though, can occur when you depend on side-effects in the software. In some cases, you and your team may not be aware that the “feature” you are using is actually a side-effect or a bug. Where you get burned is if the side-effect is changed or removed, and now your system doesn’t work. This can happen with technology you already have, but presumably you are already familiar with your current technology and are in contact with the vendor or author. In the case of new technology, the features are unexplored territory which might not come with a full set of maps and guideposts.
Generally, technology risk can be managed and overcome, even if it requires brute force. The risk to the project during transition, and delivery of the product or service, can be harder to manage. Unexpected behaviours that require time for workarounds, or require a delay while the vendor fixes the problem, will have an impact on the schedule. You can try to build slack into the schedule to try to allow for this, but unforeseen issues are called that for a reason: you didn’t see them coming. You can “anticipate” by saying “we expect there will be problems”. But that doesn’t mean you will know, in advance, if these problems will be numerous or not, and how much of an impact they will have on the schedule.
The schedule risk ultimate affects your ability to deliver in a reasonable or useful timeframe. If you are up against a hard, fixed deadline, this kind of change can effectively kill and product or service if the unforeseeable becomes the unrepairable. Whatever the impact on the schedule, impacting delivery can impact business. Now you are into territory where the project can have a negative impact on revenue, cash flow and profitability. If the technology change is significant enough, you could be betting the business on this change.
How do you mitigate this? Up until this point, a lot of the risk can be minimized through prototyping, and tight iterative schedules. Don’t let the team go away for multiple months, with little or no visibility into the on-going effort, only to find out shortly before a deadline that the system won’t be ready. Building prototypes up front, prior to committing to schedules and deadlines, is essential. It gives the team a chance to try to understand the new technologies they are selecting. It also gives you the opportunity to abandon a change if you realize that what you need from the technology simply isn’t available, or isn’t going to be as advantageous as you had expected.
There are other business risks: the risks associated with dealing with a new vendor. As part of risk mitigation, you should be looking at the financial stability of your newly selected technology provider. They may have amazing products that will “solve all your problems”, but if they are going to be in bankruptcy protection next week, that will spell trouble for you. This isn’t to say you only buy products from extremely stable vendors. Its a question of balancing the risks of your vendor not being there, or not being large or mature enough to handle your day-to-day needs, relative to the benefits of using their technologies.
So, the system is built, installed and ready to run. Now you get into operational risk, and this can be mitigated early as well. The teams that will run the new system should be involved during the prototyping stages. They should be given a chance to see the technology in action, and start to identify the tools they will need to be able to manage and monitor the system. Leaving the operations component until after the system is built can mean problems when the system is running. If the operations staff don’t have an idea of how the system works, of what they should be monitoring, and what they should be looking for in terms of problems, then you can have an impact on the service (which can be a further impact on the business). Customers don’t like systems that are unreliable, unpredictable or have extended downtimes, and this can result if the operations team doesn’t have the tools and training they need to do their job.
No change is risk-free. Presumably you are changing technologies for some gain, either in system performance, stability or operations cost. As with anything, there is a balance between the risks associated with making the change and the rewards that come with it.
Part 3 continues with a discussion on cultural roadblocks to change.