At Firefield we always talk about building software that creates real, measurable benefits. However, unless we also address software development costs, we’re only telling half the story. In this post I’ll break down the obvious, as well as the not-so-obvious, expenses your company should consider when planning your next technology project.
Pure Software Development Costs
These pure costs are the simplest to calculate. If you project is contracted out, start by adding up the invoice amounts (actual or projected) from your vendors. If the project is developed in-house, the first item would be the hourly or salaried expense of all the technical staff involved. Then add the cost of any software packages or subscriptions required to perform the development work. If those software costs aren’t obvious, your technical team should be able to break them out for you. Although the math is very straightforward, be aware that early estimates for pure software development costs are frequently too low. As unforeseen events occur, they can drive up the time, effort and cost required to complete a project. You should always ask your team how the project plan has addressed “unanticipated circumstances”. Do it early, and keep tabs on the project’s progress against those estimates.
Additional Human Costs
When a tech project gets started, the team will extend beyond software developers. Depending on the software’s expected impact on the company, project teams can comprise resources up and down the org chart. There is a cost associated with the time and effort expended by each of these people, and that cost is frequently overlooked when calculating a project’s total expense. To accurately estimate this category, start by listing everyone involved: and this might include decision-makers who simply need to sign off. Anyone whose cost was already part of “pure software development” should be excluded. Then assess how much time each resource spends doing any of the following:
- Planning the project prior to its development
- Reviewing and approving project progress during development
- Managing the post-release evolution of the project
After launch, the nature of software development costs will change. For starters, this software will run on actual servers, and those machines must be configured to handle increases in usage. It costs money to rent, share or purchase this hardware, and those expenses are known as “infrastructure costs”. You should make sure your technical team provides you with projected infrastructure costs during the project’s planning phase.
The second ongoing project cost involves monitoring and maintenance. Once a product is offered up to its users, it can’t be left alone. Its underlying code may require periodic updates to address new security concerns or technological advances. And from time to time, features may stop working as expected.
While no one likes “bugs”, a project’s planners should reserve some time and effort to address the potential for them. As with infrastructure costs, ask your technical team to prepare early estimates for product maintenance expenses.
Lastly, remember that your users will have opinions (hopefully positive, but don’t count out complaints). You should have a plan in place for how to address them. Typically, a product’s stakeholders should set aside an ongoing budget for future product improvements.
It’s likely the case that your new software is going to replace or improve an existing tool or process. Unfortunately, when you move from an existing tool to a new product, the process is more complicated than flipping a switch. Your existing system likely contains some amount of data, and that info needs to be moved. You also likely have a collection of users (employees, customers, etc.) who have been trained to use your current tools. Assuming your replacement software isn’t a pure replica of its predecessor, those users are going to require more training.
Finally, when it comes to replacing an old system, it’s often impossible to shut off the old on a Sunday night and begin anew on a Monday morning. Based on the needs of a business, the old and new tools may need to run in parallel for some transition period. Keeping two systems in sync takes time, effort, and ultimately money.
Collectively, many costs associated with switching can be hard to foresee and even harder to estimate. That’s the primary reason why decision-makers often neglect these costs when planning. Since switching costs can be substantial for many products, stakeholders should make sure not to overlook them.
It’s possible, and maybe even likely, that the first 4 software development costs are obvious to you. They describe the building, configuring, launching, and maintaining of a product. This last cost, however, is more abstract. The opportunity cost of software equals the expenses associated with things the development of the product prevents you from doing in the future. I realize that sounds counterintuitive – so much so that I’m planning a future post to address the topic in detail (check back soon). But for now, consider the following questions:
- Is your post-launch budget too small to address innovative suggestions from team members or customers?
- Have you developed the product using tools so specialized that only uniquely skilled humans can build and maintain them?
- Did you employ any “cutting edge” technical elements that could run the risk of becoming obsolete within a few years?
If you answer “yes” (or even “maybe”) to any of these questions, there’s a very good chance that your project development choices may put future opportunities out of reasonable reach. That is, of course, unless you’ve spent time accounting for all five of the software development costs that matter.