Resource planning is an essential aspect to doing projects. You need to do this however for a large part outside de project context or outside the control of the project management office. It will need to be done by the (operational) IT managers. I thought to write this down as I see too often that organisations still struggle with this. Though it will never be a stroll in the prak.
Projects come and go and are generally resourced partly through people from the existing operational teams and partly through temporary hiring. Projects are these days less about completely building something new and more about adding or changing something that already exists. Therefore it is important to use existing skills and knowledge.
Certain resources will work almost fully dedicated for the project for a longer period of time. Other resources will need to perform tasks intermittently and for shorter durations. Planning the latter group is the most difficult. Those people will work probably for many projects and will also have to perform operational support tasks.
Because the IT manager will know which person has the right skills to perform the required project tasks, it is the IT manager who will need to do the resource assignment. In fact, the IT manager has the responsibility to maintain the full resource planning for everyone within his team. Additionally, it is advised that project resources are also recruited and managed by the IT manager. In that case, he can assign some support staff to work on the project so existing knowledge can be leveraged for the project and some of the temporary staff can do support work.
With respect to resource planning, the IT manager will first of all need to make an estimate of the total amount of operational support work he has that needs to be performed. These tasks can be work related to:
- Operational support tasks such as incident and problem management, fulfilling user requests, responding to system events, systems monitoring, service desk tasks, applying software patches, replacing faulty, etc.
- Proactive support tasks such as upgrading software to a new versions, structural hardware replacement or implementing changes as requested by the users (all these activities could potentially be executed as projects).
- Overhead tasks such as team meetings, training, holidays, sick days, etc.
It is not always required to plan on the individual basis and you could maintain the information on the summary level.
When planning all your projects, you will need to ask yourself the question whether you will be able to perform all those projects. It happens unfortunately too often that certain resources are over-allocated by different projects because there was not overarching planning. Each project will have to make its own resource plan and the project management office will need to integrate those plans to see what the total project resource demand is per operational team or some cases per individual.
You will get a resource plan similar as you would have per team but instead of tasks you would haven projects. Each project manager will provide a single line item per resource or skill/team for the resource plan. You can then reorganise this demand to a demand per team. On a summary level, the total demand from all projects could be something like the table below.
If you then subtract the demand for a team from the availability, you see what is required for additional hiring of staff. Using the above examples, this is for team 1 as follows:
The “ total available” gives insight in how much time is available for projects. If projects require more, you will need to insource additional people. If these resources work only for projects, then you could leave those people out of your operational resource planning and leave the management up the project manager or the project management office.
As you will perform multiple projects and will have multiple project managers, you will also have some project coordination through a project management office or something similar.
When planning all your projects, you will need to ask yourself the question whether you will be able to perform all those projects. It happens unfortunately too often that certain resources are over-allocated by different projects because there was not overarching planning. Each project will have to make its own resource plan and the project management office will need to integrate those plans to see what the total project resource demand is per operational team or some cases per individual.
You will get a resource plan similar as you would have per team but instead of tasks you would haven projects. Each project manager will provide a single line item per resource or skill/team for the resource plan. You can then reorganise this demand to a demand per team. On a summary level, the total demand from all projects could be something like the table below.
If you then subtract the demand for a team from the availability, you see what is required for additional hiring of staff. Using the above examples, this is for team 1 as follows:
In this example, you will need an additional person with specific skills. Initially for 2 days per week, then for 1 day per week, then not at all and then you need this person again. That is unpractical. Usually you just can’t hire skilled people this way. Therefore you might need to adjust your project portfolio by either delaying or cancelling a project. Another option is to delay or cancel certain operational tasks.
Adjustments will need to be made continuously. You might need a Unix administrator only for 2 days at the end of the project. You will need to plan this into the resource planning but as we all know, projects run rarely according to the plan. You might even find out only a week before that you need to reschedule. Alignment between projects and the support tasks is needed. If you, as an IT manager, have been strict enough not to give away the time required for support tasks and have planned sufficient contingency into this, you will be flexible to accommodate these last minute changes. Instead of doing the support tasks next week, you do them this week. This flexibility can be obtained for a large part from the proactive tasks and less from tasks such as incident management.
What you definitely should not do is to ignore the issue and simply over-allocate the resources. What happens then is that support tasks are delayed or cancelled which over time will result in an increase in the number of incidents. What also will happen is that projects will take longer than planned and will be delivered with a lower quality. The latter will result in a higher number of incidents for the support teams to resolve.
Besides people, resource planning can also apply to the systems themselves. If you have 3 projects that all want to modify an existing component, all through the development, testing and production-deployment phases, you will need to align all these activities between the projects and support activities.
Adjustments will need to be made continuously. You might need a Unix administrator only for 2 days at the end of the project. You will need to plan this into the resource planning but as we all know, projects run rarely according to the plan. You might even find out only a week before that you need to reschedule. Alignment between projects and the support tasks is needed. If you, as an IT manager, have been strict enough not to give away the time required for support tasks and have planned sufficient contingency into this, you will be flexible to accommodate these last minute changes. Instead of doing the support tasks next week, you do them this week. This flexibility can be obtained for a large part from the proactive tasks and less from tasks such as incident management.
What you definitely should not do is to ignore the issue and simply over-allocate the resources. What happens then is that support tasks are delayed or cancelled which over time will result in an increase in the number of incidents. What also will happen is that projects will take longer than planned and will be delivered with a lower quality. The latter will result in a higher number of incidents for the support teams to resolve.
Besides people, resource planning can also apply to the systems themselves. If you have 3 projects that all want to modify an existing component, all through the development, testing and production-deployment phases, you will need to align all these activities between the projects and support activities.
