Need Feedback on Resource Management

[wbbusby]

I'm heading a project to enhance our use of Project Pro to include resource
management. We've been using Project Pro since Jan '05 primarily as a time
tracking tool (only actuals). We have huge inconsistencies in how projects
are set up and managed (some currently end in 2049) so we know we have some
training issues to tackle. Aside from that we need project managers to be
more specific in assigning tasks loads and having users update ETC. We
currently have approx 400 projects in play.

Have any other Project Pro installations gone down this path? What were your
major hurdles? What level of success did you attain? How much impact was it
on your project managers/users?

 

[Dale Howard [MVP]]

wbbusby --

From the description you gave for your organization's situation with Project
Server, I believe you have major issues that you must address and solve
before you can use the system for resource management. For example,
consider these issues:

1. All project managers must plan, manage, track, and close their projects
using the same tool methodologies. This is especially important when your
PM's do resource assignment planning. Your PM's must know how to show less
than full-time work when assigning a resource to a task. Too many PM's use
old habits from their days of using standalone Microsoft Project and then
carry these habits into the enterprise environment. If you have a resource
who is going to perform around 4 hours of work over a 5-day period of time,
your PM must set the Duration to 5 days and assign the resource at 10% Units
on the task. Too many PM's will simply assign the resource at 100% Units
without giving a thought to what this does to the resource's availability
during that 5-day time period on this project and on everyone else's
projects.

2. If you can get over this hurdle, your next issue would be to require
that your PM's DO NOT assign any resource to a task when the system shows
that the resource is not available. Assigning unavailable resources to
tasks is one of the primary reasons for resource overallocations in an
enterprise environment. Project Server has at least three ways that a PM
can determine whether a resource is available to work on a task in a
specific time period, yet many PM's do not look at this information, or
simply choose to ignore it. And then they assign an unavailable resource to
a task and wonder why their resources are formatted in red in the Resource
Sheet view. If everyone is accurately assigning resources to tasks, and I
need a resource to work full-time on a task next month, and the system tells
me that the desired resource is not available, then you also need a
procedure to determine what the PM is supposed to do in that situation. Do
they bring in a contractor to perform the work? Do you delay one of the
projects so that I can use the resource on my project?

3. Another issue is that you need to guarantee 100% compliance with
timesheet reporting by team members using your company's reporting
methodology. Depending on your organization's default method of tracking
project, your methodology could include any of the following:

-- Team members enter actuals on a daily basis and update actuals to their
PM by Friday at 5:00 PM
-- Team members enter Actual Work on a daily basis and adjust the Remaining
Work estimate before updating the actuals to their PM
-- Team members add Notes to document all tasks in which they adjusted the
Remaining Work value
-- Project managers update actuals into their project plans on Monday by
10:00 AM

Refer to the following link for more information about methodologies on
tracking progress:

http://www.projectserverexperts.com/Shared Documents/TrackingUpdatingBestPractices.htm

4. The 2049 issue you describes what happens when #1 and #2 have not been
done, and when a PM levels multiple projects using Microsoft Project's
built-in leveling tool. This tool can only level overallocated resources in
two ways: delay tasks or split tasks. That's all it can do. Your PM's
need to be taught how to properly use this tool, and how to level
overallocations using any of the other dozen or so methods for manually
leveling overallocations. This type of knowledge is not intuitive, so you
cannot expect your PM's to just "pick it up" by playing around with the
software. Beyond this, you would also need a leveling process when a
resource is overallocated across multiple projects managed by different
managers. Who gets the overallocated resource first, and whose project must
be delayed as a result?

These are just a few of the issues I believe you must address. I will
gladly invite the others to share their insights and ideas as well. Hope
this helps.

--
Dale A. Howard [MVP]
Enterprise Project Trainer/Consultant
Denver, Colorado
http://www.msprojectexperts.com
"We wrote the books on Project Server"

 

[wbbusby]

Dale, very informative. Your response supports much of the critical success
factors we've identified for implementation. We've conducted a preliminary
impact evaluation and are presenting to IT management next week. Given the
assumption(s) that we commit to adhering to the advice included in your
message and change our behavior to adopt more mature processes, what level of
reliable does the tool have to perform resource management for a 300 person
IT organization? Opinions? I realize that's potentially an optomistic view,
but if IT management decides to bite we'll need to hold people to the
expectation of adopting the needed changes.

 

[Dale Howard [MVP]]

wbbusby --

I may be kind of dense today, but I'm not sure I understand your question,
"...what level of reliable does the tool have to perform resource management
for a 300 person IT organization?" Could you please say more about that,
and then I'll do my best to try and answer it? Thanks!

Beyond what I have already said, I would recommend the following to give
your organization a chance at succeeding with Project Server 2003:

1. Implement the software by doing a pilot first
2. Enlist the aid of a Project Parnter, such as msProjectExperts, to assist
you with your implementation (cheesey advertisement)

Organizations that skip doing #1 above run a great risk of failing, simply
because they rush into things and don't take the time to do things right. A
pilot, involving a couple of PM's and a group of team members, gives your
organization a chance to "work out the kinks" in using the system, to learn
how the system really works, and to study what Project Server actually tells
you, particularly in the area of resource management.

Organizations that do #2 above increase their chances of success by working
with someone who has done this before many times successfully (another
cheesey advertisement). Plus, they get to hear my goofy jokes when I'm
teaching the Project Server classes.

--
Dale A. Howard [MVP]
Enterprise Project Trainer/Consultant
Denver, Colorado
http://www.msprojectexperts.com
"We wrote the books on Project Server"

 

[Gary L. Chefetz [MVP]]

WB:

My 2 cents: The reliability of information coming from the tool is not a
characteristic of the tool, but how it is applied. If you achieve the
organizational process maturity required, you will have highly reliable
resource loading data. Keep in mind that this is the **big prize** for your
efforts and is typically the last and most difficult benefit to achieve.