Software in the House

Deciding on Software Projects

By Santi on July 10, 2019


Business and technology have long been intertwined: technology enables business to be more efficient and create new products and services, and business looks at the market and decides what needs to be built and how to sell it. Implementation cycles for technological waves in business can vary in speed; what was once a competitive advantage quickly turns into the industry standard, as it has happened with computerized systems (mainframes), the internet, websites, mobile apps, and now, in some industries, machine learning. When a new technology disrupts a market, the discussion shifts from “Will my company benefit from using technology X?” to “Can I afford to ignore technology X?”.

The world of software moves fast, and software development projects can be very risky, so having a framework to decide if they are a worthy investment matters. Let’s use the case of a website redesign project. The daughter of a small business owner tells him that the website’s fonts look pretty small on her cellphone, so he thinks that it might need some refreshing. He arranges a small meeting with all 15 of the company’s employees, with coffee and donuts on a side table (in Argentina, where I live, that would be mate and pastries), and he asks for their opinions on whether this project would be good for the company. They all agree that it is nice to have a better looking website, and that it is time already, but can’t be sure how this will bring new customers, or retain existing ones. On the costs side, they decide to build it themselves, because money is tight and developers, expensive. Since no one in the company ever built a website, they don’t know how much time this will take, so even though they know their hourly rate, they cannot really estimate how much money should be considered as being part of the project’s costs. On the third meeting about this subject, they finally agree that it is time to do the redesign, since the competitor’s site looks great and they might be falling behind, and everyone agrees that Jack will be in charge of the task, since he is the most tech-savvy team member (he will have to re-schedule some meetings he had with clients, though). During the course of the following month, he learns about responsive websites and a bit of search engine optimization (SEO). He finally has the new company’s landing page ready. It is certainly an improvement from the old one, but does not look as great as the competition’s, and it is uncertain whether it will generate some revenue, or if resources would have been better spent in other pursuits.

Bigger companies use more sophisticated approaches for decision-making, which may not yield better results. If too many people are involved, coming to an agreement about the project’s responsibilities and objectives can be a daunting task. Besides, non-technical management is sometimes responsible for technical decisions (such as deciding on software tools) which can make or break a software project.

On any professionalized company, management will expect forecasts and metrics to support business decisions. Discounted cash flow (DCF) analysis is a financial standard. It involves calculating the net present value (NPV), and ranking projects depending on this quantity. To do this, one would need to know when cash flows are coming in and out of the company given the project is carried out, but this is far from an easy task: a lot variability will exist when stakeholders estimate each of the items that add up to these numbers.

The effort on the decision on whether or not to start the project has to be in line with its complexity and relative cost. DCF might be an overkill for simpler projects, but having a project selection strategy increases the chances of making the right decision. During the budgeting, one should also consider different options which increase NPV or reduce risk. Back to the website revamping case, choosing this or that hosting company can reduce costs, but the cheaper options can be less reliable and more risky.

About the Calculation

When calculating NPV, ethereal things such as “brand image” are not part of the equation. It is true that these might provide tremendous business value, or be fundamental for the company’s mission (or day-to-day operations), but if that is the case, NPV won’t be the best method for evaluating the project.

Not everything can or should be quantified. Or, even if it can be measured, it is not always helpful to do it. Gilb’s Law comes to mind:

Anything you need to quantify can be measured in some way that is superior to not measuring it at all.

But some ways of measuring things are inferior to not measuring at all. One can get obsessed with an indicator and ignore other more important ones. The statistician George Box said it best:

Essentially, all models are wrong, but some are useful.

It is very easy to get lost in the details of calculating NPV and spending too much time in fruitless estimations. One thing that makes it hard to calculate the gains are second order effects (unseen gains coming from previous gains) and the new projects that this previous one has enabled. Returning to our new responsive website, not only does it look better, but now it ranks better on search engines, which prioritize mobile friendly sites. Also, as the number of visitors is now higher, it would make sense to start offering a subscription option, and doing some kind of email marketing. These effects and new possibilities are hard to see a priori.

The upside can be nice to think about, but it is up in the air, while the costs are much more certain. In the world of custom software, the biggest cost is usually man hours from programmers, quality analysts, functional analysts, product managers, project managers, etc. Even when “doing it yourself”, it is important to include the opportunity cost that these hours have. The difficulty in this estimation lies in the tendency to think of the software developer, a knowledge professional on a highly complex task, as a linear resource. As clear sign of non-linearity, Brook’s Law, from the book The Mythical Man-Month, states that...

adding human resources to a late software project makes it later

It is important not to fall for the sunk cost fallacy. These are costs that do not change as a result of the decision on executing the project or not. The hardware already bought is not part of the project’s costs, unless there is an option to sell it if the project is not carried out.

Finally, don’t forget to account for inflation, taxes, and transaction costs.


Software projects have an interesting risk profile, as presented in the article Why Your IT Project May Be Riskier Than You Think, from Harvard Business Review:

It’s not that they’re particularly prone to high cost overruns on average [...] It’s that an unusually large proportion of them incur massive overages—that is, there are a disproportionate number of black swans.

With that in mind, actions can be taken to reduce the chances of, and lessen the downside of, black swans:

1. Education

There is a wealth of information available online about the history of success and failure -especially failure-, of software projects. This material should contain non-technical information: management does not need to learn about the difference between SQL and NoSQL.

2. Technical Expertise

People who understand both the technical and the business side need to be involved in project analysis. It can be in the form of permanent employees or consultants.

3. Risk Analysis

Since software projects are specially risky, it is key to consider it in the analysis. There are several ways to quantify risk: sensitivity analysis, scenario analysis, simulation. At the very least, for big projects, the company must use scenario analysis to make sure it can survive a project with costs 400% higher and profits just a 25% of the initial calculation.

4. Project Separation

Breaking projects into smaller ones can help reduce risk, improve measurement, keep better tracking, and do proper staffing.

5. Diagnostic

Especially during legacy software decommissions, understanding the current technology is key for upgrading or replacing it. Business-savvy technical management plays a key role in this task.

6. Buy vs Build

Building usually yields more risk than buying, particularly if the company is not in the field of software construction. Tending to larger, well known providers is a good technique for risk mitigation, for example, using Microsoft Excel versus a custom made spreadsheet system. For any mission-critical service or product, such as infrastructure and notification systems, always request, negotiate, and make sure the provider complies with the service-level agreement (SLA).

For custom-made software, the options are building in-company and hiring an agency. When using an agency, check their track record and that they have a reputation for software quality. If in-company, use proven methods and technologies, trying always not to big the biggest fish in the pond: unless there is an excellent technical or economical reason, don’t be the largest user of the technology, as measured by expenditure, terabytes of storaged data, quantity of instances, etc..

In software, there is the famous principle: don’t reinvent the wheel. Choose best practices and use solutions which are widely adopted. If the company’s business is not cutting-edge software, better to leave that risky business to Silicon Valley startups. Big tech firms are not so innovative as one might think, because R&D requires a different organization and mindset, not often found in gigantic bureaucratic companies. This is why they buy smaller competitors for their technology, data, or people.

More than numbers

There are multiple criticisms to relying too much on financial analysis for making decisions about investments. One usual complaint is that it does not consider social aspects of decisions, such as the human cost of layoffs, or the value created on the community because of the benefits that the project will bring, for example: using less paper.

Another critique is that even if something does not make short or medium-term economic sense, it might make sense strategically. Opening a software developer position is more expensive than making a website on some online builder site, but it makes perfect sense if the company wants to keep improving and updating its digital presence.

At the end of the day, when all the numbers are neatly presented in charts and graphs, intuition still has its role; it can’t and shouldn’t be ignored. Experienced successful technical management can provide invaluable input on the decision. Now that the estimations on costs and profits are in paper, however, arguments will be based on much more than just gut and opinions.

So, the decision to start the project has been made, and for a few days everything is looking great, but then someone leaves the team, the integration with the provider was harder than it initially seemed, and the budget is going to be overrun. If enough of the assumptions previous to starting the project have been shown to be wrong, the project needs to be re-evaluated. The current project might not be the best option anymore.


Capital Budgeting | Investopedia
Why Your IT Project May Be Riskier Than You Think | HBR
Productivity Dynamics: Decision Criteria for New Technology Investment | MAPI Foundation

Further Reading

The Mythical Man-Month
How to Measure Anything

‹ Previous: Dark Mode Next: Selling Internal IT ›