“What are My People Doing, and How Much is it Costing?”
Expanding the Remedy Action Request System into a Work Management System
A White Paper from Project Remedies, Inc.
This paper describes the business problems a typical IT organization faces in its
need to understand what its people are doing and how much it’s costing. It relates how an
organization must manage resources to make optimal use of each worker’s skills to improve
service delivery at the lowest possible cost, then chronicles the pitfalls of using the “best”
product for each application, under-utilizing these products, and unsuccessfully implementing its
program/project management software systems. Finally, the paper outlines a solution for these
problems – Project Remedies’ ActionProgram Manager™ combined with an organization’s
existing and/or additional Remedy AR System-based applications – and spells out the return on
investment this solution can provide.
In order for management to stabilize or reduce costs, they need to know where the costs are
being spent. There are two types of costs, resource costs and asset costs.
Resource costs can be categorized as direct costs, which involve the time spent working
requests from users, and indirect costs, which involve keeping the company in business (server
and network management, meetings, training, etc.) as well as vacation and sick time, i.e., tasks
that are not related to requests from users. Indirect costs might also be called maintenance or
Lots of requests come into an IT organization. These requests are turned into tasks that are
assigned to resources, who work the tasks and status the tasks. In order for management to
know the time and cost involved with supporting user requests, the resources have to enter their
time against tasks. In order to improve processes – and thereby improve service levels and
reduce cost by effectively deploying the right number of resources at the right times – detail is
needed about the number and type of requests and the amount of time spent against these
Within the IT organization, requests are usually managed by three main applications:
• Help desk systems. These manage small requests, which can be satisfied when a single
task is completed. Small requests often result in “problem tickets” and involve what are
customarily called problem management processes.
• Change/work order/service order management systems. These are for medium-sized
requests, which are satisfied by the completion of multiple tasks, such as all tasks involved
with approving a change or with hiring or terminating an employee. These types of requests
entail what are usually known as change management processes.
• Program/portfolio management systems. These are for large requests, which are
satisfied by the completion of many tasks, most often take longer than a medium-sized
request and have a bigger dollar value. Large requests normally result in projects, and
managing lots of projects is often called program management or portfolio management.
Often, companies buy the “best” product for each of these applications. Then they find that
these applications have to work together, that different types of requests result in similar tasks
to be performed, and that there is, in fact, a single resource pool.
A company in San Diego offers a good example of these applications working together. Their
process is for defect reports from users to come into the IT help desk. (Defects are reported
within IT in their change management application.) An incident for a particular defect is created
and categorized in the help desk application. That incident is assigned to the Change Control
Board, who decides whether it should be handled as a change request or a project. Let’s say
that it is a project. A project plan should be created using a template for defect fixes, and all the
tasks in the template should be spawned. The last task is to “implement the fix,” and in their
environment, this is done with a change request. The company wanted workflow from the
program management system to automatically create the change request to implement the fix.
When the fix is implemented and the change request closed, workflow from the change request
should automatically close the task in the project. Because this is the last task in the project,
workflow should automatically close the project, close the original help desk incident, and notify
the original user that the defect has been fixed and implemented.
Different types of requests can often result in the same task for the same resource. For
example, a field technician receives a task to “deploy a PC on Bob’s desk.” That could have
come from three different requests:
! Bob called and said that his PC didn’t work and to please deploy a replacement.
! Someone in Human Resources said the company has a new employee named Bob, and
one of the many tasks that need to be performed for this new employee is to deploy a
! A vice president said there’s a new project to deploy 5,000 PCs, and this one needs to
be deployed on Bob’s desk.
The question is: Why should these tasks look any different to the field technician?
The situation just outlined is the source of a major problem for most companies: how to get
better cost information in the short term, and without spending a huge amount of money on a
major integration project that would not be completed in the short term anyway.
Especially in difficult times like these, upper management wants to understand what their people
are doing and how much it’s costing. They need to know their IT dollar commitments and
resource commitments, and when they ask for the information necessary to make a decision,
they need the answers now, not two days from now. The data has to be current – up to the last
entry – and available immediately.
An organization really does have only one resource pool, and knowing which resources are
available for projects is critical to meeting organizational goals. A person with the desired skill
and the time available may be in another department. If a department manager tells his/her
boss, “We need to hire a consultant with this skill, in this location, for this period of time,.” the
first thing the boss would say is, “Prove it.” The second thing would be, “Is there anyone else
with that skill in that location who is not too busy during that period of time?” In order to answer
these questions, the manager needs to know all the resource commitments. If the data is in
multiple applications and databases, it is very difficult to bring it together and to do so in a timely fashion.
As indicated earlier, IT resources must enter their time against tasks in order to provide better
cost information. Unfortunately, traditional ERP (enterprise resource planning) systems do not
track detail at the needed level and are not geared for IT resources. As one IT manager said,
“Have you ever seen an ERP system create an ERP for IT resources?”
Licensing the “Best” Product for Each Application
In the past, the CIO usually instructed managers to buy the “best” product for their department’s
particular requirements. And they did just that. As a result, IT organizations are using disparate
products that run on different platforms, store data in different databases, and do not work with
each other. A developer at one company spent the last year trying to integrate two disparate
products that both store data in Oracle and has not been able to do it.
This brings us back to the IT resources entering their time against tasks. If the tasks are in
these disparate products that store the data in different databases on different platforms, one
solution is a $1-5 million “never-ending” integration project, which lots of big consulting firms
would like to propose. But even if spending that kind of money were possible, the $1-5M
integration project is a long-term proposition. This type of project is never-ending because each
time one of the vendors has a new release, the integration has to be re-done.
Under-utilized, Expensive Software
Many companies have spent a great deal of money on point solutions, and for several reasons
these products are under-utilized. A CFO commented, “At my level, the features that
differentiate the ‘best’ product from the others evaluated are usually scheduled to be
implemented in Phase 3. But we never get to Phase 3. At Phase 1, the functionality of all of the
products reviewed is about the same.”
A better solution would be a suite of applications that run in the same development
Unsuccessful Implementation of Program/Project Management Systems
Perhaps the wisest analysis of this part of the problem comes from Bob Willey, Vice President
of Information Services at KinderCare Learning Centers: “It takes about 18 months to get a
program management system embedded in an organization. Most of these products require
that all the users know everything about project management up front, and that is just not possible.”
Experienced project managers are frequently put in charge of implementing an enterprise-wide
system. Because these people know how important many of the system’s esoteric features are,
they want to train everyone on these features before getting started. This often takes a great
deal of time and investment without really producing any results.
KinderCare’s Bob Willey preferred to implement a team approach to managing projects. This
would make it as easy as possible for everyone in IT to get involved. Because the people
working the tasks are the ones who know most about what is going on with each task, if the
scope changes, they – not the project manager – are the first to know. Willey wanted it to be
easy for the workers to communicate this type of information to the project manager and any
other interested party. Improving communication is the number-one goal in enabling the team
to work together most efficiently.
Early program management systems were typically designed for e-mail communication between
project managers and the people in the performing organizations. For example, the project
manager would notify a worker by e-mail that a certain task could be started, and the worker
would then e-mail back to the project manager with the status and notes about the task. But
wouldn’t it be easier if the workers could status the tasks themselves and enter their comments
into the task, instead of creating an e-mail message? It surely doesn’t take any longer for the
worker, and it saves the project manager the time of interpreting the comments and entering
them into the system. That process is just too cumbersome – and riskier as well, if the project
manager does not correctly interpret the worker’s e-mail. When a task is completed, it would be
far simpler if the system notified the person or people responsible for the next task(s) so the
project manager would not have to be involved.
When one of these early program management systems was being installed at a major
company, its Remedy development manager asked the vendor’s representative if the length of a
field could be expanded. He was told, “No. These are ‘the best practices.’”
These particular scenarios point out a big part of the problem, and lead us now to the solution
for the entire problem.
The Solution: ActionProgram Manager and the Remedy AR System
The ideal solution to the business problem detailed above has several characteristics. All user
requests and their related tasks (help desk, change management, program management,
maintenance and administrative tasks) would be created in the same environment. People
would be considered one resource pool, and all information would be stored in the same
environment. Entering time against these tasks would also be done in the same environment.
The solution would be implemented in the short term and take advantage of investments that
have already been made. It would build upon that investment so the company sees a better
utilization rate. One such investment is the dollars spent on software product licenses and the
necessary databases and hardware. Another investment is in training the users. If the product
is already running internally, there is a support staff in place, and the users – or at least many of
them – know how to use it.
In addition, the product used would be flexible enough that a company’s business processes
could be customized within it. This would help the company realize increased efficiencies and
thus reduce costs.
A Holistic Approach to Managing All IT Requests
In the situation described, the product most likely to be already up and running is the Remedy
Action Request System (AR System), which is used by more than 6,000 companies, at some
12,000 sites worldwide, by about 10,000,000 people. Although it’s been marketed as a help
desk system and frequently thought of as a “trouble-ticketing” system, the AR System is, in fact,
a robust development environment – a true client server and GUI front-end to the major
databases (SQL Server, Oracle, Sybase, Informix, and DB2) for tracking and workflow
applications. The AR System has a dual purpose. It is the premier application platform and the
premier development environment, handling all applications – packaged, homegrown, and
As a workflow engine, the AR System allows the administrator to embed the company’s
business processes within it. Because the AR System is most frequently used for help desk
applications, the first processes implemented are the problem management processes.
The AR System, however, is not a trouble-ticketing system. It’s a development environment
that can be used for all kinds of applications that generate tasks and involve workflow. Some IT
professionals call it a “great request management” system, while others think of it as a “great
task generator.” Either way, the AR System has been so successful because its users have
been successful defining their business processes in it.
As previously mentioned, there are three major task-generating applications: help desk, change
management, and program management. Remedy Corporation has developed and markets
both Help Desk and Change Management systems, which interface with Remedy’s Asset
Management system. Many users create their own applications with the AR System, hire
consulting firms to build applications from scratch using this tool, or modify existing Remedy built
This is where Project Remedies comes in. Because of their depth of experience in program
management systems in general and the AR System in particular, the people at Project
Remedies decided to create ActionProgram Manager (APM), a program management, resource
management, and time- and expense-tracking system built using the AR System. APM is
designed to be used standalone; as an enterprise-wide program management, resource
management, and time- and expense-tracking system; or combined with Remedy’s applications,
or with custom-built applications using the AR System, to create a work management system.
APM can also interface with Remedy’s Asset Management system. It has a robust interface
with Microsoft Project, so project plans created in MS Project can be imported into APM for
approval, management, and time tracking.
Combining program management processes with problem management and change
management processes provides a complete work management framework. This could be
called an “ERP for IT” system, a requirements management system (or framework), or a workforce
management system. That’s because in order to determine what the people are doing
and how much it’s costing, all work that comes into IT, and what everyone’s working on, needs
to be tracked. Then the people working the tasks need to enter their time against the tasks.
These are direct costs. Time spent on indirect activities can also be entered into APM.
Being able to track all resource and asset costs – in detail – in the same system and database
is a huge benefit for top management.
Easiest, Fastest, Cheapest Way to Implement Work Management System
For an organization that’s already using the AR System for help desk and/or help desk and
change management, adding APM will make it possible for its IT operation – within just a few
days or weeks – to time-track against all the installed applications, enterprise wide.
APM runs on the organization’s AR System platform and takes about 30 minutes to install. After
that, it takes literally just a few minutes to add the “work time tab” to the existing AR Systembased
applications. If the AR System is already up and running, an AR System support
organization is in place and familiar with the organization’s business, so it can quickly make any
necessary modifications. Any application developed using the AR System is designed to be
modified, and we assume that modifications will indeed be made.
Enormous Return on Investment
Project Remedies’ approach is to handle these applications in Remedy and maximize an
organization’s investment in Remedy. Besides letting the organization know what its people are
doing and the related costs – so it can stabilize or lower costs and improve processes and
overall efficiency – this also results in several areas of hard savings, which can vary with the
size of the department:
• The most significant savings is reduced training. Workers are already accustomed to getting
Remedy tickets for many or most of their tasks. With APM, they’d also be getting time- and
date-stamped Remedy tasks.
• If there are three-person teams supporting each of five disparate products, reducing this
number while expanding the Remedy team to handle additional work can save about $1
million a year.
• If all of, say, 200 people in an IT department save 15 minutes a day by looking in one place
for their to-do list, instead of in five different applications, at a conservative burdened rate of
$50 per hour, the potential savings would be $630,000 per year.
• Avoiding future-year maintenance fees is another area for savings. Even if the maintenance
paid for Remedy licenses is doubled, the organization would still save because of the
eliminated maintenance costs for those other “best” products.
• Another hard savings is avoiding the $1-5 million never-ending integration project needed to
link together disparate applications.
• Because Project Remedies’ APM solution can be up faster than the $1-5 million integration
project, an organization can also save money by actually running the application and getting
the management reports they’ve wanted.
There are soft savings as well. Experience teaches that in order to complete projects, the
projects have to be managed. Management needs visibility into commitments for dollars and
resources. If management knows what its resource commitments are, resources can be used
more effectively. Also, it’s certainly much easier to know what people are working on if all their
tasks are created with the same system. This greatly simplifies time tracking too, so
management can fully understand resource costs and charge back their time.
From a business standpoint, a system has long been needed that lets an organization plan
multiple projects, approve project plans, work and manage projects in real time, and generate
accurate reports for every project – enterprise wide – all within the same system. Clearly, the
ideal solution was one that could leverage an organization’s existing investment in the Remedy
AR System, due to its almost universal usage.
Project Remedies’ ActionProgram Manager provides this solution. Because it runs on the AR
System platform, this flexible, easy-to-use, cost-effective work management system can
combine program management, problem management, service requests and change
management into a single unified process for the entire IT organization. APM represents a
whole new concept – work management – and replaces the incredibly costly, never-ending
integration project for understanding IT costs. In essence, APM gives managers the information
they need, when they need it, in a format they’ve been using – allowing them to make bettereducated
decisions to streamline and maximize their organization’s effectiveness.