Planview Blog

Your path to business agility

Work Management for Teams

5 Ways to Find Slack Time for Critical IT Improvements

Published By Mattias Skarin

As an IT department, you receive so many requests that you often have to put your own long-term improvements on the back burner. When you finally come up for air, you realize that your tech platform left the “patchable” state a long time ago — and now it’s burning.

You need slack time to make critical long-term improvements — before your staff loses faith and leaves. This is easier said than done, since finding slack time (without working longer hours) often requires making tricky trade-off decisions. Here are five areas where you can carve out the time you need.

1. Simplify Estimates

We often waste time making estimates that are far more granular than is necessary for our process. Making the shift from detailed to more coarse-grained estimates, like from story points to bucket sizes (i.e., S, M, L), can save us valuable time and energy — which we can use to make critical improvements.

For example, if you need to decide which features to prioritize, and (a) you don’t need to estimate every story behind the feature to get an idea of its size, and (b) you’re making a trade-off decision across a small set of features, then ask yourself: What is the simplest way to determine prioritization?

One estimation technique that frees up some much-needed time is to consider the effort required to develop a feature that doesn’t vary much (no more than 2-3x the effort), while the market value across the same features varies a lot more (anywhere from 10-100x the market value).The rationale for this approximation is, of course, to make a bet for long-term improvements.

2. Reduce Time Spent on Future Analysis

Your senior team is often asked to make recommendations for stories and projects planned for months in the future. As a rule of thumb, you have a good argument to stop spending time on detailed analysis and design for projects planned for six months or more from now. Even if the projects will actually materialize, the analysis and design decisions will most likely need to be revisited when development starts anyway.

The trade-off recommendation: It’s better for your senior team to invest time in training and knowledge sharing, rather than in analyzing and designing things that may never materialize.

If in doubt, ask yourself what decision will be driven by your analysis. If the answer is “to get a budget,” give your team a simpler way to drive that decision — that doesn’t involve pulling your senior people.

One way to simplify the budgeting process is to increase decision speed. If you’re currently forecasting for the year, try switching to quarterly forecasting. This is what Beyond Budgeting teaches us, and it’s something I recommend for all Agile companies.

The second approach to reducing time spent on future analysis is to decouple content from actual funding. Think of costs as the size of your pipeline, and content as what flows through it. Costs are fairly stable since they depend on a few factors (headcount, facilities, and licenses), so it is easy to estimate the change over time. By examining this change, you can determine the your budget. Content can be determined when the work reaches IT — you don’t need to estimate content to find your budget.

3. Shift Analysis to Business Units

Many feature ideas are built on products and services that we or our competitors already have.  Few are innovative, disruptive or add significant value to the customer. If your platform is burning and your resources are scarce, you have a good case for deferring the implementation of these features in order to make time for critical improvements.

Until you have a clear understanding of how a feature differentiates your product from a market perspective — or adds value from a user perspective — prioritize long-term IT improvements over building new features. Return the requests to the business units responsible for them and ask for clarification.

Please note, however, that if your product is highly IT intensive, then innovation will be, too. In this case, much of the needs analysis can still be pushed upstream, but much of the business case and solution design has to happen in close collaboration between business and IT.

4. Stop Support on Marginal Products

Every system has features and services that are used less frequently than others. If you can identify these features and services, you can make a case for stopping support for them altogether. The key is to make a fact-based analysis to identify which features you can justify not supporting. Focus your conversation on how making time for long-term improvements in your department can improve total revenue, even at the risk of losing marginal revenue.

5. Boycott Meetings With No Purpose or Agenda

Make a pact to not attend meetings without a clearly defined purpose or agenda. Tell your staff that until your platform is stable, attending meetings is voluntary, not mandatory. Instead, make a calendar booking every other week for a “tech debt hack day.”

Final Thoughts

Those are five tricks you can keep up your sleeve to help you carve out slack to make critical IT improvements. If you find yourself making habits out of them, this may a sign that you are missing something from your leadership.

You will find more examples of long-term factors that put teams in desperate situations in my new book, Real World Kanban.

Related Posts

Written by Mattias Skarin

Mattias Skarin coaches and trains management teams and value streams in Lean and Agile organizations how to build and sustain a competitive edge in a global, fast moving environment. He's the author of the book Real World Kanban and co-author of Kanban and Scrum, Making the Most of Both.