How to Organize Resource Management in IT Projects
I am often requested by clients to build a resource management capability as part of a project to implement PMS on the Jira platform and beyond. I believe that implementing resource planning is challenging, so if resources are not the priority bottleneck in the organizational project management, then it is better not to start with it. But if you understand that this is becoming a priority for you, I advise you to approach the resource management implementation as carefully as possible. And since I didn’t meet so many sensible and comprehensive materials on this topic, I decided to present my approach in this article.
Resource management is a process that includes planning and accounting for the time of personnel required to complete a specific job, based on information about the qualifications of personnel and the degree of their involvement in a particular project.
Workload can be both operational (for example, technical support) and project (limited in time or one-time work) or aimed at point development (that is, on specific tasks related to growth and innovation). When planning resources, it is necessary to consider all of these components.
When resource management becomes particularly relevant:
1) when a company experiences a shortage of resources due to their lack, the duration of aquisition and their inefficient use is too expensive;
2) when we can plan and consider all the activities in which the employee is involved. And here, it is essential to determine the scope of the process implementation. We will be unable to plan resources if we do not consider all the sources of an employee’s workload (for example, his current support activities) and do not understand how much time he needs to complete one or another stage of work.
I want to emphasize that a person responsible for planning and accounting for resources should be allocated in a company or division. This is especially important in case it is required to manage large pools of resources and frequent rescheduling cycles (for example, monthly). Remember that a resource pool is a set of resources united by some common feature (for instance, by qualification or specialization).
On a stand-alone project, resource management is possible only in two cases:
1) resources are 100% allocated,
2) a certain conditional percentage of the total workload of a particular person is available for management.
In other cases, we will manage resource pools, not individual project resources.
As I said above, it is necessary to start implementing the resource management process when specific resources are in short supply or cost the company too much. At the moment, for most large and medium-sized businesses, IT specialists are more often such a bottleneck. However, the workload of competent specialists performing business functions and involved in the implementation of projects are often at the limit. Even if a company can “buy” specialists for a project, planning does not always consider the time spent on finding, training, and onboarding new employees.
The main goal of resource management is to balance the demand and supply for them. In this case, we consider the demand to be what needs to be done. This is a need for hours or story points (the task’s weight in conventional units, without reference to real labor intensity). And the offer is the available resources of the corresponding qualification in a specific time interval. To balance supply and demand means, on the one hand, to make the workload adequate to the available resources (to limit the load to the available resources by adjusting the need), and on the other hand, to determine the availability of resources in a certain period. This is to:
1) find out what resource is missing and where it can be obtained (from your resource pool or the contractor’s resource pool);
2) understand how to allocate available resources. We must formulate the most efficient scenario: what projects we can do given the potential resources available (those that can be “bought”, hired, or mobilized from the company’s internal reserves).
For competent resource management of IT projects, it is also necessary to understand the planning horizon and “resource bucket” in more detail.
The planning horizon is the period that is used to plan and forecast the load and availability of resources.
The resource bucket is the quantity of resources (hours or story points) within the planning horizon (or sprint or increment) and a specific resource pool.
An increment is a resource bucket that is formed around the creation of a large product by several teams.
When we say “team N’s current year’s resource bucket volume,” we mean the following, albeit significantly simplified, formula:
Resource bucket volume = period duration * amount of available resources in hours or story points for the selected period per day/week.
Let’s look at three possible planning horizons and how they can be implemented in the Jira platform.
Long-term Planning
Goal: formation of the company’s budget for the purchase of resources.
Planning horizon: 6 months to 1 year.
Source of resources: internal resource pool, outsourcing (new and signed contracts), recruitment.
Planning Approach: In a long-term horizon, we plan resources by each pool (or competence center), i.e., by qualifications (for example, Java developer, tester, etc.) or teams (for dedicated cross-functional teams). In exceptional cases, loading is planned by person. But I do not recommend doing this for long-term planning since it is more difficult to predict whether a particular employee will work all this time in the company.
First of all, in the year for which resource planning takes place, it is necessary to complete already underway projects. To do this, we evaluate the remaining scope of work, required workload. Next, we proceed to the evaluation of new projects. This is how a pool of projects is gradually formed, which we will correlate with available resources, shifting projects or individual loads, taking into account the emerging shortage. If there is a fundamental lack of resources and it is impossible to replenish them, we take the project beyond the planning horizon so that it does not affect the resource bucket.
Thus, we can form a realistic portfolio of projects or other activities that are implemented taking into account the dependencies and available resources. It will also allow you to plan a budget for the necessary resources based on internal rates and outsourcing limits. Additionally, we can create a portfolio roadmap based on available resources and links.
The Structure plugin in Jira does an excellent job of planning the budget and selecting projects for the portfolio. This tool allows you to view aggregated data for sorted and grouped tasks. The object of planning is one “load” (the amount of time required) per project according to the required qualification. Each project turns into a set of downloads corresponding to its duration. The load can be determined by the percentage of involvement and the number of specialists. In this case, the load calculation formula will look like this:
W=∆T*α*Q
Where W is the load, ∆T is the duration of the period, α is the percentage of involvement, Q is the number of employees.
Accordingly, the budget is calculated by multiplying the wage rate by the load:
M=H*W
Where M is the budget, H is the wage rate.
An example of such a structure is shown in Picture 1.
Additionally, you can use the BigPicture plugin in the Resources view for a visual picture of the teams’ workload for the selected period.
Medium-term Planning
Goal: To mobilize the necessary resources.
Planning horizon: from 1 to 6 months.
Source of resources: internal resource pool, outsourcing (new and signed contracts), and recruitment.
Planning Approach: There are still somewhat inaccurate forecasts for specific jobs in this planning horizon, so I do not recommend planning by tasks by person — only selectively. When planning workloads, we consider the specifics of dividing the project into stages since there are different workloads and the demand for qualifications at different stages. In addition, there may be dependencies between different tasks that affect the need for resources.
As a planning unit, you can use either the universal unit of story points or standard hours — the time required to complete any work. As a rule, this time is calculated with the help of an expert who has previously faced similar tasks. Story points work well in Scrum, where there is a Burndown chart. All tasks are normalized in story points and keep track of team performance. Standard hours are the most versatile tool for assessing labor intensity. However, their disadvantage is that they are tied to real-time, and customers are more likely to try to challenge them.
We use the BigPicture plugin in the Resources view to schedule loads at a project milestone scale. You can see the loads assigned to the team and each specific employee individually.
An example of the BigPicture program interface is shown in Picture 2.
On the left are the teams/employees, and on the top is the timeline. The colors of the block indicate the current workload of the team/employee (red means overload, yellow means workload close to critical, and green means underload). The downloads are below the cells with the remaining workload and can be moved in drag & drop mode between resource pools and executors.
Short-term Planning
Purpose: to allocate the available resources for specific types of activities, confirm the realistic expectations for the timing, and to take into account the links between tasks and stages.
Planning horizon: less than one month.
Source of resources: internal resource pool, outsourcing (signed contracts).
Planning approach: planning for specific jobs.
In the short horizon, tasks cannot be thoroughly planned for the entire period. Something can be arranged for a week in advance, for a couple of days, and something else is not scheduled. This may not ensure 100% staff utilization, as part of the tasks will be completed in a different period (medium-term). If, in the medium horizon, we simultaneously use loading by stages and in the short time — by tasks, then somewhere there will be an overlap (duplication of loading), and somewhere there will be unutilized temporary resources (because we do not know all the tasks to the end period).
Usually, resource planning for a month is not practical since the resource situation is constantly changing: someone goes on vacation, gets sick, etc.
We simulate work in standard hours, as in a factory, but do not take into account the fact that, in reality, in the IT field, people’s productivity can vary significantly for different performers. If errors with performance variability and availability of people are smoothed out in the long and medium horizons due to an additional temporary buffer that can be used if necessary, this does not work in the short time. Inaccuracies in the decomposition of tasks and estimates, the absence of tasks in the plan are superimposed on each other, and the short-term plan becomes subject to change. Therefore, we do not recommend spending time on assessing and planning resources in the short horizon. Using the kanban method is preferable, working with a queue of incoming or scheduled tasks and identifying bottlenecks by monitoring the cycle time at each processing stage (in a resource pool or competence center).
In Jira, you can assign a download to a task on the Issue card (“Time tracking” field) and use the Tempo plugin to schedule tasks for a team and evaluate their labor intensity.
An example of load planning in Tempo can be seen in Picture 3.
Now let’s consider what difficulties can arise in resource planning.
Resource planning is a very complex and challenging process in terms of implementation and maintaining it in working condition. For its performance, several preconditions must be met:
- project plans are already underway,
- projects are described,
- projects are regularly monitored.
Resource planning is related to other processes. In addition to resource information, it requires time information from project plans. We cannot consider resource planning in isolation from other processes, leading to unrealistic plans.
Forming an estimate and collecting data on actual and forecast labor intensity is a painful procedure. It is difficult to evaluate something that will take place only in the future and does not contain detailed requirements.
In addition, this process requires negotiation (for example, when there is competition between projects). Resource planning may seem like just putting “bricks” into a wall. But it is complicated not only from a technical point of view due to the need to model and compare different scenarios but also from negotiation. It is necessary to coordinate supply and demand, to maintain a balance of interests of all stakeholders. Since not all projects and tasks can be provided with resources and someone will have to be turned down, the resource planning process often becomes politicized. It is essential to understand that an information system is only a tool for resolving the conflict between supply and demand in the hands of a skilled negotiator responsible for balancing resources.
Schedules should be maintained to account for all dependencies between tasks and milestones. If they are absent, there is a risk that the project will require resources that are not available, or, conversely, the existing resources will not be needed.
The download profile, even within the same stage, may differ — for example, the load may be more intense at the beginning of the stage. Modeling at the task decomposition level does not add accuracy. Therefore, can we correct this profile after we plan the download? This problem arises in two cases: no developed appraisal skill, the appraisal is used as an obligation, and the employee is rewarded or punished.
Without task typologization (the ability to compare similar tasks to collect statistics and refine the model in terms of estimates), it will be challenging to accumulate analytics that can be further used to refine the base estimate.
Also, given the ongoing tasks and projects, it is difficult to assess their progress and predict the rest of the work.
So, let’s summarize
Resource management allows it to provide the necessary resources for planned work in projects, operating systems, tasks, etc.
The implementation of resource management is a complicated undertaking. Before starting it, you should consider whether it is necessary, whether you can cover the required area (resource pools), whether you have enough human resources to implement and maintain the process, and whether the management processes are mature enough.
It is crucial to consider the different goals for different planning horizons. For example, Jira has tools for working with various horizons. We also recommend implementing resource planning when scheduling and regular monitoring of the entire portfolio of projects is established.
