CHAPTER 11
Work Tracking
In a project, you plan and track your work using tools like the WBS and the project schedule. It is straightforward to track the work performed, because it is simply a matter of checking off tasks as completed in your WBS. As time goes on, you may be adding additional tasks due to new knowledge, but overall you know what remains to complete in order to finish the project.
Maintenance is different, as this book has demonstrated. When you start the maintenance effort, you can categorize the activities to be performed in an SBS, but you can neither quantify how many activities there will be nor determine when they will need to be completed. You will need a different approach than using a WBS or even an SBS for tracking work completed.
But first, why is it important to track work in a maintenance team environment? Isn’t a satisfied customer good enough?
My Story
Many years ago, when I took over my first maintenance team, I thought I was proactively competent. After figuring out what services the team delivered for a variety of systems, I contacted my boss, customers, and the IT financial tracking team to see what information they would need on a routine basis. Then we instituted a manual process for tracking just this needed information. Everything was covered—until my boss asked for some data that I wasn’t tracking, which was time spent on a specific activity. He wasn’t interested in hearing about how proactive I had been previously. He just wanted the data. So the team dug through multiple sources to come up with generally correct information. We delivered what the boss wanted but at the expense of not performing other work for the customer.
I made two fundamental mistakes. First, I assumed that stake-holders would know what they would need in the future. This is an unreasonable assumption in our ever-changing business environment. Business changes too rapidly, and we all have to be ready to support new business needs.
Second, I set things up so that I would deliver information only about the current status. I did not set up overarching metrics and trending that could provide vital information on inefficiencies or problem areas. This type of information could have driven insight into areas to improve. Continuous improvement should have been my goal. But when only limited information is available on the maintenance process, inefficiencies and problems will be obscured, preventing anyone from making informed, intelligent decisions.
What to Track
So what should a maintenance team track?
Everything!
You may be thinking, “That’s a daunting command. But are we just talking about metrics?” Metrics are important, and are covered in Chapter 15, “Metrics—Overall Control,” but what we are talking about is the information that feeds most of the metrics. To use a project analogy, Earned Value is a metric. But who actually completed the specific tasks, and were the tasks completed on time? This is the information embedded in the project schedule. This chapter presents a method of easily tracking this type of information, and the method is easier than how Earned Value is tracked for projects.
Tracking everything may seem like an unreasonable challenge due to the variety of work types that the maintenance team performs. Tracking all the questions, requests, defects, enhancements, and migrations can be an overwhelming nightmare. Each type can have different attributes.
But what typically causes the maintenance team problems—not being able to predict user request demand—actually is an advantage that we can exploit. We know the categories of all the work. So tracking by category and using attributes that are common to all categories is straightforward and actually easier than tracking a project’s unique tasks.
Over time, the Work Tracking Tool becomes an invaluable knowledge database that provides a view into what work the maintenance team performs.
Work Tracking Design
We begin our design of work tracking by presenting the work-flow process. This creates a picture of how work enters the process and progresses through different states (statuses) until it is marked complete. Then we will discuss all the types of work we need to track. Lastly, we will cover the fields we need to track for each type of work.
Chapter 4, “Scope of Maintenance,” presented the Maintenance Machine and showed how the maintenance process works at a high level. Figure 11-1 shows a sample workflow tracking process from request (or creation) to completion. Use this as a sample when designing your workflow process.
Figure 11-1: Workflow Tracking Process
The workflow shows eight statuses. The statuses and their distinct meanings are:
• NEW = Work entered into the system as new ticket but not assigned yet
• ANALYSIS = Coding Work assigned to investigate and estimate
• PERFORM = Non-coding Work assigned and authorized to complete
• CODE = Work is about to be or is currently being programmed
• TEST = Work is about to be or is currently being tested
• MIGRATE = Work is about to be or is currently being migrated
• CANCEL = Work was not approved
• COMPLETE = Work is finished and ticket is closed
The number of statuses and steps in the workflow can be more or less than shown in this sample. You may want to add more statuses to reflect the multiple levels of testing or multiple analysis steps. But there is a need to balance the amount of statuses with the complexity of steps your team will have to follow. If the process is too complicated, your team will inevitably find shortcuts, making the information inaccurate and thus degrading the information’s usefulness to you.
The workflow process in Figure 11-1 starts by showing two ways to enter the process. We typically think of the user contact as starting the process, which is very often the case. But the process can also be started because of something the maintenance team itself found or is doing simply as part of its normal work.
When the process is started, a record is created in the system, which we are calling a ticket. You can refer to this ticket as an incident, a Service Investigation Request (SIR), or whatever makes sense in your environment. It doesn’t matter what it’s called, but in this book we call it a ticket.
The newly created ticket will have the status of NEW and will remain in that status until the ticket is assigned to a team member by the manager or team lead responsible for assignments. If the ticket is an enhancement request or a defect-fix request, the act of assigning constitutes an approval to investigate and estimate. The status would then be set to ANALYSIS.
If the ticket is a data change or fix request, the act of assigning constitutes an approval to make the change. If the ticket is just a question or pre-approved system administration change, the person who received the request will just address the question or make the administration change immediately without having it assigned to him or needing any other approval.
The path through the process is simpler for tickets that do not require code changes. When this type of ticket is complete, it can be closed and the status changed to COMPLETE. The procedure that you write to govern this process should specify what could take this path and what the team member is pre-authorized to perform without seeking approval. For some types of requests, you may want to add an approval step in the flow before proceeding.
The path for code changes is more complex because of the amount of work that needs to be performed. After the analysis of the ticket is finished, approval will be needed to actually make the change. This approval step most likely will involve the maintenance team manager and the business owner. This should be specified in the procedure governing this process. The ticket can be approved, sent back to the team member for more analysis, or canceled. If it is canceled, the requestor should be promptly notified of the decision and the reason for it.
Note that we don’t have a separate status to indicate that the analysis is complete. Such a status would add greater clarity to the process but would also add more complexity for the team member to follow, so we chose to keep it simpler.
When a code request ticket is approved, the ticket will propagate through the development cycle, starting with coding. The team member will change the ticket status to CODE. When the coding is finished, the ticket will go into testing with a ticket status of TEST. If testing fails, the status can remain as TEST but any corrections will have to be coded. When testing is finished and signed off on, the ticket will be migrated into production with a ticket status of MIGRATE.
A beneficial practice is to bundle many changes into one migration; an individual ticket thus may stay in the MIGRATE status for a while. To keep track of the migration grouping, a separate migration ticket can be created in the Work Tracking Tool and can reference the code request tickets that will be included. When the migration is successfully finished, all of the tickets are closed with a status of COMPLETE.
With this process in place, what should we track? What do we mean by “everything”? The following ticket types are the maintenance team activities that should be tracked as tickets in the process just presented:
• Calls with Basic Questions
• System Administration Changes
• Data Fixes or Changes
• Preventive Maintenance Tasks
• Performance Tuning Changes
• Defects and Production Incidents with Their Fixes
• Enhancement Requests
• Vendor Release Changes
• Migrations
• Disaster Recovery Drills
• General Maintenance Issues
The last part of the design to consider is the type of information that should be kept for each ticket. The following fields are recommended for each ticket (record)—the list applies to all of the different ticket types (some fields do not apply to all ticket types and should be left blank):
• Ticket Number (system-generated as a reference)
• Ticket Type (Defects, Enhancement, Sys Admin)
• System Component Involved
• Status (NEW, ANALYSIS, PERFORM, CODE, TEST, MIGRATE, CANCEL, COMPLETE)
• Assigned to Person
• Short Description (40 characters)
• Long Description
• Working Notes
• Date Entered
• Date Completed or Canceled
Implementing Work Tracking
We have defined the Workflow Tracking Process, the types of work to capture, and the fields for each type. So how do you build this? Programming your Work Tracking Tool using your favorite programming language is not recommended. There are too many standard tools in the industry that can quickly produce an easy-to-maintain system.
The obvious choice for implementing a Workflow Tracking Process is to use a traditional database provided by one of the popular vendors. Using your company’s standard database, when you have someone on your team who knows how to use it, is a good decision.
Vendor-supplied testing tools can also provide a solution for work tracking. Even though these tools are focused on tracking defects, the principles are the same for tracking tickets. Using them instead of a database would be an advantage—if your team is already using one.
Using a spreadsheet as your Work Tracking Tool most likely would be too limiting. The database or tool you use for tracking must be workable for the volume of data and the number of people accessing it. If these needs are met, any tool should work.
When you have defined your workflow process and have the system up and running, it will be time to draft the procedures that your team will need to follow. The content in this chapter, such as what to track, recommended fields, and workflow, should expedite the drafting of the procedure. Lastly, you will need to provide training to your team on the workflow process and procedure, and clearly explain your expectations. The value of setting up a Work Tracking Tool is diminished if team members do not follow the process.
Providing Work Tracking Access to the Users
With the information that can be harvested from the Work Tracking Tool, it will be easy for you, the maintenance manager, to slice and dice the data to answer questions on how your Maintenance Machine is performing and what improvements may be needed. What your team really is working on will become apparent. This information can easily flow into fast, accurate status reporting.
You can even open up access to your key users so they can look themselves at current statuses of tickets they are most interested in. You can set this up by providing a web portal into the Work Tracking Tool. Besides seeing the statuses, “Working Notes,” and overall metrics, they would be able to create new tickets, which can save time for your team.
We created such a web portal for the key users to access. I convinced my team that if it kept tickets updated, I would try to convince the business users to check the system for status instead of calling us to see how the work was progressing. This approach worked. Users got accustomed to checking the web page for statuses. When they saw that the status was relatively current and read what was being performed, they were satisfied that we were not ignoring their request, so they did not feel the need to call. The team thus had more time to perform productive work. The users were happy, the team was happy, and I was happy. A classic win-win-win strategy.