I get asked somewhat regularly about the practice of resource loading in software projects. Now, besides the fact that it refers to people as resources (which reminds me of that horrible phrase: Human Capital Management), the practice is not all it’s cracked up to be – for software projects that is.
For those of you not familiar with it, it’s the process of loading up team members a little at a time (by x%) until presumably their allocation hits 100% and they are now fully booked and unavailable for more work. So for example, you might add a bunch of part-time tasks (say 25% worth) to a person for a couple of days during a particular week, then look at a resource allocation view to see that this team member is 25% booked on Monday through Wednesday.
This practice has a lot of face value (face value = intuitively perceived value). However, it also comes with some serious draw backs that a lot of people aren’t necessarily aware of.
First, the very existance of the ability to allocate people on part-time tasks comes with the cost of having to (often manually) manage this new variable (x% allocation) by team member, over time. This means constantly checking to make sure that no-one has become more than 100% booked for any period of time – otherwise, the schedule is no longer achievable. While some extremely organized project managers have built this into their daily routine (and are extremely hesitant to let it go), the average case goes more like this:
- Project manager assigns a bunch of work to team members
- Tool doesn’t prevent (or even warn) about people being more than 100% booked
- Project manager one day figures out that there are significant chunks of time where team members are over allocated and that the current schedule is not achievable
- Finish date has already been promised and all hell breaks loose
- Not to mention that filling people up to 100% allocation creates a false sense of confidence in the plan. In reality, because of factors like Distraction Rates and Time Estimation Error, a good planner should only book people to some number less than 100% to account for these errors and delays. Especially in software projects.
Second, since we’re talking about software projects here, it’s a well documented fact that context switching is a productivity killer of software projects. Engineers really need to sit down for larger chunks of uninterrupted time to focus on particular features. Some have said that the amount of time that it takes for a coder to get “in the zone” can be hours before that coder reaches optimal productivity and quality output. This says to me that there is a serious productivity cost to actually scheduling by the part-day (which equates to this % allocation way of scheduling).
Third, often times when you’re thinking about a particular “task” as being part-time over a period (say 50% over 2 weeks, for example), what you’re really talking about is a short-hand for, “I’ve got a longer-term activity that I’m going to break into chunks and work on between now and then”, which can often also structured as a task-group and broken into individual tasks. So for example, instead of thinking of “build the data storage layer” being something you do 50% of your time over a period of a month, why not break it down further into components and schedule those components for a day (or couple) days at a time? That way you avoid the cost of context switching (increasing productivity and quality) and get greater visibility out of your schedule. Sure, little things will come up that take an hour here and there, but there are other ways of accounting for that, and at the granularity of a schedule (vs. a to-do list), counting each individual hour offers a serious diminishing return.
Finally, and I think most importantly, there are a lot really powerful things you can do with managing risk in a schedule (which is pretty darn important in software projects) that is modelled like a queue (a one dimensional space – like a timeline). When your schedule is modelled in 2 dimensions (time and x% allocation), you lose the ability to make some very good assumptions (like no-one should be more than 100% allocated AND a person can only be booked on a single “large” task at a time). These important assumptions (or scheduling rules) can serve to reduce the complexity of working with your schedule. They can serve to reduce errors and time-suckage, and actually help you manage risk. Devshop does this automatically by factoring in time for Time Estimation Error and Distraction Rates that have been individually tracked by team member over time.
My opinion of resource loading as a practice is that it is a short-hand notation for what should actually be broken down into discrete tasks. In the very short term, it feels like a good way to model work because our brains like to think in terms of patterns (doing something for y% of each day for 2 weeks is a lot easier to remember than 20 individual tasks, 2 per day for 10 days). However, we’re writing this stuff down anyway right? Might as well break it down and reap the benefits of those pretty basic assumptions about not overbooking someone and not incurring the extra time-suck factor for manually watching over x% allocation or worse – getting caught with your pants down one day when you notice the schedule you just promised someone shows some people double booked and isn’t actually achievable.
Unfortunately no single model of scheduling will allow you represent with perfect precision the work as it will actually occur. The trick is choosing a model that for a reasonable amount of input, produces the best result – and for software, that’s all about delivering on time, and fending off risk. Your best bet is to choose a model that is designed to help you deliver on your mission. One model might be better for managing the schedule for part-time employees at a Home Depot, whereas another is more appropriate for the dynamics of a software team. For software projects, your mission is delivering high quality products on-time. Choose wisely.
