The allocation of resources to the project plan is part
of the overall process of
planning, estimating
and resourcing the project. Each time the plan is
reviewed and revised, resourcing will be addressed.
Resourcing means assigning actual resources (a rather cold expression which normally means people) to the project. There are two very different aspects to this:
The allocation of resources to the project plan is part
of the overall process of
planning, estimating
and resourcing the project. Each time the plan is
reviewed and revised, resourcing will be addressed.
The initial planning will have identified the work to be done. Estimates will have been formed, not just for the overall effort but normally showing effort per resource type.
Initially, the Project Manager will have identified resource requirements theoretically. For example, you may have decided that project tracking requires:
Now you need to consider the real world.
Very often these "real world" conclusions will have an impact on the original plans and estimates. Maybe you could not get the number of people you wanted. Maybe a key resource will not be available until later. Maybe you need to re-sequence tasks to avoid overloading a unique resource.
As the plan is refined, the Project Manager incorporates these practical considerations and repeats the scheduling process until an optimum achievable plan has been generated.
Here is a summary of the overall process...
Getting the resources for a project requires very different Project Management skills. Just because you put something in the plan and get it agreed does not mean that it will happen.
It usually takes strong support from the Project Sponsor and constant attention from the Project Manager to make sure the participants are released to work on the project as agreed. These resources usually have enough work to keep them busy full time in their normal line departments. You have to convince them and their managers that it really is essential to make them available - even though it causes pain in their own departments. Getting the right level of input is particularly difficult where resources are only planned to be working part time on the project. Try to get them physically away from their line job and working from the project team's own accommodation otherwise they will constantly be diverted back to their regular job.
Here is an example from a real project that shows the potential difficulty and impact of resource mobilisation. We produced these charts to show the Project Sponsor that the promised input from the business was not materialising. Only the external consultants were matching our expectations. We thought it was a strong message, but his response was - "it shows you can get resources if you pay high fees for them". Nevertheless, our point was taken.
During the Project Definition and initial planning of the project, resourcing is generally considered at a summary level. You will need to identify roles or classes of resource and their general capability, availability and costs etc. This is also the time to start the campaign to persuade line management that they need to participate and release resources for the project.
You might start by building a matrix of the resources you need - one dimension showing the type of capability, knowledge or skill they provide and another dimension showing the level of their authority and/or ability. To deliver a business solution you will need to include all the participants required for the complete solution including those from the business and external resources.
Resourcing needs will vary throughout the project. Typically, the early stages require intensive participation from the organisation's leadership and management normally supported by specialists in the industry, the processes, the technology, Human Resources and organisational change. These tend to be senior people. For the detailed design, the balance will shift towards more analysts and designers working alongside the "architects" from the earlier work. As the solution is constructed, typically you will require a much larger number of more junior staff to do the actual work. When the solution is ready for testing, you will again require participation from the organisation's management plus a significant number of users.
For the initial high-level project plan you will not necessarily identify individual resources - unless those individuals play a significant individual role. For example,
It is enough that you can identify the types of resource, the general availability of that resource type and the approximate cost. Based on this information, the initial plan, timing, costs and benefit model can be reviewed and, if necessary, revised. Bear in mind, however, that obtaining the desired individual resources can take time, so move on as quickly as possible to the identification of individual resources - particularly those required for the initial phase of work.
As you determine the detailed plan, typically prior to the start of each phase, you will need to consider the resourcing in detail such that individual resources can be assigned to specific tasks. By this stage all individuals should be identified - assigning actual names to the roles identified earlier. As part of that process, practical considerations and rationalisation may mean you need to fine-tune the plan and estimates.
Now that you have a detailed view of the project's participants, you should also consider how best to organise them into teams and sub-teams.
It often takes time to get the identified resources from their current work duties into the project team. You will need to make plans sufficiently in advance that the resources can hand over their current duties and be released for the team. Before making any decisions or assumptions about resourcing, you will need to have agreed the details with the relevant line management. Use the Project Sponsor to apply pressure where necessary.
As well as getting the people onto the team, remember to ensure they have the accommodation and infrastructure they will need. Typically, team members may need to have:
If they are working away from home, you may also have to deal with their accommodation and travel arrangements. They may also require initial training in the technology or coaching on the project's working methods. In general, it is good practice to devote some time to welcoming team members and coaching them about the project.
Further considerations about mobilising the team can be found in the Team Building section.
During the course of the project, it is unlikely that you will make any major changes in the resourcing. Of course, circumstances may change - plans may need review, progress may slip, people may resign, individuals may perform poorly etc. In these cases the resourcing issues may need re-examination.
At each phase end there are two choices for each resource, either:
Ideally, this choice should be clear well in advance so they have sufficient warning and details can be agreed. Detailed planning and resourcing for the following phase should be performed well in advance. Where team members will be leaving, their next role or assignment should be identified.
At the end of the project there are two choices for each team member, either:
A good Project Manager cares about the well being of the project team. Where possible, you should ensure your team members have a clear, valuable role to return to. Their capabilities and experience should be rewarded and exploited in their line positions. Very often, former team members make excellent coaches, team leaders, and managers back in their line roles since they return with an excellent understanding of the new business solution. If the team member is returning to a pool of resources, eg an analyst/programmer in the organisation's IT department, make sure the resource managers for that pool know the details in advance so they can re-allocate the resource in a valuable way.
The Project Manager will often have a formal duty to assess or appraise the performance of project staff. Even where there is no formal process, it is appropriate to provide useful feedback to the participant.
 |
| Copyright © Simon Wallace, 1999-2016 |