Back to Zero – Footprints Software Utilization Project
Part 2 By Leigh Wilkinson, OIT
In May of 2008 a project team comprised of 10 people representing OIT, DHHS, and DOT interests began looking at the way we use Footprints – a software application used to drive service management workflow for the OIT Customer Service Center as well as for other more specialized projects. This group meets every other week to work on project deliverables. The title ‘Back to Zero'(BTZ) refers to a guiding principle for the groups actions; to act as is we were starting over from ‘zero' but with the benefit of all the lessons we have learned in the last 3.5 years since Footprints was first installed.
The BTZ team charter business case defined the need to review the current use of the Footprints software with a focus on the OIT customer support project and related projects. (To better understand how Footprints divides different work into separate “projects please review Part one of this article published last month.) The Customer support project is used to create tickets to manage workflow from customer contact with the call center (help desk). This project is used to assign work to various OIT work groups for both short term and long term activities ranging from password resets to the configuration and build of application servers.
The BTZ team is looking for opportunities to improve the use of the software through clearer business rules and processes. The desired outcome should increase performance in managing service desk requests and produce meaningful metrics for assessing service management performance.
Deliverables for the BTZ team include:
Reduce or eliminate backlog of open tickets in customer support and related projects ( another meaning for ‘back to zero”) – build business rules to manage ticket age and prevent a ticket backlog from reoccurring
Develop processes and business rules for use of the Footprints software within a project framework
Develop escalation rules and definitions for service level agreements
Develop metrics through standardized reports for assessment of service level performance
Identify and adopt best practices for use of Footprints as recommended by the software manufacturer and approved by the Footprints project team.
After 6 months of meetings (we had a two month summer hiatus) and work, here is a summary of what we have accomplished so far:
- We have revised and clearly defined the roles for the different levels of employee activity within Footprints. These roles are: System Administrator, Project Administrators, and differing levels of permissions for Agents – training materials will be developed in the next few months including how to use customer portals allowing for self-service for some footprints tasks.
- A member of the group created a ticket number look-up capability for Footprints tickets and placed it on the CSN page: http://csn.state.me.us (available on the state intranet only). This allows anyone to review ticket activity without needing an agent status.
- We have created and reviewed process maps of the current project configuration – these are helpful when we redesign any portions of Footprints projects. They were especially helpful in the early meetings as the BTZ team learned just how complex the software was and how projects interact with each other based on business rules.
- We have updated lists of agents, administrators, etc – these lists will be helpful in consolidating role assignments and other improvements.
- We compiled and sorted a list of Footprints ticket problem types complete with diagrams of escalation rules and drop down menus attached. This is part of ongoing work to define problem types and reduction of the number of types from 128 problem types to around 50 better defined terms.
- We have successfully adopted a change management process to mirror the OIT Information Technology Infrastucture Library (ITIL) based change management process. This change management process will prevent changes from occurring within a Footprints project without a full assessment of impact on other linked projects.
- We have held several meetings with the vendor regarding a future version upgrade of Footprints, a review of application best practices and discussed project design concepts.
- We are continuing outreach meetings with various agencies and stakeholders to better understand their needs and how they use Footprints. Our goal of creating usable forms is closely tied to this effort.
- We are close to rolling out a business rule designed to dramatically reduce old tickets – it will be designed to close tickets not edited within a defined time frame after first notifying the assigned agent of the pending close. The agent will have an opportunity to update the ticket or allow it to close automatically.
- We are building a better understanding of how Footprints project design dramatically impacts the ability to report metrics. We have begun detailed discussion with managers regarding what they need for metrics regarding OIT activities.
It is important to note that the learning curve for this project has been immense. Few of the team members had any idea how complex the inter-relationships and configuration options are within Footprints projects. As a group we had to learn how to write reports and experiment with the existing project in order to understand how the program works and to better define opportunities to make changes in future projects. We are now in the process of defining a new customer support project which will be configured and run as a separate test project before replacing the current project. One of the design challenges yet to be resolved is simplifying the project interface to improve its' usability by the call center and service technicians without a corresponding loss of functionality for other assignment teams such as the server group or network group. We will be working with assignment groups to ensure functionality as we design the new project.
Our group has also learned about the impact of our work culture on the use of Footprints software. In the past, many people were resistant to training on their roles, how to complete tickets correctly, and write reports. Many managers and project administrators expected to be able to create changes to their projects on the fly. The result was a system of interrelated Footprints projects that became unwieldy and complex. Projects no longer met the needs of all of the users when changes were made without looking at the overall impact. Reporting became difficult and in some cases impossible.
It is clear that we will need to adopt some key changes as we move forward in improving Footprints functionality:
- We need to manage according to assigned Footprints role designations. The more clearly defined roles will bring accountability and require that someone be assigned and trained in their roles – project administrators will be critical in managing their projects and have increased responsibility to train agents and maintain their projects.
- We need to make all business rules explicit through publication – rules that are implied are forgotten or ignored. All users of Footprints must follow established business rules and the change management process – clear and regular metrics will be critical to measure our progress in service delivery and other Footprint project deliverables.
- We will have to define escalation rules with clear service level agreements (SLAs). Each major OIT area is responsible for defining SLAs and following agreed upon escalation rules.
- Agents will need to complete tickets in detail and using the correct naming conventions as defined by business rules. At this time it appears there may be more mandatory fields implemented in the new design to help prevent incomplete tickets.
We will also recommend a 2 level governance of the Footprints application to be created in the future; the first level will be a group of project administrators led by the system administrator -they will meet frequently to ensure that all changes requested are investigated carefully. They will also assist in the training of new agents and help with the design of new projects as they are requested within Footprints. The 2 nd level of governance would likely be a variation of the current project team representing major stakeholders in the services being delivered. Their role would be more of a steering committee and guide the strategic use of the Footprints application.
The future of the Back to Zero team:
We have completed a significant learning curve and created some foundational deliverables but we are far from done. The complexity of this project will require many more months of work as we design improvements, test project concepts and help create the governance for this critical application in state government. We will be sure to update you in a few months regarding our activities.
If you have an questions about this article please contact Leigh Wilkinson at email@example.com