IT Project Management: Why There Are No Stupid Users

I’ve spent most of this century (doesn’t that sound cool?) working in IT and am amazed how often you hear someone say “Users are so stupid.” Well, here’s my take on that…

As a project manager with a functional background, the most successful implementations were those where we had enough time to carefully assess users’ real needs and build an easy-to-use, practical, intuitive GUI (graphical user interface) along with providing very clear, simple, user-oriented training sessions and documentation. The user is the customer and it’s our job to help them get a system (and implementation) that works for them.

Calling them stupid and focusing on what they don’t know is like when they call us stupid for not knowing their end of the business. Basically a lot of name calling without any useful purpose. Remember, many of these users have tedious, mind-numbing tasks that require the system you are designing for them. You can make their day or add to their hell on earth.

In fact, I will argue that if you’re in a mindset where you see people you work with as “stupid”, then what you really are building is walls, not good systems. And in the end, you will miss the mark…and the true beauty of the fabulous system you could have designed. You are judged by ease of use and performance, not by how brilliant a colleague might think it is.

Users know their business and what they need from a system. Systems people know what systems can do and a gizzilion ways to get that done. But there is no success unless the system is truly useful to the people who use it every day. That’s why leaving ample time for requirements gathering and for meetings of minds is essential.

In the best of all worlds, you have functional people like me who serve as interpreters for both sides and make sure there is a meeting of minds. But I will assure you that minds have a better chance of meeting when they stop thinking of each other as idiots. And yes…the other side thinks that right back at ya. I’ve seen that kind of thinking on both sides and it really does just build walls – as well as crappy systems that need to be reworked later.

If you start with the assumption that the other person knows things you don’t and that each can gain from the other, you are off to a good start. And the best thing you can do is keep asking questions, reframing the concepts again and again if necessary just to make sure there is real agreement. Patience really does pay off here.

And if you can get a prototype of the proposed system up quickly, all the better. A user really can’t always understand what you are talking about (or the gorgeous diagrams you show them) even if you think you’re being clear and they think they understand. It’s not their expertise. But a prototype allows them to better see what it is and whether it would meet their needs.

And if at that point they make you go back to the drawing board, rather than seeing them as complete dummies, simply view it as part of the process needed to get to a great result. Keep checking along the way and keep the design as simple as possible (I like the word “elegant”) while still meeting every requirement of course. What brilliance goes on in the background really should be transparent to them. (Also good to remember that whatever you are designing you have to maintain.)

Finally, after the system has made it through all phases of development (including “let’s see if I can break it” system testing with real users if possible) and you also have excellent step-by-step user documentation with good screen shots, you’re ready to go live. Now it’s time to provide training that covers the basics but doesn’t overwhelm with too many details. Sometimes more than one training is a good idea to really set the learning. (And keep the training as close to go-live as possible. People forget if they aren’t using it.)

And the last gift you might want to leave them with after the training is a one or two page cheat sheet they can use for daily reminders if needed. (Some people don’t use the system every day and they forget.)

Oh…and of course, it’s essential to provide ample friendly customer support from then on. (And that might include an easy-to-use knowledge base if at all possible, as well as a database of notes from these calls and other feedback to review for a possible version 2.)

There’s nothing more beautiful than having users, one after another, thank you for making the process so pleasant and the system so easy to use. To me, that’s the real art of great system design. Not the bells and the whistles, but the smiles of the satisfied customers.


About the author…

Ronnie Ann, founder of Work Coach Cafe, bases her real-world advice on her many years as an organizational consultant where she helped interview and hire people, added to a certificate from NYU in Career Planning & Development and her own adventures as a serial job seeker. She can also be found on her new blog, and on Google+.


  1. Very true! I agree with you, unfortunately the customer focus gets lost in the rush to beat delivery dates!

  2. You are too right, Ankur! When management has been smart enough to leave ample time up front, we’ve not only delivered better systems, but we’ve had less clean-up on the back end. But somehow, that all too rarely enters into the calculation.

    My dream would be to provide non-techie budget folks and decision makers with a true understanding of the process and how consistently tight deadlines may in the end cost them more and deliver less.

    By the way…good luck with your MBA. I hope one day when you are a top decision maker, you’ll remember that time to plan and get it right really does pay off in the end. Also remember the words “Phase 1” and “Phase 2”, since the people above you still want tight deadlines and something to show for their money. (-;

Speak Your Mind