Chief Guinea Pig October 12, 2009
Posted by Chuck Musciano in Leadership.Tags: Customer Service, Interfaces, Users
trackback
As technology penetrates every aspect of the business world, those of us in IT find ourselves deploying tools more and more frequently. These tools are more tightly integrated to everything our users do. In days gone by, we provided green screens for data entry and green bar for rudimentary reporting. Now we control every aspect of communication, including voice, email, and text messaging, and provide interfaces to every system in the business.
Most shops do a lot of testing before rolling out new stuff. Typically, testing begins on the IT side of the house and ends up on the user side, with qualified end users signing off before something goes into production. Is there a place in that process for the CIO?
I think there is. I think I have a responsibility to know how our systems function and what the overall user experience is going to be. I’m the first to admit that I am not qualified to test the business processes behind these systems, but I do think I have a voice in the general experience.
Generally, I consider myself the primary guinea pig for almost everything we deploy in my company. I usually try out each new laptop, many new phones, and almost all user interfaces that we develop. I try to see how these tools would impact a typical end user. Are they easy to use and understand? Do they have confusing options or weird configuration choices? Would users be confronted by tedious, pointless interaction sequences?
In short, if I were an end user, would I be happy with the device or system? I feel strongly that I should never ask a user to use a device or participate in a process that I have not personally experienced.
In conversing with other CIOs, I find that some do not wish to engage at this level. They don’t have time to go through this process and don’t feel that they are qualified to make a reasonable judgment. However, most of them do have trusted coworkers that fulfill the role of guinea pig for them. They value the testing experience; they’ve just outsourced the task to someone else.
There have been times I find myself doing the same thing. Some new phones are only available on other carriers; I’ll find someone I trust to see if the phone is acceptable. Some business processes are beyond my reach (or security level), but I’ll find someone else to give me the unvarnished truth about a new system.
CIOs should be operating at a strategic level above the details. That altitude, however, does not absolve of us from having the ultimate responsibility for the quality of everything we deliver to the business. Ironically, our distance from a tool or system gives us a different perspective from the developers who toil so closely with it. By being closer to the forest than the trees, we can often see problems that are overlooked by the tactical developers and testers.
Although it may drive your developers to distraction, simply asking “why?” as you walk through an interface or use a device may ultimately create a better experience for your end users. And that, regardless of your preferred level of engagement, is what our job is all about.
[tweetmeme source=”EffectiveCIO” alias=”http://bit.ly/cio116″ only_single=false]
The Effective CIO 
I know of one company, at least, that had numerous issues from their staff with network response time. Senior management wasn’t buying it as they had no such experiences.
In doing some (very informal) root cause investigation, we discovered that the senior management were on a separate, network just for their floor. So they had 5-10 people sharing their network (and not all even using it much of the time) while everyone else shared their network with ~1500 people who were on most of the time. (There were 2-3 of these in the building so feedback to senior management was also spotty given that not everyone had issues at the same time.)
Management (not sure who) decided to swap out every desktop machine in the company for new, faster machines. Don’t know the cost of each one purchased in bulk for a few thousand people, but the servers (4-5) were not touched but, I was told, would have cost ~$60K each to upgrade. So they ended up with greater load on the servers since the desktop machines could now pump out more into the network faster. (The senior management were happy since they actually did see a faster response given the limited use they made of their “private” network anyway.)
Not sure what finally happened, but I think a vendor of a new project management super-tool that the company was committing to told them their network/servers could not handle the load. But that was after the commitment to the tool had been made and many other changes were underway to accommodate it.
(And I heard 4 years later, that conversion to the new tool suite was still not finished.)
I agree that this testing is important, but also see the need to ensure that key IT staff are using the same OLD equipment as users throughout the business. We need to feel the pain of IE6, understand the performance frustration of machines that are 3-4 years old, etc.
We need to ensure that IT is subject to IT policies for all their strengths and weaknesses.
Congratulations! This post was selected as one of the five best independent business blog posts of the week in my Three Star Leadership Midweek Review of the Business Blogs.
http://blog.threestarleadership.com/2009/10/14/101409-midweek-look-at-the-independent-business-blogs.aspx
Wally Bock
[…] by the IT team before it is ever deployed to (or inflicted upon) our end users. Whenever possible, I like to use new tools myself to really understand what my users will […]