How do you involve people that don't want what you are making

Question

I am currently working on a simple system to replace an Excel spreadsheet. It's just a log for activities on a boat. The people working on the boat are of course happy with the Excel spreadsheet and don't see a reason for change. However, those on land have problems when they need to accumulate data. Basically they have 1 report each day, and if they want accumulated data, they need to go through each and every spreadsheet. Having stuff in a database will of course help greatly for them.

My problem is that I want the people working on the boat to get involved and think about what kind of system they want, instead of taking the stance "we hate change, and will just use whatever you make while being grumpy." I want people to think in terms off what they need and how they work, instead of thinking everything in terms off the existing solution.

Has anyone had experiences with getting people that need to use your solution, but don't want it, involved in thinking about how this can be a win instead of a pain for them?

Answer 1

Looks to me you have to get management involved, I don't see any way you can have leverage as a developer to have them adopt the new model.

Answer 2

It all starts with putting yourself in their shoes. They may be making your life a little harder by resisting change, but you're making their life way harder by changing their system. Either find a way to make this an improvement for them or admit to yourself that you're improving the experience of one group to the detriment of another. The second option is not necessarily bad, it could be (and probably is) a net good, but appealing to altruism will only get you so far with the group that is taking the productivity hit.

Answer 3

Perhaps you could approach them with an attitude of helping to make their job easier so they don't have to spend as much time doing annoying things on the computer?

If they think you are making their lives harder just for the sake of making your life easier (or other peoples lives easier) they may not respond well. If they think you are on their side, they may be a little more amenable to change.

Answer 4

I think the best solution to this is: involve them. Demo the program to them. Make them feel they have a say in the whole matter. Show the application and collect their feedback. Use that feedback to make the product better for them.

Though it may never fully remove their 'hatred' for the application, it will at least make them feel important, make them feel that you listen to them, and that a new application is not completely forced upon them - at least not without having something to say in the matter.

Answer 5

Why don't you keep the excel spreadsheet that your coworker like and create a mechanism that takes the speadsheet as input and puts that in a database for the people on land.

Answer 6

You have find out the main problem the boat users have with their current excel-based system, and then explain to them how your system will solve that problem.

That's the first step to winning them over.

Answer 7

OK, I couldn't resist "don't rock the boat". By which, I mean don't try to make drastic changes to their current process. You need to enable the needs of all parties if you actually want them to use it.

This doesn't mean that you cannot change from using the excel spreadsheet, but make the process as similar as is sensible so that they can adapt to change more easily. The approach should be an evolution, not a revolution (otherwise the only revolution will be against the new changes).

It is also important that any changes show value for them, otherwise they will not want to make the change.

Answer 8

Show them why what you're doing will help THEM. If it won't help them perhaps you need to rethink it...

Answer 9

I had a personal bad experience with users that didn't want to adopt the new system. It was exactly the same thing (Excel files) but for a different industry.

What may help is develop some kind of added value immediately and show it to the users. For example you could say: Look guys, if you use the new system, then you get this information calculated that help you bla bla... The key here for the users is to see this working.

If with tricks like that, you don't win them over, then I am sorry to say you might be in trouble. The project I was talking about failed miserably because the users refused to stop using their old system although the new one was up and running.

In that case, as others said, the last resort is the management. If the boss doesn't say: Stop using the old system, I don't see another way to succeed.

Sometimes, even if you are the guru of communication, there are users with influence in the organization that are determined not to let your software see the light of day. It may not be because they hate us or something, but because the status quo supports their influence and if that changes, they might lose that benefit. If that is the case, it is very difficult if not impossible to have a successful project.

Answer 10

Pretend to develop a better excel sheet. Its very likely they will ask for features that cannot be easily done in excel.

Maybe, you will actually come up with an Excel solution that connects to a database. In my opinion its perfectly ok to use excel as a front-end to a database (especially if the users are used to it)

Answer 11

People by "default" don't like "changes", so you need to make they see the benefits of the "change". If you are able to do that, your problem is solved.

Answer 12

I've dealt with a similar situation on a project I've worked on:

Problem

We were tasked with creating a resource tracking program for a construction company. They had been in the same situation, using an excel sheet to do all their work, but the work was growing so that it took 4 people a full day to do all the work. They had to track 90 employees and umpteen pieces of equipment and they were growing fast! (100+ employees in the 2 months we spent on the project)

Our job was to build them an application that made management easy. However, our customer was less than helpful when it came to requirements gathering. Because they don't know what they wanted! And they sure as hell didn't want something that wasn't Excel.

Solution

Our approach was to send a consultant to shadow them for 3 days and watch for what they needed, how they worked, and how their work could be improved/made more efficient. What they needed was something that worked in a spreadsheet like manner, because it was fast and was already a process they used.

We created for them a program that utilized a customized spreadsheet to make processing efficient and easy (we didn't use VBA!) They didn't want to change. And why would they? Excel worked... it was just slow. To overcome this barrier meant creating a product that impresses them and made their work easier.

This meant, we created a grid view that functioned like a spreadsheet. We tailored this sheet to how they input work. It was hard. It was messy, but ultimately turned out very well for them and us.

The Golden Nugget

We didn't change how they worked. We didn't touch their process. Instead we changed their tools, so that they could work faster. That's how I would suggest you work with people that don't want to change.

Answer 13

I'm here with bad news for you, so I hope you can take some constructive and highly-realistic advice. ;)

First off, I applaud what you're trying to do.

Excel spreadsheets are great for simple tracking, for playing with the numbers, and as a platform for communicating data to others. On the other hand, using spreadsheets as a form of long- or even short-term data storage is a terrible idea for a myriad of technical and social reasons that your employers do not care about.

You need to face one truth immediately: there is nothing you can do to make them care about these issues. If easy access, better security/stability, or flexibility were important to them they wouldn't even have their current methodology.

So you need to change your approach, and the first step to doing it is abandoning your hopes for a moment where their faces light up and they just "get it". If you're telling them that the change is necessary and they're trusting you on that fact (even if grudgingly) then that's all you need.

It's no different than trusting your mechanic when he says you need a new part installed in your car. Are you happy about the expense? Of course not. The work you're doing and the subsequent retraining is an expense.

To address the other half of your question: you want them to be more involved, more proactive, in providing you with their "wants" regarding a new system. You want them to "think about what they need and how they work" and provide you with ideas about features.

I have bad news again. They won't and it's mostly because they can't.

They. Don't. Know. What. They. Need.

The truth is, the hardest part of most systems is the design, not the coding. And the hardest part of most designs is the interface. Design is a hard job requiring special knowledge and skill sets.

Do not treat design as the byproduct of coding. It's the other way around. Learn that well and learn it now. Almost anyone can learn to hack some code together. I've always felt my business card should say software DESIGNER.

Think of it this way. You hire a home decorator to come in and spruce up your living area. So the decorator comes in and starts grilling you for ideas on what you want the place to look like. Would that work well?

If you knew how to make your place look nice, if you had the ideas, why would you need the home decorator?

A good decorator would observe your living arrangement and how your carry about your daily business at home. He or she would make note of the way you've currently decorated, thus learning your general taste.

Then without your direct input, the decorator would put together an overall design. And only then would the decorator ask for customer input.

You need to do the exact same thing. For example, you know they like the spreadsheets. Well, what do we know about spreadsheets? They're dead-simple for data entry. They're very responsive (no waiting involved). They provide a very simple mental model through which to understand the data. They require no logins or authentication.

In other words, a spreadsheet gets out of the way and lets the person work.

Your new system, I would assume, is going to have a web interface that's far less direct, will require authentication of some sort ("I have to remember a password now?!"), will lag in response time, etc.

In other words, your new system will remove everything they like about the current system.

So you have to win them over in other ways. So figure out what frustrates them about excel, and how you can avoid that in your system. Figure out what data they have to manually enter into this log that you can automatically derive and enter in the new system.

In other words, you're going to make some things harder on them with the new system, that's unavoidable and you shouldn't be in denial about it. Your system will be better organized and cleaner; well what's easier, keeping your room tidy or letting it go to mess?

So with that reality in mind, find every single part of their tasks that you can optimize out so that your new system is a net gain. If you do that, they'll lose the grousing within a week or two and come to like the new system.

That's my advice, as someone who's built a career on doing exactly what you're doing: coming into a small business and replacing real-world system and outdated software systems with my own software.

Answer 14

Seems like you could write an automated service with Visual Studio Tools for Office (VSTO) to automatically process the excel files and perform the data aggregation or insert it into a database which will do the reporting. The boat guys keep it the way they like it, the management gets it the way they need it, and everybody wins.

Answer 15

Sounds to me like you are doing what management SAYS instead of trying to solve their problem. You are assuming management actually knows what they want and have immediately decided that coding a new spreadsheet as per management's directive is the solution.

Why not take a step BACK and analyze the actual problem, and then try and solve THAT instead of pissing off your user base?

As others have said - you could write an application that would easily read the current excel spreadsheets and scrape the data into a database for the management folks. Assuming the current spreadsheet captures the data required, that's all you really need to do. You can even automate this process easily if you need it automated.

It's all about finding solutions to the WORK FLOW or DATA FLOW instead of just jumping in and writing code (even if its' just a spreadsheet).

-R

Answer 16

Extending Excel to continue as the front-end entry tool has been suggested. However, my experience is that this can become difficult to maintained and distribute. When there is a coordinated front-end and database change, it's often difficult to ensure that everyone uses the right version of the spreadsheet at the right time. This approach also really doesn't get at the heart of the issue which is their resistance to any change.

One strategy is to 1) listen and understand their needed and concerns 2) explain the "whys" to them 3) reassure them that the change will not hurt them. 4) Find some benefit for them.

One of the best ways, I've found to give this reassure without a lot of up-front work is to build mock screens (using Visio for example) that you can use to walk them through the new system. It would be great to add a feature that would benefit them.

This will be a win-win for both of you. 1) they can be more comfortable without a sense of uncertainty. 2) they can offer constructive feedback 3) you can do this without too much up-front investment of time and effort. If you wait until the later in the build process, you will be loathe to make significant changes which will further undermined the subsequent testing and roll-out phases.