Why computerized information systems frequently fail to meet the needs of users

Let’s take a look at another CISSP-type question today, because I think it has broad implications for more than just CISSPs.

Here’s the question.

Which of the following best explains why computerized information systems frequently fail to meet the needs of users?
A)Inadequate QA (quality assurance) tools
B)Constantly changing user needs
C)Not enough project management.
D)Inadequate user participation in defining system requirements

I don’t think I’ve ever worked somewhere that the IT department could look itself in the mirror every morning and say, “I’m SO glad my information systems completely meet the needs of my users!”

Let’s start this one from the top.

Inadequate QA tools. I don’t buy this answer, if only because if there were an epidemic of inadequate QA tools, I would have noticed a pattern in the headlines sometime between 1997 and now. I’m sure QA tools could be better, but lack of something jumping up and down screams that there’s probably a better answer.

Constantly changing user needs. There’s some legitimacy here. User needs, whether real or whimsical, certainly change very quickly. But the world as a whole changes very quickly and we have to respond to it, or go out of business. Maybe it’s a better answer than the previous one, but it’s also a bit of a cop-out. Maybe they’re both cop-outs. Let’s move on.

Not enough project management. I’ve worked in many shops that believed this was the issue, which is probably why I frequently found myself with five bosses earlier in my career. In my experience, adding layers of management does little more than add confusion and conflicting priorities. Jesus said no man can serve two masters, but there’s no shortage of IT shops that think a man can serve five. (ISC)² recommends against this; its recommended structure for a security organization is to have it report directly to the CEO and make it completely independent of IT and business operations. That’s a different study question; one that required me to unlearn some things before I could get it right.

Inadequate user participation in defining system requirements. We have a winner. The problem is that the people designing and implementing the system don’t build what the users want. Certainly, there’s blame on both sides. Neither side sees the other side as reasonable. And I remember, about a year ago, talking to a couple of users and trying to solve a problem for them. “Tell me what you need, and I’ll translate that into ports and protocols and get that fixed for you–real quick,” I offered.

“See, now you’re already jumping to ports and protocols,” one said angrily.

“That’s just geek talk,” the other said. She even waved her hand dismissively.

Gee, thanks for the slur. I was only trying to help. I walked away frustrated. Now I’m working something completely different, and they most likely still have a system they say doesn’t meet their needs because if they couldn’t tell me what they wanted, they probably can’t tell someone else like me, either.

But sometimes they do know what they want, and repeat it loudly and often. I worked in a shop whose users were saying in 1998 that they wanted Microsoft Exchange and Blackberries. The shop didn’t want to do it, so the users revolted and found someone who would give them what they wanted. There were a million reasons not to do it–namely, there were solutions out there that were cheaper to buy, cheaper to operate, and more capable–but they had their minds made up. Had the shop given the users what they wanted, it most likely would have run over budget and we would have had to bring in more people to run the system adequately, but that would have been better than laying people off annually for nearly a decade.

If you found this post informative or helpful, please share it!
%d bloggers like this: