Scheduling project-wide resource overheads with Microsoft Project

This 2-part question is from Mark Moeller of Woodinville, WA, USA:

I have two different resource assignment issues to solve:

1) I have a resource who needs to be on a project 25% of their time for the entire project, regardless of when it starts or ends. How do I set that up?

2) I have a fixed pool of days of work that needs to be spread evenly across 'n' resources for the duration of the project. This should then take away some small fraction of availability of those same resources for other tasks (basically allocating specific overhead tasks). How do I do this?

As Mark is looking to schedule resource work over the entire project’s duration, the temptation would be to simply use a project summary task. Unfortunately, a project summary task isn’t really a task at all. It is merely a mechanism that rolls up duration, work and cost from the “real” tasks within the project.

What Mark therefore needs to help him is a “Hammock” task. Hammock tasks (as they are commonly known) span between two parts of a project. In Mark’s case this is between the project’s start and end dates; but hammocks can be used to span between any two points within a project’s schedule. Once created, resources can be assigned to hammocks to represent project overheads. Creating a hammock task is a fairly straightforward thing to do:

1. Create a summary task at level 1 of the project’s outline. If you create this task at the top of the list of tasks or at its base, this will make the summary task easier to identify.

2. Hierarchically beneath this summary task, add two Milestones with no fixed dates against them; i.e. their Constraint Type is ‘ASAP’. Give these milestones recognizable names; such as. “Hammock start” and “Hammock end”.

3. Within the main body of the task list create two milestones entitled “Project start” and “Project end”. Ensure these milestones are linked to the first and last tasks (or summary tasks) within the project respectively. Ideally, these milestones should not be embedded within a summary task.

4. Create an F-S link from your “Project start” milestone to your “Hammock start” milestone. Repeat the process for the “Project start” and “Hammock end” milestones.

You will now have created a hammock task. It will start when the project starts and it will finish when the project finishes. Any change to the start and finish of the project will automatically be reflected in the hammock’s duration and its dates. The next step is to assign some resources:

• To reflect assigning 25% of a person’s time over the project duration, simply assign that person to the hammock task, choosing 25% as the Assigned Units value. You can use the Assign Resources dialog or a Task Form to do this. As the hammock is a summary task, it is Fixed Duration in type. As such, the work for the resource will be calculated as Task Duration x Assigned Units. All this useful information is displayed within the Task Form view

• To assign work for several resources out of the pool, these resources can also be assigned to the hammock. Due to the scheduling rules regarding summary tasks, their non effort-driven status means that all assignments against summary tasks are independent of one another. Thus, Mark will have to apportion the total work for the pool between each pool member. This in turn will calculate the assigned units by the formula: Assigned Work / Task Duration = Assigned work. The remaining availability for each resource can then be seen within the Resource Usage view.

Download scheduling_projectwide_resource_overheads.mpp

Project Plan notes:

1. The start of the hammock task is controlled by the “Project start” milestone as this is the earliest task in the project’s schedule. The end of the hammock could be controlled by either the “Project end” milestone, or the end of “Summary B” (chosen in this case for illustration purposes), as either of these are scheduled at the end of the project.

2. All resources within the resource pool have max units (availability of 100%). The resource Usage view illustrates:

• The resource “Management resource” is assigned to the hammock task at 25% units to represent an overhead against the project. The assignments at 75% for this resource against “Task A1” and “Task B2” show work against real tasks and illustrate how remaining availability can be consumed.

• The resource “Pool Member 1” does not exceed their max units. This is because the sum of the assignments for this resource against parallel tasks “Task A2”, “Task B1” and “Hammock” is less than 100%.

• The resource “Pool member 2” is overallocated. This is due to an assignment at 100% units (the default) against “Task B1” and an 8% unit assignment against “Hammock”. You should therefore be careful not to allocate any resource greater than their remaining availability when resource overheads are being scheduled.

• To display Remaining Availability within the Resource Usage veiw, simply select this option by choosing Details from the Format menu.

• The Gantt Chart view has been customized to highlight the hammock task to differentiate it from normal summary tasks. In this instance, the Bar for “Hammock” has been formatted to a different bar shape and Resource Names have been appended as bar text.

This useful hint and tip came from Project Mentor, our computer based training package for Microsoft Project.

Posted by Andy Jessop

Comments

[Jim Garrard]

As MS Project experts you should know better than to link tasks to summary tasks. In this example you linked Project Start (line 1) to Summary A and you linked Summary B to Project end (line 8). A better way to show relationships so that a schedule would ebb & flow as task duraitons change would be to link Project Start to Task A1 and Task B2 to Project End.

[Trevor Rabey]

While this is a useful example which illustrates some of the features and behavior of MSP, there are a couple of things done here which need a comment.

What is more usually referred to as a "hammock" task (see newsgroup microsoft.public.project) is made by copying the start from some cell, in this case the Start of the Project Start Milestone, and then selecting the Start of the hammock and then Edit, Paste, Special, Link, ...similarly for the Finish end. Then the hammock shrinks or grows as either of the dates change.

It is not good modeling practice to use the Summaries as either Predecessor or Successor. It creates problems and is unnecessary.

Also, it is not good modeling practice to assign Resources to Summaries.
Again, creates problems and is unnecessary. It produces unresolvable over-allocation. Also, since the "Analyse Time Scaled Data In Excel" macro/wizard in the Analysis Toolbar trawls Cumulative Cost and Work from Tasks only, it produces incorrect totals.
Generally, it is not good practice to use Summaries for anything except headings, no links, no Resources, no Fixed Cost.

The hammock has to be able to stretch and shrink, and the Task Type cannot be Fixed Duration if this is to happen. There has to be a decision about what will happen to the Work and Units if the hammock duration changes. Making the hammock Fixed Work will mean that if the duration changes the assignment units will change. It is easy to test both situations.

These are only suggestions, just my opinion, just 2c worth.

[Andy Jessop]

OK Jim. Hand’s up. Creating links between tasks and milestones IS the preferred way to schedule a project; as opposed to linking to and from summary tasks. The published example was there to illustrate merely how to create a ‘hammock’ task. I took the shortcut of linking to and from summary tasks to merely show that these kinds of links are possible, but not to necessarily promote the practice.

When I train people, I take time to explain the pros and cons of linking; making people think “what needs to be done before this task can start” – its predecessor(s). As I’m sure you are aware, many Microsoft Project users simply enter a row number in the ‘Predecessors’ column and leave it at that. There are also many Microsoft Project users who don’t use links at all – merely dragging bars or entering in constraint dates. - I get people to think about listing ALL relevant immediate predecessors. In most cases this will result in the creation of links purely between tasks or milestones. When we then look at analysing the schedule, we can then see that total slack and free slack are calculated and displayed accurately. In certain circumstances I will explain that links to and from summary tasks are valid, but those links should be to/from milestones and not tasks. I’ll make a separate post to explain my thinking on this.