Renewing an existing digital service is seldom an easy task. No matter whether it is an intranet, extranet or public web site that needs renovation or what the reasoning behind it is, the puzzle often has so many moving elements that it is hard to decide what really should be done, what the correct steps are and who should do them. Should you build everything from scratch or consider only a partial renewal? And where to start the renovation?
1. Prioritize, prioritize, prioritize!
As a first step, create a clear list of the key functionalities you and your users really need. Website analytics can give you valuable data about what the most used parts of your service are and what parts you might be able to leave out of the first release. Also, consider interviewing some of your users and partners to find out what they think are the most critical parts. Of course, rank those parts higher that support your business the most.
Prioritize the functionalities into three categories. Priority ones you cannot live without, priority twos can be postponed until later, and priority threes are more or less just nice to have. Depending on the complexity of the functionalities, you shouldn’t end up with too many priority ones. At this phase you really need to be hard on yourself. Leaving some parts out of the first release may mean weakening the service temporarily. But that way you may speed up go-live significantly. Besides, your end users often don’t feel as bad about it as you think.
Once you have determined all the building blocks and their priorities, you should already have a vision of the entity you are trying to create in the first phase. For each block, you should now try to estimate the complexity and the resource requirements. You may need some help from your implementation partner, but basically you should try to figure out how fundamental changes are required. If you have been farsighted (or just plain lucky) and your service has been planned modularly, it may be enough to renew just the user interface layer. Then again, if the business logic requires heavier changes, it may be wiser to recreate the service from scratch. The more resource-intensive the phase is, the wider block it requires.
Place the blocks on the roadmap timeline. Be realistic with the schedules, do not try to squeeze the timeline too much. Keep in mind that you have only a limited amount of resources for simultaneous projects.
The first phase of the renewal project should contain mostly priority ones, but you can also include some “quick wins” in it. If a single priority two or three feature is easy to implement and does not require too much of your resources, it might be a good idea to prioritize it higher, even if the functionality is not really business critical.
3. From roadmap to implementation
Now that you have all the moving elements on the timeline, what next? Should you create a massive requirement specification and try to choose one technology partner that can implement all those functionalities with some supernatural technology platform? Not necessarily. Sure, each block on the timeline requires at least some sort of a requirement specification, especially when you are planning a competitive bid. But you can also think smaller and eat one piece at the time. Focus on specifying the elements that must exist in the first release. Of the lower priority elements, it is important to document what you know at that moment, but the detail level can be much lower.
Don’t forget that you must still have a clear vision of the big picture you are aiming at. You need to have a concept plan that describes the user experience and usability guidelines. Keep that as a baseline when renewing the services.
What about technology?
You may also be wondering whether you should first select the technology platform and then try to implement all the functionalities on top of that. Generally speaking, the best user experience is usually achieved when all the functionalities are built with the same technology and run on the same technical platform, especially from the content editors’ point of view. On the other hand, things like e-commerce toolkits are generally not at their best in managing rich and structured communicative content. So, there may not be a product in the market that alone could handle all your business needs properly.
It will always be a case-by-case decision, but you should not be too scared of mixing technologies. Modern user interfaces can pretty well hide the underlying technology. Sometimes the best solution is achieved by selecting two or three different products or platforms, taking out the best parts of each and combining them into one seamless entity. In some cases the old and new systems are even able to live together in peace and harmony. You may still need some additional services like identity management to act as the glue between the services, which admittedly introduces some complexity to the wholeness. But if one platform is not able to offer a cost-effective solution to your requirements, a technology mixture may be the best approach for you.