There are many times when I’ve been involved in introducing an internal system to an organisation, and one of the user representatives has pushed for changes to the default setup because it doesn’t fit the way they do things, or their people are just used to something else.
Most of the time I see this in technology services—for example, a content management system that feeds a website. A new content management system is sought, one is found that is a very good match to the organistion’s needs, but then one team will be unhappy with, say, the input process. “Our team has always used their own editors,” they’ll say, “We don’t want to have to train everyone on a new standard editor, they’ll riot. We need to allow our writers the freedom to continue as they are. We need to add an integration from their own editors to the new system.”
Occasionally I see this in business processes, such as an expenses process. Everyone will need to upload their receipts at the end of the month, and then one department head will say, “But my team are on the road, they’re busy people, they can’t be logging into another new system. We should let them email their expenses in as before and let the Finance admins do the admin. It’s fine for everyone else, but not for us.”
The problem with customising a standard system is that there’s a cost not just in the initial setup, but in on-going maintenance. I’ve seen plenty of these projects where the cost of customisation is more than the cost of the system itself. But then as the vendor’s system evolves and underlying technologies need renewal, so our unique add-on has to evolve with it. If we’d kept with the standard system all that cost and effort would be handled invisibly by the vendor. Instead, we need to run our own little engine to keep pace with them.
Even for more manual business processes, the more exceptions exist the more special knowledge is needed. (“Ah, yes, Jasmine usually deals with the expenses from them because it’s a bit different. You’ll have to wait til she gets back from holiday.”) Exceptions also bring more chance of error, and therefore more time spent hunting down and unravelling those errors rather than getting on with the core work.
And then when the organisation falls on hard times—or just gets scrutinised closely—it’s those elements that stand out, and the people who lobbied for them and tolerate them suddenly look profligate. Then the systems can be cut. So can some of the people needed to support them.
Now without doubt every organisation is special in some way. That’s why people go to them and not their competitors. But we need to be careful about why we’re special. A long time ago I even argued (against a well-known journalistic expert) that my then-employer, The Guardian, was right to build its own content management system—because its content creation process was the very thing that differentiated it. But, with all due respect to so many of the hard working staff there, that organisation wasn’t and isn’t special because of its expense process or its room booking system or its email communication. Those are all processes and systems that can use standard solutions.
Sometimes we have to take the hard decision to change the way we work. We can we adopt a ready-made solution, and use our special human ability to learn and adapt and get used to new ways of doing things. That difficult change may well make things easier for us in the long run, and be better for the organisation as a whole.
niksilver.com 