For those of you that do not know, Alaska is kind of like the 3rd world of the United States in that we have semi-exploitative love/hate economic relationship with a single industry . . . petroleum. Why does this matter? It matters because two years ago oil was $120 a barrel and now it is floating between $40 and $50. For those of us in public service or who are private industry support services that contract with government and municipal agencies it means that our budget just shrank by 60%. The Legislature is currently struggling with balancing a budget that runs an annual 3.5 to 4 billion dollar deficit, a pretty difficult task if your only revenue stream is oil.
Regardless of where you work and who you work for in Alaska, this means “the times, they are a changin'”. As budgets shrink, so do resources: staff, time, support services, training opportunities, travel, equipment refreshes and so on. Belts tighten but we still have to eat. One way to make the food go further is to consolidate. In IT, especially these days of Everything-as-a-Service, there is more and more momentum in the business to go to centralized, standardized and consolidated service delivery (ITIL buzzword detected! +5 points).
In the last few years, I have been involved in a few of these type of projects. I am here to share a couple of observations.
Above you should find a fairly straight forward management-esque graph with made-up numbers and metrics. Workload is how much stuff you actually have to get done. This is deceptive because Workload can break down in many different types of work: projects, break/fix, work that requires immediate action, and work that can be scheduled. But for the sake of this general 40,000ft view, it can just be deemed work that you and your team do.
Operational Capacity is simply you and your team’s ability to actually do that work. Again, this is deceptive because depending on your team’s skills, personalities, culture, organizational support, and morale, their Operational Capacity can look different even if the total amount of work they do in given time stays constant. But whatever, management-esque talk can be vague.
Consolidation projects can be all over the map as well: combining disparate systems that have the same business function, eliminating duplicate systems and/or services, centralization of services or even something as disruptive as combining business units and teams. Consolidation projects generally require standardization as a prerequisite; how else would you consolidate? The technical piece here is generally the smallest, People, Process, Technology, right?
And from that technical standpoint, especially one from a team somewhere along that Workload vs. Operational Capacity timeline, consolidation and standardization look very, very different.
Standardization has no appreciable long-term Workload increase or reduction. There is an Increased capture of business value for existing work performed. If there is wider use of the same Process and Technology the given business value of a unit of work goes further, for example if it takes 10 hours to patch 200 workstations it may only take 10.2 hours to patch 2000 workstations.
Consolidation brings a long-term Workload increase with a corresponding increase of Operational Capacity due to addition of new resources or re-allocation of existing resources (that’s the dotted orange line on the graph). For example, if there is wide spread adoption of the same Process and Technology, you can take the 10 hours my team spends on patching workstations and combine it with the 10 hours another team spends on patching workstations. You just bought yourself some Operational Capacity in the terms of having twice as many people deal with the patching or maybe it turns out that it only takes 10 hours to patch both team’s workstations and you freed up 10 hours worth of labor that can go to something else. There is still more work than before but that increased Workload is more than offset by increased Operational Capacity.
Both standardization and consolidation projects increase the short-term Workload while the project is on-going (see Spring of ’15 in the graph). They are often triggered by external events like mergers, management decisions, or simply proactive planning in a time of shrinking budgets. In this example, it is a reduction of staff. This obviously reduces the team’s Operational Capacity. The ability to remain proactive at both the strategic and tactical level is reduced. In fact, we are just barely able to get work done. BUT we have (or had) enough surplus capacity to continue to remain proactive even while taking on more projects, hopefully projects that will either reduce our Workload or increase our Operational Capacity or both because things are thin right now.
Boom! Things get worse. Workload increases a few months later. Maybe another position was cut, maybe a new project or requirement from on-high that was unanticipated came down to your team. Now you are in, wait for it… THE DANGER ZONE! You cannot get all the work done inside of the required time frame with what you have. This is a bad, bad, bad place to be for too long. You have to put projects on hold, put maintenance on hold or let the ticket queues grow. Your team works harder, longer and burns out. A steady hand, a calm demeanor and a bit of healthy irreverence are really important here. Your team needs to pick your projects very, very carefully since you are no longer in a position to complete them all. The one’s you do complete damn well better either lower Workload significantly, increase your Operational Capacity or hopefully do both. Mistakes here, cost a lot more than they did a year ago.
The problem here is technical staff does not generally prioritize their projects. Their business leaders do. And in times where budgets are evaporating, priorities seems to settle around a single thing: cost savings. This makes obvious sense but the danger is that there is no reason that the project with the most significant cost savings will also happen to be the project that will help your team decrease their Workload and/or increase their Operational Capacity. I am not saying it won’t happen just that there is no guarantee that it will. So your team is falling apart, you just completed a project that saves the whole business rap star dollars worth of money and you have not done anything to move your team out of THE DANGER ZONE.
In summation, projects that increase your Operational Capacity and/or reduce your Workload have significant long-term savings in terms more efficient allocation of resources but the projects that will get priority will be those that have immediate short-term savings in terms of dollars and cents.
Then a critical team member finds better work. Then it’s over. No more projects with cost savings, no more projects at all. All that maintenance that was put off, all the business leaders that tolerated the “temporary” increase in response time for ticket resolution, all the “I really should verify our backups via simulated recovery” kind of tasks – all those salmon come home to spawn. Your team is in full blown reactive mode. They spend all their time putting out fires. You are just surviving.
Moral of the story? If you go to THE DANGER ZONE, don’t stay to long and make sure you have a plan to get your team out.