Effective Definition of Operational Costs to Justify Development

Everyone has those parts of their job while working in an operational or Tier 2 / 3 job they wish would be automated or solved as its often repetitive and tedious. Feel like you are being ignored when you complain about an issue? Ever wonder what would it take to get development to solve it?

It is time to visualize the impact and cost of these manual operations to make data driven decisions about what is best for reducing costs in the organization.

Discover Repetitive Tasks

---

Use the data you have. Most of the data you need to gather is sitting around being unused. Depending on how your work is logged and customer tickets are structured this could be difficult or easy. Is all work tracked in a ticketing system? Or does it live in documents and spreadsheets?

Look for patterns in your existing logged data / tickets.

• Use a word cloud to discern common words in work peple have done. Analyze tickets entered in the last week, month, quarter or even year to see what words come out largest.

• If your business has key words or phrases which are not part of normal words, search for trends with those and how often they occur.

• 
  

Do a poll of Tiers 2 and 3 to see what they view to be the most common issues. The people on the ground each day have a different view of how things work. Things to interview them about:

• What are your biggest pain points?

• Which things do you need to do each day?

• How do you track this work?

• What are the common issues you see?

Create a culture of looking for new repetitive tasks. Instill a mindset in the team of looking for patterns of common issues, and starting to track them. Make sure to capture how often and how long each of these tasks takes to use in forecasting. Have the team understand the more they log and document these kinds of tasks, the faster they can be automated. The hope of a resolution should drive them to be proactive in this process.

---

Define Improvement Areas

With your list of issues, it is time to categorize them and start collecting data in a more rigorous fashion. Some options to try in a bug / ticket tracker:

• Create a ticket type on your bug tracker or service desk for these specific manual tasks which are done each day. This will make reporting on these types of issues much easier in the future.

• Link each new ticket instance of this repetitive task to the improvement / automation or development ticket to solve this issue.

• Label each ticket or instance of a repetitive task with a specific label you can group and report on.

• For tasks always run on a specific day or time, log the repetition so you can forecast out the amount of time this will take. This also eliminate the need for the team to be logging these each instance.

If you have a history of old tickets which already have these issues, its time to now link / modify / add metadata to these tickets so you can build a historical record of these repeating issues.

---

Report on this Data

This is the fun part where it all comes together. So far we have groupings of common tasks defined and all of the related times these have been worked. Hopefully your bug / issue tracker has a decent reporting tool. It will need to do some math. If not, you can always export and use a spreadsheet tool to do the same thing.

Its time to estimate and then calculate these data points. Notice how they build on each other:

• Count the amount of time per ad-hoc task. For each recurring issue which occurs on an irregular basis, count the number of times this has happened. You might want to break this down into timeframes as well, such as: starting from the beginning, to the last quarter / month / week. Depending on how often the issues occur, lower recurring issues might necessitate longer reporting timeframes whereas regularly occurring issues you can report on impact in the last week.

• Estimate the size of scheduled daily manual tasks. Figure out when this issue started, multiply that by the number of days its been performed times the number of minutes per instance. This will give you an estimate of the cost to date of this issue so far.

Add it all together to find out where you stand. Now you can get some numbers out of what we are doing here. The math gets pretty simple:

• Human cost: take the count of instances times the number of minutes per instance. Divide that by 60 and that will give you the cost in hours. You can also take this further: multiply by the average cost to the company per employee per hour.

• Financial impact: similarly if each instance of this repetitive task has an actual financial cost besides human labor, multiply that by the number of instances.

Add these two factors together and see what this all tells you. You might find some of your repetitive tasks to be quite costly. Use the most expensive ones to justify to development why these should get done. Work with product to understand the future revenue of new features to weigh the costs and benefits of both.

Forecast

---

Use historical data to see trends in the past predicting future costs. Now that you have costing information, lets predict how these might escalate into the future if not addressed. Use the information you have to break out the average cost by week or month given the number of instances. You can now forecast what the future costs of this issue will be. Use this to align with development priorities on when things should be fixed.

As an example if you are being told the fix can happen in 2 quarters, make sure those making the priority decisions know what the cost of this issue will be over those 2 quarters while not addressed.

Leverage this new data to ensure the new product pipeline aligns with current operational costs to maximize cost / benefit to the company.