FRAMINGHAM (03/10/2000) - A reader writes: "I just read your column entitled Hell hath no fury ...' I get the impression from your article that I should let the users define and possibly dig their own hole when it comes to [redesigning unusable applications]. That would defeat my purpose in (IT) life.
One of my biggest challenges in this field is to help users interpret their requests into functional computer software. It's far easier to give them exactly what they want and then put the blame back on them. I prefer to guide them as much as I can so that we as a company develop software that makes everybody's life easier and helps the bottom line."
He's right, of course - about how to work with users, not about what I was suggesting. (That column was about getting user support and involvement for otherwise impossible projects.) We have to get in tight with users to guide them and help them make sense of the technology available. And we need them as much as they need us. We know IT, but they know the business.
So why do so many IT people refuse to buy into that idea?
Face it: For most of us, users are mainly an annoyance when we're building systems. They don't understand the technology. They don't like it when they get what they asked for. They're always changing the requirements and demanding the inelegant, the hard to design, the impossible to code.
Besides, isn't IT cozying up to users just some management guru's fatheaded fad? Why can't users just throw the specs over the wall, let us do our work and accept what we throw back?
That's not an idle question. We used to develop systems that way. Why do we have to change?
Because the pivot point, the fulcrum we get our leverage from, has changed.
In the old days, our job was about data. We collected it, protected it, massaged it and doled it out in reports (and, after LANs arrived, in client/server applications). Sure, we also managed and maintained a lot of technology. But still, at the heart of our mission was the data.
And data structures don't change much over time. They can't, because changing a data structure means changing every application, every screen, every report, every protocol that depends on that data structure.
So every new application was really just another variation on an old theme:
Fetch the data, present the data, process the data, store the data.
But today our job is about business. It's about a whole slew of specialties we're supposed to support - sales, manufacturing, supply chains, just-in-time everything. And not just the data-related parts. It's also about communications, trust, relationship building, deal-closing.
Those are real, immensely complex business processes. And they change constantly. And the only people who really know them are users. But the users can't formalize what they know into a spec, even if they had the time. And that spec wouldn't be valid by the time we finished a new system anyway.
As stable and unchanging as data structures were before - that's how slippery business processes are now.
And that's why we need users, why we have to be in so close with them today.
Many - maybe most - of the applications and systems we'll be building for the next decade won't be about data. They'll be about what users do. And that will keep changing. We'll have to help make sense of all that. And we'll have to keep refining and changing our understanding - and our systems - to match what users really need each day.
So don't kid yourself. Getting in close with users isn't some annoying gimmick or business fad. This time it's for real. Things have changed - and for IT, how we leverage that change will define how well we serve the business.
Hayes, Computerworld's staff columnist, has covered IT for more than 20 years.
His e-mail address is firstname.lastname@example.org.