"Actually, we have a beautiful CRM system. Except nobody's using it."
At first, I could not believe my ears: was my client really telling me that this piece of high-end software was simply languishing in utter disuse? Soon after, I started to fear for our own OGSM software and reporting software - because our clients should never suffer that same fate!
But over the years, I’ve noticed that many of our users are struggling with some kind of resistance. People who say they hate software. Or people who aren’t quite sure what their problem is, but who still have something keeping them from filling out their progress reports in the software. No matter how much evidence we can show that it would save them time if they did. How is this possible?
I began to understand this problem – one that is not at all uncommon – when I learned about a model proposed by Krauthammer. It's a very simple analysis, consisting only of three short questions:
Do they see the point? That depends on the organization's goals, strategy, and communications.
Do they want it? That depends on the organization's culture: principles and behavior.
Can they do it? That depends on the structure: responsibilities, hierarchy, distribution of tools and means.
When seeking to implement new software, the first problem you run into is a basic law of human psychology: people simply want to be left alone. This leads them to fiercely resist any perceived form of micromanagement. A typical response that we often see is: "I'm already responsible for the final result. Why should I submit interim progress reports? It's just extra work."
The project manager in question may have a point, and it's worth checking: are the progress reports actually being used for anything? If people in the organization believe that this is not the case, you might be dealing with a problem that runs much deeper than the software. Just because this attitude is understandable, however, does not mean it is justified: not every project manager can see the whole picture. Sometimes interim reports can be extremely important for the progress of other, related projects; reports might provide valuable information to the board of directors; or the interim reports are used to keep the company accountable to its clients or stakeholders. Such interests are not always in the direct purview of the project manager.
To get people to use project management or reporting software, then, you'll have to explain to your users why what you're asking them to do is important. What are the reports used for, and how do they influence decision-making at the top? Only by introducing them to the big picture can you help your users see the point of software.
The unwilling user is a totally different species that demands its own approach. Resistance to software is often linked to an organizational culture that has left people feeling shortchanged in some way. Some rebellious non-users of our software, for example, had been assigned tasks through the software without any prior announcement or dialogue with their manager. For these users, our software instantly became the object of a great deal of pent-up rage: why is management treating us like slaves?!
Oftentimes, in such cases, the 'rage against the machine' is merely the tip of the iceberg: below the water line you might find all sorts of (long-running) frustrations with an organization's culture. If you want to assist with the implementation of software in such circumstances, it's important not to take people's complaints at face value, but to help management see that they need to make changes if they want the implementation to succeed. Strong interpersonal skills will typically be required to communicate that message.
The most dangerous type of unwilling user is the true subversive, who doesn't feel responsible in the slightest for particular projects and for that reason completely refuses to submit reports for them or, upon repeated insistence, just submits 'whatever'. This kind of behavior can't be blamed on the software and is impossible to solve from the design side, but it's a good reason to get some management coaching involved. Only if projects are designed in such a way that project managers can truly operate as such, and that they've had some agency in negotiating and accepting a well-defined set of responsibilities, you can expect such obstinacy to dissolve.
On the other hand, if an organization fails to support its project managers and a culture of apathy renders them unable to develop, grow and expand their responsibilities, we've sometimes seen our users submit data at random just to escape the line of (reporting) duty. Unfortunately, random input doesn't yield any useful information for upper management, which means the pressure to report will quickly abate and your software will probably be short-lived.
If you've been working with a certain piece of software for a long time - or even developed it from scratch, like we did - there's always the risk that you lose sight of just how complicated it is. Everything might look deceptively self-evident to you. Good software is user-friendly, which is to say, users should be able to navigate it without much effort and the interface should be intuitive at all times. Failing this, users will be prone to losing their way. Worse, they'll typically be hesitant to put any effort into learning a system that appears 'illogical' to them.
But even if you do comply with a high standard of UI design, there is no guarantee of success. A mismatch between the the number and the complexity of the available features of your software and the maturity of the organization (the ability of users to use these features in a meaningful way) can lead to implementation difficulties. Bizaline's users, for example, are asked to indicate the status of a project in the familiar RAG format: red for real problems, orange for threats, green for nothing-to-report. Conceptually, everyone can understand this, but that doesn't mean it's smooth sailing from there: a project manager who has lost control won't know whether to pick red, orange or green. He might pin the blame on the software being too difficult, rather than acknowledging the fact that he doesn't have his act together.
When the division of tasks on paper is not representative for the real situation (who's doing the work?), or the team’s resources are assigned in sub-optimal ways, people might be unable to experience the benefits of software at all. Some project managers that we tried to convince of the software's usefulness, for example, were simply so overloaded with work that they had no time whatsoever left to spend on reporting.
Most of our clients’ teams will have a small number of unwavering digital illiterates who'll simply never get the hang of it. (My colleague once had to spend two hours driving to solve a user’s ‘problem’ in all of 30 seconds). Those are best left to their own devices: software is built and bought to save people time, and with these users, you’re not going to achieve that goal.
Finally, there are those users who are intellectually perfectly capable of grasping what you're trying to teach them, but who are paralyzed by irrational panic or resistance in the face of having to learn something new and potentially making mistakes. Such fears will often be hidden behind a facade of feigned impotence. Those users whose instinctive resistance has already taken a complete hold will accept any excuse to refuse cooperation.
With this type, it is essential to offer personal guidance and lower the threshold for using the software as much as possible, by prioritizing 'familiar' functionalities like cloud document storage or an messaging system to replace e-mail. Oftentimes, it helps a lot to simply show them in person how everything works - it might be easier than they thought, or they'll have an epiphany as to what the software can do for them. Training users to make the most of the software - ideally by their own colleagues and supervisors - is the most important factor to realize a successful implementation.
Conclusion: overcoming resistance
Over time, I learned that refusal to use the software is actually not our greatest concern: at the very least, the absence of information will typically trigger an effort to track it down. It's a far bigger problem when users simply submit incorrect information at random. After all: the quality of any information or conclusion that emerges from the software is directly linked to the accuracy of the input data. For that reason, it's very important to keep an eye on the morale of your software's users. Can they do it, do they want it, do they see the point? If you sense resistance to the software, make a serious effort to understand precisely what's happening. Is it a design fault? Or rather a problem with your client's organizational strategy, culture, or structure? Only after analyzing that question is it possible to select the right approach to the issue. That way, you can beat the rage against the machine.
Do you have any stories to share about the successful or failed implementation of software in your organization? I'd love to hear them. Or are you curious to learn more about OGSM software, MyProgramanager, MyContractmanager or what we can do for your organization? Don't hesitate to send me an e-mail at firstname.lastname@example.org.
Not enough time to read management books and explore research in your field? But still want to keep up to date? Sign up for Bizaline's newsletter: full of fresh insights, juicy stories from colleagues and spam-free, guaranteed. We will share regular blogs and book reviews on topics ranging from strategic execution and programme management to risk, governance, compliance and contract management. And if there's something you'd like us to write about, drop us a note and we will pick it up! Register for our mailinglist below, and subscribe to our LinkedIn page or subscribe to our Youtube channel!