To find the critical resource, there are 3 criteria:
1/ Point of convergence/divergence
In your project, you have a clear convergence/divergence point. That is to say that a set of tasks converges towards this task (and the resource). And when the task is done, you can launch several sets of tasks in parallel.
2/ Resource with limited capacity
In your organization, you probably have a resource that has a lower capacity than the others. This may be due to a rare skill… Or simply because the organization has historically refused to consider it as critical.
For example, the design authority function is scarce in some areas and it quickly becomes the resource that everyone is running after to have available.
The other example is the role of design control. Many companies in high-tech industries struggle to have drafters because they represent a capacity issue. However, all these drawings need to be checked. This is often denounced as a non-value-added operation.
“We already have difficulties recruiting designers that we have to pay a lot of money for. It’s not like we’re hiring someone to check their work. We assume they do it right the first time.” Fail…
As a result, the control resource sees fewer and fewer defects because it is under pressure to validate. When there is rework, the design team multitasks a bit more… Which continues to generate errors. #infernalspiral.
3/ The resource generates high variability on the schedule.
Let’s take the last case. If this critical resource refuses the design, the designer will have to redo part of the work, which will involve significant schedule shifts. This example may not seem to have so much impact, but there are sometimes much more severe cases: prototypes and their validation.
Your team is working on a new product that will have a prototype validation phase:
- Several resources work in parallel to create the different components that will be assembled to make the prototype (point of convergence).
- Then, the prototype will have to be validated from all points of view (aesthetic, technical, etc.). It may take time to find a time when everyone is available to validate, or simply to technically check the result (limited capacities resources).
- Finally, if the team does not validate the prototype, you risk going back to the early stages of the project and redoing part of the work, which inevitably risks delaying the project.
So to conclude, if you find a place in the project that combines at least two of these three points, you have a good chance of identifying the point of regulation.
All that remains is to regulate now.
To do this, go to episode 4.
