Understanding the true cost of a technology initiative can help you determine when (or whether) you should take on a new system initiative, usually in combination with some sense of the potential benefits to be realized from the implementation.  We’ll discuss different ways to evaluate the Return from a project in a future post.

Cost constraints are often one of the first things that people think of when talking about technology, in large part because technology investments generally involve purchasing or building something tangible, such as servers, laptops, or software to install.

While the outright cost to purchase technology is usually pretty apparent, it’s not the whole story, as it doesn’t take into account the the hidden costs of maintenance and support and the less-tangible costs of training, user adoption and efficiency.  Adding these costs in is the concept of Total Cost of Ownership or TCO.  This concept applies as well to the implementation of new systems as it does the acquisition of hardware.

When evaluating the Total Cost of Ownership, there are three main elements to take into account:  Acquisition cost, Implementation cost and Support/Maintenance cost.

Acquisition Cost

Typically, this category will include the outright purchase of hardware and software and is usually accounted for as a capital expense in the organization’s budget and can be depreciated over time.  Acquisition through in-kind donations or grants should also be accounted for in this category, with the value of the donation being the key driver.  There may also be a labor component that should be accounted for in determining the total acquisition cost, represented by the time required to evaluate different vendors or platforms or, in the case of in-kind donations, in the solicitation and proposal writing process.  Because technology requests often require specialized knowledge that grant-writing teams don’t possess, members of the technology team or outside consultants may be needed as integral members of the process, with an opportunity cost or outright consulting cost involved.

Additionally, acquisition cost may include the necessary pre-conditions to enable the new technology to function properly, such as new hardware to support a new software platform or the purchase of upgrades to existing hardware and software.  In effect, any one-time purchase would be counted towards the acquisition cost of the technology.

Implementation Cost

Once hardware or software has been acquired, it has to be set up, made operable according to its intended use, and deployed to the intended users.  Costs in this category generally consist of the installation of hardware, software and network connectivity (e.g. increased use of web-based platforms might required a faster, more robust internet connection, which, depending on the organization’s office situation, could require installation costs on the part of the broadband vendor – or even a change in vendor), as well as the time cost of configuring and deploying the system.  

Additionally, it’s also important to include the cost of training users on the new technology and have some sense for the impact of the change to productivity and efficiency.  In almost every case in our experience, implementation of a new system causes a short-term dip in efficiency as users get used to working in the new environment (understanding that this dip is going to happen and planning how to help users transition through it is an important part of the Change Management process of a project).

Depending on accounting interpretations much of the Implementation cost may be treated as a capital expense, and it is often the largest visible cost of a project, particularly when using external consultants to do the implementation.  As with Acquisition Costs, these are generally one-time expenses, although they may fall within multiple budget years depending on project timing.  Training and Adoption support, alas, don’t usually qualify.

Maintenance/Support Cost

Although often not highly visible in planning for initiatives, the ongoing cost of keeping the new system up and running in the long run, as well as in deploying new or additional functionality and (depending on the scenario) in scaling it to additional users.  These costs include warranties, support contracts with external vendors, ongoing license costs and (occasionally) upgrade costs.  The technology plan must be able to forecast these recurring costs based not just on current numbers, but also on the organization’s planned future state.  For example, if a customer portal costs $1 per user per year with 5000 current users, but the organization plans to scale it to 100,000 users in five years, the cost will also scale, which can provide an unwelcome surprise from a budgeting perspective unless it’s been planned for from the outset.

Additionally, future planning  costs must take into account the staff resources necessary meet the organization’s needs.  This could include support or administrative staff for the technology, general technology support to keep up with the organization’s growth and management capacity to keep up with the organization’s strategic planning.  This capacity may be maintained in-house or provided by external partners, but the cost implications of both models should be evaluated as part of the planning process.

Without proper planning or budgeting (including future staffing/support costs) to support the overall set of initiatives, an organization may be building an architecture that is they can’t afford to support at the scale they desire.  As much work as possible should be done to isolate known and projectable costs and build them into the overall organizational plan so that you know what you need to fund and when.  Ideally, your investments will begin to give you economies of scale or other savings over time.

TCO can also be used to evaluate different alternatives – for example, when evaluating taking in-kind donations of hardware as compared to buying new and is a valuable concept to apply whether evaluating a single system implementation or building a long-term strategic plan.

This post originally appeared on the Cloud for Good Blog.

Will Nourse is Director of Cloud Solutions at Cloud for Good where he focuses on defining solution architectures and technology strategy for clients.