A few days back, while prototyping a new solution for a customer, one of the key users said: “But in our old software it didn’t work like that.” I was about to try to explain why the change, but then the user’s boss said:
– We aren’t implementing a new solution so that everything can stay the way it was.
How often does it happen to you that your customers say to you a similar thing: “But in our old system…”? What do you say to them? How do you approach change when your consultant proposes a new way of doing things, or a new approach to a common problem?
Any new software implementation will bring many new changes. Yes, user interface will change, functions will change, but these are the least important. Many times, more often than not in fact, you will have to change the way you do things. When the software is inflexible, and you can’t customize it to your wishes, you’ll just accept this as a given, and the change will take place. But if the software is flexible, and you can customize it to your fancies, you’ll try to bend it to meet your needs, and you’ll try to get your new solution look like your old one. And this happens more often than most customers would be willing to admit. And it’s natural.
But it doesn’t mean the software must be bent. Before you decide to mold your new software to the likeness of your old one, try as much as you can to see the benefit of the new ways of doing common tasks. It’ll usually pay off.
This Post Has 2 Comments
I’m absolutelly agree with your moral. In my case I’m used to doing a GAP-FIT analysis that is the best way to implement NAV.
@Jesus: yes, gap-fit must always be done, it is also the part of Sure Step methodology – but still, either when or after you complete the analysis, “their old software” monster still survives…