Project's driving me nuts -- help!

[James]

We're currently trying to use Project in an environment that is very
deadline-driven. Our end dates for a project are sacred. This makes it
difficult to work with Project (which would probably otherwise be perfect
for our needs) because I can't seem to convince it to lock in the end date.
It always "helpfully" shifts it around when the scope of the project
changes.

I've tried every combination of settings, options, etc., that I can come up
with, but haven't found the magic combo. I can't tell you how many times
I've set a task to "Must Finish On" a certain constraint date, and then had
project move it around anyway. It's making me mental.

Here's what we're trying to do:

At the beginning of a project, I want to specify the estimated number of
work hours, estimated resources, and a firm end date.

Before a project starts, or during the project, the scope may change. I
want this to change the START DATE, not the end date. If the start date is
too early, I would then know that I need to allocate more resources to it
until the start date comes into line. The start date should move where it
needs to in order to fit the work and the resources, but under no
circumstances would I ever want the finish date to change unless I
explicitly change it.

I know there's got to be a magic combination of options that makes this all
come together, but I haven't been able to find it.

Anyone have any suggestions?

Thanks in advance,

James

 

[James]

By the way -- I'm aware of the general project management notion that
projects shouldn't be planned from the end. If I explain myself better, I
hopefully can avoid some knee-jerk criticism.

We're using this not to plan projects. We have an extensive set of Excel
worksheets that handle project planning. We're only using Project to keep
an eye on projects, and to reallocate resources (which have to shift often
and quickly between projects).

We're planning to keep track of each "project" (we have hundreds of them) as
task line items in Project, so we can allocate at a birds-eye view. All I
really need is a high-level way to allocate resources and see how projects
are progressing based on current allocations.

Because of the nature of our work, it's not possible for us to get an early
start on a project. We have an end date and an estimate of work, so the
start date is a simple calculation based on our resource allocation.
Avoiding planning from deadlines is generally a good principle, but there
are exceptions, and we're one of them.

 

[Gérard Ducouret]

Hello James,

In your specific case, you could use, as a first estimate, the "backward
pass" that Project can manage :
Project / Project Information / Schedule from : Project Finish Date
Then, you know when you have to start.
When the project is running, the best way is to switch back to the forward
pass. But you create a End Milestone with a Must Finish date.
Don't forget to create, on this milestone, all dependancies needed to block
all tasks which are liable to mark the end of the projet.

Gérard Ducouret

 

[Steve House]

Actually you're not an exception - I know you think you are but step
back and take a look. You have a deadline that is engraved in granite.
Your problem is to try to figure out how to meet that deadline. You
have a lot of things under your control, but that is not one of them -
very well. You create a project plan in MSP (I know, you said you do it
in Excel but why drive a Yugo when you have a Ferrari in the driveway?)
and you let Project do its thing. Lo and behold it gives you a
calculated finish date that is 6 weeks late. What does this mean? It
means that if you work the plan as you initially conceived it, you WILL
finish 6 weeks late. You have no choice and that is what will happen no
matter what your lovely plan says you'll do because it is physically
impossible to finish on time with the plan and resource assignments you
originally devised. That's a fundamental reason to use software like
MSP - as a reality check to see if you're going to make it or not while
it's still early enough to do something to fix it if it's going to go
wrong. After all, the fact you say "We have to finish by xxxxx" does
not magically make it so - you have to devise some strategy to
accomplish it and that's where Project's calculations come in - it tells
you whether the strategy you've worked out is actually going to worrk.
If it does, great. If it doesn't, as in my example, your ONLY
alternative is to go back to the drawing board and come up with another
strategy, manipulating the things you actually do control like scope and
resources until you come up with a plan where the calculated finish
meets the required deadline.

Why avoid scheduling backwards? It's really simple - scheduling
backwards means that all tasks will be scheduled as late as possible
that meets the deadline. In turn that means that if anything slips, no
matter how trivially, you will inevitably and unavoidably miss your
deadline, no question about it. By doing so you removed all possible
"wiggle room" to fix problems that arise, as they always will, and still
meet your required finish date.

All that being said, in the Project menu, Project Information screen,
choose "Schedule from Finish Date" and enter the required date. Project
will behave the way you say you want it to. But I'd strongly urge you
to go the other route, setting a logical tentative start date, create
the plan, links, and enter the assignments and see if it meets your
deadline. If not, modify the assignments or start date until it does.
If you later have to modify the scope, you'll immediately see the impact
on the schedule and can adjust the assignments accordingly. By
focussing on continually scheduling the start date to the latest one
that will hit the deadline, any scope change that comes AFTER that date
when the project has started and that increases the duration is always
going to blow your finish out of the water and you WILL finsh late, you
simply have left yourself no options.

 

[James]

Steve,

I appreciate the feedback, and I understand your perspective. In our
situation, though, there are no circumstances under which a deadline will be
missed. We can reduce scope or increase resources, but the finish date will
never move. We also don't have the option of finishing before the deadline,
because the nature of our work requires that it be done right up even until
the final minutes, so we can't get it done early.

Also, we're not tracking individual tasks within a project. We have other
ways of doing that. We just need a way of visualizing current projects and
seeing how the start dates change based on resources and work quantity.

Given the fact that we can't finish early or late, but have to finish
exactly on a specific date, and because we're tracking independent line
items instead of an interconnected set of tasks, having to manually tweak
start dates to make the end date match something we already know doesn't
seem to make sense. We've tried it, and it winds up just being busywork.

All this being the case, we're trying to figure out how to use project to
manage variations on resources and scope without it trying to help us by
moving the finish date.

Thanks,
James

 

[Trevor Rabey]

James, as long as you cling to these precious notions that your particular
type of work is an exception and that normal rules of the Critical Path
Method (that's what MSP is) don't apply, then all of the experience and
expertise that are available to you on this group (and it is considerable)
are of no use to you, and your investment in MSP is a waste of money and
time.
If you want the pain to go away, if you want the CPM and the software to
start working for you the way it can, give up your opinions and go with the
flow.
This situation arises many, many times in this group and it just illustrates
over and over how much people can come to so love their opinions and their
personal view of "how it should be".
Steve seems to be endlessly happy to give out perfect and comprehensive
advice to people who seem to value it not at all. If I were you I would take
it.

 

[Matthew McDermott]

James,

You have half the equation by setting a "Must Finish On" date..We set it on
the last task called "Project Complete".
The rest of the plan is free to move within the calculations of work
required to complete the plan. As actuals are applied to the plan the end
date does not move. Now here is the important part...pay attention to the
available slack on each task. If you set your Project Complete with a MFO
date that give you some slack, then manage the slack you will be able to
accomplish what you are trying to do.

When the scope grows to exceed the project schedule, slack will go negative.
Following a plan update that results in negative slack, you add resources
(or reduce scope) to restore positive slack. Do this every week and you will
be successful.

The slack value is calculated for you by project (the Ferrari that Trevor
mentioned). The field is not displayed by default. You will have to right
click on the table and choose to show it.

Hope this helps.

Matthew

 

[Steve House]

How can it be that there are no circumstances where a deadline could
possibly be missed? I understand completely that any date other than
the specified one is totally unacceptable but these are human endeavors
and c**p happens. There's usually no physical law of nature that can
make a project end on a certain date under any and all possible
circumstances. True, you may be out of a job or even out of business if
it doesn't hit the required date but that's a different issue. What
happens if a key resource gets hit by a truck and there is no
replacement? A production facility is wiped out by a fire? There's a
SARS outbreak in your city? Someone screwed up and left out the
requirement of a key deliverable that you only discover the day before
it's due?

I'm not suggesting that you let the actual real-world finish date move
about - far from it. But the CALCULATED date in project is only an
INDICATOR of what will happen if you work your plan as presently
outlined. It shows whether your currently scheduled plan is going to be
successful or not, success being defined as the date you will finish
when working as scheduled matching the required date you must hit. If
Project calculates a different date from the target it doesn't mean you
have to accept it, it means you must change your project plan - the
scope and resource assignments - or your project will fail. So you
change the scope and assignments and see if the calculated date moves
closer or farther from your target. You repeat that process iteratively
until Project's calculated finish matches up with your required finish.
NOW you have a plan that you can say with a high level of confidence is
do-able and will actually accomplish what you need it to. Your plan has
actually moved away from wishful thinking and become a "work order" that
spells out precisely what has to happen when by whom in order for you to
meet your business objectives and gives you a predictive model of the
project process itself to allow you to immediately see the impact of
deviations early enough to fix them.

It is imperative to realize that a project plan in MS PRoject is not
just a simple list of what you plan to do where you check-off progress.
The plan is a dynamic model of the behavior of the project that allows
you to predict what will happen as conditions change, thus giving you
the ability to manage the project proactively to meet your objectives
instead of simply reacting as changing circumstances present themselves
and hoping it will work out.