‘I’ve had it- we’re switching.’
‘The salesperson from [the other leading vendor] is telling me [all our problems will be solved] if we switch.’
I’ve heard this stuff. If you work on company IT, you’ve probably heard it, too. The reality of enterprise software is that it’s hard to do well, even if you’re buying the very leading off-the-shelf applications. People get frustrated and that’s understandable. It’s fine.
What’s not fine is perpetually switching vendors or kicking off new development as a solution to problems that lie elsewhere. Now more than ever, enterprise software is pretty flexible. Most successful implementations are about the hard work of figuring out what you really want the software to do and translating that into action.
Blaming the software is an easy way to vent but often misses the point. I don’t have a silver bullet for you, but I will say that I think the most important first step is to assess whether:
A) This application is basically fine. Our main problem is with deployment.
or
B) Using this application is no longer a good investment and we should explore an alternative.
Too often, it’s politically, emotionally easier to go with ‘B’. Too often, I see teams declaring ‘B’ when to get where they want to be, they really should focus on ‘A’. To help you make a balanced assessment, here are a few common signs that you have an ‘A’ and a few that you have a ‘B’.
‘A’: Signs that the Application is Basically Fine
The ‘Requirements’ Need Work
Was the implementation team obliged to get requirements from all the different audiences and then patch something together that met all those requirements? Do a lot of the current issues have to do with the handoff’s from one department or job function to another?
Gathering ‘requirements’ in this way, makes it likely that the issues lie with the way the software was deployed and configured vs. the underlying application. Try creating user stories based on the underlying jobs the users are doing and then explore how much work it is to revise the deployment (or surface features).
Side note: I don’t think requirements work. Even for deploying IT applications, I think testable narrative, user stories work better. For a fully featured view on this, I can’t help but mention week 5 of my Coursera course ‘Agile Meets Design Thinking‘. In that module, I step through how you can use process design to link your work in design thinking/user discovery with strong, testable user stories to guide your implementation.
The Processes in Question Aren’t Ready for Automation
All software can do is standardize and automate things humans already know how to do. Did the implementation team find that no one really had an answer on how a lot of the processes should work? Was some poor manager cornered in a conference room and made to design a process in two hours without input from her team or testing?
While there is sometimes a bit of ‘best practice’ baked into enterprise software, I’ve found it’s usually about 1/10 of what its customers expect. There’s often a pretty big disconnect between how much an application vendor will expect you to know about how to define your processes vs. how you were hoping they’d know how to automate and standardize things in a way that will work for you. Sad but true. There may be another vendor out there with more ‘best practices’ baked in, but probably not. Your best bet is almost definitely to invest in designing and describing your processes and then revisiting the question of how to use an application to automate them.
The Schedule was Arbitrary
As humans, we love the comfort of certainty and therefore we love plans. The problem with software is that there are so many possibilities, it’s rare you know enough to create a detailed plan (yes, this is basically the whole premise of agile).
Did the implementation team feel like they didn’t have enough time to do things right? Here’s a good litmus test: Did everything get tested with real users using realistic test data? If not, the schedule was probably too rushed. Try using a more agile approach with problem/job-centric charters and time for testing.
‘B’: Signs that You Should Explore an Alternative
Changes are Hard
You’re trying to change the way you do business, you’ve thought through important changes you want to make with actionable narrative (user stories) and prototypes, but the changes aren’t reasonably possible. You’ve talked to the vendor about what you want and why, and they don’t have any good ideas.
You’re at 90०
You’re trying to use the application for billing, but the vendor clearly doesn’t see that as part of what their application was meant to do (or doesn’t any longer). There appear to be more focused alternatives available.
Integrations are Hard
You have a set of applications you like but one of them makes it hard or impossible to achieve the type of integration you want. This is causing you to do things like duplicate data in awkward ways that are generating overhead and causing errors.
You Can’t Find Talent
You’re starting to find that no one on the job market knows how to work on the application or its underlying plumbing. Training is hard and the talent you want isn’t that interested in learning.
In Closing…
We want software to figure us out and do what. While that is the job of those of us that make it and operationalize it, standardizing and automating the way a company does business is complex. Even in the best of circumstances, it takes a pairing of good software and thoughtful deployment.
If you have a minute, I’d love to hear what you think in the Comments form below.
If you’re interested in some ideas on a user-centric approach to IT and enterprise software:
- I’ve put together some thoughts in the Enterprise Software Playbook.
- My Coursera course on agile steps through this
