Fun with Microsoft Project–Fixed Capacity Scheduling

I’ve spent a lot of years managing projects or parts of projects, but up until recently, I’d had very little exposure to formalized processes about same. For example, not only did the teams I was on not use Microsoft Project, I had one manager expressly forbid its use. However, the client for the last project I worked on ended up demanding a Project (capital P) file as a deliverable of the project. Well, he *sort of* did that, what he really kept asking for was a “capacity plan,” but what he meant, it turns out, was a Project file (future blog post about trying to interpret what people want regardless of what they ask for needed).

I will, for brevity’s sake, skip much of the minutia here about the entire structure of our team, the specifics of the project, and how much time our team spent on figuring out accurate ways to estimate our work. Here, however, are some high level factoids:

  • The project deliverables were fully edited documents ready for publish.
  • We had 2 editors and 1 visual communications (read: PowerPoint polisher) person.
  • The client was paying for a fixed capacity per month. In our case, the client was paying for the full time use of the 3 resources (as well as for my time, and a managing editor’s time which I’ll leave out here, again for brevity).

The client, therefore, wanted to make sure that our team was fully utilized, and producing as many completed documents as possible within each fiscal quarter.

The high level process was:

  1. People on the client’s team would send us an initial request indicating what documents they wanted edited, along with some specifics about document size, graphics requirements, and specific editorial services.
  2. The client’s team would also provide ideal start and end dates (when docs would be handed off to us, and when they wanted them completed).
  3. Our team would estimate how much work was needed (down to the hour).
  4. I would throw this into the schedule and figure out if we had the capacity to complete the work in the desired timeframe. If so, we’d add it to the plan. If not, we’d tell them how much extra it would be to bring on extra resources, or we’d give them the date we could get it done.

As I mentioned, I had very little experience with using Project up to this point. I had used it to itemize tasks and generate a Gantt chart, but that was about it. My initial swag at trying to plan out all of this work was a bit disastrous. I really could’ve done it with a spreadsheet and a calendar, but as I said, the client demanded the Project file. I made assumptions about Project and how smart it is, and I was wrong. After a lot of trial and error, and a 3 hour session with a Project expert, I was able to come up with a working model. The goal of this blog post is to document what I learned so I don’t forget it.

Here are some basic things that I learned:

  • Project doesn’t have any sense of task priority. You cannot tell it “I’d like to schedule this person to work on both of these things, but please make sure that s/he prioritizes this task before this one.” You can set dependencies, but that is a false relationship (one task does not require another). You can also mark a priority on a task, but Project does not use this in any calculations.
  • Project’s really not designed to plan work down to the hour. You can do it, but basic project management methodology recommends only going down to the day. When you’re not planning on budget, but rather on capacity, this can cause problems.

OK, so what did I end up doing? What should you do it you’re in the same sort of situation?

  • Roll-up tasks as much as makes sense without losing accurate scheduling ability. For example, our editors might do an initial review, then consult with the client, then do another pass, then send it back, etc. All of that is very difficult to track, and you end up spending more time tracking and estimating then getting work done. For simplicity’s sake, you could roll that up into “Editorial Review.” Then, the final pass on the document might be “Document Finalizing,” or something like that.
  • Develop a solid mechanism for tracking time. In our case, we adapted our payroll time entering system to match the categories for our work. We still needed to tweak this a bit by the time the project ended, but it was definitely the way to go. In other words, the way people get paid should match the hours that you’re billing the client for (other wise you could over or under bill).
  • Do some initial calculations before you start applying the actual capacity of your team. For instance, if you’ve estimated that Document Set 1 will take 40 hours of work (which is one person full time for one week), but the client wants the work done in two days (16 hours), you know without even looking at your team’s schedule that you’ll need 2.5 people to complete the work (or, rather, 2 people working two days, and one person working 1 day).
  • As the project manager, don’t concern yourself with which work will get done on which day. This will make you and your team crazy. Rather, and this is key, be concerned with accurate overall estimates, and firm start and end dates as dictated by the clients. Then, all you’re planning is the hours per day your team has blocked out, and whether they spend.

Nittty-Gritty Project Stuff

  1. Start working in Task Sheet view (this eliminates the space taken by the Gantt chart, and gives you more room for columns).
  2. Add the “Work” column.
    You are scheduling work, not scheduling duration.
  3. To that end, you should also change the default task type to “Fixed Work” in the Schedule options.


  4. Add each task, and based on your initial calculations, enter the hours of work,  the names of the resources you believe you’ll need, a fixed start date, and the duration that it would take to get the work done. I know this seems backwards, but remember, you know how many days it should take to get done with x number of people working x hours per day,  and what day you can start.  Project should then give you the end date. You can also manually enter the start and end dates, and have Project determine the duration. You risk Project adjusting the start date when you do that, though.
  5. Now, flip to the “Resource Usage” view, and you’ll see if you’ve over-scheduled someone. But this view is the key to making sure you’ve got full capacity scheduled. If you’re over, you can assign another resource, or, you can play with your start date on the item. You can of course try the famous Project “resource leveling” feature, but then you’ve given up all control.


  6. Play a bit with Project’s automatic and manual scheduling. Be cognizant of which you’re using. Switch something back to manual when Project becomes possessed and does something strange.

I know that some of this is specific to the work our team did, but the key for me here was learning that instead of worrying about the specific work product that my team was working on in any particular day (and the priority of each), I just needed to make sure that within a timeframe they had 8 hours of work per day each. As soon as I had 8 hours of work for a given person on a given day, they were fully booked, and the earliest I could schedule any work for them was a day on which they had less than 8 hours available. It sounds simple, but when we had over 30 projects requested, and only 3 people to do the work, I went down a path of trying to prioritize and figure out who was going to work on what on which day.

I hope this is of some value to someone besides me, but really, I just wanted to document my experience so I can remember the thought that went into it, and some of the practical tool usage.

Finally, big anonymous thanks to the person who sat down and thought through some of this with me. As a PMP she was a bit horrified at the approach we were taking, but she was able to help us out with the specific needs of this client and project. If I had to do it all over again, I would attempt to set different client expectations rather than go through all of the same gyrations, but I’ve learned a lot from the experience.