Why Your IT Shared Services Teams Can’t Deliver

A project manager is on the phone with what seems like 50 people talking through the status of the latest death march. The PM continues, “…well, before we get this feature in production we’re waiting on the network request to process, this database change got held up which means our people can’t test, the new machines for our DR build out are delayed by procurement…” A VP chimes in, “Let me get the DBA team on the line here, we’ll get this worked out right now.”

Anyone who has worked at a non-unicorn knows this project slog because the companies they work for are not the unicorns. The mismatched alignment of projects and dependencies is well documented by industrial authors like Deming and Goldratt and more recently in the IT industry by the authors of the Phoenix Project and the DevOps Handbook. What happens when everything must be done now and every team is forced to deliver on a schedule that is not aligned with their goals and incentives, most often, is chaos.

I want to suggest two key contributors to this dis-alignment, a vicious cycle of a downward spiral that lowers trust, increases burnout, and slows the delivery cycle of IT shared service groups. These two contributors are a lack of consistent prioritization across the organization and over-utilization for shared service groups. I want to outline how these two factors work together to drive down overall success of shared service teams within organizations.

A colleague of mine works on this type of internal service delivery team and was recently telling me of a meeting where leadership on a project outlined the importance of the project for the whole organization. “This project is critical across all business lines, everyone here should consider this top priority.” Coming into this somewhat innocuous meeting with an idea that a external consulting group was taking the reigns on the first implementation phase, this person was slightly shocked to hear about their supposed new number one! Going back to his boss and director, he discussed this conversation and asked where the priority for this project really stood. Top? No. Top three? Probably not.

This type of discussion crops up fairly consistently, amidst both changing and undefined priority structures it is hard to know just what to work on. Goldratt lays this out very clearly in The Goal, every individual should know the goal of the organization and their team should be aligned towards these goals. I have seen firsthand how this philosophy can be executed poorly in both small and large companies. If context for prioritization decisions is lacking, or was never there in the first place, then individuals face an impossible task of determining how their work aligns with the organizational goals.

Now, think of how these shifting priorities play into the work stream of a central service team within a large organization. When there is misunderstanding of priorities, people rarely err on the side of their project being less important to the overall organization success. These teams become laden with requests, often without appropriate time to prepare, that come attached with this prioritization heavy language. “We need this server delivered so that work can begin on a critical project.” “This request needs to get through today, its been escalated through VP1 and VP2.” This type of language drives down the trust between teams because it implies an inherent sense of lack of alignment. When requests comes with forcing language but not appropriate context, it implies that the team receiving the request is not capable of understanding the context that the forcing language is derived from and therefore the language of priority is the only language used to communicate. It does not express a trust in the other group to be able to evaluate appropriately against the concerns of the overall organization.

The second contributor is an over-utilization for these service groups, but I want to outline how this over-utilization creeps into the system. Let’s say that ten years ago a team was built up to manage a set of shared services that a number of groups across the organization would use. If nothing changed in the set of promises that these groups made to one another or the system that was being supported, that team would be perfectly capable of maintaining their job as is. The challenge comes when new responsibilities continually are added to their plate and suddenly the burden that the organization places on this individual shared service team is large. This team has a mountain of debt from systems added quickly and changes made based on misunderstood priorities and now must support that system as-is for their customers to be happy.

Imagine a different model where this team was given the necessary respect to do their job. The first critical component of this type of respect is an evaluation of the work actually done by this team. If, in the case outlined above, ownership lines have become blurred, the first step may be to determine exactly where ownership lies and what that responsibilities means. Measure that responsibilities impact on the team. This process allows a team to determine their largest bottleneck within their own system. It is critical, though, that the team determine the bottleneck using the context of the larger organizational goals, rather than the local optimization of their own latency. It may be OK that some request takes 3 weeks to process if it is not within the critical success path of the organization.

Once this team model has been measured and a single bottleneck identified, what is left to do is a simple Goldratt-ian process of eliminating the bottleneck and moving on to the next step. As IT professionals, we have a number of tools in our array for eliminating bottlenecks, and often this step is as simple as deciding which tools is right for the bottleneck. Automation is the primary tool and should be applied in all possible situations, but it is important to understand the cost, both upfront and long term support for the team automation. These teams must measure their own technical debt that is accumulated as systems become automated. Do not allow errors to creep into this type of system.

Another tools that is available is re-assignment of resources, specifically identifying a more appropriate team for ownership. For example, if a tool was intended for use by many groups within an organization but in reality was only ever implemented by one, that group should take the ownership back from a shared services team, as the “cost” savings of centralization equation is unbalanced when the shared service is not shared.

Finally, service elimination is a key part of reducing burnout and frustration across the organization. If teams are not effectively able to set EOL for products and services that no longer serve the organizations goals, then these services become a burden around the necks of teams that do not want to support them. This is a critical factor in organizational stability, as good engineers placed in untenable situations of a product lifespan will often quickly find another place to share their talents. It can then be difficult and very costly to find people to support this legacy technology. It is critical for each shared service team to have the power to identify and measure when shared services are no longer living up to their value proposition and eliminate them from their support catalog. If this power is not granted, the eternal project slog will continue and good engineers (and good people) will filter out of the organization. With these good people goes knowledge and care for the system as short-term mercenaries are often then required to maintain so-called “critical” pieces of business functionality.

In conclusion, good understanding of organizational priorities allows shared services groups to focus on eliminating large bottlenecks within their own process, thus allowing these teams to more effectively serve the larger organizations needs. Without this alignment, teams are weighed down by the responsibility and mistrust of many across the organization and are never able to dig out of the mountain they find themselves under. On the other hand, doing the right thing for shared service teams will reduce burnout and keep good people within the organization.