The Value Guides: Is Your Technology Project Profitable?

Published in

Technogise

5 min readFeb 1, 2021

The state of technology project management has been changing. A few years ago, it was common to see high failure rates across software development projects. Recent updates on that data show an optimistic picture. As per 2018 data published by PMI, close to 60% of technology projects were developed and implemented within their designated budget.

While this might be a considerable improvement if one considers historical performance as the benchmark for comparison, it still means that over 40% of technology projects are running over their designated budget.

Adhering to the budget should not be the goal of a software development project. The focus should be on creating value. However, going over the budget might be a sign of value erosion. This means that there has to be a more reliable way to determine value creation. A common metric used for such evaluation is the profitability of the project.

Profitability is a simple concept to understand: Sales minus cost of goods sold gives you your gross margins. But, are gross margins a healthy metric to suggest value creation? Certainly not. There are other expenses like salaries and admin, depreciation and amortisation, taxes, capital structure costs, and so on. You would not want to get buried in drawing out income statements and cash flow statements for each project and update them with each attained benchmark.

Hence, here are a few ways you can measure the profitability of your technology project. You can use this to:

a. Course-correct and cost control.

b. Reinvest in the project.

c. Scale the project or shut it down.

1. Net Present Value of Future Cashflows.

Net Present Value (NPV) is used as the decisive metric in several financial calculations. Whenever the question of incoming or outgoing cash flows over multiple periods arises, NPV is used as a reliable metric. The basic formula for NPV dictates you to have your expected cashflows over all the years of operating the project, life of your technology, and the cost of capital applicable to your company.

Here is a quick reference to calculate the NPV.

This may seem a little too tilted towards quantifying the project, but it shows an accurate picture of what you expect from the project over the years. NPV calculations are largely probabilistic, but they make you pay attention to the cashflows of the project. While these cashflows will change, having this number available at the beginning of the project will give you a more pragmatic limit of spending, instead of the budget. Your project costs should not overrun this NPV of the product you are developing.

2. Cost of Internal Development.

If you already have an internal team of developers, engineers, and product owners, you would have already made this calculation. However, if you are starting a new operation, you should still consider making this calculation.

Begin with the cost of having a team. You will have to hire a recruiter, pay the new signees some form of signing bonus, paying the legal fees for drawing the employment contracts, providing the tools necessary for working, and even the office space. Then, you would have to pay them salaries for the duration of the project. You can use average market data to get to this figure. (You will continue paying them salaries beyond the project’s implementation as well; hopefully, you would have another project in your pipeline to allocate their skills.) When you add all of this together, it gives your projected cost of internal development.

If you are working with a technology partner, you should keep this cost handy. While your technology partner or vendor will have efficiency attained with years of experience and economies of scale, there are still chances that at some point the project will get so out of schedule, that hiring a new team from scratch and developing the project internally would become more affordable than operating the partnership. Make sure that point acts as one of your cost thresholds throughout the project.

3. Person-Hours Saved.

Another angle of evaluating the profitability of the project is by looking at the person-hours saved. This can be used on two levels:

a. The person-hours you saved by hiring an external team to focus on the project so your internal team can focus on other areas. The benefits of these other areas would be added to the value of the project you are developing. In an ideal case scenario, the value of both these areas and the project would be far greater than the cost of hiring your technology partner to develop the project.

b. If you are implementing an enterprise product for internal use, you can compare the pre-implementation and post-implementation processes to get a fair idea about the value created by the product. Make sure you include the cost of maintaining and updating the system over the coming years if you are annualizing and adding the person-hours for multiple years.

4. Opportunity Cost.

Every single person from your team who is associated with the project should keep track of all the person-hours she/he has put into the project. Now, you can use these person-hours as your starting point for getting opportunity cost:

What are the other things they could have worked on? If there were other projects that they could not take because of their engagement on this one, the forecasted value of that project would be the benchmark against the forecasted value of this project. The moment this project’s value decreases than the one not pursued, it becomes an unprofitable project.

Make sure you include all the person-hours you have put into the project. This will serve as the cost of having missed out on all the strategic initiatives you could have focused on otherwise.

5. Impact of Schedule Overruns.

Unlike the other metrics given here, schedule overruns do not show prospective value creation. Instead, they highlight the extent of value erosion due to a particular hiccup in the schedule. Overruns are quite common in technology projects. However, each overrun means — more management person-hours to be invested in the project, later delivery to the customers, continued use of inefficient processes that the product being developed was supposed to replace, and the marginal cost of having the external team on-board.

Schedule overruns can often help you create more value if the feature being added or the work being produced as an output of the overrun exceeds the cost of the overrun.

In Conclusion

There is no definite framework for you to follow. Your finance and accounting team will help you with many of these calculations. However, using each one of these metrics will give you an incisive look into how the project is evolving. Instead of looking at an ideal steady-state scenario which magically creates value at the point of implementation, you would have concrete data to support your decision-making. Most of the results you get by using these metrics should be the inputs in your decision-making and not a proxy for decision-making. For instance, opportunity cost as a standalone metric should not be used to shut down a project or fire your technology partner. Instead, use it with another metric to get a complete picture.

References: