How to Do Many Projects (Part 4): Resource Planning


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:

  1. For every type of work a specific number of days per month must be allocated (by a resource planner) in people's calendars;
  2. Different people can be made responsible for the allocated timeslots by managing the work that is carried out in those periods;
  3. 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)

  • Top 100 Best Books for Managers, Leaders & Humans
  • 5 Easy Questions for Randall Hyde
Related Posts
free book
GET MY FREE BOOK!
“How to Change the World”
  • http://www.basilv.com/psd/ Basil Vandegriend

    There are some brilliant ideas in this article! I especially loved the notion of academy days and quality days. Have you figured out a reasonable percentage of total time to allocate for academy and quality days? I would say that 1 day a month of academy time would be a minimum (equals about 2 weeks a year), and I assume Google’s 20% personal projects time would be a maximum.
    I work for a consulting company that needs to deal with similar resourcing issues. Regarding the scheduling of issue days – does this include direct operational support issues, or only defect fixing? One of the biggest challenges in my area is staff whose time is split between project work and providing operational support. Since support issues and outages can arise at any time and typically require prompt (same-day) investigation, it makes scheduling time much more difficult for these resources.

  • http://profile.typekey.com/jurgenappelo/ Jurgen Appelo

    @Basil: 1 day a month (20 work days) is 5% of an employee’s time. This is a reasonable figure to start with for academy days, I think. (And at this time we cannot really afford more than that.)
    I haven’t figured out yet how much of our company’s time I can let them spend on quality days.
    The issue days cover all kinds of maintenance (bugs, refactoring, new features, maintenance tasks). It works reasonably well to allocate a fixed number of issues days per month, and let the team members share the burden. Every day there’s always one team member doing an issue day. This means show stopper problems can always be picked up right away, with (usually) no impact on the sprints of the project(s) carried out by the other team members.

  • Adrian

    Really great article. It would be nice in a future article to speak more about estimations, since you mentioned it this article. How do you manage to estimate a fixed while you guys are developing using SCRUM ?

  • http://profile.typekey.com/jurgenappelo/ Jurgen Appelo

    @Adrian: Projec estimation is indeed a difficult subject. I am reorganizing our estimation process at this time, so it’s a bit too early to tell you about it. But I will definately do so in some later post!

  • http://management.curiouscatblog.net/2008/11/17/management-improvement-carnival-47/ Curious Cat Management Improvement Blog

    Management Improvement Carnival #47

  • Tibia

    Great article, thank you !

    Any suggestion on tooling for multi project capacity management ? Something that can replace Excel when the organization becomes too large large ?

    Thank you
    Tibia

  • Arnie Sumalde

    Hi, do you use any project management tool that can support multi-project teams?

How to Change the World - free Workout - free
CLOSE