Resource planning based on size and degree of certainty.
Many companies struggle with how to use their employees for projects. In particular, the tug-of-war over employees from different parts of the company has shown to be disastrous for the correct and timely execution of the projects. You can deal with this by choosing the right project approach, assigning full-time employees and distinguishing between projects and other work. In this blog we will discuss this further.
For this problem, we will take project-based companies as the basic premise; such as an IT company or an Web agency. They are project-based, but also do small assignments for clients and carry this out with a staff of a few dozen employees. We will also assume that management does not take on more work than there are available employees, because that adds another entire dimension to the tug-of-war over employees.
We are assuming a situation where a company has enough employees, but is struggling to perform projects and other work in an efficient and effective way. Their execution falters, because employees are pulled back and forth between projects and assignments, due to urgent incidents that occur, changes in the scope, setbacks, etc.
We have distinguished 3 possible causes:
- Wrong project approach
- Dispersed and wrong use of employees
- No separation between projects and other work
1. Wrong project approach
You can approach a project basically in two ways: according to the classic waterfall model, or with an Agile model. These two methods are both extremes of the spectrum, because there are a number of hybrid options in between. Many organizations have opted to use one or the other approach for every project, but that is a pitfall. You should assess for each individual project which approach to use.
The waterfall method
The waterfall method is an approach in which the steps regularly flow downward, like a waterfall. The concept behind this approach is that the project is sub-divided into several steps and that step 2 cannot be started before step 1 is done. If an error is found in one of the steps, you go back to that step to correct the error and and carry out the subsequent steps again.
The method works well if the intended project results are clearly specified, do not change and if the project is carried out in a stable environment. Under those circumstances, there is a high degree of certainty, because during the course of the project, it can easily be determined per step when, how many hours and what skills are required. Based on that, a suitable employee can be selected for the job.
An Agile method
There are also projects whose results are not clearly specified and that are carried out in a dynamic environment. During the course of the project, anything may change. The final destination is known approximately (there is a direction), but the route to it unfolds during the process. These projects are coupled with quite a bit of uncertainty.
If you use the waterfall method for a project like that, you are asking for problems. You will see that you constantly have to adjust the plan to the changed circumstances. Due to dependencies between the steps, this leads directly to delaying the execution and to problems with the availability of employees. The resource plan was put together in advance like a fitting puzzle and now the frameworks are changing, so the puzzle is not working anymore.
For projects with a high degree of uncertainty it is better to use a more Agile method, like, for example, Scrum. The English word Agile means nimble, supple. An Agile method is geared to quick adjustment to the changing reality. With regard to the resource planning, you work with a fixed team of full-time staff for the entire duration of the project. You estimate in advance how many disciplines you will need.
The degree of certainty is decisive
For projects with a high degree of certainty, you can reason based on the work that must be done. The resource planning is derived based on the content of the work. For projects with a lot of uncertainty this is not possible, because it is constantly in flux. With an Agile approach, you can see that the premise of the resource planning is reversed: you start with a fixed team (capacity) and start the work from there.
The approach to resource planning differs fundamentally with the waterfall method compared to an Agile method. We have seen that the classic waterfall method can lead to problems for uncertain projects, but even the Agile approach will not fit in perfectly with a project that has a lot of certainty. You then have a fixed capacity, although the execution requires specific staffing at specific times. This leads to inefficient use of employees, because you will probably not be able to keep everyone working.
2. Dispersed and wrong use of employees
Dedicated vs. multi-tasking
Ideally, you assign your employees to projects full-time as much as possible. An Agile method like Scrum even sets that as a condition. Multi-tasking is inefficient, see the blog 4 time wasters in project planning for this too, and it promotes the tug-of-war over employees. This is because employees must record progress on several fronts and project managers direct them in this.
In the above figure, you can see that if you can work on project A full-time, the work will be done after 2 days, compared to 4 days while multi-tasking. The work could be aligned over several projects, but as soon as project manager A demands more staff (and gets it), this will directly compromise the other projects. As counter-action, project managers B and C will then also start pulling on the employee, or, in other words, the tug-of-war has begun.
If you can plan employees to work on projects full-time, you can avoid the aforementioned problem. The counter-argument is often used that it is simply not possible to completely free up employees, because their expertise is also needed elsewhere. This may be true, but, of course, you can also consciously choose to assign a slightly less competent employee, whose capacity can at least be employed full-time unconditionally. That way, you can prevent the tug-of-war over employees and that provides calmness.
Specialists vs. generalists
With the waterfall method, you can really plan the work and you can indicate exactly when, how many hours and what skills are needed. This situation lends itself well to planning specialists, because you know exactly what is needed and can look for the employee that is the best fit for the job.
With an Agile approach, it is different. In order to deal with the uncertainty of the environment and the fact that the specifications of the intended project results are not entirely clear, a team is put together that roughly includes all the required disciplines. This requires using generalists that can work in a broader way and therefore can also pick up tasks that are not necessarily part of their primary discipline.
If you use a specialist in a generic role, there is a chance that the specialist will quit at any time, because he is not able to meet the demand and his skills are not used enough. Conversely: if you constantly use the generalist for very specialized tasks, he will not be very happy. A variety of tasks gives him energy. So, make sure you use the right people based on the chosen project approach.
Flexibility vs. working methodically
For the resource planning it is also a good idea to see if the dynamics of the project environment fit in well with the employees’ profile. If you approach a project with an Agile approach, that will require employees to be able to adapt quickly to a changing reality. Flexibility is an important value here. Employees that don’t function well in such a dynamic environment will not be optimally used. Their added value will not be optimum.
Conversely, if you approach a project with the waterfall method, you need employees who are used to planning their work in detail. They should be able to indicate exactly when they can expect to provide what results. If you use employees that have trouble working methodically, your project planning will become unreliable. This may also frustrate the employee in question, because he or she is not meeting the expectations.
3. No distinction between projects and other work
We have only distinguished between projects that have a lot of uncertainty and projects that show little uncertainty. For project-based companies, however, not all the work consists of projects. Often, a substantial portion of the work is made up of smaller assignments. For example, incidents, maintenance and change requests.
These minor assignments can engage employees to a substantial degree, because you don’t always know when they will occur and how much work they require, for example, when resolving an incident. You often see that employees are used both for these minor assignments and for projects. This is not a good idea, because it promotes a tug-of-war over the employees again. For example, solving an urgent incident will be given priority at the expense of putting someone on the project, with all the associated consequences.
Because among the minor assignments you can also distinguish between the really small assignments and the somewhat bigger ones, it is advisable to use two separate teams for this: the support team and the service team.
The support team
Many companies have a support desk for fielding questions, incident reports and minor requests, such as changes on the website. This support team primarily carries out everyday requests from clients, which are very short cyclically and reasonably uncertain with respect to the planning. Assignments typically don’t take longer than a few hours.
From the perspective of resource planing, it is not advisable to plan to use the employees of this team at the level of the assignments. The work is too unpredictable and small for this. See the blog Detailed planning? 3 deciding factors for this too. You will want to mostly plan the shifts of the support team, to guarantee that there are always enough employees to do the work.
The service team
The service team does assignments that require a substantial number of hours, are too big for the support team and too small to be made into a project. For example, a change request that takes a developer and a tester 80 hours. A change request like that often requires a different approach and more specialized knowledge than the support team has. The execution of these assignments can be clearly assessed and planned.
For the turnaround of a project, you could set a limit of, for example, 480 hours. Then it would really be a substantial job, because you would have 3 employees working on it full-time for 3 weeks. As soon as an assignment suddenly unfolds from an initial 300 hours to 3,000 hours, it should be made into a project and taken away from the service team.
Conclusion
In summary, we can state that the work in the form of projects and smaller assignments are about size and degree of certainty. 4 work domains can therefore be distinguished a shown in the figure below.
For a particular size of the work, we opt to approach the work project-based. An important choice in this is the project approach. When there are clear specifications and a stable environment, you can opt for the waterfall method. When there is a lot of uncertainty, you opt for an Agile approach. For the minor assignments, you create the same kind of division. All the minor, incoming work is handled by the support team and you get the service team to carry out the bigger assignments.
Based on this division and the employee’s profile, you will soon see in what domain the employee is most suitable. Are you more of a generalist? Then you would do best in a support team or on a Scrum project. If you are more specialized, you would be a better fit for a service team or on a traditional project, where you will be able to apply you deeper level of knowledge and skills.
You can prevent the tug-of-war over employees by:
- ensure the work ends up in the right work domain
- let employees work full-time in one of these domains
