An Unconventional Solution to a Big IT Problem

By Marc J. Schiller  |  Posted 11-20-2014 Print Email

Users believe IT will somehow divine a perfect system for them. As much as IT pros wish this unrealistic expectation would go away, they know it’s not possible.

IT stakeholders

Doesn’t this cartoon illustrate the truth? So often, the user community

  •  doesn’t know what it wants
  • can’t tell IT what it wants and
  • isn’t available to review IT's specifications and plans—even when they are written out for the users.

No matter how you slice it, the user community believes that we will somehow divine the perfect system for them. And as much as we wish this unrealistic expectation would go away—or that we could just go ahead and write the systems without our users’ involvement—we all know that’s not possible. (At least, not if we want to have a hope of actually delivering on their real needs.)

So what’s an IT professional to do when faced with the ever-present burden of unavailable stakeholders? Here’s a real-life story that may cause you to not only think a little differently, but to act a little differently in the coming year.

A Big System With a Big Engagement Problem

Yvonne Scott, CIO of Crowe Horwath, an accounting and professional services firm, was tasked with building a new platform to support the core audit business. The audit business was in the process of replacing its current system with a new service delivery platform that would enable auditors to manage their business from a single place.

The new system was set to offer a suite of new features, including collaboration capabilities, internal and external portals, and a host of reporting options. Most important, it was critical to the user community. The current technology was essentially obsolete and needed to be replaced ASAP.

All the preplanning and architectural visioning was done. The business case was complete. The vendors, the tools—all of the pure IT work involved in project setup—had been completed. In fact, Scott’s team had finished developing a full set of functional requirements.

The problem: It was time for business leadership to get involved, and to take steps to ensure the long-term involvement of their team. In particular, Scott needed the business leadership to

  • approve the final functional requirements
  • demonstrate excitement for the project and
  • communicate the importance of the project throughout the business to ensure continued buy-in and participation.

Scott scheduled numerous meetings with the key stakeholder, who had communicated with her several times about the importance of the project and his desire to support it. However, the logistics of their business (the need to travel a great deal) made it impossible for her to get any meaningful face-to-face time with the key stakeholder to address the issues. The key stakeholder wasn't turning down her meetings. He was just on the road all the time.

Scott considered using some classic distance-based communication tools— online meetings, conference calls, etc.—that we all know and love (hah!). But, since she managed a large, geographically diverse team with many remote users, Scott knew that long-distance communication wouldn’t produce the deep level of engagement required to drive this project forward. She needed to be in the same room as the key stakeholder, and neither of their offices was an option.

In the audit and professional services business, delaying a project until travel schedules calm down is not an option.

A simple, but unconventional, solution came to Scott during a team meeting: “Instead of waiting for our stakeholder to come to the office, let’s send some of our key people to travel with him.”



 

Submit a Comment

Loading Comments...