Is It Time for User Accountability?

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.

What Is IT’s Role in User Relations?

The IT focus on customer service for end users is laudable. It improves IT’s historic reputation for being difficult to communicate with. CIOs and IT team leaders have made enormous strides in improving IT customer service over the past five years, and they are to be commended for it.

However, there are times when the quest to provide great customer service can go too far, such as when IT continues to speculatively work on projects because users get busy. That may mean the users don’t finish their jobs in defining requirements or in testing out prototype applications for usability and functionality before the applications are scheduled to go live.

In the end, IT projects succeed only when they are fully implemented, and the users are happy. To reach these goals, IT must do the system building. However, users are accountable for articulating what they want in the form of requirements and periodically testing applications to verify that the apps aren’t drifting away from what was requested.

If there are business exigencies that force users away from doing the work on a timely basis, it is reasonable for IT to request a pause on a project until the users are again available to perform the work that they committed to do. Pausing a project will likely push back deadlines, but it is a necessary step to make the delays (and their causes) visible and understandable to users, IT, and executive management.

This isn’t poor customer service. It’s getting upfront concurrence and/or discussion on project delays and their causes. It’s about explaining the risks of proceeding on projects without the active participation that users promised, which could cause projects to drift off course from what the business expects.

Effecting Project Collaboration

Successful projects and working relationships between users and IT require open communication, mutual trust, and meeting project commitments.

Delivering excellent customer service is one way to build communications and trust, but so is

“calling time” on projects when critical activities are missing or delayed, whether they are IT steps or participation from end users.

There are many reasons why users delay their work in projects.

One might be a hostile merger, as outlined above. Another might be a change in management at the top of a user organization, where the new manager wants to bring in their own system. In other cases, users might be fearful of having to learn a new work process when the old one worked “just fine,” or even concerned about possibly losing their jobs once a new system is implemented.

The more IT can be sensitive to these elements and take proactive measures so projects can stay on course, the better are the odds for project and business success.

What to Read Next:

When is it Okay to Miss an IT Project Deadline?

Staff IT Projects to Optimize Team Chemistry

The Art of Sharing Credit for a Successful IT Project