May 9, 2017 at 9:44 am
So the question is how do you encourage users to really give the new app/software solution a try?
Kindest Regards, Rod Connect with me on LinkedIn.
May 9, 2017 at 10:32 am
Rod at work - Tuesday, May 9, 2017 9:44 AMIn my current job we use TFS's Team Rooms for discussions related to the projects that we're on. That's because we're distributed without the state. A couple of my colleagues are discussing an application they support. I don't know much about the app, other than its name and a vague idea as to what it is about. But what I do recognize is a pattern I've seen over and over again. The app uses a PHP front-end with SQL Server on the back-end. Today I learned that the old version of the app was written in MS Access. And (surprise, surprise) it is still being used by the users. So they've got this new PHP/SQL app that they're supposed to use, but the users are clinging to the older version. I've seen this behavior before and not just here. At my old job we wrote a WPF app to replace an old VB6 app. (The backend was SQL in both cases, same database in fact.) We encouraged users to give the new app a try, that it fixed many issues the old app had, added new functionality, etc. But did they test it? Heck, no. I like to try new things, so I don't understand users reluctance to try anything new, especially when the old app is very buggy, etc. It reminds me of people staying in abusive relationships, even though moving on would be so much better for them.So the question is how do you encourage users to really give the new app/software solution a try?
Unless your users are particularly agreeable to change, there's no 'nice' way:
Get senior management buy-in.
Tell the users that migration is going to happen. When they complain, use the senior management you've already secured.
Get the more enthusiastic ones involved in the process of development & testing. They will champion the new system to other users.
The absence of evidence is not evidence of absence
- Martin Rees
The absence of consumable DDL, sample data and desired results is, however, evidence of the absence of my response
- Phil Parkin
May 9, 2017 at 8:19 pm
Rod at work - Tuesday, May 9, 2017 9:44 AMSo the question is how do you encourage users to really give the new app/software solution a try?
I, of course, cannot speak for all users but I've been beat to death with "improvements" that aren't. Heh... let the rant begin and, no... it's not directed at you nor anyone personally.
For example, I "love" the "Ribbon Bar". It now takes 4-7 clicks to do what I used to do in 1 or 2 and so my right index finger has grow strong enough for me to be able to push 10 penny nails into wood.
I "Love" the new look and feel of the new "metro" look for Office products. The icons are so "great" looking and the save, minimize and close buttons have made my day by giving me time to sip my coffee while I hover over where I think they might be so that I can actually see them to click on them.
I could go on but I won't bore you. It IS human nature to be a bit resistant to change especially if there's no clear advantage to the changes. If you want to sell your users on the change, you'll need to educate them. Before you can educate them, you have to educate yourself, not on the new product, but on the problems that they face. Having new functionality isn't worth beans if it comes at the cost of losing some functionality or the old functionality present is now more difficult to use or requires "more clicks". Familiarize yourself as if you were one of them and try not to bias yourself in the new shinny object. See what they see, Feel what they feel. Only when you can relate at the most basic levels can you make it work. And study groups are a great tool but you not only have to listen what the users are telling you, you have to find a way to satisfy them. Then you'll need to provide some decent training with references to the exact problems they've had and how the new stuff fixes that for them without breaking tried and true capabilities. Otherwise, you'll end up with users like me... begrudgingly trying to adapt to what I think are foolish and counter productive changes and losing productivity while I get used to the supposedly better way to do things.
This very site is a great example. They've got some really cool new features that work great. But, they killed my ability to quickly post code no matter which web browser I use. I now have to copy from SSMS, paste into Notepad, copy from that and then paste into an IF_Code that no longer places the cursor correctly and I still get crappy colored code for my reward but at least indentation and line spacing are correct. I used to be able to copy and paste directly with no issues. Unless I remember to scroll down, the pull-down for the IF Codes disappear off the bottom of the screen and I now have to click more times to even get to BOLD something because they changed the menu. Heh... and WTF is with the bloody round avatars!? That's like semi-transparent windows. Cute and clever (although I'd be ticked if my avatar was a written saying on a square sign) but I'd rather they spend their time on fixing the functionality. And they still haven't fixed other stuff.. Despite all of the improvements they made on this site, I'd take the old stuff back in a second because it's become much more difficult (and more disappointing results) to do what I mainly do on this site.
The bottom line is that "Change is inevitable... change for the better is not" and the people that know that best are the users themselves. Make sure that the changes actually are better for the users (rather than a convenience for IT) and then kindly demonstrate that fact and the users will be fighting to get the new stuff installed. Any other way and you're just going to have to put up with the strong resistance to change.
--Jeff Moden
Change is inevitable... Change for the better is not.
May 9, 2017 at 9:38 pm
What Phil and Jeff said are both true - people don't generally like change. Some will actively resist it as long as they can, no matter what new functionality you give them. This is just human nature. The problem with a lot of change is poor change - see Jeff's post. If you really need people to move to the new application for data integrity or something important, you'll have to force them to make the move because some people will not go willingly. My best advice:
1. Take Phil's suggestion to heart and get management buy-in. This is important. Make sure you don't have to support old versions, say, more than 1 revision back.
2. After you get the enthusiastic users involved and on-board with testing, implement at least 2 of their good suggestions and get them excited about it, do thorough testing. Make sure it does everything the old one does and at least something new or better. Hopefully, they'll help to create a "buzz" about it and get more people to want to use it. Don't expect 100%.
3. Distribute it to the masses. Be sure slip in a blurb that future updates are planned and will be released as they come available.
4. Some time later, release an update. It doesn't have to be huge, but make sure it breaks the old app.
To summarize, to get people to use a new version, don't let them use the old one.
May 10, 2017 at 9:28 am
Jeff and Ed, you've both brought up some things that I want to address. First Jeff, I completely agree with you that the thing to do is to watch and interact with the users. I completely agree with that. In my old job I would spend a lot of time doing exactly that. In a way, I could do my users' job. (In another I couldn't because their job required licensure which I didn't have.) My point is, that's exactly what I would do, understand what they were doing and their needs.
In my current job, forget it. The IT dept of which I'm a part, is big . Everyone has their role and you must never, ever, move outside of that role!!!!!!!!!!!!! So the odds of my being able to interact with the users is almost zero. I'll try again, but whenever I do it isn't looked on favorably.
I also agree that people tend to not want to change. But what's weird, at least at the old job, was when the technology was so bad that it crashed and lost data, but the users still didn't want to change. Even when I demonstrated that the new app was reliable.
I'll work on getting upper management buy-in.
Kindest Regards, Rod Connect with me on LinkedIn.
May 10, 2017 at 10:51 am
Would you politically be able to use a logon trigger to kill these Access connections?
May 10, 2017 at 12:59 pm
Rod at work - Wednesday, May 10, 2017 9:28 AMJeff and Ed, you've both brought up some things that I want to address. First Jeff, I completely agree with you that the thing to do is to watch and interact with the users. I completely agree with that. In my old job I would spend a lot of time doing exactly that. In a way, I could do my users' job. (In another I couldn't because their job required licensure which I didn't have.) My point is, that's exactly what I would do, understand what they were doing and their needs.In my current job, forget it. The IT dept of which I'm a part, is big . Everyone has their role and you must never, ever, move outside of that role!!!!!!!!!!!!! So the odds of my being able to interact with the users is almost zero. I'll try again, but whenever I do it isn't looked on favorably.
I also agree that people tend to not want to change. But what's weird, at least at the old job, was when the technology was so bad that it crashed and lost data, but the users still didn't want to change. Even when I demonstrated that the new app was reliable.
I'll work on getting upper management buy-in.
I definitely knew I wasn't talking to a deaf bat and knew that you already knew most of what I said in my rant. It's a real shame that "big" ends up being "isolated", as well. Been there, done that, and have a great appreciation for the problems that you have to hurdle because of that, especially that bloody "role" silo that big departments seem to value. Thanks for the feedback, Rod.
Heh... and I don't get some users either. Sometimes they'd rather get on their knees to drink from muddy water than learn how to use something like a Filter Pitcher, which is an improvement all the way around. Of course, running water via plumbing might be better... well, unless you live in Flint, Mi. 😉
I'll also state that sometimes, in order to get someone to move, you have to set the woods on fire. 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
May 10, 2017 at 2:49 pm
My initial reaction would be - why is it your task to get them to try it? Is this an IT only driven effort? If it was, expect a REALLY bumpy road.
If this #WAS business-sponsored, I'd push whoever in the business sponsored the change to go out and get those end-users to use the new stuff (or find out why they can't or won't). Organizational change (including moving users into a new application) just won't work unless that business sponsor is out there earning their keep. Even WITH a good, engaged sponsor we've had to deploy "uninstall scripts" to go out and remove the prior application from user desktops just so they HAVE to use the other piece. Your change won't last 20 secs unless you have air cover to perform such a drastic step.
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
May 11, 2017 at 9:25 am
Matt Miller (4) - Wednesday, May 10, 2017 2:49 PMMy initial reaction would be - why is it your task to get them to try it? Is this an IT only driven effort? If it was, expect a REALLY bumpy road.If this #WAS business-sponsored, I'd push whoever in the business sponsored the change to go out and get those end-users to use the new stuff (or find out why they can't or won't). Organizational change (including moving users into a new application) just won't work unless that business sponsor is out there earning their keep. Even WITH a good, engaged sponsor we've had to deploy "uninstall scripts" to go out and remove the prior application from user desktops just so they HAVE to use the other piece. Your change won't last 20 secs unless you have air cover to perform such a drastic step.
Its a mixed bag. In my previous position we wrote the original app using some 3rd party ActiveX controls. Towards then end those controls began to fail. I think it was due to changes in Windows itself which the original authors of the ActiveX controls hadn't anticipated. And the vendor of those 3rd party controls went out of business. Anyway, it resulted in the old app often closing suddenly, losing all data. Considering that sometimes the user would be in the app collecting data for up to 90 minutes, you can imagine the frustration they had with it. And yet they didn't want to adopt the newer app, which didn't crash, I guess simply because they didn't want to change. The "someone moved my cheese and I don't like that" syndrome.
In my current position there's also a lot of resistance, but I think it is much more complicated. Its not just the end users who don't want to change, sometimes its management. And I think some processes are in place which slow things down. And I get the feeling that there's other things involved, which I know nothing about.
Kindest Regards, Rod Connect with me on LinkedIn.
May 11, 2017 at 11:20 am
Rod at work - Thursday, May 11, 2017 9:25 AMMatt Miller (4) - Wednesday, May 10, 2017 2:49 PMMy initial reaction would be - why is it your task to get them to try it? Is this an IT only driven effort? If it was, expect a REALLY bumpy road.If this #WAS business-sponsored, I'd push whoever in the business sponsored the change to go out and get those end-users to use the new stuff (or find out why they can't or won't). Organizational change (including moving users into a new application) just won't work unless that business sponsor is out there earning their keep. Even WITH a good, engaged sponsor we've had to deploy "uninstall scripts" to go out and remove the prior application from user desktops just so they HAVE to use the other piece. Your change won't last 20 secs unless you have air cover to perform such a drastic step.
Its a mixed bag. In my previous position we wrote the original app using some 3rd party ActiveX controls. Towards then end those controls began to fail. I think it was due to changes in Windows itself which the original authors of the ActiveX controls hadn't anticipated. And the vendor of those 3rd party controls went out of business. Anyway, it resulted in the old app often closing suddenly, losing all data. Considering that sometimes the user would be in the app collecting data for up to 90 minutes, you can imagine the frustration they had with it. And yet they didn't want to adopt the newer app, which didn't crash, I guess simply because they didn't want to change. The "someone moved my cheese and I don't like that" syndrome.
In my current position there's also a lot of resistance, but I think it is much more complicated. Its not just the end users who don't want to change, sometimes its management. And I think some processes are in place which slow things down. And I get the feeling that there's other things involved, which I know nothing about.
Yeah... I feel your pain. I've had the pleasure of being dragged into the middle of a similar kind of shooting war between departments. Still - it's a fairly straightforward question of whether the business leadership wants to continue to fund BOTH solutions (which might entail bringing in more help for you). If that isn't an option, then THEY need to own getting the message out there and forcing the issue. Unless your org is very different from ours - they are the only ones who can.
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
June 12, 2017 at 7:42 am
Keep in mind - the job of your users is not "using the application".
They do something else for living.
The application is meant to help them in doing their job, not distracting them on learning new interfaces, new process flows, etc.
The problem with most "new versions" is that they've been driven not by users, but by developers.
And developers usually do not care much about what uses do with their interfaces day-to-day, they are more excited about the fancy look of new controls, about capabilities of expanding frames, etc.
And guess what?
Users don't give a sh.t about those fancy looks.
They need comfortable easy-to-navigate interface with minimum unnecessary c..p.
They have to stare on that interface the whole bloody working day.
And grey 3-D buttons with clearly visible rounded boundaries are way comfortable for a human eye than any of those fashionable controls with transparent background.
Not to mention - all those new features eat into computer resources like crazy.
Accountants don't usually have the latest quad-core SSD machines with ultimate graphic accelerators. Therefore your beautiful new interfaces are simply sloooow on their desktops.
And that's what they (and their management) really do care about.
If you want users to switch to the new version:
- make sure the new interfaces look as close to the old ones as possible. Improvements must be suggestive, but not demanding;
- spend a day "doing work" on the application. See how tired are you at the end of the day;
- visit an e-waste collection site, pull an old but still operational machine out of the pile and make it your testing machine. Open your new application and feel the pain of your users.
If you pass these 3 simple steps then your users will love to switch to your new software.
_____________
Code for TallyGenerator
Viewing 12 posts - 1 through 11 (of 11 total)
You must be logged in to reply to this topic. Login to reply