A Costing Model for Project-Based Information and Communication Technology Systems

By Brian Stewart and Dave Hrenewich

• A lack of accurate information on costs for information and communications technologies hampers effective decision making on ICT proposals.
• Having accurate cost information leads to improved allocation of institutional resources.
• Obtaining relevant costing data requires identifying the main cost drivers of ICT activities, determining system component costs, and using an appropriate methodology to ascertain the total cost of any ICT initiative.
• The costing model used by Athabasca University aims to provide the total costs of any system configuration, allowing more accurate estimates of resource requirements and returns on investment.

Resource allocation is a problem for all organizations, including educational institutions. Information and communications technologies (ICT) in particular fare poorly in this arena, with many institutions finding effective decision making severely hampered by a lack of accurate information on ICT costs. The lack of information beyond the direct purchase and licensing costs of a system has led to event costing — the process of evaluating an ICT service on its installation cost rather than on the total cost of ownership.¹ This approach makes resource budgeters wary of ICT proposals. IT departments have damaged their own reputations by providing overly optimistic estimates for ICT projects that then failed to deliver — or budgets along the lines of "take the first number estimated, double it, then double it again." In general, ICT has the reputation of offering a poor return on investment (ROI) and being a poor risk for ongoing budgetary commitment.

To reverse the generally negative reactions to proposed ICT projects, we need to provide decision makers with accurate and timely information on the cost of any given configuration. Then traditional asset allocation metrics can apply, and ICT will take an equal footing with its more mature competitors, such as facilities management, in competing for scarce resources.

The Problem

A major difficulty facing IT departments is ensuring that the projects and activities to which ICT resources are committed represent an effective, economic, and efficient use of those resources. This complex problem has no single answer. To determine effective use requires, at the least, a comprehensive review of the institution's organizational, strategic, and competitive position, coupled with a clear understanding of the core competencies of the internal ICT resources and a broad knowledge of external resource capabilities.

An essential first step for effective planning, budgeting, and funding of ICT resources is providing good cost information. Failure to have a strong grasp of ICT economics will, at best, result in a misallocation of resources supporting the activities of the institution. At worst, it may result in failing to serve stakeholders appropriately.

A reasoned decision on assigning resources between alternatives requires a good estimate of their costs. In addition, a business-case ROI analysis requires valid and repeatable projections. Without these, the decision space is indeterminate and involves non-economic arguments.

In this article we seek to unravel a key aspect of this complex puzzle: how to determine the cost of ICT resource use in order to provide the information necessary to make an effective decision. Knowing how much it will cost to undertake an initiative, either in dollars or in foregone opportunity, makes it possible to ascertain the supply cost of any initiative, compare choices, and use traditional financial metrics in making a go/no-go decision.

We created a model that calculates the economic cost of an ICT system. It does this by identifying the building blocks or components of a system and determining the cost of such components. Specifically, we address the following questions:

• What are the main cost drivers of ICT activities?
• What does an ICT system cost?
• What does an ICT project cost?
• How can an institution estimate the costs of any given ICT configuration?

The Approach

ICT is a critical infrastructure for Athabasca University (AU) as an online university with a distributed workforce. ICT services are vital to the daily operation of the institution. AU's ICT services, or AUIT, are delivered on a federated basis with central services supported by local centers delivering specialized services. Overall, approximately 75 percent of all ICT expenditures, including all core services, are provided by the Computing Services (CS) department. Because ICT is so important, efficient management tools are essential to ensuring that services are provided economically and effectively. With regard to cost management, the CS department adapted an activity-based absorbed costing methodology² to develop an ICT cost model. Secondarily, we used the cost model to determine individual systems' costs, taking a total cost of ownership approach. Our approach differs from MIT's 2006 model³ in that we focus mainly on determining the activities that drive costs in addition to identifying and accounting for the value of the cost components, allowing the model to be used for predictive and not just recording purposes. A further difference in our model is the inclusion of indirect costs, albeit with some subjectivity in determining them, which yields a more complete accounting of the total cost of ownership.

Limiting the calculation to direct costs ignores two significant cost drivers:

• the overhead burden of operating a significant cost center, and
• the variable costs of ICT activities.

These omissions lead to the view of ICT costs as having no separate fixed and variable cost components. However, variable costs — such as the cost of energy or licensing costs required to operate data centers — are variable and need to be considered as such, particularly when the growth of software as a service is an increasingly relevant option for ICT services. Providing a fixed/variable breakdown of costs makes scalability apparent and scenario planning more effective.

Our approach aligns with that undertaken by the University of Virginia in their Cost of Service Modeling (COSM) [http://www.itc.virginia.edu/virginia.edu/fall97/costs/costs_linkA.html], from which the following quotation was taken:

The system should focus on the management of activities (services) in such a way that contributes to the continued improvement of products and services provided to customers and to the continuous control and reduction of costs. It is crucial to identify all of the cost components associated with providing a given service or set of services. Direct costs which can be tracked directly to the activity or service, such as labor, materials used on the job, and equipment used in the process of performing the work are easily identified. Less obvious are those costs which are shared by a set of related services, such as hardware maintenance contracts for equipment used to provide multiple services. Overhead costs, such as utilities, general supplies and equipment, administrative and support staff and associated costs which cannot be directly charged or tracked to a specific activity or service, must also be apportioned across all service categories.

Our approach also uses cost data that can be aggregated to obtain an individual system's total costs rather than administrative unit costs, thereby allowing a systems perspective rather than an organizational one. This capability provides a basis for comparison with alternate technologies and a useful tool for evaluating economic performance and investment decisions such as outsourcing.

The AUIT model was developed in stages, each building on the previous one:

• Stage 1: Identify and classify all costs into cost elements.
• Stage 2: Identify the cost drivers — those activities that cause costs to move.
• Stage 3: Attribute the cost elements to the cost drivers to create a set of hourly activity cost rates.
• Stage 4: Aggregate the output of the previous three stages to determine total system and system subcomponent costs.

Stage 1: Identification and Classification of Cost Elements

The first stage identifies all the cost elements of ICT activities, whether direct or indirect. Direct costs are defined as those costs that relate directly to the activity being undertaken. Indirect or overhead costs are defined as those costs related to an activity but either too complex or too expensive to derive in a direct-cost calculation.⁴ Schedule 1 (Table 1 in the Costict Model) shows samples of these costs for the CS department and their categorization into direct and indirect costs.

Schedule 1. Cost Criteria Factors — Direct and Indirect Costs for Computing Services

Type of Cost	Description/Example
Direct Costs
Salary	Salaries of CS employees
Workstation	Cost of CS employee's work technology
Benefit percentage	Benefits as a percentage of CS employee's salary
Energy costs	Electricity costs to operate data center
Computing Services square feet	Includes all space allocated to CS activities
Indirect Costs
Office of the CIO assessment	Spread evenly across all AU staff; supports CS functions
Overhead assessment	Makes up approximately 5% of Finance, Human Resources operating budget
Supervisor's assessment	Percentage of CS supervisor's cost spread across reporting staff
Manager assessment	Cost of CS managers spread across CS employees
Administration assessment	Cost of CS phones, printing, copying, travel and training, books, etc.

Stage 2: Identification of Cost Drivers

Identification of the activities driving cost is critical to a costing system because not having that understanding severely restricts any practical use of the model. The appropriate level of granularity required for identifying the cost drivers is specific to each institution, and to the expected use of the model. As a matter of practicality, we were guided by the size of the driver's impact on the total cost of ICT activities. Thus we aggregated smaller cost drivers into larger ones to facilitate efficient data gathering. The degree of granularity should be revisited on a periodic basis to make sure assumptions have not changed.

To identify cost drivers, we reviewed the activities undertaken by CS personnel and those normally undertaken in ICT projects. We reviewed literature related to ICT projects and held brainstorming sessions with CS personnel. Both sources of information converged on the following cost drivers:

• Employee activity hours
• Occupancy overhead (per square foot)
• Data center and network provision
• Hardware acquisition
• Application licenses

The last two items can often be costed directly to an application or system and might not have to be absorbed as an indirect cost. Network and data center costs will be absorbed or assigned to each system configuration (in stage 4) based on CS personnel's estimates of the costs based on their knowledge and past experience.

The occupancy overheads are not as easily tied to a particular system configuration and must be simplified for use with the model. Using the employee activity hours as the basic cost element and folding the occupancy costs into them yields a direct hourly cost rate that can be used to allocate indirect costs and produce the absorbed or activity-based hourly cost rates — the building blocks for system and project estimating.

The model as presented encompasses staff in two divisional units in two locations. The model could be enhanced to encompass more locations or units as the need arises without changing the formulas because they are driven by the values of location and divisional unit within the Costict Model.

Indirect Cost Allocation

Indirect cost allocation requires discretion and can appear more art than science. The impracticality of calculating all costs and their sources necessitates some assumptions regarding their grouping. To assess all indirect costs, we viewed the total university budget to ascertain the departments that provide services to CS.⁵ Given the structure of the institution's budget, these all appeared in Finance and Administration:

• Financial Services — purchasing, accounting, contracts
• Human Resources — payroll, hiring, benefits management
• Facilities — space, HVAC, cleaning

To simplify the calculation of CS's overhead or indirect cost burden, we grouped Finance and Human Resources into one group and left Facilities by itself.

In the case of Financial and Human Resources services, we used two methods to cross-reference:

• Total budgets of the institution and the portion attributable to ICT
• Total full-time employee (FTE) count of the institution and total FTE count attributable to ICT

The results from both methods were close at approximately five percent of total institutional budget related to CS activities. We took this as a measure of the Finance and Human Resources cost overhead allocated to the CS department.

Facilities required a more detailed analysis to determine the cost of providing physical working space, defined as serviced operational space including services such as HVAC, lighting, cleaning, furniture and fittings, and maintenance. In addition, the model needed to incorporate the power cost of operating ICT equipment, including the data centers and all employee workstations. A rent opportunity cost was also included in the serviced space costs, based on an approximation of the market rate for similar furnished space.

Once obtained, the cost of facilities, excluding energy costs, was allocated to the CS department's total space by dividing the total facilities cost by the total square feet occupied by CS. This yielded a total occupancy cost per square foot of $19 for the first location and $20 for the second location.

Summary of ICT Costs

Our analysis brought out the fact that the majority of direct cost for the CS department, with over 70 percent salaries, relates to people. Other elements of technology, in the form of hardware, software, network connectivity, and other licensing, is less than 30 percent of total CS expenditures.

The overhead analysis provided us with an approximation of the overhead costs that we needed to incorporate into our hourly charge rates to ensure we captured indirect costs. While such proportions are likely to change over time, they do provide a useful heuristic for ascertaining system costs.

Stage 3: Apportioning Costs to Cost Drivers

The absorbed costing model requires that all costs be absorbed into or assigned to the cost drivers. To achieve this, we needed to find a method to apportion costs to the cost drivers. The method we chose was to iteratively assign costs in a series of steps. The model creates Schedules 2 and 3 described below (Table 3 within the Costict Model) through the Microsoft Excel Pivot Table functionality.

Step 1: Determine Direct Hourly Cost Rate

Each employee's hourly cost rate was calculated from the following costs:

• Employee salary and benefits
• Employee cost of equipment
• Employee cost of space

The direct hourly cost rate of each employee is found in the Costict Model within "Table 2 – Staff Costing Profile."

Step 2: Attribute the Indirect Costs to Create Absorbed Costs

On the basis of the direct hourly cost rate from we apportioned the following costs:

• Overhead assessment
• Supervisor assessment
• Internal CS managerial assessment
• CS administration assessment

The values for these cost drivers are found in the Costict Model within "Table 1: Cost Criteria Factors." Step 2 yielded the absorbed hourly cost rate for each employee, again presented within Table 2 of the Costict Model.

Step 3: Determine Average Hourly Cost Rate by Functional Group

Step 3 was to place each employee within their functional group (job class) and functional area (departmental unit) and to use their direct and absorbed hourly cost rates:

• Assign employees to functional groups.
• Assign employees to functional areas.
• Use the Microsoft Excel Pivot Table functionality to obtain averages by functional group and functional area.

This step yields the average hourly cost rates of each functional group, as in Schedule 2, and of each functional area, as in Schedule 3.⁶

Schedule 2. Average Hourly Cost Rate by CS Functional Group

Functional Group	Average Direct Hourly Cost*	Average Absorbed Hourly Cost
Database Analyst	64.95	79.30
Help Desk Analyst	40.65	48.07
Intermediate Systems Administrator	54.72	65.58
Junior Systems Administrator	47.99	58.16
Microcomputer Support	55.30	63.35
Network/Telecomm Support	48.97	57.67
Programmer/Analyst	47.92	59.19
Project Manager	74.03	85.64
Senior Systems Administrator	72.60	84.37
Senior Systems Analyst	62.95	76.60
Systems Analyst/Programmer	58.34	69.96
Tester/Trainer	54.08	63.64
Unit Manager	80.96	86.81
Composite Average	58.57	68.26

* While all amounts approximate actual costs, they are used for explanatory and not comparative purposes.

Schedule 3. Average Hourly Cost Rate by CS Functional Area

Unit	Average Direct Hourly Cost	Average Absorbed Hourly Cost
Administrative Systems	60.55	71.12
Administrative Web Services	64.21	76.62
Database Services	70.04	83.03
Identity & Access Management	81.54	92.08
Information Technology Systems (ITS)	79.76	85.98
ITS Help Desk	40.65	48.07
ITS PC Support	55.04	63.12
ITSIM Client & Operational Services	64.25	73.89
ITSIM Telecom & Networking	52.71	60.90
Learning & Research Web Services	57.10	67.94
Project Management Office	58.33	66.78
Composite Average	58.42	68.13

Schedules 2 and 3 contain average absorbed hourly cost rates; these will be used as the cost elements in determining ICT systems and project costs. By absorbing all the costs into these cost elements, we have enabled estimates and projections based on them to be both accurate and relatively simple to use. The end user of the absorbed rates does not have to be concerned with their derivation and can employ them as necessary to cost any given ICT system.

Model Maintenance

To further ensure ease of use, we constructed the model in a manner that would facilitate updating information on an ongoing basis. To do this we used a series of spreadsheets that were linked by the model's constructs. The use of Schedule 1 (Table 1 in Costict), Cost Criteria Factors, allows for entry of all the primary data and simplifies the model's updating on an as-needed basis. Therefore, as organizational changes such as new space or increased energy rates occur, the table is easily updated to reflect the changes. The staff table is also updated to reflect changes in employees' positions, salaries, and benefits. This keeps the hourly cost rates current.

Should a significant change occur in the CS department's operation, a new cost element can be added to the Cost Criteria Factors table. The new cost will then need to be attributed on the same iterative basis as the initial calculation to derive the updated cost rates.

Stage 4: Determining System Cost Estimates

A system may be a single application on a server within a networked data center, viewed from a remote terminal. Or, a system might consist of a main application supported by a set of subsystems. To illustrate the nature of a system calculation, we have chosen a student information system (SIS), of which the architecture might look as shown in Schedule 4.

Schedule 4. Sample SIS Architecture and Its Components

Major System	System Component
SIS application	Banner/PeopleSoft
Personnel	System administrators
Support Systems	Â
Database Management System	Oracle database
Identify and access management	Firewalls
Authentication	Kerberos
User support	Help desk
User development	Training
Physical Infrastructure	Â
Hosting	Application servers
Hosting	Storage servers
Hosting	Data center
Access	Networks

To determine systems costs, therefore, the first step is to identify and categorize the major support and infrastructure components that reflect any given architecture. The main reason for this is to provide flexibility and ease of maintenance because systems' subcomponents often change.

Once the system's map is complete, the cost elements developed previously can be inserted where appropriate. There is an aspect of discretion here, as the allocation of costs to infrastructure components might not be quantifiable on a simple mathematical basis; instead, they might require some judgment by the model creators. Nonetheless, errors are likely to be minor due to the categorization simplifying the allocation process by asking a straightforward question — such as how much support from the help desk does the SIS require?

Each of the system components identified above in Schedule 4 can be either a single component or a subsystem with elements that require further evaluation. The granularity is contextual and should be proportionate to the usage required. As a general rule, the granularity should be inversely proportional to the size of a given system. The larger the system, the finer the granularity. Thus in a complex ICT infrastructure serving a large user base with a student population of 30,000, the degree would be an order of magnitude higher than for a smaller institution with a student body of less than 5,000. The model is therefore scalable and applicable at any level of operation.

Ascertaining a system's total cost of ownership requires analyzing its support requirements. For example, determining the cost of our SIS required identifying the system subcomponents, which will include technological and human resources, and evaluating their costs.

The more data that are available regarding employees' activities, the better will be the ability to assign resources to the various support activities. In the absence of hard data, brainstorming and anecdotal evidence provide a good first approximation.

The direct system costs of licenses and hardware purchases form the basis for the cost assessment. Added to these are the employee support hours multiplied by their absorbed hourly rates (per the formula identified above).

We can thus derive the total cost of our SIS as well as its individual subcomponents. The results provide useful information for comparing alternate systems, estimating value for money and benchmarking against other institutions, and evaluating system enhancements or modifications.

We now have a baseline to determine the cost/benefit ratio for projects to change or improve the SIS. Again, this does not preclude any activity with a potentially beneficial impact on the institution that is not directly financial. Rather, it simply relates the attendant resource cost to the activity's completion. Knowing what something costs provides critical knowledge for understanding the economic implications of a given action; it does not preempt or prohibit the action.

Using Costict to Derive a System's Cost

Estimating the cost of systems within the Costict Model is performed with the workbook tab labeled "Tables 4, 5, 6, 7 – Systems." The first section of that tab, "Table 4: System Costing Criteria," contains master data such as:

• A calculation of the typical/average annual hours of work for all CS employees. The actual details and differences in leave lengths and other benefits are found within the first tab of the workbook.
• As not all IT services are provided by CS, two parameters for average hourly wage costs for IT staff external to CS are provided. In AU's case, they refer to staff in our Finance/HR Administrative IT unit and to one particular academic area that has significant IT resources.
• The final two master data parameters are used to obtain an electricity/cooling cost for the university's server rooms. Because we do not have separate metering within the server rooms, this is obtained through reporting from the uninterruptible power supplies servicing them.

The second section of the tab, "Table 5: Information Technology System Infrastructure Costs," is used to determine an infrastructure cost that is allocated across all systems. This section can be as precisely detailed as the model user wishes. AU has chosen to use:

• Network costs
• Security costs

This section allows the use of either staff FTEs or annual hourly allocations. Again, the level of precision is left to the model user — you may link back to the actual costs of specific staff members who are responsible for the administration and maintenance of a system, or to average hourly costs for a job grouping (for example, Senior Systems Administrator). Determining which staff are allocated to each system and their amount of involvement is a significant exercise that should be revisited as changes to resource allocations dictate.

Components of the cost calculation include both mandatory and discretionary labor costs and external fees. We have defined mandatory staff costs as what might otherwise be classified as maintenance — keeping the systems running. Discretionary staff costs relate to project and enhancement tasks. The external fees value reflects items like maintenance fees. The Microsoft Excel comment feature in Costict provides additional detail as to what makes up the total external fee; it also describes how the mandatory and discretionary FTE numbers were derived from staff resource allocations.

The third section of this tab, "Table 6: Allocation of Database (DB) Costs," is used to determine the costs of running the university's database systems. A fixed component of costs is determined using the same components as described for the infrastructure costs like networking and security.

The rest of the database costing section uses one method for assigning costs of database support across systems. After discussion, we decided to apportion database costs based on the size of the data sets used by each system, specifically the size of the Oracle dump files. Other suggestions included the space allocated at the disk level, the number of users within each system, the amount of staff time used to maintain the systems, and so forth. You may choose whatever metric you feel most closely mirrors the effort and cost of providing database services. The cost values for database services obtained in this section are referred to and added to the costs for the corresponding systems in the final section of the Systems tab.

The final section of this tab, "Table 7: Information Systems Costs," lists many of the university's significant systems. The level of granularity (how many systems to report) is customizable. Obviously, the more systems reported, the more work involved in creating and maintaining the model. The columns and calculations in this final section reflect the same concepts introduced earlier in the Systems tab. The name of the system and the unit responsible for the system should be self-evident. Again, the mandatory staff FTEs and person hours are input from an assessment of resource allocation to these systems for their ongoing daily maintenance. External fees specific to each system may be entered. External fees and mandatory staff costs are subtotaled in an internal cost column. Adding any database costs derived from the calculation described above creates an annual operating cost for each system. The final costing component includes costs for enhancements and projects related to each system, which creates the final, total cost column. Again, the level of granularity and detail desired will drive the frequency and amount of review and maintenance of this section of the model.

Results and Lessons Learned

While development of the cost model was relatively straightforward, roadblocks and difficulties came up along the way. We also learned some basic lessons from using the model.

1. Cost data were not always available in the form required.

Obtaining the cost information appears easier than it was — budgets in most universities are not developed with the intention of developing cost models, after all. They focus on providing administrative units with the ability to plan, control, and manage resources. Activity costing is a lot messier, as the activities that drive cost do not fit neatly into the organization chart. To derive cost information for our model required both interpolation and extrapolation of organizational budget data.

For example, the cost of the CS department's power bill is not recorded separately. To derive that cost, we first developed a coefficient based on the average computer power usage coupled with the HVAC and UPS requirements of the data center to get an estimate of usage. From this estimate we established a percentage of the overall university's power bill as a simple ratio. Periodic reassessment will correct the ratio for future usage.

2. Precision and accuracy aren't identical.

While accuracy and precision can mean the same thing, for our purposes accuracy is defined as a measure of the truthfulness or factual state of a particular metric, whereas precision is defined as the measure of exactness of the coefficient⁷ of the metric.

Costing studies require precision to ensure that all costs are included in the correct proportion. However, the pursuit of precision is taxing in terms of time and resources, and a cost-benefit analysis should be undertaken to protect against excessive precision in the model's specification. There is no correct amount of precision — it depends on the usage, just as with rounding up of decimal places in financial projections.

In our study we chose to pursue accuracy as the primary objective and determine the necessary level of precision based on the cost driver's usage. For example, if a small difference in the value of a cost coefficient could have significant impacts on resource allocation, we would refine the value to reduce errors from miscalculation. Where necessary, we improved precision by further analysis of the cost components, until the precision reached the desired level. In the power example above, far greater precision could have been obtained by metering the power to the data center, potentially to the individual machine, over a given period. Given that power accounted for less than 4 percent of the total aggregated cost of ICT activities, however, even a 50 percent estimate error would impact the total cost by only two percent.

3. Keep the model as simple as possible.

Keeping the model relatively simple encourages its use and simplifies its maintenance. If the model becomes too complex and idiosyncratic, it will probably fail to gain acceptance by anyone besides its creator. The model requires general acceptance and understanding to gain traction and become a part of the decision-making processes of the department and institution. The creator should not be the primary user, and the design should respond to others' needs.

4. Document the model.

As with all algorithms, clear documentation is necessary to explain how the model was formed and what logic steps were used to develop the cost drivers and components. The creativity needed to find and use data to support the model makes noting such reasoning essential to future review and defense when proposing its adoption into the organization.

Benefits

The ability to predict resource utilization cost provides the university with an understanding of the trade-offs necessary to prioritize initiatives. It further allows for capacity planning through aggregating all activities. In particular, the benefits can be viewed under the following categories:

• System cost identification
• Project estimates and costing
• Operations and resource planning
• Benchmarking

System Cost Identification

By using the model outlined here, the organization gains the ability to accurately assess the cost of any given system configuration. The level of detail will depend on the granularity of the systems mapping undertaken. This capability is very useful when comparing the cost of systems or making a build-versus-buy decision. Note, however, that the costing model does not produce a definitive cost estimate comparable to the marketplace. The context provides an economic cost of systems, not a purchase price.

In addition, we can use the costing model to help in scenario planning, such as when replacing any system component or viewing the impacts of an overall system switch. The model further provides a map for identification of the technical dependencies of systems on subcomponents. It also provides more knowledge for improved decision making, which is particularly useful when considering new systems architectures.

Project Estimates and Costing

The cost modeling also enables project estimation. Through the usage of the cost elements, the model can complete evaluation of a project's cost by multiplying the cost element by the estimate of use. For example, the project estimate for system development, deployment, and maintenance would require estimation of the activities shown in Schedule 5.

Schedule 5. Project Estimation Example

Activity	Estimating Method	Frequency
Systems analysis	Hours estimate — hourly rate	One time/ongoing
Programming	Hours estimate — hourly rate	One time/ongoing
Testing	Hours estimate — hourly rate	One time/ongoing
Documentation	Hours estimate — hourly rate	One time/ongoing
System administration	Hours estimate — hourly rate	One time/ongoing
Hardware	Cost of supported servers	One time/ongoing
Network	Attributed percentage of network costs	One time/ongoing
Data center	Attributed percentage of data center costs	One time/ongoing
Training	Hours estimate — hourly rate	One time/ongoing
Help desk	Attributed percentage of help desk costs	One time/ongoing

One caution: internal estimates tend to significantly underestimate the complexity and resource requirements of ICT projects. While the model cannot directly address the lack of operational standards, it can help in their formation. For example, to estimate the cost of a system's maintenance, resource support costs for comparable systems have already been determined in the costing model. This information can be reused to extrapolate future system resource requirements.

The model provides the necessary cost identification following derivation of the time estimate. The project estimate thus provides information for total cost budgeting or for comparison with alternate systems to determine a go/no-go decision.

Operations and Resource Planning

Planning of ICT activities into the future can be parlayed back into resource requirements by using the master table in reverse. Using the coefficients determined from the current position permits extrapolating into the future. For example, if new systems require six FTEs as derived through system maintenance analysis, this would lead to an estimated increase in the salaries budget (by an average of the FTE times the average position cost); the cost and square footage of space and work equipment are also determined. The analysis can be continued to view the multiplier impacts of a significant staff increase on the unit's operation and on support departments outside the unit.

Through the analysis to derive cost drivers we have enabled a far more predictive environment for ICT-related activities than previously available.

Benchmarking

ICT operations management requires an ability to ascertain where operational performance can be improved. Much of the information required will come from internal sources through user requests for additional and improved services. However, such requests do not validate the ability of the institution's ICT infrastructure to effectively and efficiently deliver such services. Additional information is required in the form of benchmark comparisons with other organizations.

The cost model yields a series of values that can readily be turned into ratios by selection of the appropriate denominator. Ratios can be used to benchmark the activities of an ICT unit, or the CS department in the case of AU, both internally and externally, to see where improvements can be made. Similarly, comparisons can be made with external studies such as those from the EDUCAUSE Center for Analysis and Research (ECAR).

Having a more objective picture of the unit's operational performance improves understanding of its core competencies. The choice of ratios may also depend on published benchmarks that can be used for comparison. Help desk cost per student or cost per help desk case are two ratios typical in the user support area.

Expansion and Next Steps

Use of a more codified project management methodology at AU is yielding a data set of system activities, which is critical to the development of a project estimating model. The aggregation of this data will yield standard activity times that can be used with cost rates to provide relatively accurate project estimates. Note that the activities are likely to have greater variance than the costs. Thus, until variances between estimated and actual activity times become acceptable, reasonable caution should be used in interpreting project estimates.

Our costing model affords a foundation for developing a sustainable funding framework for ICT. The ability to forecast costs into the future and to cost-evaluate new initiatives enables Athabasca University to determine funding requirements and establish credible business cases. The cost model thus makes it possible for the CS department to substantiate the value of ICT initiatives and increase the chances of obtaining funding for them.

1. Total cost of ownership (TCO) was originally developed in the late 1980s by the research firm Gartner to determine the cost of owning and deploying personal computers. Their methodology was carefully examined and, over the ensuing years, has been accepted as a standard way to evaluate total costs.
2. From Wikipedia: activity-based costing (ABC) is a costing model that identifies activities in an organization and assigns the cost of each activity resource to all products and services according to the actual consumption by each. ABC assigns more indirect costs (overhead) into direct costs.
3. Angie Milonas, Robert Smyser, and Jerrold M. Grochow, "So, What Does IT Cost?" (Research Bulletin, Issue 16) (Boulder, CO: EDUCAUSE Center for Analysis and Research, 2006).
4. A more intensive activity-based costing analysis would have yielded finer granularity for the cost drivers and provided a greater degree of precision to our estimates. In addition, the identification of fixed and variable costs was not pursued because most costs are variable.
5. Other departments provide services indirectly to CS, but the causal link is difficult to approximate. In addition, the functioning of CS did not depend on them. We therefore decided to omit them from the analysis.
6. By and large, absorbed hourly cost was approximately 30 percent higher than the direct labor cost.
7. In mathematics, a coefficient is a constant multiplicative factor of a certain object. The object can be such things as hours, desktops, number of staff, etc. For example, the coefficient of 9 hours is 9. (Adapted from Wikipedia.)

© 2009 Brian Stewart and Dave Hrenewich. The text of this article is licensed under the Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 license.