3 problems to avoid with technologic migration projects
As man landed on the moon with power equivalent to our actual smartphones, we have undergone technological breakthroughs in our information systems.
Whether being indispensable steps to maintain a product support, a change to integrate new functionalities or even new necessities, we have had to or will need to go through this critical phase of change in our career, standing from an IT side or a user side. This phase, even more when undergone to counter maintenance problems or strategic choices in a company, is often experienced as an ordeal by IT teams. How to make users accept change, how to manage cost, how, how, how…
This is a small extract of some of the problems that can emerge and more importantly one or two tips on how to tackle them.
The worker problem: Choose the proper tool!
As we would expect a worker to lack efficiency smashing a nail with a screwdriver instead of a hammer, choosing the tool is essential. Many companies think about converting their existing applications once the tool has already been chosen. I cannot count the times I have been called by a company asking to : “redo this using that”. If you are considering hiring consultants to migrate applications, do include them in the process of choosing the appropriate tool. This often comes along with an IT roadmap, even sometimes a global roadmap at the company level. Since you are trusting companies to use a tool, trust them with choosing it. They use them, break them, fix them…in short they know them. We will see later on how this phase will have a deep impact on your project.
The Sailor problem: the siren of iso-functionality
At the beginning of each migration project, a word is used to ease users: it’s the iso-functionality! Let’s stop right there. It does not exists, it’s a myth, a lifebuoy to which many project managers hang to reassure those resisting to change. Beware of appearances as they can be deceptive: this lifebuoy is by far the anchor that will sink your project. Thorough my career, I have seen project costs increase up to a 100% by trying to reproduce non-native functionalities. From the button to place on the proper side to the exotic selection to reproduce, to functionalities being erased by the program creator because of too many bugs, we can find dozen of examples on a same project. The tool choice is thus essential. Make a list of vital users functionalities for business needs and choose the adequate tool. When
talking about business needs, let’s be clear: Freeze pans in order to be able to scroll through 145 600 pages of sale lines is not a business need. However, having a tool that can allow to identify efficiently a decrease in figures according to certain settings is. Moreover; if tools change, it is also because they assimilate new functionalities. Sell them, show them, make the product attractive by using new functionalities that will speak directly to your final costumer in a language that he understands: make his life easier.
The parent problem: Manage the budget!
Both points seen above should bring you to a difficult choice: which level of compromise can I achieve? The answer is simple: the business case. Too often do the IT managers say: “users have not asked for this change, we need iso-functionality. Yes, users are not supposed to accept changes like that from IT, they have a much more important role: making sure that the company is cost-effective, thanks to their own role and impact in the change management. Investigate all options and make decisions as a proper family head, if ever as a company head.