How To Keep Software Project Support Costs In Check

Too many businesses don’t think about support costs until after completing a software project. Here are four steps to take before that point.

As a longtime consultant and CTO, I have seen organizations, executives and project managers spend enormous amounts of time and energy managing the design and development of software solutions. Unfortunately, it is quite common for questions and planning related to post-deployment support to come up only when a project is nearing the end of development.

At that point of the project, budgets have already been spent and focus often turns to how to support the solution in a cost-effective way while peeling off non-essential technical resources. But the most effective things you can do to keep support costs down need to happen before then. Here are four.

1.      Invest Time and Effort in User-Acceptance Testing

Resist the temptation to rush into production. In good development models, user-acceptance testing (UAT) gets its due, with actual end users doing the testing—not the technical team. In UAT, end users will use the software application like it will be used in production, not necessarily as it was designed to be used. They will find things that developers might miss.

Good UAT cuts support costs because it finds and fixes errors before they go live. After go-live, the cost to address errors is significantly higher and requires more thought, care and time. Why? Those support costs are higher because updates to production systems have business and user consequences and thus take more steps and rigor to mitigate those risks. 

The next time that competing deliverables and deadlines tempt a project team to launch without thorough UAT, remember that the consequence of that earlier delivery may be much higher post-deployment support costs. 

2.      Keep a Developer to Support Users While Building

Sometimes you need the roof of the house over your head before you add the trim. Companies often choose the Minimally Viable Product (MVP) approach to unlock the bare minimum functionality they need. Then, they add enhancements during later phases of work.

If you choose the MVP approach, keep at least one of the original developers. In this scenario, he or she will handle support when it comes up and can continue to deliver enhancements as you move beyond MVP. By keeping a developer, you can save on onboarding costs as you evolve the product and have a real-time support model from the start.

3.      Consider Support When Choosing Your Software Development Partner

When you pick a development partner for your custom-software application, remember to ask about support plans. Support gets handled very differently across vendors. Some require a minimum upfront fee before they provide support, or they want you to commit to paying for a full-time resource. Other vendors will offer as-needed support, which is the cheapest model.

When choosing your project partner, make support options part of your selection process. Ask if they have support resources in-house. When vendors don’t have in-house support resources, they often fill the void with contractors. That’s great until the work dries up and the contractors disappear from the vendor’s control.

When you call for support later, new contractors will have to start from scratch. That has onboarding costs and makes it hard for that company to offer support down the road. Ask upfront so you won’t be surprised in the end.

There are software-development vendors that offer no-contract support plans, allowing clients to move through tiered support levels as their needs change. For example, at product release, they can choose the highest level of support. As the dust settles, they can switch to an as-needed plan. That plan won’t have the same turnaround, but it may be the right fit for clients who want to prioritize budget over response time.

4.      Hire an In-House Person to Run Point for Your Developers

Developers make big money. That makes their time expensive. To save money, it often makes sense to hire an in-house person to run point between your dev team and your end users. Why? Businesspeople often describe problems without providing the details that a development team needs to recreate the error. Your point person can dig out those details before your developers spend hours recreating the error. Instead, they can just focus on fixing it.

A point person can also filter the requests that arrive for your development team. From a cost-benefit perspective, it’s a lot more cost effective to funnel requests to someone who works one-on-one with your developers. They can then run point on their questions and save you money on your support costs. 

Support Keeps the Software Engine Humming

In project-management disciplines such as custom-app development, people often adopt an “eye on the prize” approach. And everyone assumes that the prize is go-live. But, after the dev team leaves, the app still has to deliver on its objectives. Support is the grease that keeps the engine of your software solution running, long after the dev team moves on to a new project, and the next after that. When you’re choosing your software-development partner, choose one who will stay with you for the long run and who will invest in the relationship with solid support. You’ve invested this much time, effort and money to get to deployment. Make the right choices now, and you’ll be happier on the other side.

Get the StrategicCIO360 Briefing

Sign up today to get weekly access to the latest issues affecting CIOs in every industry

MORE INSIGHTS

Strategy, Insights, Action

In our weekly newsletter, get insight into the biggest issues facing CIOs, along with strategic ideas, solutions, and interviews.

Strategy, Insights, Action

Once a week, get insight into the biggest issues facing CIOs, along with strategic ideas, solutions, and interviews.

Your information is secure – we don’t sell or rent your data to any third-parties.