Applying Kanban to IT Processes

What is Kanban?

Kanban is a Japanese term for 'visual board' or 'signboard' and is a tool for reducing the cycle time¹ of a process, increasing visibility into the flow of processes, and reducing the amount of In Process² work. By leveraging the visibility into the process and flow between processes we can see where the work flow loses momentum and either bottlenecks or reduces the effectiveness of earlier steps. Kanban is used in Lean Manufacturing to gain visibility into the process and execution status, reduce wastes (and costs), and help achieve Just In Time production capability.

1. Cycle Time: The time it takes for an order to be produced from initial reception through completion
2. [Work] In Process: Incomplete products that are currently being worked on in the process or are waiting to re-enter the process and be completed. Unfinished work.

The Kanban Signal

At it's most basic, Kanban is a signaling system that tells earlier steps in a production process that there is a requirement or customer demand to make X.

In a manufacturing process a customer order is converted into one or more cards that represent the production requirement to fulfill the order. Each card or symbol defines the product to be produced and quantity needed. The card is given to the associate responsible for managing the work center that will fulfill the production request. If the associate has a local sign or visual board to display the orders queue or available capacity, they will place the received card in the next empty slot, otherwise they update the board for the area. Depending on the complexity of the process, the receipt or execution of the Kanban signal may trigger additional signals back to prior steps in the process or to personnel responsible for bringing the correct materials to the production step. Each step has a limited number of slots on their board that defines the maximum number of cards that can be present at a given point in time. This Kanban limit keeps the amount of work and in process items constrained and prevents incomplete work or requests from piling up.

Limiting the amount of in process work to a small, maintainable number allows us to continue to fully utilize our resources (in this case machinery and operators) while reducing the amount of work that is partially completed and waiting to be finished. The application of Kanban limits to a process helps us start reducing the variability in the duration of producing a product, as well as remove the necessity (and temptation) to reschedule the flow or priority of work at each individual step. Though this may seem like it would slow response times when a priority order comes in, this actually speeds up processing because we don't have to rearrange our resources to drop 47 outstanding, partially started tasks. We simply slot the priority order into the queue at the last step (when a spot is available) and let the signal flow back through the previous steps in a standard fashion. Since we have a limited amount of work in progress already, we are able to handle new requests quickly without interrupting items we have already promised.

By removing backlogged queues and re-prioritization between each step we have reduced the amount of non-value added work the operators are doing and improved both the accuracy and (usually) the duration of the time estimates we are giving the customer. We also reduce the number of changeovers that occur because we complete each task before moving to the next one, instead of switching back and forth between several outstanding orders. The removal of unnecessary changeovers are an immediate cost savings because they are of no direct value to the customer while the decrease in lead times improves our responsiveness to the end customer and reduced changeovers and rework increases our capacity without additional expense.

Visualization and Metrics

Visualizing the requests at each 'station' using a physical board is a good way to communicate across the group and manage your Kanban. If your board only has 3 physical areas or slots for 'cards' then your not going to take more than 3 requests. People at later and earlier steps can see progress being made as well as excess capacity (ie, nothing to do) at your step. The board is not only a method to manage your tasks but also an instant communications tool, allowing the area to focus more on doing the work and less on creating reports or filling in metric scorecards.

Finishing 2 Units/Day - ~14 days to produce new order

Another major benefit from Kanban methods will become apparent as the initial visual board is created. Besides driving the creation of a clear definition of the operations or production steps, the initial population of the board with current requests and WIP will start to make process bottlenecks evident. As time progresses and the kanban system forces you to reduce this backlog, the bottlenecks will continue to become more obvious, showing areas where direct improvement will affect the delivery time for the whole process. In many systems, when a previous step goes dry in a Kanban system the personnel from that step will start to move forward to help product clear the backlogged step. Simple rules or rearrangement of current staff can continue to give performance gains, as the board displays where slowdowns and hiccups occur as well as potential areas that are frequently left without work.

Finishing 2 Units/Day - ~5 days to produce new order

The manufacturing community has hundreds of examples of visual boards, but for the purpose of the article I'm going to point out a couple links from Agile software development articles. Kanban boards do not have to be expensive and, in my opinion, should always start out as a physical board before diving into a software solution (if ever).

• "Lean -Software Development in Small Teams" Article - Whiteboard and Magnets
• "Evolution of a Kanban Board" Article - Whiteboard and Post-Its &tm;
• "Visualizing Agile Projects with Kanban Boards" Article - Several pictures and informative article
• "The Kanban Story - Kanban Board" Article - Final (Simple!) Result for another software development board

Searching the internet will give you many additional examples in a variety of environments.

Applying Kanban to the IT Department

Now that we have an idea how Kanban works, we can begin exploring how to apply it to processes in IT administrative, support, and development environments. Initially the idea of applying Kanban in a non-manufacturing environment may seem challenging, so the examples will cover a wide range of possible situations. By exploring several sample implementations we can gain insight or ideas on how to apply these concepts (and see the resulting benefits) in our own individual IT environments.

Welcome to ABC Corp's Help Desk

This story follows the fictional help desk group for ABC Corp as they implement a Kanban system to define and improve their processes. The details of their process, decisions that are made throughout the story, and methods used to communicate and measure their goals, should be treated as examples and not rules. While some groups can make a one-step leap from their current process to using Kanban, this type of instant transformation is risky, especially if the group doesn't have a realistic and well-defined process.

Late Last Year

Last year the IT Department at ABC Corp became understaffed and started to fall behind on their tasks. Financial pressure convinced the company to delay replacement hiring for several months. Despite the best efforts of the support group, the group started to fall behind on help tickets. Through hard work and overtime the team managed to get the extra work under control and stopped falling behind, but the average amount of time between a request coming in and the task being completed continued to be measured in weeks. Increased numbers of status requests and tasks meant that people were often 'working' on ten to fifteen task simultaneously, even basic tasks like connecting new phones or ordering new equipment were being juggled with so many other tasks that the end users felt that the IT Department just didn't care about their problems.

Current State

It's now several months later. ABC Corp found some valuable replacements and the overtime has started to come back down. Members of the IT Department are returning to regular schedules and there is a sense of pride in how well they were able to hang on. Unfortunately that sense of pride doesn't reach outside the walls of IT, where the users have seen a very different picture. The end users still believe the IT Department takes too long to deliver because 'not falling behind' is different from 'same day delivery' and the executive team is questioning whether hiring the replacements was effective or even necessary, as they don't see improvements in delivery times or performance. Because ABC Corp has a good team, they will probably regain their reputation, the task completion times will come down a bit, the users will start to forget that bad period, and the executives might even see that bringing replacements on board helped the performance of the team. Being students of improvement, though, we can't allow the team to settle for 'not as late as it could have been' or 'not as bad as it was'.

Defining Current State

Before attempting to improve the process, we need to know what the process is and determine how it operates. Our initial focus will be to define how the departments process currently works, including the steps they follow while completing work and what the unit of 'work' actually is. At this stage we are not trying to figure out how to solve their problems or where the bottlenecks are, we're simply trying to describe and define the process and tasks. From the beginning, we are going to include members of the team and people in supervisory roles, so that we can be sure we get an accurate picture of the process.

After analyzing processes with the group, we have found that:
ABC Corp accepts customer requests from several different avenues, including email, telephone, walk-ups, and the web-based task system. Once these are received, one of three things happens, either the request is entered into the task system, the person taking the call/email/etc begins executing it right away, or it is recorded in a temporary fashion (sticky note, email client to do list). When a task is completed, there is no defined follow-up process to ensure it met the requestors needs, nor is time taken to enter the task into the system if it had not already been entered.

Visual Board I

After defining the processes with the team, we have enough information to put together our first visual board. Based on our findings above, we know there are already a number of processes people follow, so we want to make this one as simple as possible to begin with. Our initial goals are to get people to start using this new process and to get people comfortable with it. If we try to make a new process that solves all problems and provides numerous levels of reporting, we will end up with something like the computer system that is already in place and obviously not in consistent use. By starting off simply, we can evolve the board and new process to better fit the team's needs, rather than trying to create a detail process and then bend the environment to that process.

In the spirit of keeping it simple, we have put together our first Kanban Board by using a whiteboard, some tape, and some sticky notes.

ABC Corp's first visual board - complete with current task sticky notes

Creating a Request

When a team member receives a new request, they are to fill out a sticky note and place it in the 'Pending Work' queue. A sample note is posted by the board, along with several stacks of empty notes and writing implements. The sample note has fields for the name of the requestor, the date the task was received, the person that took the request, and a very short description of the request or task. We now have enough information to keep tasks separate on the board, determine how long it took to complete them, find the correct person, if we have questions about the original request, and communicate with the end user about their request. The whole process should take less than a minute and the entry method (sticky note) is simple enough that it can be done while talking to the requestor.

Executing a Request

When a team member starts working on a request they move the corresponding sticky note from the 'Pending Work' column to the 'Working' Column. Each member of the team has a swimlane on the board to keep the notes organized and so it is obvious who is currently working on a given task. Once the task is completed, it is moved to the 'Pending Feedback' column to indicate that the team member is trying to contact the end user to ensure they are satisfied or to walk them through new changes or instructions. Once that has been done, the task is moved to the 'Completed' column. When the end user is present for the tasks, such as installing software or setting up a projector, a task may go directly from the 'Working' column to the 'Completed' column. When a team member completes a task, they enter the completed date on the task note.

Now we spend some time getting our team used to this new process. Each day we check the board in the morning and in the afternoon so we can keep track of how the team is doing and see if anyone needs assistance in using the board (or perhaps less passively going around and reminding people to use the board). At the end of the week, collect the tasks from the 'Completed' column and enter the start and end dates in a spreadsheet. By clearing the 'Completed' tasks section at a regularly defined interval, we also give the team a visual measurement or goal for the week.

Process Changes and Kanban Limits

After several weeks of using the board, we have brought the team together to review people's reactions and start working on the next steps. By now the team has gotten used to the process and should be using it consistently. The team has started making the board their first stop when looking for new tasks or answering an end-users question on the status of a request and the starting and completion dates are starting to build a picture of the current delivery times.

Up until now the purpose has been to get the team used to the board and we haven't put any limits on how tasks are selected, how many someone should be working on at once, etc. This has helped the team engage and helped visualize our current situation, but that visualization is a mess. It's a good time to start improving the board and introduce improvements to the process.

Revising the Process Steps

After talking to the team and reviewing the task notes on our current board, the team has decided to modify the board by adding an area for 'Escalated Tasks'. This modification was an idea from one of the team members to help us better track tasks that have been escalated to the Systems Administrators and Development groups so they don't take up space in the 'Executing' column - we do not want to lose them by taking them off the board entirely. For the ABC Corp team, this request makes sense, so we add it to the board.

ABC Corp's visual board with new escalation step

Kanban Limits

One of the important attributes of a Kanban board is the idea of limiting the amount of work in process. In a manufacturing environment, we could use the equipment capacities to help us calculate some viable numbers for each process step, but in our IT Environment we don't have anything that obvious. We could spend weeks trying to come up with equations or perfect numbers, but instead we are going to just pick some arbitrary numbers based on the number of people we have. If the numbers don't work perfectly, then we can adjust them a little later and experiment to find a more comfortable set.

We will also assign each member of the group a "home" column. These 'home' columns are where people will primarily work. Because the Kanban limits enforce a maximum number of tasks allowed in each process step, there are going to be times when entire sections of the board come to a halt. For instance, if the person responsible for our "Pending Feedback" column gets overloaded or is out sick, the entire department will deadlock because the 'Pending Feedback' column is full. When this happens then people will start to move forward from their home column to help clear the bottlenecks.

ABC Corp's visual board with defined limits

Executing Tasks

The last change to our process is going to be how we assign tasks and how they move across the board. Until now, we have not put any restrictions on how or when people select tasks to work on, or how to prioritize new tasks. One of the important concepts of Kanban is to pull tasks or solutions through the process instead of pushing them. At each step our team members will pick up a task from the previous step to work on and they will only do so within the limits placed on their work area or column. To help identify tasks that are ready to be picked up, we have added a shaded area to each column. For the 'Pending Work' column, the shaded area holds the next several prioritized tasks, for the rest of the columns it serves as a 'Completed' area.

Completed tasks still count against the limits assigned to each column, so if part of the process breaks down, then the task flow will slowly turn into a traffic jam. As team members earlier in the process fill their column, they should move forward to help clear the problem. This ensures that when a complex situation arises, it is dealt with immediately instead of being allowed to sit on the sidelines. This also ensures that even the worst situations are completed in a more timely manner and that delivery times are constantly improved.

Final Analysis

The team has a made a number of gains through this new process, which has also opened the door to continuing improvements and opportunities for good press inside the company.

Process Flow

Initially people worked on numerous tasks at once, splitting attention and losing time as they switched back and forth. With no prioritization there was no guarantee on when a task would be picked up by a team member and tasks could even be misplaced or forgotten altogether. Communications to the end user was inconsistent and escalated tasks were rarely communicated or tracked, while complex solutions were usually not explained and generated additional tasks to complete.

ABC Corp's visual board as time progresses

One member of the team has been assigned to manage end user communications. That team member is responsible for following back up with end users, checking on the status of escalated tasks, answering requests for status updates for pending tasks, and walking users through complex changes or solutions. New tasks are prioritized based on severity level and length of time in the queue and wait in a queue for the next available technician to pick them up. Team members focus on executing a single task at a time and when completed, immediately pass their task on for reporting and select the next highest prioritized task from the pending queue. A distribution is calculated each week of how many days elapsed between task reception and completion and this number serves as a team measurement and source for weekly goals.

The team is gaining on their pending tasks through fewer interruptions, fewer costly attention-switches, and being able to focus a team member on end user communications. End users are receiving more regular communications and time estimates are both firmer and more accurate. Reports to the executives show the number of outstanding tasks shrinking while the total time between reception of tasks and completion has been reduced in variability and duration. T

Achievements

Here are some of the achievements:

• Measurable Results - We have reduced the amount of time between receiving and completing tasks, and for the next several months that duration will continue to shorten until the backlog has been worked through and we find our new pace
• Measurable Improvements - We not only have measured results but we took a baseline before changing the process, which means we now have hard numbers on how far we have improved
• Status at a Glance - The visual board serves as a way to quickly gauge the status of the department, potential problems, and overall work flow or rhythm
• Department Goals - Hard measurements on delivery times serve as a good key indicator of how well the department is performing and provide an excellent measurement for annual goals
• Tighter Estimates - More data and a smoother process has reduced variation in completion times and allows task estimation to be much more accurate
• Morale - Engaging the team members in defining their own process, trying ideas they bring to the table, and allowing them to experiment are all going to raise both morale and respect, which ultimately raises productivity, reduces turnover, and makes the workplace a much more enjoyable place
• Higher Productivity - Work is now being executed more effectively due to reducing the amount of task switching, hunting for information, interruptions for status updates, and lack of prioritization

The advantages above are direct advantages of applying Kanban in a general environment. In the case of ABC Corp, we could probably add several more gains that were more specific to their environment, had they not been a fictional company. Perhaps the biggest gain is that the department now runs from a whiteboard. Someone recently commented that whiteboards, by their nature, invite people to write on them or try and change their content, whereas printed paper has a read-only connotation. How is that relevant? No process is perfect and a process set in stone is a process that is not growing to meet the needs of their company better. By engaging the team members, experimenting, and defining the process on a changeable medium there is encouragement to continue to offer suggestions and to continue and try to improve the process and department.

Welcome to DEF's Annual PC Deployment

DEF Inc is a small to medium company with roughly 1000 PCs and laptops actively deployed. Their IT group works like most groups this size, with a high level of individual management, strong team ties, and a relatively small number of IT personnel covering a wide variety of roles. Of the 15 active IT people, only 2 will be working on the PC deployment, and they have been given a high level of latitude in creating a process to get the work done. Clear, simple reporting of progress and successes is determined to be a requirement by the team, to prevent their hard work from being an invisible project. Finally, there is limited space for undeployed systems, so the team will need to carefully manage the number of undeployed systems and purchase orders for new systems.

The Equipment and Tasks

The annual PC deployment is expected to account for the following equipment:

• 160 new PCs to be deployed
• 40 new laptops to be deployed
• 120 PCs and 10 laptops to be refreshed and redeployed

Software imaging is available to install a base operating system and set of drivers on each PC, reducing the variability in initial install process. Tasks like domain registration, utility software, office software, and IT software installations will be standard for every system, but there will also be some customized software installation based on the final user or area the equipment will be assigned to. Refreshing an existing PC requires the same steps with the addition of an extra task in the audit system to link the old and new use of the system. Based on stories from prior years it is clear that one of the most disruptive issues was when a system required *rework due to a missing software installation or configuration, so the team decides to add some verifications to the process to limit opportunities to miss software installs or configurations.

First Visual Board

After discussing the requirements and steps in the process, the technicians have created a common process for all equipment:

• Receiving - New equipment and equipment for re-deployment that has not yet been 'tagged'
• Inventory - New equipment and equipment for re-deployment that has a 'tag' applied
• Imaging - Applying basic OS, driver, and software images to the systems
• Customization Analysis - Building a list of customer software and/or settings for the intended end-user
• Office Software - Installation and initial configuration of office software and company templates
  
• IT Software and Utilities - Installation of a standard set of utilities and IT software for troubleshooting and auditing
• Custom Installation - Installing and applying custom configurations
• Audit - Running the first Audit of a PC and linking assignments for re-deployed PCs
• Deployment - deploying the hardware to the end user

To manage PCs through this process, the team has invented a system of 'tagging' the equipment. The technicians have designed a combination check-list and worksheet that is copied and filled out for each PC. The top corner of the document becomes the Kanban card, while the rest serves as a checklist that will be used to verify the previous step of each deployment stage as the equipment progresses through the process. In prior years the team determined there was an average of 5% rework required to correct missing configurations or software.

Example worksheet with cut-out for Kanban card

Rather than putting a QA step at the end of their deployment process, they have chosen to start each step by verifying the task from the previous step. By verifying sooner they hope to prevent the need for a long QA process, reduce the amount of rework, and catch and correct issues earlier to prevent repetition of later tasks (such as running the audit software). Check boxes for 'execute' and 'verify' are available for each line on the tag.

Now that the tasks have been defined, the first visual board is put together using tape and labels on a corkboard. Thumbtacks will be used to attach the Kanban cards for each piece of equipment to the appropriate step on the board.

Kanban board with some example cards on it

The Kanban limits at each stage are based on the available workspace and the desire to keep equipment flowing regularly through the processes. The team has decided that to balance between consistent flow (small limits) and the additional effectiveness of running installers in parallel (larger limits), they will define limits based on the length of the software installs in order to ensure the longest steps also have the highest throughput and don't become delays for later steps. Imaging, office software, and auditing require little human involvement but large amounts of time, while Customization Analysis, Deployment, and the remaining two software installation steps require higher levels of interaction and attention from the installer.

Creating a Report

There are a number of requirements and factors available to report on with this process. Based on the requirements and expressed wishes of the IT Manager, the team produces the following list of items to report on:

• Progress - based on the concept of a burndown chart, the Progress chart displays actual progress and a projected completion date
• Inventory to Deployment - a simple graph to show the actual deployment times against the averages and range from prior years
• User Satisfaction - A pair of horizontal bars that display successful delivery to promise date and number of incomplete deployments (rework)

Spreadsheet and Charts for Weekly Report

Generating the report will require updating the spreadsheet at the end of each week with the number of actual PCs completed, incrementing the total amount in a second cell (if any occurred), and indicating the number of PCs that did not meet their target delivery date in a third cell. The projections automatically update based on an equation in the spreadsheet and the information is reflected in the charts. A few simple copy and paste operations places the graphs in last weeks document and the new weekly report is done.

Final Analysis

During the execution of the deployment process the team tweaked the Kanban limits a little and made minor changes to the reporting mechanism, but did not have any large changes to make to their process. Given the transparency of the work, they were able to stay on track and deploy equipment at a regular pace. As they adjusted to the rhythm of the process they were able to start timing new PC orders to coincide better with inventory depletion, allowing them to increase their order size and take advantage of improved quotes on the equipment without running out of work in between orders. A final report was created with the final charts from the weekly reports and additional information on spending and labor reductions.

Process Flow

New and re-purposed equipment was assigned a user and tagged prior to any work taking place. This prevented issues that had occurred in prior years, such as mis-assignments, double assignments, and re-assignments with the wrong software. The process also provided an accurate inventory of available equipment at all times, so that questions could be answered immediately rather than requiring someone to go to the work area and perform an inventory. Early communications with the end user on when the equipment would be available reduced the difficulty of deploying the PCs when they were completed, as end users had earlier warning and could help better define their availability, with the secondary result of fewer rescheduled installations compared to prior years. Immediate verification of prior steps and Kanban limits ensured that equipment flowed smoothly through the process, providing the bases for more consistent and repeatable cycle times. Better estimation of the deployment process time (inventory space availability) allowed for direct budget savings by allowing the team to increase the size of their orders and take advantage of better savings for the same amount of equipment. And finally, the reporting mechanism the team created was simple enough that the IT manager was able to use it in departmental meetings as part of the overall IT status report, without staying any later the night before the meeting.

Achievements

Here are some of the achievements:

• 100% Visibility - Visibility into the process and inventory at all times with no additional effort spent on tracking down technicians or counting hardware on the fly
• Improved Morale - Reduced confusion and negativity from the end-users around the assignment process based on clearer communications and assignment process
• Time Savings - no rework meant time savings in the deployment process as well as removing the interruptions that rework caused
• Financial Savings - better inventory estimation and management allowed for larger order sizes and better savings without impacting completion times
• Good Marketing, Cheap - the simple process of creating reports not only saved time but also produced simple enough metrics that they could be re-used at management meetings for additional positive press without requiring additional time and effort from the IT manager
• Higher Productivity - Based on process consistency, estimation improvements, and reduction of the interruption level of prior years, the overall process took fewer labor hours to complete
• Measurable Improvement - Due to careful tracking, the same statistics tracked during the process execution can be reported at the end of the year as department and personal improvements

The achievements listed here range from hard (financial) to soft (morale) and likely do not cover all of the achievements that would have occurred in a non-fictional version of this story. In a nutshell, the process was able to run more smoothly, more effectively, and more predictably, and that gave the team a number of measurable improvements over prior years. This same process will be re-usable in future years, and can be used as a foundation for further improvement or allow the improvement efforts to focus on other processes while this one simply runs smoothly forward. While using a Kanban system for a temporary process is not a common application, it shows another angle on how it can be used to tame complex work processes and help drive overall improvement of the process.

Next Week

In the next article we will explore the usage of Kanban by a software development team as they seek to deliver and maintain a set of products. While there are already many non-fictional accounts of people applying Kanban to the software development process, development is a notable piece of the IT Department and I would be remiss if I did not provide my own spin on how Kanban can be utilized by a development team.

(From blogs.lessthandot.com)