Costing IT
A Costing Model for Project-based Information and Communication Technology (ICT) Systems
Brian Stewart, CIO
Dave Hrenewich, Director Computing Services
Athabasca University
Table of Contents
Overview ........................................................................................................................................................................................... 3
The Problem ..................................................................................................................................................................................... 4
Approach .......................................................................................................................................................................................... 6
Results and Lessons Learned ......................................................................................................................................................... 22
Benefits ........................................................................................................................................................................................... 25
Expansion and Next Steps .............................................................................................................................................................. 29
Overview
Resource allocation is a continuous problem for all organizations, and educational institutions are no exception. Knowing how much
to allocate to the plethora of worthy initiatives in an environment as predictable as the value of a stock portfolio, is a Solomonic
task. Information and Communications Technologies (ICT) fare poorly in this arena with many institutions finding effective decision
making severely hampered by a lack of accurate information on the cost of system provisioning. This all but renders a standard
cost/benefit analysis redundant and leaves funding or budget providers with very little capacity to make a supportable decision.
Indeed, the paucity of information outside the direct purchase and licensing costs of a system has led to what we term “Event
Costing” which is the costing of an ICT service on its installation cost rather than the Total Cost of Ownership 1. Such has caused a
large degree of circumspection when ICT proposals are forwarded for funding. ICT has become a victim of its own practice of
providing optimistic estimates to resource allocators resulting in either a failure to deliver on the estimate or for the estimates to be
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.
Costing IT
2
normalized based upon a heuristic such as take the first number estimated, double it, then double it again. In addition the cost of
ICT is seen as excessive, implying that its operations are inefficient, ineffective, a poor return on investment and an unsound area for
ongoing budgetary commitment.
To move to a better state of understanding and knowledge regarding ICT system provisioning we need to be able to provide decision
makers with accurate and timely information on the cost of any given configuration. Once this is reliable, traditional asset allocation
metrics can apply and ICT will be on an equal footing with its more mature competitors, such as facilities management, for the
scarce available resources.
The Problem
The central difficulty is how to ensure that the projects and activities ICT resources are committed to, are an effective, economic,
and efficient use of those resources. This problem is very complex with no singular answer or even a limited set of algorithms to
solve. To determine effective usage requires, at the very 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 the effective planning, budgeting and funding of ICT resources is the provision of good cost information.
Failure to have a strong grasp of ICT economics is, at best, likely to result in a misallocation of resources in supporting the activities
of the institution. At worst it may result in stakeholders being underserved of critical functionalities and services.
Without a good approximation of the cost of an initiative it is all but impossible to make a reasoned decision on the application of
resources between alternatives. A business case Return on Investment analysis (ROI) requires valid and repeatable projections.
Without these the decision space is indeterminate and almost exclusively in the domain of non-economic arguments.
Costing IT
3
For example, evaluating the budgetary impact of “buy versus build” is an ongoing issue that has become even more important
as institutions seek to reduce expenditures. A quick assessment to outsource email to a low cost host may look very
appealing, however without fully understanding the impact on internal activities and their costs the decision is based on belief
not facts.
A key aspect of this complex puzzle that this paper seeks to unravel is how to determine the economic cost of ICT resource
utilization, to provide the information necessary to make an effective business and IT decision. By knowing how much it will cost to
undertake an initiative either in dollars or in foregone opportunity, the supply cost of any initiative can be ascertained. Such enables
the decision maker to compare choices and where using traditional financial metrics such as ROI, Breakeven, and Net Present Value
(NPV) and other benefit propositions can then be used effectively.
The purpose of this paper is to provide a methodology that identifies the economic cost of an ICT system. It does this by identifying
the building blocks or components of any system and providing a methodology for determining the cost of such components. By so
doing the model provides a flexible and non-contextual capability to ascertain the cost of any chosen ICT scenario.
More specifically the paper addresses 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 the costs of any given ICT configuration be estimated?
Costing IT
4
Approach
The approach adopted by the Athabasca University Computing Services (CS) Department was to adapt an activity based absorbed
costing methodology for the development of an ICT cost model. As a secondary component of the initiative we used the cost model
to determine individual systems cost. A total cost of ownership approach was undertaken in the evaluation of systems costs.
The approach differs from the 2006 model produced by MIT2 with the main focus on determining activities that drive costs in
addition to identifying and accounting the value of the cost components. A further difference is in the inclusion of indirect costs,
albeit open to some subjectivity in their determination, which yields a more complete accounting of the total cost of ownership. By
limiting the calculation to direct cost, two significant cost drivers are ignored: the overhead burden of operating a significant cost
centre and the variable costs that are proportionate to ITS activities. The latter in particular has become of increasing interest with
the rising cost of energy required to operate data centres. These omissions lead to the view of ITS costs as having no fixed/variable
split. Again with the growth of software as a service provisioning this is a limiting assumption. By providing a fixed/variable
breakdown, scalability becomes apparent and scenario planning can more effectively be undertaken.
The approach is in alignment with that undertaken by the University of Virginia in their Cost of Service Modeling (COSM)3 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
2
3
Milonas A., Smyser R., Grochow J. So, What does IT Cost? ECAR Issue 16 Vol 2006
http://www.itc.virginia.edu/virginia.edu/fall97/costs/costs_linkA.html
Costing IT
5
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.
The approach taken also makes use of cost data that can be aggregated to obtain individual systems provisioning costs rather than
administrative department cost. This has the benefit of providing a basis for comparison with alternate technologies and
methodologies and provides a very useful tool for the evaluation of economic performance and investment decisions such as
outsourcing.
Model Development
The model was developed through a series of stages each building on the previous stage.
Stage 1: The first stage was to identify and classify all the costs into cost elements, an essential step to the construction of the
model.
Stage 2: This is followed by the identification of the cost drivers, those activities that cause costs to move.
Stage 3: The third stage is to attribute the cost elements to the cost drivers to create a set of hourly activity cost rates.
Stage 4: The final stage is the aggregation of the previous three stages output to determine total system and system sub
components costs.
Costing IT
6
Stage 1: Identification and classification of Cost elements
The first step was to identify all the cost elements whether direct and indirect of ICT activities. Table 1 indicates the nature of these
costs and the categorization into direct and indirect costs.
Direct costs are defined as those costs that relate directly to the activity being undertaken. Indirect or overhead costs are defined as
those costs that are related to an activity but are either too complex or costly to derive in a direct cost calculation.4 Table 1 shows
samples of each cost type.
Table 1
Direct Costs
Description
Salary
Salaries of employees
Workstation
Cost of employee’s work technology
Benefit Percentage
Benefits as a percentage of employees salary
Energy Costs
Electricity costs to operate data centre
CS sq. ft.
Includes all space allocated to CS activities.
Indirect Costs
Description
Office of the CIO Levy
Spread evenly across all AU staff
Overhead Assessment
Approximately 5% of Finance, Human Resources operating budget
Supervisors Assessment
Percentage of supervisors cost that is spread across reporting staff
Manager Assessment
Value of CS managers spread across CS employees
Administration Cost
Phones, printing, copying, travel and training, books, etc.
4
A more intensive activity based costing analysis would have yielded finer granularity for the cost drivers and provide a greater degree of precision to our
estimates. In addition the identification of fixed and variable costs was not pursued as the majority of costs are variable.
Costing IT
7
Stage 2: Identification of Cost Drivers
The identification of what elements drive cost is critical to any costing system. Without understanding what actually causes cost
movements any practical use of the model is severely restricted. It should be noted that the degree of granularity required for cost
driver determination is contextual to each institution. As a rule 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 causes into larger drivers to facilitate an efficient data gathering
process. This degree of granularity should be revisited on a periodic basis to ensure assumptions have not changed.
For example long-distance telephony would have declined considerably over the past few years as a cost driver and where it
may have been required to separate it into its own cost driver, it can now be adequately represented within another
telecommunications sub-group.
To identify the cost drivers we reviewed the activities undertaken by CS personnel and the activities normally undertaken in ICT
projects. This was achieved by reviewing literature related to ICT projects and brainstorming sessions with CS personnel. Both
sources of information converged on the following cost drivers:
•
Employee Activity hours
•
Occupational costs
•
Data Centre and Network costs
•
Hardware Acquisition
•
Application licenses
Costing IT
8
The last two items can be directly related to any given application and may not require an absorbed analysis. Network and Data
Centre costs will be absorbed to each configuration based on the expert knowledge of the systems by AU personnel. This will be
done in stage 4 of the model.
The Occupational costs are not as easily related to any particular configuration and require to be simplified for more accurate and
easy usability. This is achieved by using the Employee Activity hours as the basic cost element and absorbing into them the
Occupational Costs to form a Direct Hourly Cost Rate. This will then be used to apportion indirect costs to achieve the Absorbed
Hourly Cost Rates, the building blocks for system and project estimating. The model as presented allows the use of two staff
locations, and two bargaining units for staff –the model could be enhanced to more locations or units as the need arises without
needing to change the formulas as they are data driven by the values of location and bargaining unit.
Indirect Cost Allocation
Indirect cost attribution is a practice that requires discretion and can appear more art than science. To assess all indirect costs for
Athabasca University we viewed the total University budget to ascertain the departments that provide services to ICT 5. Given the
structure of the institution’s budget these were all found in the Finance and Administration budget:
•
Financial services – purchasing, accounting, contracts
•
Human resources – payroll, hiring, benefits management
•
Facilities – space, HVAC, cleaning
5
Other department provide services indirectly to CS, however the causal link is very difficult to approximate, in addition the functioning of CS was not dependent
upon them. It was therefore decided to omit them from the analysis.
Costing IT
9
To simplify the calculation of the overhead or indirect cost burden of ICT we grouped Finance and Human Resources into one group
and left Facilities by itself.
In the case of Financial and Human Resource services two methods were used to cross reference other:
•
the total budgets of the institution and the portion which was attributable to ICT and:
•
the total full time employee (FTE) count of the institution and the total FTE count attributable ICT.
•
The results from both methods were close at approximately five percent of total institutional budget related to ICT
activities and this was taken as a measure of the Finance and Human Resource cost overhead levy of ICT services.
Facilities required a more detailed analysis as the cost of providing physical working space, defined as serviced operational space
which included such services as HVAC, lighting, cleaning, furniture and fittings, and maintenance. In addition the power cost of
operating ICT equipment was also required, including the data centres and all employee work stations. A rent opportunity cost was
also included in the serviced space costs, being based on an approximation of the market rate for similar furnished space.
Once obtained the cost of facilities, excluding energy costs, was apportioned to the total space given to the CS department, achieved
by dividing the total facilities cost by the total square feet occupied by CS. This yielded a total occupational cost per square foot.
Summary of ICT costs
Our analysis brought out the fact that the majority of direct cost related to ICT is related to people at over 70 percent. Other
elements of technology, in the form of hardware, software, network connectivity and other licensing is less than 30 percent of total
ICT expenditure. 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.
Costing IT
10
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 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 apportion costs in a series of steps. The model creates
Tables 2 and 3 described below (Table 3 within the model), through the Microsoft Excel pivot table functionality.
Step 1 – Determine Average Hourly Cost Rate by Functional Group
Step 1 was to take each employee within their functional group (job class) and to use their salary as the initial cost element.
•
Obtain each employee’s salary and benefits
•
Group employees into functional categorizations
•
Use the Microsoft Excel Pivot Table functionality to obtain averages by functional group
This step yields the Average Hourly Cost Rate of each functional group as per Table 2.
Costing IT
11
Functional Group
Database Analyst
Help Desk Analyst
Intermediate Systems
Administrator
Junior Systems Administrator
Microcomputer Support
Network/Telecomm Support
Programmer/Analyst
Project Manager
Senior Systems Administrator
Senior Systems Analyst
Systems Analyst/Programmer
Tester/Trainer
Unit Manager
Grand Total
Table 2
Average Direct
Hourly Cost
64.95
40.65
54.72
Average Absorbed
Hourly Cost
79.30
48.07
65.58
47.99
55.30
48.97
47.92
74.03
72.60
62.95
58.34
54.08
80.96
58.57
58.16
63.35
57.67
59.19
85.64
84.37
76.60
69.96
63.64
86.81
68.26
Step 2 – Determine Direct Hourly Cost Rate
Attribute direct cost to the Average Hourly Cost Rate on the basis of their salary and benefits we proportionally attributed the
following costs:
•
Costing IT
Employee cost of equipment
12
•
Employee cost of space
This step yielded the Direct Hourly Cost Rate of each functional area6 contained in Table 3A.
Table 3A
Unit
Administrative Systems
Administrative Web Services
Database Services
Identity & Access Management
Info Technology Systems (ITS)
ITS Help Desk
ITS PC Support
ITSIM Client & Operational Services
ITSIM Telecom & Networking
Learning & Research Web Services
PMO
Grand Total
Average Direct
Hourly Cost
60.55
64.21
70.04
81.54
79.76
40.65
55.04
64.25
52.71
57.10
58.33
58.42
Step 3 – Attribute the Indirect cost to the Functional Areas
On the basis of the Direct Hourly Cost Rate we apportioned the following costs:
6
•
Overhead Levy
•
Supervisor Levy
By and large absorbed hourly cost was approximately 30 percent higher than the direct labour cost.
Costing IT
13
•
Internal CS Managerial Levy
•
CS Administration Costs
The values for these cost drivers are found in the model within “Table 1: Cost Criteria Factors.” Step 3 yielded the Absorbed Hourly
Cost Rate for each functional area.
Table 3B
Unit
Administrative Systems
Administrative Web Services
Database Services
Identity & Access Management
Info Technology Systems (ITS)
ITS Help Desk
ITS PC Support
ITSIM Client & Operational Services
ITSIM Telecom & Networking
Learning & Research Web Services
PMO
Grand Total
Average Absorbed
Hourly Cost
71.12
76.62
83.03
92.08
85.98
48.07
63.12
73.89
60.90
67.94
66.78
68.13
Tables 2 and 3B above contain the Average Absorbed Hourly Cost Rates; it is these that will be used as the cost elements in
determination of ICT systems and project costs. By absorbing all the costs into these cost elements we have enabled estimates and
computations based on them to be both accurate and relatively simple to use. The user of the absorbed rates does not have to be
concerned with their derivation and can employ them as necessary to cost any given ITC system.
Costing IT
14
Model Maintenance
To further ensure ease of use we constructed the model in a manner that would facilitate updating of information on an ongoing
basis. A series of spreadsheets were used that were linked by the constructs of the model. The use “Table 1: Cost Criteria Factors”
allows for the input 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 occupational cost occurs the table is updated to reflect the changes. The staff table is also
updated to reflect changes in employees’ positions, salaries and benefits. By so doing the hourly cost rates are kept current.
Should there be a significant change in the operation of the department a new cost element can be added to the “Table 1: Cost
Criteria Factors” and the cost will be attributed on an iterative basis.
Stage 4: Determining System Cost Estimates
Systems by their definition are a set of interconnected interdependent components. Thus a system may be a singular application
resting on a server within a networked data centre, being viewed from a remote terminal. Alternately a system may consist of a
main application being supported by a set of subsystems. For example a Student Information System architecture may look as
follows:
Major System
SIS Application
Personnel
System Component
Banner/PeopleSoft
System Administrators
Support Systems
Database Management System
Identify and Access Management
Oracle Database
Firewalls
Costing IT
15
Authentication
User Support
User development
Kerberos
Help Desk
Training
Physical Infrastructure
Hosting
Hosting
Hosting
Access
Application Servers
Storage Servers
Data Centre
Networks
Therefore to determine systems costs the first step is to identify and categorize the major support and infrastructural components
that reflect any given architecture. The main reason for this is to provide flexibility as systems’ sub-components change.
Once the systems map is complete the cost elements developed previously can be inserted where appropriate. There is an element
of discretion here as the allocation of systems costs to components may not be quantifiable on a straightforward ratio basis.
Nonetheless errors are likely to be of a low order of magnitude due to the categorization having provided a schema that, by its
nature, has significantly simplified the allocation process.
Each of the system components identified above can be either a singular constituent or a subsystem with elements that require
further evaluation. The granularity of the decomposition is contextual and should be proportionate to the usage required. Thus in a
complex ICT infrastructure serving a large user base the degree would be an order of magnitude higher than a smaller centre with
less than ten employees for example. The key is that the model is scalable and applicable at any level of operation
To ascertain the cost of a system requires analyzing the support requirements of the system. For example the cost of our Student
Information System required determining the system sub-components and evaluating the cost of these sub-components.
Costing IT
16
The more data that are available regarding employees activities the better will be the ability to assign resources to the various
support activities undertaken in the institution. In the absence of hard data brainstorming and anecdotal evidence is a good first
approximation.
Thus the direct system costs of licenses and hardware purchase costs, form the base for the cost assessment. Added to these are the
employee support hours multiplied by their absorbed hourly rates (as per the formula identified above).
Thus we could derive the total cost of our SIS as well as the individual sub-components. Such provides very useful information for
comparisons of alternate systems, value for money comparisons with other institutions, and evaluation of system enhancements or
modifications.
We are now in a position to better assess projects to change or improve the SIS as we have a baseline to determine the cost/benefit
ratio. Again this does not preclude any activity that may have a beneficial impact on the institution that is not directly financial.
Rather it simply relates the attended resource cost to its completion. Knowing what something costs does not prevent it, but it does
provide a critical point of knowledge to understand the economic implications.
Estimating the cost of systems within the 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 AU IT employees. The actual details and differences in
leave lengths and other benefits are found within the first tab of the workbook.
•
As Athabasca University uses a federated model for IT services, two parameters for average hourly wage costs for IT staff
external to Computing Services 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.
Costing IT
17
•
The final two master data parameters are used to obtain an electricity/cooling cost for the server rooms of the University.
As we do not have separate metering within the server rooms, this is obtained through reporting from our uninterruptible
power supplies servicing the server rooms.
The second section of the tab, “Table 5: Information Technology System infrastructure Costs”, is used to determine an infrastructure
cost which is allocated across all systems. This section can be as detailed as precisely as the model user might wish. AU has chosen to
use:
•
Network costs
•
Security costs
This section allows the use of either full-time equivalents of staff or annual hourly allocations. Again, the level of precision is left to
the model user – you may link back directly to the actual costs of specific staff members who are responsible for the administration
and maintenance of a system, or you may prefer to link back to average hourly costs for a job grouping (e.g., “Senior Systems
Administrator”). Determining which staff are allocated to each system, and their amount of involvement is a significant exercise
which 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
would be related to project and enhancement tasks. The external fees value reflects items like maintenance fees. The Microsoft
Excel comment feature is used in the model to provide additional detail as to what makes up the total external fee and also
describes how the mandatory and discretionary FTE numbers were derived from staff resource allocations.
Costing IT
18
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 using one method for apportioning costs of database support
across systems. After some discussions, we decided to apportion database costs based upon the size of the datasets used by each
system – specifically the size of the Oracle dump files. Other suggestions included the space allocated at the disk level, or the
number of users within each system, amount of staff time used in maintain the systems, etc. Readers may choose whatever metric
they 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 into 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 significant systems within the University. The
level of granularity (how many systems to report) is at the discretion of each model user. Obviously, the more systems reported
means more work creating and maintaining the model and a requirement for a finer level of staff resource allocation. 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 FTE’s and person hours are input from an
assessment of resource allocation to these systems for their on-going daily maintenance. External fees specific to each system may
be entered. External fees and mandatory staff costs are subtotaled into 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 directly drive the frequency and amount of review and maintenance of this
section of the model.
Costing IT
19
Results and Lessons Learned
While the development of the model was relatively straightforward there were roadblocks and difficulties experienced along the
way.
1. Cost data were not always available in the form required
Obtaining the cost information appears more straightforward than it was in actuality. Budgets in most universities are not developed
with the intention of developing cost models. Their focus is to provide administrative units with the ability to plan, control, and
manage their resources. Activity costing is unfortunately a lot messier, as the activities that drive cost do not fit neatly into the
organization chart. Anyone that has undertaken a business process review using a swimming lane flow chart will understand the
interdepartmental aspect to most processes within an institution. To derive cost information usable to the model required both the
interpolation and extrapolation of organizational budget data to derive useful cost data.
For example the cost of the CS department’s power bill is not recorded separately from the University. To derive the cost we
developed a coefficient based on the average computer power usage coupled with the HVAC and UPS requirements of the data
centre to derive an estimate of usage. Once computed the usage estimate was relayed into a percentage of the overall University’s
power bill and was then used as a simple ratio. Periodic reassessment will correct the ratio, allowing for a more simple projection for
future usage.
Costing IT
20
2. Precision versus accuracy
There is a trade-off between accuracy and precision that is of particular interest here. While both can mean the same thing, for the
purposes at hand 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 coefficient7 of the metric.
In costing studies there is a desire to be precise 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 over
precision in the model’s specification. There is no correct amount of precision it is dependent on the usage the model will be used
for, just as with the rounding up of decimal places in financial projections.
In our study we took the approach that we would pursue accuracy as the primary objective and determine the necessary level of
precision from the requirement of 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 of the cost coefficient to reduce any likely errors due to its
miscalculation. Where necessary, improved precision was achieved by further analysis of the cost components, until the precision
was at the desired level was obtained. In the power example above, far greater precision could have been obtained by metering the
power to the data centre, potentially to the individual machine, over a given period. However given that power accounted for less
than four percent of the total aggregated cost of ICT activities it was felt that even with a 50 percent estimate error this would only
impact the total cost by two percent, which was not held to be material.
7
In mathematics, a coefficient is a constant multiplicative factor of a certain object. The object can be such things as hours, desktops, staff, etc. For example, the
coefficient of 9 hours is 9. (Adapted from Wikipedia)
Costing IT
21
3. Keep the model as simple as possible
Pursuant to the arguments for relative precision is to keep the model as uncomplicated as possible. By keeping the model relatively
simple its usage and maintenance are encouraged. If the model becomes too complex and idiosyncratic it will likely only be used by
its creator and will fail to gain acceptance by anyone else. The model requires a general acceptance and understanding to gain
traction and become a part of the decision making processes of the department and institution. It is advised that the creator should
not be the primary user. By so doing it becomes a necessity for it to be designed in order for others to use.
4. Document the Model
As with all algorithms it is necessary to document clearly how the model was formed and what logic steps were used to develop the
cost drivers and components. The requirement to be creative to find and use data to support the model makes noting such
reasoning as essential to future review and defense when proposing its adoption into the organization.
Benefits
As was stated at the beginning the central problem of resource allocation can now be better approached. 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 the aggregating of all activities, providing for effective planning and sequencing of activities. In
particular the benefits can be viewed under the following headings:
1. System cost identification
Costing IT
22
By using the model outline here the organization will have the ability to accurately assess the cost of any given system configuration.
The detail of which will be dependent of the granularity of the systems mapping that has been undertaken. This ability is very useful
when comparing the cost of systems or making a build versus buy decision. It should be noted that the costing model does not
produce a definitive cost estimate that is comparably in the marketplace. The contextual nature provides an economic cost of
systems not a purchase price.
In addition we can use the costing model to help in scenario planning. For example replacing any system component or viewing the
impacts of an overall system switch. It further provides a map for the identification of the technical dependencies of systems on
subcomponents and provides more knowledge for improved decision making. Such is particularly useful when considering new
systems architectures.
2. Project estimates and costing
Another very valuable ability enabled by the cost modeling is that of project estimation. Through the usage of the cost elements the
evaluation of a project cost can be completed by the multiplication of the cost element by the estimate of recourse usage. For
example the project estimate for a system development, deployment and maintenance would require the following activities to be
estimated.
Project Estimation Example
Activity
Systems analysis
Costing IT
Estimating Method
Hours estimate x hourly rate
Frequency
One time Ongoing
23
Programming
Hours estimate x hourly rate
One time Ongoing
Testing
Hours estimate x hourly rate
One time Ongoing
Documentation
Hours estimate x hourly rate
One time Ongoing
System Administration
Hours estimate x hourly rate
One time Ongoing
Hardware
cost of supported servers
One time Ongoing
Network
Attributed percentage of network costs
One time Ongoing
Data centre
Attributed percentage of data centre costs
One time Ongoing
Training
Hours estimate x hourly rate
One time Ongoing
Helpdesk
Attributed percentage of Help Desk costs
One time Ongoing
A caution is that internal estimates tend to significantly underestimate the complexity and resource requirement of ICT projects and
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, analysis of resource support cost for comparable systems has already been determined in the
costing model. This information can be reused to extrapolate future system resource requirements and to include these in estimates
of such systems.
Given this, the model does, nonetheless, provide the necessary condition of cost identification once the time estimate is derived.
The project estimate thus provides information for total cost budgeting or for comparison with alternate systems to determine a
go/no go decision.
3. Operations and resource planning
Costing IT
24
From the forgoing it can be seen that the planning of ICT activities into the future can be parlayed back into resource requirements.
This can be achieved by using the master table in reverse. By using the coefficients determined from the current position the future
can be extrapolated. For example, if new systems are determined to require 6 FTE derived through the 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), in
addition the cost and square footage of space and work equipment is also determined. The analysis can be carried on to view the
multiplier impacts of a significant staff increase on the operation of the unit and on support departments outside the unit. For
example the cost of the CS Help Desk can be divided by the number of calls to develop a cost per call. Relating the number of calls to
the number of students, faculty and staff allows the support costs for any given compliment of stakeholders to be calculated.
Thus through the analysis to derive cost drivers we have enabled a far more predictive environment for ICT related activities.
4. Benchmarking
ICT operations management requires an ability to ascertain where performance can be improved. Much of the information required
will come from internal sources through user’s requests for additional and improved services. However such requests do not provide
a validation of the ability of the institutions ICT capability to effectively and efficiently deliver such services. Additional information in
the form of benchmark comparisons with other organizations is required.
The cost model yields a series of values that can readily be turned into ratios by the selection of the appropriate denominator. Ratios
can be used to benchmark the ICT unit’s activities, both internally and externally, allowing the analysis of activities to see where
improvements can be made. Comparisons can similarly be made with external studies such as ECAR. Having a more objective picture
of the operational performance of the unit provides an excellent ability to improve the understanding of the department’s core
Costing IT
25
competencies. The choice of ratios may also depend on other published benchmarks that can be used for comparison; Help Desk
cost per student or cost per Help Desk case are two ratios used consistently in the user support area.
Expansion and Next Steps
The model affords a foundation for the development of a sustainable funding framework for ICT in the future. The ability to forecast
costs into the future and to cost-evaluate new initiatives enables the situations to determine funding requirements and thereby
establish credible business cases. By so doing the IT department can substantiate the value of their initiatives and increase their
chances of obtaining funding.
Development of a project estimating model
The use of a more codified project management methodology at AU is yielding a dataset of system activities and their related times.
Such information 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 the cost rates to provide relatively accurate project estimates. It should be noted that it is the activities
that are likely to have the greatest variance rather than the costs. Thus until variances between estimate and actual activity times
become acceptable, reasonable caution should be used in the interpretation of project estimates.
Costing IT
26