Working with transformational technologies such as Workflow and Content Management, I often find myself warning clients not to transform too much, too fast. During our sessions, they’re eager to pronounce low-level, semi-detailed rules without giving much thought to administrative overhead or implementation costs. They’ll throw-out sentences such as, “Oh, and the system should stop the user if it’s an XYZ account and the ABC letter should be sent out to all the JKL clients.” The problem is that this seemingly reasonable request requires:
- Integration to a new system,
- A letter generation system plus integration to a database, and,
- Implementation/administration of organizational support tables.
Then the user blithely adds, “Unless it’s quarter closing and we’re behind on processing, then just let it go through.”
Do the Big Stuff, then tweak…
The most effective way to implement systems that introduce radical change is to concentrate on getting the basics right. The most common objection I hear to this advice is, “If we’re going to do it, let’s do it right!” It’s typically said as if what’s “right” were obvious to all but the dullest fool. As I’ve pointed out before, however, new software is an invasive species, and it can breed unanticipated offspring.
I like to see software in it’s new habitat, and then evolve it, by design. After it’s introduction, we watch and analyze. We see how users are leveraging the new functions and data, what old habits are now redundant, and where former processing validations need not be enforced or can be obtained without user intervention. Only then do we tweak…
Don’t forget to tweak.
Tweaking is easy to forget, and yet, it’s where business can often reap the greatest reward. After implementing a disruptive system, and putting your users through so much change, you have to go back and listen to them all over again. You have to find out what works and what doesn’t. Yes, you may hear a lot of griping, and it may be on the heels of a difficult and stressful roll-out, but it’s crucial. No one likes to hear negative user feedback, but if you don’t clean up your own mess, someone else will, and you’ll be remembered not for what you got right, but for a vague smell of inefficiency and missed opportunity — it’s not a pleasant scent.
No Funding for the Tweak!?
This is one of the stupidest and most avoidable problems in all of software development — companies forcing project sponsors to procure funding once and never being able to ask again. This is a self-induced crippling of benefits. It forces sponsors/managers to spend more upfront, attempting to predict exactly how a system will be used, because going back for additional funding is difficult or impossible.
I understand it’s done for cost containment reasons, so that ROIs can be calculated and paybacks ensured — but it’s dumb. It’s the reason that rapid development and agile techniques are so often promoted, and it’s one of the reasons such techniques are ignored, because those approaches make building a compelling business case more difficult,
Numbers are hard to ignore. I find that when presented with real numbers (and the solid math behind them) folks will listen. Let’s say you have 30 Specialists each processing 6000 “applications” per month. If you can demonstrate how a $50,000 change to the system will save each user 30 seconds per application they process, the payback would be (in theory) 3 years (and there are many ways that theory can turn out to be wrong, but that’s the subject of another post).
If you add enough of those tweaks together — you’ll be talking about real money!