What happens when IT is guilty of Shadow IT?

When team leaders enjoy autonomy, you can end up with different solutions that solve the same problem

It's bad enough when people in your organization procure IT resources without the help or knowledge of IT, but before you can address it, you better get your own house in order.

Between staff and consultants, IT in our organization numbers some 200 people. That's a lot of people to keep track of. A couple of years back, IT management started putting more focus on strategy and prioritizing work to align to the strategic plan. And as we began scratching beneath the surface we realized we had a problem.

Under previous leadership, technical team leaders had enjoyed a large degree of autonomy. This had resulted in team leaders working closely with specific customer bases to deliver IT solutions, which in itself was a positive.  But with these customers being the funding source for the resources, it created an unhealthy situation whereby team leaders were focused on responding to any requests from individual business units without taking time to look at the bigger business picture and ask whether it made sense to do that work or not.

Even worse, since team leaders worked within specific technology domains, their solutions were built within that domain with no consideration of whether other technologies might be more suitable. The upshot: solutions were sometimes sub-optimal and team leaders were offering different technological solutions to different customers to solve the same business problem.

To get a grip on the situation, we took three key steps. First, the budgetary responsibility was centralized under the Office of the Director. In a stroke, this ensured tighter control of funds, especially those coming in from outside IT to fund consultants to perform specific work.

Secondly, a team was set up to coordinate project work, putting in processes to ensure that deliverables and target dates were being defined with customers and tracking that commitments were being met. This helped address both project overruns and the tendency to renew consultants that were working on vaguely defined objectives. The absence of good documentation also compelled renewal in many cases since knowledge was in consultants heads.  A time-keeping system was also introduced, with time recorded either against operational activities or specifically assigned projects.  This helped hammer home the message that we should all be working towards an agreed set of prioritized activities, and also deprived teams of the time they once allocated to pet projects.

Thirdly, a coordination process was put in place for the approval of new IT investments. This coordination had in itself three elements:

  • A common entry point for business requests. This didn't prevent business users from going to team leaders, but they had the obligation to route requests through this common entry point. Requests were logged, tracked, and reported on regularly.
  • Development of a short business case template to document each request in terms of the business need, indicative costs and timeframes, and any architecture, security and other technical points of note.
  • And a formal approval process consisting of an online consultation among the IT community, followed by a management review and signoff on the business case for the investment. During the first year over $2 million of work was approved through this mechanism.

All of this caused a good deal of negative reaction within IT. Having been used to autonomy, the processes were often perceived as both adding work and in stripping away responsibility. We needed to repeatedly stress the objectives of better prioritization and delivery of work, and ultimately greater clarity for individuals.

Frankly, we exacerbated this staff reaction by making some mistakes along the way. For example, we built the time keeping system with a view to reporting everything with the finest degree of granularity, but that proved to be totally unpractical and we changed tack and introduced something simpler. We also were overly ambitious about the first build of the project monitoring system and eventually eased back on the level of reporting requested.

All in all, we think we now have the balance between control and giving staff the responsibility to get on with their work.  For management, the important thing is we now have genuine oversight into what is going on and can steer in the right strategic direction. And now, having demonstrated efficient and effective delivery from inside, we have the moral high ground when going to talk to Shadow IT groups outside of IT.

Whimpenny is the Senior Officer for Digital Strategy in the IT Division of the Food and Agriculture Organization of the United Nations (FAO). The views expressed here are those of the author and do not necessarily reflect the views of the Food and Agriculture Organization of the United Nations (FAO).

This story, "What happens when IT is guilty of Shadow IT?" was originally published by Network World.