Leveling -- How best to set up a production support team?

[Steve Schacher]

Hello.

I've posted this question in various ways over the past year, and I
keep coming back and reading other leveling questions where many
answers contain the advice "never use anything other than 100% units."
I'd like to post my current scenario and let you tell me how to
improve it.

Specifications: We're using MS Project 2002, no server yet.

I have a team of 60 resources who are divided into four sub-teams.
Each resource is assigned several ongoing responsibilities -- end-user
support (help desk), bug fixes, consulting, ad hoc short-term
assignments. Each sub-team leader assigns the assignment units to meet
their own sub-team's needs. Any unused availability is available for
scheduled enhancement work, which we install in monthly releases.

I have all the resources in one resource pool. Each resource has their
own personal calendar, and their personal calendar is based on one of
two "standard" calendars, depending on geographic location (different
holidays, workdays, etc.)

Each sub-team leader has their own baseline activity project plan. The
sub-team leaders will enter their assignment units to the baseline
activities here and save them to the resource pool. Initially, we had
one single task for each activity for the year, i.e., for bug fixes a
team leader might assign Resource A for 40%, Resource B for 25%,
Resource C for 10%, etc. This would be set up as a fixed duration task
so we can spread the work over the entire year. If the sub-team leader
wants to change the assignment units, the work would recalculate.
Sometimes, they will "close out" a task and create a new one with
different assignment units as the work levels vary; otherwise they
will change the existing task. Also, the sub-team leader can add
additional tasks specific to their team to cover short-term
assignments. These ad hoc tasks would work the same way.

The release manager has a separate release plan that also uses the
resource pool. This plan is not a true start-to-finish project plan
(with critical paths), but rather a collection of independent
enhancements over time that need to get scheduled for release. In this
file, we import enhancement estimates from an Access database where
manpower estimates are developed and prioritized by the business. The
imported tasks are fixed work, and are loaded as a three-level
hierarchy where level 1 is the enhancement, level 2 is the things
being changed, and level 3 are the deliverables (functional spec,
technical spec, code/test, etc.) for each change within the
enhancement. Resources are generic skill sets; the resource pool also
contains the generic resources with an availability of 10,000% in
order to eliminate resource constraints.

Each month, we replace the generic skill set resources with actual
people and level the release plan. Our goal is to see when an
enhancement can complete given the following: 1) the resource's
baseline commitments, 2) the resource's other enhancement commitments,
3) the resources planned vacation, 4) business priorities. We level
with the following settings: 1) week-by-week, 2) priority, standard,
3) leveling can create splits in remaining work. Once we get the
resourcing the way that we like them, we use the Deadline field to
mark the target release date for the enhancement and save the plan to
the resource pool. From then on, we use % complete to track the
progress in order to assess the resources' ongoing availability. We
use custom filters to hide completed enhancements.

Until now, each month as I would enter the initial people in place of
the generic resources, I'd look at each person's availability and
enter the available assignment unit for each resource. In the case of
varying availability, I'd approximate to get as close to 100% as
possible, sometimes changing a particular deliverable if it fell in a
time period with higher availability. However, if circumstances cause
a resource to be replaced, I'd have to do this again for the new
resource. Also, if the sub-team leader changes baseline
availabilities, the enhancement assignment units may no longer be
optimal. However, the number of enhancements each month was
manageable, and the result was a tight plan with nice-looking unbroken
Gantt bars.

When I first set up this structure, I played with different schemes
for working with assignment units. When I left units at 100% and
leveled day-by-day, Project would shift all the tasks out past the
finish dates of baseline tasks. When I manually changed the units to
fit the remaining availability, then it leveled nicely. I moved to
week-by-week leveling with splits because it just seemed to eliminate
some over-allocation problems on odd days that weren't really
problems.

Now, however, we have a major upgrade planned that is using many
resources. We are planning this effort in its own project plan using
the resource pool. Tasks are time-boxed. The same activity may be
represented by several tasks because the hours assigned vary by
half-month to half-month. Resources were assigned to these tasks and
saved to the resource pool. Now we needed to assess what this does to
our ability to meet the enhancement demand, both new work and work
underway.

I decided to try assigning everybody at 100% to everything to see if
simplifying this would still give me the same results as manually
setting the assignment units. It still shifts everything past the
finish of baseline tasks. When I level week-by-week, what happens is
that on a daily basis, the resource is under-allocated, and all the
remaining time is shoved into Friday, causing an over-allocation.
Since I set my timescale to Months/Weeks, the resource graph shows
everyone at 100%, even though a daily graph might show
40%-40%-40%-40%-340%. The Gantt bar looks like a spectrograph, with
lots of broken lines separated by dots. It does appear that higher
priority tasks are finishing before lower-priority tasks, but it also
looks like Project is trying to start them all at roughly the same
time. Also, there are some weeks of under-allocation by as much as 70%
utilization.

As a test, I took one resource and manually entered their units on all
their tasks. The result was to shorten their overall duration by three
days. It didn't seem worth it to me to go back to manually entering
the units for that little optimization, considering the fluidity of
the upgrade estimate and resource decisions. In previous posts, I
asked about leveling contours that are essentially "fill in the gaps"
contours like NIKU's Project Workbench does. I do understand the MS
Project only delays work and breaks up work, but does not adjust units
on a day-by-day basis in order to fill the gaps in availability.

Am I setting things up as best as I can? I can't see how always using
100% availability can work here considering the way that we have
baseline activities that enhancements must schedule around. I'd hate
to have to keep manually entering remaining availability on
enhancement assignments each month once the upgrade is complete.

I know this was long. Thanks for making it this far.

Steve Schacher

 

[Jan De Messemaeker]

Hi Steve,

To use leveling at its best and indeed make it fill in the gaps these gaps
have to be time gaps, not capacity gaps.
When the "background work owners" instead of filling in a percentage, define
their tasks as recurring tasks (for instance 15% would be a 6 hours task per
week @100%) you can then define your release tasks at 100% and leveling
would give a perfect result.
The advice to only use 100% should be continued till the end.
The problem is that people tend to mix two methods of leveling : one manual
(by changing short interventions into a few seconds of work every minute)
and Project's logic, and the match is often poor.

Believe me, I have a customer wher this works.

 

[Steve Schacher]

Hi Steve,

To use leveling at its best and indeed make it fill in the gaps these gaps
have to be time gaps, not capacity gaps.
When the "background work owners" instead of filling in a percentage, define
their tasks as recurring tasks (for instance 15% would be a 6 hours task per
week @100%) you can then define your release tasks at 100% and leveling
would give a perfect result.
The advice to only use 100% should be continued till the end.

Thanks, Jan. I'm going to experiment with this. I've done a little bit
already.

Some initial questions:

1) If my "background work owners" each have different percent
assignments, then I will need a separate recurring task for each of
them instead of a single recurring task with multiple resources
assigned?

2) It looks like I can set up the recurring daily workday task with a
duration of .15d to make the resource 15% available. I could teach the
sub-team leaders to make the duration the desired percent. Even though
the top-level task has the default priority, the recurring tasks have
a priority of 1000, so this will keep the task from leveling, which is
good.

3) Since the recurring task setup box doesn't allow resource
assignments, I will then have to expand the task, select all the
recurring tasks, and then make the resource assignment using the task
information screen. Does this sound correct?

4) I notice that the recurring task doesn't know the resource at setup
time, and when I assign a resource with a personal calendar that has a
day off, the recurring task for that date is bumped to the next day,
doubling the task for that date. This means that I'll have to watch
for this whenever a day off is planned, which I may not know about. Am
I doing this right?

Thanks.

Steve

 

[Steve Schacher]

Did anyone actually understand that! (all in the best possible taste, of
course!!)

I did. I'm working on mocking up a test to see how it will work for my
situation.

I'm trying to figure out how to make working with the recurring tasks
less cumbersome right now. I've read here how assigning the resource
to the summary level pushes the assignment down to the recurring
tasks, but I'm not seeing that happening. I have to expand the task,
highlight all the recurring tasks, then use the task window to assign
the resource. Or, I can use the resource assignment button, that that
is a much slower process.

Then there is the question about personal days off moving the
recurring tasks -- I would have preferred to see them ignored.

Steve

 

[Jan De Messemaeker]

Hi Steve,

Lot of new questions! I guess I better embed the answers in your text so see
below
And thank you for understanding ) This was the Nth time I explained this
and never had anybody not understood at all!

Greetz,
--
Jan De Messemaeker
Microsoft Project Most Valuable Professional
http://users.online.be/prom-ade/index.htm
32-495-300 620

"Jan De Messemaeker" <jandemes at prom hyphen ade dot be> wrote in message

Thanks, Jan. I'm going to experiment with this. I've done a little bit
already.

Some initial questions:

1) If my "background work owners" each have different percent
assignments, then I will need a separate recurring task for each of
them instead of a single recurring task with multiple resources
assigned?

It's not absolutely necessary (you could edit the work in Task Usage View)
but for the sake of clarity I do recommend one recurring task per person.

2) It looks like I can set up the recurring daily workday task with a
duration of .15d to make the resource 15% available. I could teach the
sub-team leaders to make the duration the desired percent. Even though
the top-level task has the default priority, the recurring tasks have
a priority of 1000, so this will keep the task from leveling, which is
good.

The top level task has no resources adssigned to it so its priority is irrel
evant (as you probably already found out)

3) Since the recurring task setup box doesn't allow resource
assignments, I will then have to expand the task, select all the
recurring tasks, and then make the resource assignment using the task
information screen. Does this sound correct?

On your other mail, with astonishment I noticed your allergy towards the
Resoure assignment box which is not the slowest but doubtlessly "a" fast
assignment method.
It is when you assign the resoruce to the summary (recurring) task through
this window that the assignment is "spread" to the individual tasks.

4) I notice that the recurring task doesn't know the resource at setup
time, and when I assign a resource with a personal calendar that has a
day off, the recurring task for that date is bumped to the next day,
doubling the task for that date. This means that I'll have to watch
for this whenever a day off is planned, which I may not know about. Am
I doing this right?

I'm afraid so. You could write a formula in a flag field comparing Start to
Constraint Date and filter on that flag if the volume is high.

HTH

 

[Jan De Messemaeker]

Glad the guy who needed it did understand - For a moment I was afraid the
understanding of this logic was by nature restrained to Belgians (who up to
now had all understood this when I explained) but no, Steve got it.

 

[Steve Schacher]

Jan, thanks for taking the time to help me.

On your other mail, with astonishment I noticed your allergy towards the
Resoure assignment box which is not the slowest but doubtlessly "a" fast
assignment method.
It is when you assign the resoruce to the summary (recurring) task through
this window that the assignment is "spread" to the individual tasks.

I guess that all I was saying here was that the resource assignment
window takes a while to load up on my workstation. Selecting all the
recurring tasks and the using the task information button does the
same thing, only faster. However, it has the added burden of having to
expand the recurring tasks and then selecting them. Not an issue at
all.

I'm concerned about the number of recurring tasks that might be
created in my situation. Some simple math: let's say 30 resources x 5
recurring tasks x 260 workdays in a year. That's 39,000 recurring
tasks in my project plan. I can probably reduce the 5 recurring tasks
down to 1 if my sub-team leaders consolidate their baseline activities
into one "baseline support" task, so that makes it 7,800 recurring
tasks. These tasks will be spread unevenly across the individual
sub-team baseline plans (figure resources split 15/10/5 into three
plans). Then, each sub-team leader might add additional recurring
tasks for short-term time commitments. And this is all for just one
year. Since we are now scheduling work into next year, I need to
include next year's baseline activities as well.

I am conducting a test right now. I used MS Access to generate a load
file of tasks simulating recurring tasks (I can't import a recurring
task, just individual daily tasks under a summary task). I used Access
because I didn't want to enter thousands of recurring tasks. I didn't
do all 30 resources either. What I see so far is that leveling takes
much longer than before, as I suppose is to be expected. Resource
Usage windows are very cluttered with each day's task, where it used
to have just the one line for the task. The leveling is giving me good
results at the daily level, although I didn't generate baseline tasks
for all of my resources, so I can't see a true overall picture of
results.

So, I'm beginning to conclude that, while this approach works, it
seems like an extreme burden to work around a feature that Microsoft
ought to provide, which is a "fill in the gaps" contour feature to
leveling.

Any comments?

Steve

 

[Jan De Messemaeker]

Hi Steve,

First, let me tell you that I share your problem with the lack of a fill the
contour feature in leveling. I have asked MS for it several times, but as
the scheduling engine hasn't been updated since 98 (all new features were on
the outside) I don't even hope this will anyhow get into the product.

This being said, after reading your note I went back to your original
question a few days ago.
Therein, you said you would only use your named resources over a month and
you would use generic resources after that.
It seems a bit overdone to me to try to plan generic resourcs on indirect
tasks on a day by day basis! Is thsi granulatity really necssary or are we
talking about (best guess) 10 generic resources with 52 weekly tasks equals
520 tasks? Still a lot I admit, but nowhere near the (unworkable I agree) 39
000 - even if you have to add 30 resources times 20 days for the short term
plan.

HTH

 

[Steve Schacher]

This being said, after reading your note I went back to your original
question a few days ago.
Therein, you said you would only use your named resources over a month and
you would use generic resources after that.
It seems a bit overdone to me to try to plan generic resourcs on indirect
tasks on a day by day basis! Is thsi granulatity really necssary or are we
talking about (best guess) 10 generic resources with 52 weekly tasks equals
520 tasks? Still a lot I admit, but nowhere near the (unworkable I agree) 39
000 - even if you have to add 30 resources times 20 days for the short term
plan.

I think you missed what I said, although your recommendations were
right in theory. I do appreciate the time that you're taking to help
me think through this.

I am using generic resources only when estimating the effort required
for an enhancement. I probably didn't elaborate that the generic
resources are loose skill sets used as placeholders during estimating.
Once the enhancement is approved by the business, I import the
approved estimates (which include the generic resources) and then
replace the generic names with real names. It is the real names that
are in the baseline sub-team plans that would require the recurring
tasks.

Once the sub-team leaders supply real names in place of the generic
resources, I level the plan again to determine when an enhancement can
complete. This is why I'd prefer to use percent units to model the
time a resource spends on various baseline activities. I would like to
be able to schedule enhancements around the baseline activities
without having to manually determine the remaining availability to be
entered for each enhancement task.

From other readings on this forum, I gather that there is a
philosophical split on what MS Project is supposed to be used for: 1)
is it for tasks that need to be worked, or 2) is it for workers who
perform tasks? If it is for #1, then the argument is why care about
non-project tasks that a person may also need to do, because that
shouldn't be included in the metrics (costs, etc) of the project. The
tasks are known, and the project manager assigns all the work at 100%
units, levels the plan, baselines it, and tracks progress to the end.
If it is for #2, then we are talking about modeling a resource and all
the things that they do, ongoing or project-related. In this case (my
case), the need to be able to block out ongoing time on a percentage
base, and then to schedule periodic assignments in a "fill in the
gaps" mode by priority is more important. I want to understand the
ongoing baseline commitments of a resource, be able to assign
additional tasks to a resource, and level the plan each month to see
when new work can be completed. I will stack up work for a resource
many months in advance, and sub-team leaders will change the baseline
commitments as help desk activity fluctuates.

If on Microsoft were to include this one little feature, in my opinion
that would make it a complete tool.

Steve

 

[Jan De Messemaeker]

Hi Steve,

OK, sorry.
I still think the day per day granularity for the baseline work beyond
current month is over the top.
HTH

 

[Steve Schacher]

OK, sorry.

I still think the day per day granularity for the baseline work beyond
current month is over the top.

Maybe I misinterpreted the solution. I assumed day-by-day instead of
weekly because I thought that a .15w duration would put the hours into
the first day of the week instead of evenly distributing the hours
across the week. There may be layers of baseline activities that add
up to 30% of a person's commitment. I would like these hours spread
across the week before assigning any enhancement work. These baseline
activities are unscheduled work, so it seems best to average the hours
across the week instead of blocking out time on the first day of the
week.

Steve

 

[Steve House]

There is absolutely no question, at least in my mind. Project is a task, ie
work, scheduling tool. Resources certainly come into the picture because
without resources being available tasks can't happen and the cost of doing
work the resources do constitutes the majority of what you pay for with the
project budget. But it is absolutely focussed on the task schedule and the
costs of getting the specific tasks done, not the resource schedule or their
overall costs to the firm. Essentially we are concerned with the time and
cost of producing the specific deliverable of the project and could care
less what else is happening with the resource. As a PM charged with
creating a specific outcome, all I need to know is when he's available to do
the work I need done and how much it's going to cost me. Anything else he
may or may not be doing is simply not my concern.

--
Steve House [MVP]
MS Project Trainer/Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

 

[Steve Schacher]

There is absolutely no question, at least in my mind. Project is a task, ie
work, scheduling tool.

Thanks for your input.

Are you saying, then, that Project should only be used for
self-contained project tasks, not ongoing support tasks?

If I'm responsible for scheduling tasks, but not project-related
tasks, just ongoing monthly cycle tasks (and I'm including production
support enhancement work as monthly cycle tasks because they come and
go on a regular basis) with a steady resource pool, are you saying
that Project should not be used to model this?

The split in paradigms that I think I'm seeing is that Project is for
a fixed set of tasks with a variable pool of resources (i.e, you can
always hire contractors to cover the work). I'm faced with just the
opposite: a fixed pool of resources and variable work. I want to use
Project to model that. To me, the only thing in my way is the ability
to contour the leveling with a "fill in the gaps" feature that allows
me to add new work to existing commitments and let Project tell me
when the work can be completed based on business priorities.

As it is now, I have to look at each resource's histogram to see their
availablity at various points in time and adjust their units to fit
their availability. That is very inefficient, since the sub-team
leaders are always assigning resources to special efforts for short
durations as the business requirements dictate.

I think that Project is a tool that can (or should) do this, if only
that one feature were added. Project Workbench has it. It's not enough
to just be a task scheduling tool; it has to be both a task scheduling
tool and a resource scheduling tool, simultaneously. I have no
quarrels with the former, it is just the latter that is imcomplete, in
my opinion. It also seems like such a simple function to add.

Steve Schacher

 

[Steve House [MVP]]

While you certainly may be able to kludge together workarounds so you can
use Project, you are correct that it is not designed for managing the
resources required for on-going, line of business activities. A "project"
by definition is a time limited set of definable and quantifiable activities
culminating in the creation of a unique deliverable or result (cf. PMBOK).
It has a discrete start point and a discrete ending at the point when the
deliverable has been completed, after which the project no longer exists and
everyone goes home. Thus projects are closed ended while line of business
activities are continuous and open ended. Setting up a new help desk is
certainly a project. Scheduling the staff and work flow for the help desk
once it's up and running is not. Or another example I use in classes,
building an oil refinery is a project but scheduling its production runs is
not.