Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

What happens when IT is guilty of Shadow IT?

Paul Whimpenny, Senior Officer for Digital Strategy in the IT Division of the Food and Agriculture Organization of the United Nations | Oct. 6, 2016
When team leaders enjoy autonomy, you can end up with different solutions that solve the same problem

This vendor-written piece has been edited by Executive Networks Media to eliminate product promotion, but readers should note it will likely favour the submitter's approach. 

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.


1  2  Next Page 

Sign up for CIO Asia eNewsletters.