Is It Time for User Accountability?
CIOs have focused on an IT service culture, but how much is too much, and what responsibilities fall to users?
The project was a large system conversion, moving from one hardware platform to another and from one software system to another. This work was the result of a hostile acquisition between two large financial companies, and the “losers” on the side of the acquired company were required to participate in requirements definition and system testing, but they didn’t want to do it.
I was an IT programmer on that project. I remember that users were friendly and offered to freshen up my coffee, but defining requirements lagged, testing systems lagged, and there were numerous unforeseen enhancements that suddenly had to be incorporated in the middle of the project. Consequently, the project barely chugged along, and was well over a year past its scheduled due date for cutover.
The delay and the cost overruns didn’t go well. Several managers on the IT project got the blame and lost their jobs. To be sure, they did own some of the blame, but not all of it.
This was a classic case of user resistance to a major change in IT systems that was not even about changing hardware or software. It was about being taken over and losing a sense of personal autonomy. This was an issue that IT could do nothing about.
I often keep this career experience front of mind when I speak to IT executives and organizations about developing a service culture. I think about it because even if a CIO is intent on developing a service culture, there are times when user accountability is the problem.
What Is User Accountability?
If you want to build a house, you hire a contractor to construct the building and they require you to furnish them with a blueprint, along with other specifications, such as what color of paint you want for the interior and exterior.
It is your job to define your needs and to agree and sign off on any change orders that arise.
Users requesting new systems or system changes are obligated to do the same. Yet often, IT and users start new projects without complete sets of specifications that everyone has agreed upon.
When it comes time to kick the tires of new systems or to perform functional testing to make sure that a new system or application works, there are occasions when users don’t make themselves available because they have other pressing business needs. This can delay any project.
Unforeseen delays and priorities that come up are understandable in today’s rapidly changing business world, but when they happen, they should be acknowledged, along with any adverse impact they might have on project deadlines.
The trap IT often falls into is that it fails to “call time” and request that a project be placed “on hold” until users become available, if the project is at a point that requires user action. Instead, IT tries to work around the delay by doing other project tasks that it feels don’t require users. Then it fails to communicate to project stakeholders that there are project delays. When the project timetable slips, IT ends up getting the blame for delays that it wasn’t responsible for.