alotofpeople - stock.adobe.com
How to make a strong business case for software projects
Every software project proposal requires in-depth research into the technical aspects at play, but the business case for the project should tone down the tech talk.
For any new software initiative, such as an architecture redesign or innovative application development project, a project proposal usually marks the first step. However, no matter how comprehensive or detailed it is from a technical standpoint, a proposal that lacks buy-in from business-side management staff can end a project before it even gets a chance to begin. By mastering communication with the business side, architects, development leads and other senior software staff stand to get more of their top-priority projects approved.
The need for strong POCs
Typically, a software-based proof of concept (PoC) aims to acquire funding for initiatives considered important from a technical perspective, but might not reflect an obvious business need on the surface. For example, imagine a team wants to replace a legacy architecture that is still technically functional, but limits their ability to pursue new application design approaches or implement modern development tools.
While programmers can see the technical benefits of such an initiative, their arguments might not mean much to a product manager or other senior business-side managers. Through the POC, software teams must make a strong financial case for the project and demonstrate that the work will pay off enough for the company to justify the investment.
Finding meaningful metrics
To make a strong business case for software projects, a POC must include metrics that the reviewing business-side managers can sensibly translate into tangible, realistic and demonstrable ROI numbers. It's not always easy to know what metrics will matter to the business side. However, while not an exhaustive list, the following are a few examples of some typical POC metrics that software teams should try and translate into financial terms.
Reduced technical debt
While technical debt comes in many forms, Agile development pioneer Ward Cunningham provided one of the first definitions. He described technical debt as an operational byproduct that forms when teams implement features without regard to the actual subject's domain and fail to revise the software with information the programmers have learned. As technical debt builds up, those existing disconnects get worse and eventually prolong the time it takes to develop application components and features.
Software experts typically grasp the value of reducing technical debt, but it can still be hard to get projects aimed at reducing technical debt approved by the business side. To nontechnical staff, such a project might simply look like a rewrite of software that already works -- something that will take up a development team's time without delivering any new value for the company. As such, any POC aimed at reducing technical debt should offer hard numbers that demonstrate the specific financial or productivity benefits such a project will bring about.
Improved resilience
Software team leads can also make a strong business case for software projects aimed at improving the resilience of software or its supporting architecture. Rather than attempt to prevent errors from ever occurring in software, the concept of resilient software design compels developers to anticipate that failures will occur in live software and make upfront provisions that address those failures. For instance, imagine that a website requires users to log in to view certain pages, but a user attempts to view the page before logging in. Rather than simply displaying a vague 404 error, a more resilient approach would be to display a custom message informing the user that they need to log in.
From a business perspective, resilient software design can speed up failure recovery times and improve the user experience. As such, an architect can build a business case for projects aimed at improving resilience by demonstrating how it relates to things like decreased downtime, increased customer retention or higher volumes of sales.
Regression test costs
Regression tests can help development teams prevent feature additions or other updates from breaking a codebase, but those tests can take a lot of time and effort. However, development teams that delay or skip regression tests will eventually create uncertainty concerning the codebase's ability to handle updates. When regression tests must eventually occur, those testing cycles become longer and more arduous. This, in turn, makes the team want to perform fewer and fewer regression tests, and the problem perpetuates exponentially. Adding automation won't resolve the problem, either, as it takes time to write and maintain extensive, end-to-end automated test suites.
One way to solve this regression testing problem is to implement an architecture design that promotes a component- or feature-based codebase. This design will help ensure that updates in one area of an application won't affect the others. This also means that teams can test components and features independently, reducing the time and effort needed to perform updates and deploy bug fixes. To quantify the ROI for such an architecture project, estimate how much time the team can save on performing regression tests, how much faster software changes will roll out and how those improvements could translate into financial benefits for the company.
Measure productivity against complexity
Most Agile teams have some method of measuring the velocity of development cycles, such as calculating the number of features the team completes each week and assessing how much effort should reasonably go into each development initiative. Agile-specific methodologies like Scrum are, in theory, attempts to get more work done per week. However, the reality is that, over time, software components become increasingly coupled and less cohesive, the original domain model mapping becomes less reflective of the actual domain, and so on. In other words, while software teams might expect to move faster over time, they rarely do. This is why appraisals of developer productivity should always consider the relative complexity of the software systems they work with.
New development capabilities
Sometimes, the business case for a software project resides in its ability to imbue a team with entirely new ways of developing and deploying critical user-facing applications. For example, a software team might push for a low-code tool that allows developers to redesign existing web applications for mobile with reusable APIs. Not only will this help open up a new vector for user engagement, but it also means that the company can potentially save money by avoiding the need to hire specialized mobile application programmers. Avoid the temptation to advocate for projects like this solely on the technical benefits of things like API reusability; instead, make an effort to focus on those core business value considerations.
Tips for building business cases and POCs
Speaking to the business side of things in a project proposal takes a little bit of finesse. Thankfully, there are certain techniques and strategies tech-side staff can adopt to help shore up their ability to make strong business cases for software projects. Here are a few tips for architects, development leads and other senior technical staff to keep in mind:
- The more specific metrics in a POC are, the better. If a certain initiative can help an Agile team generate more user stories per week without the need to add additional team members, that translates into a tangible productivity benefit. Employee turnover rates and onboarding times are other metrics software team leads can use to measure the productivity benefits of a new initiative or development approach.
- There is an endless number of metrics software architects can try to quantify to make the business case for a particular project. However, three particularly useful metrics to highlight include ROI in relation to development productivity, the cost of pursuing an initiative versus the cost of doing nothing, and an "all-inclusive" ROI that calculates the cost of a software initiative against its projected financial benefit.
- When it comes to forming relations with the business side, software team leads should act as influencers and advisors. One way to do this is to initially create a generic project POC, and then allow lower-level technical staff to offer specific ideas and, ideally, take ownership over pieces of an implementation.
- If possible, build out the POC as an improved implementation of an existing application rather than a new, standalone application. By the time the POC is ready for a demo, the team will have already built a collection of features that they are ready to implement and demonstrate. This is one area where a strangler pattern implementation could come in handy.
- Soft skills matter. Meet with key staff members and business partners ahead of formal meetings to gather their ideas and feedback. Ask potential stakeholders what their concerns are about a project or initiative so you can find a way for the PoC to cater to these needs.
Matt Heusser is a managing director at Excelon Development, where he recruits, trains and conducts software testing and development. The initial lead organizer of the Great Lakes Software Excellence Conference and lead editor of "How to Reduce the Cost of Software Testing," Matt served a term on the board of directors for the Association for Software Testing.
