Help, please, with Enterprise Projects

[dm0502]

Our IT department has 8 employees that plan and schedule projects. We have
just started using Project Pro and Project Server recently, and could use
some advice.

The goals are:

- To be able to see what projects are scheduled and when projects are needed
and/or projected to be complete

- A way to manage resource allocations for the 22 employees in our
department (all of which have other work outside the projects to which they
are assigned)

- Tracking project time accurately so that we can use these project plans as
templates for future similar projects

Because we are all very busy with other work, we tried to set up Project and
Project Server as simply as possible. Also, because we need to review
everyone’s projects together, we tried to have everyone use the same task
types.

Currently, we use fixed work for each project. Project managers input the
tasks that need to be completed, determine dependencies, input an estimate of
the amount of work that is needed for each task, and assign resources. Our
resources’ availability percents have been adjusted to reflect how much time
they actually can work on projects (anywhere from 10% up to about 75%).

If a project has a drop dead deadline and the schedule does not fit into the
time line, we adjust the resource allocations where we can to try to get the
work completed in the timeframe, or determine which tasks can be scaled back.

Resources use PWA to update the time worked on tasks, and time remaining if
needed.

This mostly works for us, except, it takes an incredible amount of time to
manage, especially as tasks slip and dates change. Some of us have 5 or 6 or
more projects underway at the same time. To some, it feels as if we are
‘playing’ around with the project, to get it to ‘work’ into a pre-determined
schedule.

Is there anything else we should be doing, or can do, to make this any
simpler for us? One manager wants to use fixed duration to set the start and
finish dates for each task, so that even if work runs behind schedule, or
more is added, the project still shows the date that tasks need to complete.
This does not seem like it is managing the reality of a project, it’s only a
way to make sure your dates always look right.

Any advice?

Thanks in advance.

 

[Gary L. Chefetz [MVP]]

dm:

You're basically asking for someone to explain the world to you in 10
sentences or less.<g> Can you budget some time for training? It doesn't
sound like you really have a situation where fixed work is an appropriate
task type, for instance. It also sounds as though you're struggling with the
update cycles which should work for you if you've got things set up
correctly and you know how to use the update and tracking tools.

 

[dm0502]

Thank you for your response.

We did take some training, and we thought we were approaching this as the
training indicated. Determine tasks, determine amount of work for each task,
link the tasks based on dependencies, and then assign resources. We don't
really want the whole world explained, we are just interested in what others
may be doing in similar situations.

Part of our situation is that our projects are constantly changing, moving
and being put on hold due to other more critical projects and issues. It's
almost takes more time to manage the actual project than it does to do the
work, and, we do have the same people doing both.

Some of our projects are deadline driven, that is, need to be completed by a
certain date. Others are task driven; we need to determine when it will be
completed based on the work and the available resources. In an enterprise
setting, is it appropriate to have different projects using different types
(fixed work and fixed duration) or will that affect analysis of all the
projects as a whole? The department manager needs to be able to use this
tool (or some other) to show where we need additional resources, or why we
can't take on a newly requested project, due to overallocation of resources.

Is there any other training availalble that is designed specifically for
managing enterprise projects using project server? All the ones we found
seemed to only cover it minimally.

Thanks.

 

[Rolly Perreaux]

Thank you for your response.

Is there any other training availalble that is designed specifically for
managing enterprise projects using project server? All the ones we found
seemed to only cover it minimally.

(Shameless plug for Gary and Dale

You might want to check out Gary and Dale's website at:
http://www.msprojectexperts.com/?B

I've taught both of these courses and the material is very good
Lot's of illustrations which in my opinion is Key

Good Luck!

--
Rolly Perreaux, PMP
Project Server Trainer/Consultant

IT Summit Series
Advanced Microsoft Technology Training
http://www.itsummitseries.com

 

[Gary L. Chefetz [MVP]]

dm:

My personal opinion is that it's most appropriate to use the task type that
fits the requirement. In most situations, for most work in most
organizations, Fixed Units works best. The next most appropriately used task
type is Fixed Duration. The least likely to be used is Fixed Work. In other
words, most of the time we now with rather certainty how many resources we
have to work with. Sometimes we're under a duration constraint and will
throw all resources necessary to complete the work or we actually know the
duration of something like how long it takes for cement to cure. The one
thing we're most likely not to know, or that we're likely to predict very
badly, is how much effort it takes to get things done.

It takes a while to get the hang of this. Even folks with years of
experience using Project have a fairly steep learning curve entering the
enterprise environment as even the most beautifully laid out schedules end
up looking like they were used for target practice by the time the project
finishes.

You are absolutely on target by trying to keep things simple; especially at
the beginning, but over-simplification can actually have a paradoxical
affect.

 

[Dale Howard [MVP]]

Rolly --

Thank you for the shameless plug. I'm glad you like our books. Gary and I
labored on them long and hard to make them the very best we could do.

 

[John Sitka]

You are fine dm0502, in fact you are in the best possible situation.

Maybe you want to switch later on but for now stick with fixed work.

Two things though

-maintain calendars for your 22 employees, these calendars are used to block where
the task will take place.
-always book resources to tasks at 100%.
The premise here is do not guess and stagnate your plan with a political idea of brain splitting.
People do their work or they wouldn't be employeed by you. The ins and outs of
their daily task focus is unkownable. Whether you have a day 1 picture of what you want to happen
or not is not going to make one bit of difference once the project begins. The estimate of that work (or duration or units)
is only valid until the first reporting cycle of the current task anyway;

which is....,

by the golden rules of Project Tracking

1.) On task completion
2.) On task change
3.) At end of shift or similar demarcation (because resources have logins)

After that first reporting cycle your resource can contribute a better estimate than a planner ever could.
because they have looked under the hood of the task and understand how to bring "their" certain
skillset to bear on it. You may not be happy with what effort they claim is needed but that is a totally different
thing than project planning. That is, it is either a lack of knowledge on the part of the planner or a resource
that is not as capable of the task as what was once thought. Don't mix the two. Project is to be the tool and
the knowledge base for generating a flow of effort, and an early warning system that more resources may be needed
to meet contractual obligations. Demand disciplined and frequent reporting, this is the single most important requirement
to good project management. You can't make good decisions on what you do not know; so no sense in
going without knowing when the tool is right in front of you.

Also you are coming up against one of the great flaws of human reasoning when it comes to planning anything.
Shit happens but that dosen't mean things won't go well and exceed your expectaions.
Ask yourself how long it will take you to write a series of application config/doc pages.
Then Ask yourself how long it would take if you knew that absolutely nothing else would distract you
when you were writing them. I'd guess if original estimate was 8 hrs the second would be 5 hrs.
Most of the time the 5hrs is easily achiveable and you can plan on that but most folks will not estimate
to that because of the political repercusions of missing a deadline. So we say 8hrs then finish in 5 and wait around 3 hrs for the
next
resource in the chain to pick up where you left off. So we did good works, we are personnally impressed with our performance
but it had absolutely zero extra benefit to the project globally. Crazy but that's how the world works, no chance to do better than
you thought
you could of, because everybody is so locked into their dates. Dates are the only way many folks know how to think. I like the
focused effort model much better. Much more logical. The sun rising and setting does not mean progress is being made anywhere
except along the road to the grave. That's what I think of fixed duration.