In three earlier blog posts I talked about multi-functional teams, matrix management and maintenance. In my maintenance article I argued that maintenance work on an application should be done by the developers who were responsible for building it. However, I also pointed out that this introduces some additional resource planning problems...
When software developers are responsible for multiple projects, you always end up with complications in resource planning. This is not just the case when you let developers perform maintenance on previous projects. Similar problems arise when they are required to do some other activities, like spending time on consultancy or estimations for projects that haven't yet been signed into contracts. Likewise, believe it or not, many developers actually need regular training, or they like to do some quality/infrastructure stuff for the organisation itself.
Therefore, maintenance work on old projects is a challenge, but it's just one of many types of work that can take people's attention away from their current projects. This requires a professional approach to resource planning...
I think there are 3 principles for resource planning:
- For every type of work a specific number of days per month must be allocated (by a resource planner) in people's calendars;
- Different people can be made responsible for the allocated timeslots by managing the work that is carried out in those periods;
- Considering that task-switching is bad, the resource planner must seek to minimize the number of different activities per week, per person. (for example: allocating one week to activity A and one week to activity B is much better than swapping both activities every day)
This is how we have implemented these principles in our company:
- We maintain a 1-on-1 relationship between project managers and teams. This means that our project managers can do the resource planning for the members in their (multi-functional) team.
- The project managers are, of course, responsible for managing the projects in their teams. In these cases they act as ScrumMasters, as all our projects are using Scrum. These projects typically cover about 75% of our people's agenda's. There can be multiple projects going on in one team, but any conflicts of interest are taken care of by the project manager, as he is (by definition) responsible for all of them.
- Team members stick to their own teams. We don't continuously reassign people across teams. (And if someone tries again, I'll kill him.)
- Every month, a specific number of days are reserved for maintenance work. We call them issue days. The number of issue days needed is estimated from our maintenance contracts. Management of maintenance issues is done by service managers, not our project/resource managers. Explicitly allocating time for maintenance work in people's agendas has been a big help in improving both our service levels and the reliability of our project estimates.
- Every week a number of hours are set aside for doing estimations (for fixed price projects) and consultancy work by some of our lead developers. This pipeline of work is managed by someone who is neither a project manager nor a service manager.
- Software developers themselves are allowed to reserve a number of academy days. These are days for self-development and training. It works similar to requesting time off for vacations. As long as people request these days well in advance, this should usually not be a problem. The things our people do and learn on those academy days are monitored by their own functional managers.
- Last but not least, I am now considering the introduction of quality days. These should be days where software developers work on improving our own tools, techniques and processes, in ways that cannot be directly translated to billable hours in our projects. As a quality manager I would personally be responsible for the way those days are spent by our people.
Resource planning is not difficult. It just requires some discipline to do it right.
People should be able to trust that their resource manager has thought long and hard on how they must distribute their valuable time over multiple activities. And they should always know which other managers they must turn to for the details of the work in those allocated timeslots. And when the resource managers make sure that there's only a minor level of task-switching, then it's entirely possible to have a small number of people working on a large number of different projects and activities.
Subscribe to this blog with a reader or by email!
Latest, greatest and favoritest posts:
How to Do Many Projects (Part 3): Maintenance
How to Do Many Projects (Part 2): Matrix Management
How to Do Many Projects with Few People (Part 1)
