In my last article I talked about why IT magic is never good. Well, I guess I should have known better than to use the word “never.” In his “Thoughts by Techxplorer” blog, one of my readers came up with a pretty good exception: a situation where the thought of IT magic — but not the actual use — can be valuable.
Here’s the situation: Imagine you’re in the early part of a new project doing the initial requirements definition. This particular project is trying to improve the way that a certain business process is being done, so naturally you talk to the people who are carrying out the existing process to get their ideas on improvements. But now you run into “the ditch digger syndrome”: If you ask an uneducated ditch digger what he needs to do a better job, he’ll more than likely say “a bigger shovel.” He won’t know to ask for a backhoe if he’s never seen one.
This is a common problem when we try to get people to talk about requirements: people tend to be limited by the way they’ve always done things. And if they’re not encouraged to do otherwise, people tend to think small. They’ll tell you that a certain field should be moved to another place on a screen, or they’ll ask for a new report. But they won’t ask for big things because they won’t think of them. As Steve Jobs once said, “It’s really hard to design products by focus groups. A lot of times, people don’t know what they want until you show it to them.”
Unfortunately, the result of people thinking small during the requirements process is that you end up specifying a system that looks very much like the one they already have. And that’s usually a tremendous waste of money (why bother replacing something with itself?), and it gives you only single digit percentage increases in productivity.
Now, as Techxplorer points out, the business users you’re talking to may just be trying to be reasonable. They are trying to make your job easier by asking for small things to minimize the effort required. So how do you shake them up? How do you get them to open themselves up to whole new ways of viewing the process you’re trying to improve?
That’s where Techxplorer suggests you use the idea of IT magic. Take the business users through a hypothetical situation: “Suppose you could get anything you want. And suppose that we could use magic to make this process ten times easier for you. How would you change the process in that situation?”
I’ve also heard this called “blue-sky brainstorming” (the sky is the limit). And frankly I’ve never used the word magic when I’ve done this — I’ve just relied on the phrase “make the process ten times easier.” Most people have to think big when they improve a process by a factor of ten.
But no matter what you call it, and no matter how you explain the concept to business users, I think this is an important tool to employ during the early stages of requirements definition, and I’m glad Techxplorer pointed it out. You need to shake up your users and make them think about what could be, because even if it’s something you can’t deliver — even if it’s impossible — it gives you valuable information about radical new ways to improve business processes. A totally ridiculous idea may spark a great idea that’s very practical to implement.
I only have one concern with this hypothetical use of IT magic. If you use this method, then you need to be very careful to bring your business users back to reality before you leave them. It’s all well and good to tell them, “suppose we could use magic,” but before you leave you need to remove the magic spell. You should remind them that there is no magic, and make sure they realize that this was an exercise, and that the only way this kind of thing can be implemented is through hard work using real day-to-day tools.
Or, if you prefer, you can avoid use of the m-word altogether (or save it in reserve for extreme cases) and just use the “ten times easier” approach to broaden their thinking. I’ve found that it works just as well.
Remember that my argument against IT magic is that it creates unreasonable expectations. So be careful that during your requirements gathering you don’t create those unreasonable expectations yourself.