Resource Optimization: A Good Idea?
Project Schedule Management is a significant part of not only the PMP® exam but of project management in general. Preparing and tracking a schedule is a fundamental part of project management, to the extent that many practitioners regard it as project management!
Anyone who has taken a PMP® course will remember that we begin by defining activities and then sequencing them without any consideration for resources. This is a useful step because we focus on inherent dependencies in the work – you cannot build the walls until the foundation is laid; you cannot test the plumbing until the water is connected up. However, the resulting network diagram can contain many anomalies. For instance: five unrelated carpentry tasks might be scheduled simultaneously, despite having only one carpenter on the job.
This is why your PMP® training warns that resource levelling can push out the schedule. If equipment or people are not available, the schedule has to accommodate this. Tools like Resource Calendars and Resource Histograms allow us to visualize when resources are free and we can adapt the schedule to suit.
There is a view that project managers should strive for 100% resource utilization. On the surface this makes perfect sense – people and machines are expensive and we should get the most out of them – however, is this really a good idea?
Back in 2001, Tom DeMarco wrote an interesting book, called “Slack”. In it, he describes slack as the capacity to change. If your organization is tremendously efficient – with very high resource utilization levels – it will find it difficult to cope with the unexpected. Who is available for emergency bug fixes for instance?
Having everyone busy can actually serve to slow things down. If work is passed from person to person and everyone is busy, then the work ends up being queued along the way – something any lean practitioner will recognize as waste. Another danger with the drive to 100% utilization is the tendency to assign staff to several projects at once. No thought is given to the context switching overhead, which can be enormous. DeMarco estimates this overhead for a knowledge worker juggling two tasks at more than 15%.
Another efficiency drive which DeMarco cautions against is laying off people who seem to be surplus to requirements. An obvious example is the elimination of so many secretarial workers. This leads to high-paid executives spending more time printing, filing and photocopying. Is this the best use of executives’ time? On the subject of executives, DeMarco expresses concern about the purge in middle management. He regards management as essential and describes its elimination for the sake of cost cutting as “losing weight by giving blood”.
For PMPs®, this caveat can help us when it comes to Project Risk Management. Thanks again to our PMP® training, we should be familiar with contingency reserves. During the Perform Quantitative Risk Analysis process, project managers estimate the actual monetary costs of a risk materializing, factor in the probability of occurrence and add reserves to cover the risk. However, we tend to regard contingency exclusively as a monetary value. What about schedule contingency?
Probably the most damaging risk in any sort of development project is the loss of a key team member. What can be done to mitigate this? Ideally, no one person should be hidden away, working autonomously on a particular part of the project. So an obvious way to cope with such a person getting run down by the mythical Big Red Bus is to have another team member working side by side with the critical resource, or shadowing them in an apprentice role. However, there are dangers with these ideas. Not giving someone autonomy can be demotivating – effectively saying that the person is not to be trusted – and assigning a student may not work in certain cases, such as when the person is uncomfortable in a teaching role.
The use of multi-disciplinary, self-managed teams can help with knowledge sharing. Agile teams, for instance, work on particular features together, so there is a common goal during each iteration. Because the work is closely coupled, a team member falling out is not that critical – other team members should be familiar with, at least, the interfaces to that part of the feature. Often, other roles, such as QA, can jump in and take over, having a good idea what the feature is about. The important thing is to have someone who can help out in an emergency without affecting their own work.
So the trade-off is efficiency versus flexibility. A giraffe is highly efficient, but if it was relocated somewhere where there were no high trees, it would not have a happy life. Similarly, efficiency is very desirable in a predictable environment, but given the uncertainties inherent in projects (each one is unique!) it is important to have a measure of flexibility, particularly with regard to the project team.
For more information on scheduling, risk management and resource allocation, please consider one of our project management training courses. We hold our project management certification courses online in our virtual classroom. Find out more by contacting us.