Continual Improvement: Proactive vs. Reactive Support and Maintenance

It’s time to build something new, but what does that look like in the long run? We’re going to think through how this plays out using Widget Co. as an example.


Revolutionize the industry, build something new

The team has come together to define the new widget sales process, we’ve thoroughly thought through the design, we’ve had the chance to improve on all of the pain points, removed all of the barriers that we’ve been working against and have all of the shiny new features identified. It will allow our sales team to sell widgets and sign deals from their phones on the road, marketing will run and monitor campaigns between PR engagements, and customers will have a new website, mobile app, and in-person kiosks to educate themselves and make purchases for home delivery. All of the interfaces will have up-to-date inventory, pricing, shipping and receiving information.

This will revolutionize our business and bring Widget Co to the forefront of the industry. Everyone involved is extremely excited to get this rolled out!

Months later…

The new widget ecosystem is launched! There are now a few ways to move forward with maintaining this new system.

  1. Maintain. Keep the framework updated, and do testing whenever the operating system is updated or a supported device is added.
  2. Continuous improvement. Regularly validate our workflow with our users, both internal and external. Continually test our software with every software update. Add and depreciate features as the users and process “tell” us it needs to evolve.
  3. It’s done! We’ve revolutionized the industry, now we can assume the software will work indefinitely without any further input or changes from us.

I’m sure we can agree that the last option sounds like a path to having something that is broken sooner than later, as the market and supporting technology evolve. When only considering immediate costs, option one might sound the most reasonable. The second option sounds ideal, but we’ve just spent a sizable amount of time, energy, and money on this widget, so facing this ongoing investment may at first seem daunting. Let’s take a closer look.

Option: Maintain

To have a nice round number to work with, let’s say that the total research, design and development cost of this software deployment is $100,000. In scenario number one we determine we can maintain the application for $300/month. That sounds great, and it is for a short time. Year two comes around and everything is going pretty well – no additional budget is allocated, and we’ll continue supporting the application with a small line-item in the budget. Everything is on autopilot, but as time goes on there are (quietly at first) issues coming up, but they don’t fit in the budget to fix or implement. Five years pass and the application starts to feel dated, and there is enough feedback coming in with feature requests and established workarounds that affect efficiency that we’re looking at a facelift or a rebuild. The rebuild cost comes out to another $100,000.

Option: Continuous Improvement

With option two we’re going to be spending $2000 per month on average. Some months will be lighter as we’re only doing analysis, but that analysis will lead to larger spends when we implement new features and improvements as they’re identified. The first year, there probably won’t be many changes, or we’ll discover new pain points that weren’t identified earlier because the prior challenges were so “loud” as to drown out these other issues. At year six we’re not looking at a rebuild – we’ll continue to make iterative improvements.

Compare the Costs

We’ll address the improved user experience next, but first let’s look at the cost in dollars. In the first case at 6 years, we’ve done two builds at $100,000 and we’ve maintained the application at $300 per month for 4 years, as an equation this looks like:

($100,000 x 2 builds) + ($300 x 12 months x 4 years) = $214,400

In the second scenario, we’ve spent $100,000 to build the software, and we’re averaging $2000 per month on continually improving the software and experience.

$100,000 + ($2000 x 12 months x 5 years) = $220,000

Over 6 years the cost is not that much different, but there is a major difference in when those dollars are spent along with a corresponding impact on all of the users. Using a continuous improvement model, the costs are spread out over the lifetime of the project, and users are given a constantly improving product, helping to achieve the company’s goals of more market share and widget sales.

Here’s what it looks like when we graph it out:

Comparing the User Experience

What we often see is around the five year mark with the “maintain” option is user satisfaction is low enough that it is obvious to everyone that something needs to be done, but plans to address the issue haven’t been made, so the application continues unchanged causing the user experience to continue to suffer. This negatively affects revenue and user perception. Because we haven’t been monitoring for the last five years, we’re only identifying today’s pain points and have lost the full context and ability to see all of the opportunities. Now we’re back to square one: doing stakeholder research, creating a new design, etc.

By contrast, when we proactively and consistently assess users and processes, we address pain points before they become overwhelming issues. Also, by budgeting for continuous improvements, we have the capacity to identify real opportunities both from the users’ and systems’ point of view, which helps Widget Co. maintain its industry leader status.


Planning

The key takeaway is when investing in a project with long term goals, a correspondingly long-term commitment is required in order to continuously meet the objectives. That needs to be accounted for with time, capacity, resources, and budget for the project to best meet and sustain its ambitions.