What is resource liquidity?
There is often a lack of depth in skills in a department. There may be only one person having the knowledge or skills required to perform a task, who thereby becomes a bottleneck. The immediate availability of a person to perform a task is the liquidity of the personnel in the group concerned. How can we use kanban to improve on the “traditional” way of managing resource liquidity?1
The measurement of liquidity is normally a ratio of certain assets to liabilities. The assets in this case are the personnel having the skills and experience necessary to the execution of the mission of the organization. The liabilities are the unfulfilled requirements of the customers to which that organization is committed, such as the need to resolve an incident, diagnose a problem, assess a change, plan for capacity, and so forth. As we shall see, the great challenges of people resource liquidity are in:
- identifying those assets (the skills and experience) in a useful way
- identifying the probable future liabilities and when they might occur
- determining how to efficiently deploy which assets to which liabilities, and when.
Top-down planning of resource liquidity
A common approach to liquidity management, what we might call the “traditional” approach, is top-down in nature. Typically, a team manager compiles a list of skills required to perform the team’s work. These skills are then mapped to the team members, sometimes associated with a skill level. The gaps are identified and a training plan is established to fill those gaps. Training could range anywhere from a formal course to an informal in-house apprenticeship, or perhaps it could combine several approaches. The presences and absences for the team members are then planned, keeping in mind the need to ensure the availability of a certain minimum headcount for each of the required skills.
This approach sounds good in theory. I call it a top-down approach, but it could just as easily be called a knee-jerk approach. Commonly, there are two modes for defining what skills are required. The first approach is to ask an extremely busy person to make a list of required skills. In the ten minutes allocated to this task, a seat of the pants estimate of what is required is generated. The second approach, sometimes in complement to the first, is to identify in the post mortem of a major incident that a certain skill was lacking and therefore should be part of the definition of the pertinent role. This approach tends to prioritize the latest and most painful episodes, rather than looking at the big picture and the overall needs.
A third approach is to base the skill list on the syllabus for a training course in the subject. I have taken many such courses and have supported many different technologies. I have always found that many of the required skills are simply not taught in the classroom.
The first difficulty, then, is in defining which skills are really required. The second difficulty is in giving priorities to those skills. The third difficulty is in the need to predict which skills may be needed in the future, especially if the mandate of a team is to be able to do whatever is necessary to keep systems running according to the expectations of the customers.
A more objective method for prioritizing skill requirements would be to track them using the tools that manage the flow of work. Later in this article, I will make a concrete proposal for achieving this. However, many of today’s commonly used tools do not provide us with the means for tracking these issues.
Ticketing tools hide resource liquidity issues
It is difficult to track the issue of resource liquidity with the traditional push-type ticketing tools used by many organizations. These tools might tell us how long a ticket stays in a queue before it is taken in hand, but they tell us nothing about why a ticket might fail to be worked on, in spite of its priority. This is especially an issue when tickets are assigned to workgroups, but not to individuals within a workgroup, as is very often the case.2 The number of times someone views a ticket in a queue, or even views the details, but does not take charge of the task remains largely invisible. Even worse are the cases where a qualified person passes over a ticket for unacceptable reasons, such as personal comfort or laziness, cases which also remain largely invisible.
In another scenario, the problem of resource liquidity might be hidden behind a series of reassignments of a ticket within a team, attempting to find a person qualified to handle to work. This may occur if the ticket is assigned to the correct workgroup, but to the wrong person within that workgroup. The ticketing tool would indicate that there was an abnormally large number of ticket reassignments, but would give no indication why. While the ticketing tool might allow the currently assigned person to enter a reason for reassigning the ticket, I have yet to see any organization that tracks this information. At best, organizations would investigate such information in a labor-intensive, manual way, as part of a process improvement initiative.
Defining core competencies
The strong risk in using a top-down approach where work is assigned using ticketing tools (or without any tools at all!), is that the lists of skills be an incomplete, seat-of-the-pants estimate strongly influenced by the most recent problems. Furthermore, in my experience, such lists tend to be highly focused on the tools being used, rather than the real business issues requiring support and solutions.
For example, an organization might face an on-going issue of poor performance of databases. Therefore, the responsible team needs to know how, taking an example, to optimize queries. But all the skill list might say is that the team needs “excellent knowledge of MySQL or Postgres”. The art and theory of optimization is relatively hard to acquire, whereas the knowledge of how to optimize using a specific tool is quite easy, once you know the theory. Be that as it may, there is a mismatch in this example of the skill required and the way the corresponding skill is listed in the personnel assessment matrix.
In another example, a team might have the issue of failing to resolve a major incident in a timely fashion. That team ends up relying on external resources for the resolution, which resources might not be as available as the team would like. In the post mortem to such cases, management often exclaims that “something must be done such that we don’t face the same problem again in the future.” So people are taken off their jobs and sent off for training, without an objective analysis of the risk of recurrence of the need. But the collective memory is marked by that incident and the skills required to resolve it because part of the core competencies, even if the underlying conditions change and those skills are no longer needed. A case of generals fighting the last war, not the next one.
At the same time, the skills that might be needed to improve the execution of common tasks—tasks that have low visibility and don’t cause a lot of pain when they are executed slowly—those skills might never be identified as part of a top-down or knee-jerk analysis.
Measuring personnel resource liquidity
From the perspective of getting work done and managing the flow of work, a key metric is to know how long, on average, work items are blocked due to insufficient resource liquidity. In other words, when a work item is ready for work but no suitable resource is immediately available to handle it, how long, on average, must you wait for the right resource?
Since this is a classic queuing issue, we might be able to get an answer using Little’s Law. According to this law, the average duration of blockage equals the average number of work items waiting for a resource divided by the average rate at which those items arrive, during a given period of time:
W = L / λ
where, in the context of personnel liquidity issues,
W = the average wait until the right resource is available
L = the average number of work items blocked due to insufficient resource liquidity
λ = the average rate at which work items become blocked due to insufficient resource liquidity
Little’s Law is particularly useful when two out of the three elements are known, making it easy to calculate the third. So, how can we find values for L and λ so that we can calculate W? It turns out, however, that W and L can be measured directly using the method proposed below.
In the following section, I propose a method to easily make these measurements. The method is also of particular value in helping to plan the acquisition of new skills in the team concerned. Furthermore, it gives us a simple means for modeling the impact in insufficient resource liquidity as the volume of work changes.
Pragmatic planning of resource liquidity using kanban3
When a team uses kanban to manage the flow of its work, it becomes much simpler to track and manage resource liquidity issues. There are two prerequisites to the approach proposed below:
- There must be space somewhere on each kanban card to capture additional information. If paper cards are used, this information could be captured on the back of cards. If an electronic system is used, it would suffice to configure the additional relevant fields associated with each card.4 It might not be a good idea to use brown “blockage” cards for this purpose, as the threshold for indicating a blockage might be quite different from the measurement of insufficient skills.
- If a physical kanban board is used, it needs a place, such as a box near the bottom, in which a periodic count of blockages could be recorded.
Here are the proposed steps:
- A team member completes a task and looks for the next work item ready to be worked on in the newly opened slot. If there are several items ready for work, which is typically the case, the prioritization rules, based on risk and cost of delay, are applied.
Fig. 3: The person looking for the next work item lacks a necessary skill for the card and notes this on the back. If the team member has the skills required to perform the selected work, the work flows on normally. However, if the person lacks the skills or experience required, this is the moment of truth. If the situation is not recorded now, it will probably never be recorded. So, a note is made on the kanban card, stating that it would have been worked on at a certain time, but for a problem of resource liquidity. Ideally, the missing skill would be noted there.
- Each time a new slot opens downstream and a team member considers the work item but does not work on it, due to the resource liquidity issue, the kanban card is again updated, until finally someone is available to do the work. If each update includes a date-time stamp, it becomes easy to measure W directly, by averaging the delay over all work items.
- When the kanban cards are removed from the kanban board, any cases of insufficient resource liquidity are aggregated on a master list. This gives a pragmatic indication of exactly which missing skills or experience are needed and how often. If the kanban board is electronic, this calculation may be made directly in the tool, based on the data recorded for each card.
Fig. 4: Missing skill data on kanban cards is periodically aggregated. - At the end of each day (or other period, as required) the total count of work items that experienced a blockage due to insufficient resource liquidity is recorded. The average of this count is then used is calculate L, the average number of blocked items in the system.
- In preparation for the monthly operations reviews, the list of skills required may be normalized and consolidated. At the review itself, the evidence of lack of resource liquidity can be brought out to justify specific training, re-organization or other expenditures. These reviews permit all lacking skills to be put in a broader context and prioritized, rather than simply reacting to isolated circumstances.
- The team leader may briefly present at a daily standup meeting the plan agreed at the operation review. The individual coaching sessions may also be used as a vehicle for getting volunteers for training and otherwise identifying solutions for increasing the team’s resource liquidity.
Inflexible strategy vs. agile operations
Some might complain that the job of defining the skills and competences of a team is part of the strategic plan of an organization. Rather than reacting to circumstances, they might say, an organization must take proactive control of its destiny and plan for it accordingly. In an ideal, unchanging world, there is merit to this thought. It is applicable principally in a green-field situation where new teams are created to support new business lines.
However, numerous factors mitigate against the strategic planning approach as an on-going means for adapting skills to needs. Strategic planners rarely work at the level of detail required. Strategy might define the need for designers, operators and support people, but it does not describe the details of the skills required. Furthermore, strategic planning tends to be slow in conception and slower to deploy, often with significant gaps between the strategic intent and the operational reality.
Instead of depending on the strategy generation and implementation cycle, the approach recommended here is to leverage an existing kanban approach to tune skills to requirements. This cycle is much shorter and much more likely to develop required skills in a quick, flexible and pragmatic way.
Leveraging kanban for resource liquidity
The approach proposed above leverages all the periodic activities that are already present in kanban.5 As a result, it adds very little overhead and is fully in the spirit of how a team using kanban already manages its work.
- updating kanban cards when an appropriate resource is not available is part of the pull activity of each team member
- readjusting work, especially when a card is blocked due to a lack of appropriate resources, is part of the daily review and unblocking activity
- analyzing the data on the cards is part of the periodic analysis performed in preparation for the operations review meeting
- making decisions about changing team composition or allocating resources for training is performed during the operations review
- organizing for the implementation of that training is part of the one-on-one coaching.
The approach thereby demonstrates the flexibility of kanban, as a method for managing work. It does so with very low overhead. It ensures that the skills required in a team are driven directly by customer needs, ensuring good alignment of skills with tasks and reduction of wasteful investment in skills that are of minor importance to a team.
People resource liquidity metrics
I referred above to liquidity being measured as a ratio of the personnel having the necessary skills and experience for a task to the number of work items that are ready to be handled. Suppose there is one task ready to be performed and there are two people available to perform that task. The liquidity for that task would be 2 (people) : 1 (task). If only one person were available, the liquidity would be 1 : 1. And if no one were immediately available, the liquidity would be 0 : 1.
This sort of metric is analogous to the metrics for financial liquidity, based on the ratio of assets to liabilities. But this financial metric is really just a proxy metric for something else, something much more interesting. It helps answer the question, “should I sell now or should I wait for more favorable circumstances?” If, for example, you were to sell shares in the stock market you might want to know how liquidity might impact the value of the shares. If there are very few buyers, meaning lower market liquidity, the price you could get might go down. This is what we really want to know, not the theoretical liquidity measurements.
But, as we saw above, what we really want to know is how resource liquidity impacts flow. We saw that that impact may be measured directly, without having to depend on a proxy measurement of liquidity. The real questions we should want to ask are of the sort, “If we spend €2’000 on training to increase liquidity, what will be the impact on flow and, consequently, the benefit of delivering work sooner. Consequently, the sort of liquidity metric described above is a curiosity still looking for a practical application in resource management.
Liquidity is more than just developing skills
One drawback of the top-down approach to liquidity management is that it says nothing about managing liquidity on a case by case basis. It is one thing to ensure that a team has the right combination of skills for its mission. It is quite a different thing to effectively deploy those skills in a flexible, indeed, in a liquid, way. Think of the current tragedy in the world where enough food is produced globally to feed everyone, and yet many still starve or are malnourished, because the logistics of getting that food to the people who need it is not well mastered.
There are various scenarios that show how different approaches to deploying skills impacts resource liquidity.
- The “it’s not my job” syndrome
In this scenario, people might have the skills needed to do some work, but they do not get involved because that work is not part of their job description. Everyone is expected to do their own jobs. Period. - The “everyone works independently” syndrome
In this scenario, people do not readily exchange information about what they are doing. Asking someone for help is thought of as an admission of weakness or incompetence. Or, in any case, you don’t want to bother others with your problems. They have their own work to do. - The “work in pairs” approach
The first two syndromes may be mitigated by pairing people in their work. Increasingly found in the software development world, paired resources remain quite rare in operations, probably because of the perception of it being an inefficient way to allocate your scarce resources. - The “kanban unblocking” approach
Kanban actively fosters collaboration to unblock work items that do not progress in a timely manner. It encourages the temporary reallocation of resources, especially when there is a resource bottleneck that needs to be protected. Is it better to wait until customers or top management complains, when resource liquidity is too low, or is it better to have a system like kanban, that facilitates liquidity on a timely basis?
In summary, the traditional approach to resource liquidity management does a seat of the pants, hit or miss, job in identifying the required assets. It reacts to past liabilities, rather than assessing the risks of future liabilities. When coupled with a traditional push ticketing system, it ignores what is likely to happen in the future, focusing only on the current open issues that cause pain. In contrast, the kanban approach can use objective data to identify how asset requirements evolve. It can provide a systematic way of identifying resource gaps and of identifying the granular needs to improve skills. It uses opportunity cost and cost of delay analysis to manage the risks of future liabilities. And it uses the highly efficient, customer-aligned pull approach to deploying resources to doing work.
The article Managing People Resource Liquidity by Robert S. Falkowitz, including all its contents, is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.
1The concept of resource liquidity, as applied to people, is obviously taken over from the issue of liquidity as applied to a company’s treasury. In addition to the questions of its profitability and the value of its assets, a company also needs cash on hand to pay its bills, when due. Similarly, the liquidity of an investment is a measure of how easily that investment may be negotiated for cash. In accounting terms, liquidity is normally measured as the ratio of liquid assets to liabilities. But in a service system, we cannot liquidate the human assets in order to meet current requirements. So a better analogy would be the ratio of the operation cash flow to the liabilities.
2Do not mistake my intention. I am not recommending that tickets be assigned directly to individuals, rather than to workgroups.
3I am assuming that that reader already has a basic understanding of how kanban works, so I do not go into those details here. For a general overview of kanban, as used in IT work, see the reference in the last note, below.
4Since the relation of a work item to the cases of insufficient resource liquidity could be one to many, a table of blockage instances would be required, which requirement might not be easily fulfilled in certain tools.
5For an overview of these cyclic activities in kanban, it is best to go straight to the source. See David Anderson’s book KANBAN. Successful Evolutionary Change for Your Technology Business.
Fantastic article Robert and there are some good aspects for my team when we implement Kanban in the next weeks. I will forward and discuss with my management.
I hope it was ok too share the link over Linkedin because I think a lot of companies and guys in NZ and AUS will like that article too.
General Robert thanks again to be a contact from you and I am really enjoy your article what help me to get a better ITSM guy.
Cheers
Frank
Frank, consider having your team master the basics of kanban before trying to manage resource liquidity.
Robert, thanks, excellent artice. We currently use adopted Kanban for daily activities like workload and quality management as wall as for customer communications management inside development and operation stages. Your view will help to go deeply.
Good idea this one related with taking notes about lack of skills into a ticketing system, but I wonder if this idea could be applied only to mature organizations because of the level of responsibility inherited to people. Thks!
I agree that the concept, like the kanban approach in general, depends on a certain level of empowerment of the teams involved – which is not the same, for me, as maturity. That being said, I don’t see how it requires much maturity to follow the instruction: “When you look in the queue for the next task to perform, if there is a task that you should perform because it has the highest priority among the ready tasks, but you lack the skills to perform it, than note that information on the ticket or kanban card.”