Mutiny on the Project

I then, as if that wasn’t enough self-realisation for one week, read the recent blog posts by Scott Summers regarding his thoughts on increasing test maturity. Scott’s blogs drove home the point of how two-faced I was actually being.

Now, this isn’t meant to be a confessional. But rather, I’m hoping that by sharing the process I went through on this issue, I can help you understand how to help those that may outwardly or passive-aggressively, be resisting your development project. There are three lessons I’ve learned in this area that I’d like to share.

But first, my complaint with the software in question. This software is designed to track the work we do over the course of a day, week and month and link it to projects so that project managers can manage the time and budget spent on various projects. We enter what we did, how much time we spent doing it and link it to a project code. Pretty basic stuff really and this particular software makes the process of doing that just about as difficult and non-intuitive as one could possibly imagine. Plus, in my current role, I don’t really work on these sorts of projects. Like, at all. Maybe a few hours here and there over the course of a couple of months but the vast majority of my current job isn’t project related. So, my argument to my line manager is that the software is difficult to use, non-intuitive and it doesn’t apply to me anyway. I said to her as I folded my arms across my chest, flopped back into my chair and gave her that look employed by 10-year olds around the world that don’t want to eat their vegetables!

So, she assigned me the task of teaching my team how to use the software and to write up a short set of instructions to supplement the training. She’s a smart one, my boss and this leads us to Lesson 1.

Lesson 1: Crew vs Passenger

If someone is against a change that you are rolling out, it is often fuelled by them not being involved and having no say in the course of the project. It makes people feel like the change is being forced upon them. It’s like they’ve been pushed onto a boat as a passenger but have no idea where the boat is going or why.

Of course, they are going to be a bit disgruntled, who wouldn’t be? Sometimes, resolving this conflict is just a case of promoting them to crew. Have them hoist the mainsail, pull some lines and weigh anchor (although, preferably not in that order). Anything that makes them a part of the project. In my case, I was tasked with learning the software well enough to teach it and to write up instructions for its use that apply specifically to my team. In doing so, I got over some of the non-intuitive issues I had with the software and found quick and easy shortcuts that made populating the data - mostly - painless.

Lesson 2: What did you say, iceberg ahead?

As Scott mentions in his blog, use workshops to win over the hearts and minds of any detractors. This means taking the time to listen to what the detractors are saying. I mean, REALLY listen. Don’t listen while thinking about your reply to refute everything they are saying and thus dismiss them out of hand. Listen to understand, don’t listen to respond (I believe the saying goes).

Sometimes a workshop is great for this but also sometimes a workshop will let negative comments grow out of control and a few detractors can quickly turn into a mutinous crew. If someone is very much against the project, sit down with them one-on-one over coffee. In fact, buy them a coffee and listen. Let them talk and get it all out of their system and just listen.

Then, reply to their questions and concerns with thoughtful answers. Even if you can’t reply immediately, you MUST reply to them. You must address their concerns. As a bonus, you may get some good ideas from them to make the project even better.

Quite often people are against something because they see a potential fault that you’ve missed or their needs and concerns were never considered from the start. Also, by listening and taking onboard their comments, you are giving them an active role in the project and may save yourself greater problems further down wind.

Sometimes all the disgruntled wants, is to be heard.

Lesson 3: When the wind blows, put the sails up

There are times when you just have to put the mainsail up and catch the wind and outgoing tide regardless if you have everyone onboard or not. Rarely can you just let a project sit with slack sails in the doldrums and hope that everyone will grab an oar and be happy about it. It just doesn’t happen that way.

So…sometimes you just have to press on. It might help in these times to remind the detractors of your (or your company’s) past successes. Assure them you have listened to their concerns but you have also done this before. Even though they may struggle to see the end result, remind them that you can. Quite often we are more afraid of what we can’t see than of what is actually in the dark. Sometimes asking someone to trust you, trust that you have their best interest at heart, the best interests of the company and to be patient until the end result, is the only course of action.

In my case, in addition to being asked to train my staff on the software, we were given deadlines of when the data had to be entered by, with weekly and monthly reports being run to ensure everyone is complying. When it comes down to it, regardless if I like the software or not, this is the software the organisation has chosen to use to track our projects.

The goal of these three lessons is not to confront people resisting change head on but rather to listen and bring them on board. When we change something in our organisation, we must always remember that we are changing how people work and to do that successfully, people have to want to change.