I am close to launching a new application for my company. It will replace a previous application which I wrote 8 years ago. The new version is much cleverer as I have designed the tables better and my vba programming skills are much better now.
The benefits are that entering and finding data is going to be much easier.
My problem is that I sense the users are not happy. I have tried to design everything to look similar but people are not happy that there will be a change. They are also worried that the new application is automating a lot of proceedures and they feel thet their positions are under threat.
Has anyone been through this and if so, can you offer and advice?
This is of course a bit late now but these are my thoughts:
People are typically resistant to change of all kinds. The very best way to counter that resistance is to include them in the process right from day one. Before writing a line of code engage with all stakeholders: review what currently exists and what works about it and what causes people pain. Review business processes - try to tease apart a client's activity from the goal of those activities (not as easy as it might sound). Create a written specification and get sign off from stakeholders.
That, I am afraid, is IME the best way to ensure that users embrace your product. Foisting something on them inevitably results in resistance.
From here I would review with your manager. You might need a bit of carrot and stick: engage in training sessions with users which gives them an opportunity to voice their concerns and you (and perhaps yours and their managers) to address these. The stick part would be instruction from their superiors that ultimately they need to suck it up and use the new system.
I have tried to include everyone right from the start but I found people have very little interest even though it can save them a lot of hassle. The business owner has seen the application and his attitude is that he loves it and that I should ask for feedback, if none is forthcoming then launch.
Whenever I show anyone a form, the usual comment is..."can it be blue, green, orange etc"
I am just a little disappointed because I want people to look at it and test it before launchng because I know that on day 1, I will have a line of people at my desk complaining because there is a piece of info missing etc.
If the business owner gave the green light, then make sure the line queues at his desk instead of yours...
When stuck in a scenario like this were the users are having my work imposed on them by management (such as every gov't contract I've ever completed), it becomes important to ensure the decision maker is willing to be held accountable for their decisions. Things like software requirements specification documents and formal acceptance procedures are very useful for producing a paper trail that leads back to the person who actually pulled the trigger. It also helps provide a uniform method of gathering feedback and requirements from the users, should they wish to participate. A formal change request process is also handy for addressing folks who like to release first and design later...
Ideally I'd like to be driving the requirements bus from the start as pootle is describing. That said, it's a good idea to get out of the way should one realize not only are they not driving the bus, but they've been thrown in front of it.