I haven’t written in a bit (well I have actually, but on Excella’s Insight blog), but I wanted to write about an anti-pattern I am seeing in one of our clients. Many have written that management seems to think of “Agile” as only within development teams, and forget that this Lean and Agile thinking needs to permeate everywhere.  It’s a dysfunction to continue working on…

So let me give you the example I am seeing so we can talk in more concrete terms.

The organization has had a rocky past between central IT and the business. Software development is distributed in various business units as well as a central IT shop (I’m staying away from actual terms the customer uses BTW). Central IT also does considerably more though, such as manage the network, run a server farm or three, manage cloud providers, email and content management services, etc.

The complaints from the business have been articulated as (in no particular order):

• I have to know who to call in order to get good service; any official channel for requests is difficult to know.
• Service is often slow and paper/form intensive.
• When I use any official channel, it doesn’t necessarily get routed to the right location.
• I’m not told everything I need to do to get my request fulfilled, resulting in delays.
• I don’t know the status on requests that have a longer time to fulfill, nor have I been told or know where to go to find out my status.
• I’m uncertain if any feedback I provide is acted upon.

I’m certain everyone has seen these before in some mix.  IT also has a set of complaints:

• People go to whoever they happen to know that is related to the request they want to make to get service. This eats into people’s time without management having much knowledge of it (perhaps the immediate supervisor knows, but no one else).
• IT needs to begin a charge-back model due to budget restructuring that is removing a great deal of central ITs funding, thus more knowledge of requests and services is needed to be known. The manner in which requests are coming does not provide a means to track it.
• The business sides doesn’t see the great work we are doing.
• The right people in IT don’t receive the needed feedback.
• IT has a blemished image/brand and are thus not viewed as a valuable partner.
• The CIO can’t keep up with the requests given to him by his peers; too many are bubbling up and being made directly to him.

If you work in an IT organization, particularly as a senior manager type, how many of these have you seen? Before I go into how to handle these with some Agility, let’s look at what this organization is doing that I consider an anti-pattern; literally anti-Agility thinking.

The senior manager tasked with solving this sees this primarily as a communications problem in 3 areas:

• Routing to the right people to do the work
• Taking in feedback on ITs performance
• Improving the communications on good performance (improving the “brand”)

To solve this, they are standing up a Customer Relations Group that will take in initial requests/requirements, receive feedback about performance during and at the end of the work and provide it to the group(s) that performed it, and get the word out on the good stuff IT does.

They are starting by creating a master catalog of services IT provides (which on the back-end will have costs associated with them). It’s unclear whether these costs and/or the parts of the IT organization that will perform them will be a part of this catalog.  So far not bad… They also will stand up a single intake service (along with an online form) to process these needs, then ‘interview’ the customer to get any additional information, and route this request to the proper parts of IT.  It seems at this point there will be a hand-off; what is unclear is how this hand-off will work if multiple parts of the organization are involved simultaneously. If software development is the primary concern, it will be handed off to a development team (or a new team will be stood up).

This new Customer Relations Group will also query the customers periodically to find out how well the various parts are doing and give this to the right part of the organization. It will also give any responses back to the customer. And finally it will create some marketing material and positive ‘press’ to help sell IT services.

To keep this from being a burden on the current IT organization, the bulk of this work will be contracted out to a big name firm that everyone respects. Sounds great doesn’t it!? Every organization needs this, right?

As well as intentioned at this group (and its contractors) may be, this creates several dysfunctions.

1. This is actually adding an additional step that will actually slow requests getting to the right people. This will increase the time to service, probably decreasing happiness, perhaps not initially, but certainly in the long run.
2. It adds a hand-off of information so that the people needing it are getting it second-hand. This will lead to greater misunderstandings between the groups that need to work together.
3. Feedback and working communications are at least partly being removed from the group that needs them directly.
4. There is an assumption that a one-size-fits-all intake process can accommodate getting all of the unique needs a customer needs to portray to a unique supplier. Requests for an email distribution list would be vastly different than one for a software development project, or just even business analysis services for a development project.
5. Messaging (branding) will be coming from a third party not responsible for any of the results.

Even worse though, there are fundamental root-cause problems being masked over.  For example, why does the business feel feedback they give is not listened to and acted upon? This solution isn’t going to address this root-cause concern. What is causing the long lead-time for IT to respond to business needs? Why are we trying to create a standard process for intake and routing as opposed to simply better connecting people to those that would supply the services and give proper visibility into the incoming work, but allow a self-routing approach? Why do we need to do a charge-back for the services internally as opposed to getting the budget reallocated properly to pay for them?

So how would I approach these items? I’d start with challenging the fundamental way things are done. I would learn where are the bottlenecks causing the unacceptable lead-time. I’d investigate the root-causes to the image/branding and see how to solve those. I’d see how I could make a catalog of services attached to the people that provide the services and work them to create mechanisms that give me an understanding of the allocation of requests. And I would at least talk with the budget personnel to find out how I could simply get the budget allocated properly; if that couldn’t be done, I’d make my service costs transparent to those when they look up my services. If I wanted something Customer Relationship-like, I’d perhaps think about deploying customer relationship software to all the groups directly, if evidence showed it would help.

Bottomline: I’d reduce hand-offs and keep with the spirit of individuals and interactions over processes and tools. I’d do the simplest thing I think is in the right direction and then retrospect on how that is working for me.