No pressure or anything! (HA!) (Long)

[lamby74]

My boss has charged me with the task of:
being able to:

1)get back to a reliable schedule if we get off-track (meaning when Project
"messes up" our original timeline - which he wants FROZEN in time no matter
what resources we throw at it)
2)PREDICT with 100% accuracy what will happen in Project with every button
click.
3) EXPLAIN why Project behaves the way it does.
4) explain HOW does it calculate???

I am afraid that in the end I will have to tell him I can't completely do
this and my rear will be in a sling (and then my kids won't eat, the mortgage
will fall behind, etc, etc).

My hypothesis to #1 was that by going to
Tool-Options-Calculation-Manual-and Click the Calculate button this would
un-do any shifts in our timeline (in Gantt view). however on testing this
hypothesis for consistency, I think this is not correct.(???)

My answer to #2, #3, and #4, I think, will be this:

I can predict in general what it will do, but that's it. I "get it" that it
calculates on w = d*u (why beat a dead horse? LOL!). But how can I predict
every time what it will do? I mean it all depends on how a task is set up
(task type), effot-driven vs. non-effort driven, what are it's
pred/successors, what are its resources, are those resources assigned to its
pred/successors.
I mean mathematically, I can't explain WHY (For Example...)it moved Resource
Person #1 from working 8 hours on a task today the 27th all the way over to
working on that task for .2 hours on Wednesday Oct 30. and so on....

Am I right? Is there a way to predict with mathematical certainty what it
will do based not only on inputs of w or d or u, but also of the rest of the
schedule that we all KNOW are also a part of this calculation. I mean w=d*u
is a completely watered-down explanation of HOW project schedules, correct?

Am I correct to when I say that I think my boss may be asking for the
impossible?
I really need your input, everyone. I am desperate. My boss wants
bottom-line answers and I think because of the very nature of MS project,
that I can't give him bottom-line answers. Am I right about this?

 

[lamby74]

an addendum to my initial post....
my boss wants to be able to show that recources are assigned to tasks, but
have us be in complete control of the overall timeline.
He is frustrated because he can set up an initial timeline and get really
neat looking reports, but that once we "throw resources at it" MSP, OR make
any changes at all to anything after that initial set up, MSP behaves
unpredictable and messes up our timeline. He is confident in the software
only from the DAY 1 set up.

From there on out, it appears to him to be a black hole of unanswered
questions, illogical inconsistencies, and rogue-ish behavior. I can tell him
generalities why MSP did what it did, ie "MSP split task a because we
selected the splitting option, automatic scheduling is on, and because we
have Bob assigned to Task B which runs concurrently, yadda, yadda....., so he
is overallocated...", but he wants a deeper explanation than that.

We KNOW what our timeline is already...we don't want MSP to tell us. We
just want it for the "pretty" reporting.
Give to to me straight all....maybe MSP is the completely WRONG software for
us to be using.

The best I could hope out of this post is for someone to tell me HOW to
completely and RELIABLY and with 100% predictability to TURN OFF MSP's
scheduling engine.

 

[Dale Howard [MVP]]

lamby74 --

I believe you are in a pretty tough spot. Neither you nor your boss seems
to know even the basics of how to use Microsoft Project, nor do either of
you understand how the software actually works. Because of this, your
boss's expectations of both you and the software will be pretty much
impossible to achieve and are destined to fail.

Your questions are too lengthy for a response in this newsgroup. I would
strongly recommend that both you AND your boss take a good 2-day or 3-day
course in how to properly use Microsoft Project. As you seek out a training
partner, I would recommend that you avoid "point and click" training classes
at commerical training centers, and focus instead on using the services of a
Microsoft Project Partner whose curriculum will be based on "real world"
usage of the software.

Feel free to show this message to your boss if you think it would help your
situation. Hope this helps.

 

[lamby74]

Thanks for giving it to me straight, Dale, that's what I want to hear.

How about anyone else? I need to hear a variety of opinions.

I want to know if I am going to hear a "Then why are you using MSP in the
first place?!?!" kind of response.

 

[Steve House [MVP]]

I'm not sure on the task splitting you're getting because I don't have
specific information to work with but some general considerations.

No offense intended but IMO you DON'T know what the timeline is. What you
know is what you HOPE the timeline might be, wishful thinking without basis
in fact. If Project is telling you something different from what you
expect, Project's version is more likely to be a valid predictor of what's
going to happen when you go out and try to have resources actually do the
work.

The fundamental problem seems to be that your boss wants to tell Project
what the timeline will be. That's getting it backwards, IMHO. Project's
fundamental job is to tell HIM what timeline he can reasonably expect to
achieve given what needs to be done, the amount of work each part of it will
take, and the assets he has at his disposal to do it. He doesn't tell
Project the timeline; Project tells HIM the timeline that will result from
what he has input as the tasks and resources. If its results don't make him
happy, he can't just kludge it to make it look better by,say, turning off
recalculation, he actually has to change the input - change the project
scope, obtain more resources, find ways to work more efficiently, look for
sequenced tasks that could be done in parallel, etc. If he chooses not to
pay attention, he's trying to force a square peg down a round hole and it's
very likely the project will fail.

W=D*E is not an approximation or a watered-down generality, that is exactly
how Project calculates in every single instance. No exceptions. The task
type influences it in the sense that any linear equation has an independent
variable, a dependent variable, and a constant. We have a task estimated at
5 day and assign someone to it who works 8 hours per day giving 100% of
their attention to it. That means the work required to create that task's
deliverable is 40 man-hours. Now I'm going to change something. What
factors in my equation are the variables and what factor is the constant?
If it's constant work, I can change the duration and have project calculate
the percentage or change the percentage and have project recalculate the
duration. In most cases I think that is the appropriate setting because work
usually takes what it's going to take and there's not a lot of control you
have over it. If it usually takes me a month to write a program module
it's not likely I can do one in 2 weeks just because someone says I have to,
at least not and maintain quality. Or I can choose to hold the duration
constant or hold the percentage constant. What determines the setting? My
understanding of the nature of the work and the resources assigned to it.

If your boss has set up a timeline and it gets scrambled when you assign
resources, that is telling you something valuable. What it is telling you
is that when you have your resources work according to the way you want to
assign them, that timeline is unrealistic. Project is telling him what he
will GET, not just parroting what he wants. If what it calculates after
assigning resources is not what he wants the project to be and the model is
otherwise valid with regard to links etc, he has to do one of two things -
either change his expectations or re-think the resource assignments. (You
might show him this message so he doesn't blame you for the bad news
<grin>.) If he is unwilling to do either, IT IS VERY LIKELY THE PROJECT
WILL FAIL!!!! The reason Project does what it does is to alert you to that
fact early enough to have a chance of doing something to prevent it.

Work can only takes place when resources are there, available to work, and
not otherwise committed to other conflicting tasks. That seems obvious but
it is a point often overlooked by eager bosses. If Bill is scheduled to be
on holiday Monday and he is assigned to a task currently scheduled for
Monday, the task must move to Tuesday so its schedule changes to conform to
when he is going to be there. Non-working time is not scheduled around the
task requirements unless you do it manually, editing the resource calendar
to move nonworking time that is causing tasks to shift unacceptably to days
that work better for you; tasks are scheduled around resource non-working
time as defined by the calendar. Secondly, resources cannot be in 2 places
at once. If I have task A on Monday and also task B and I assign Bill to
both of them and expect him to devote 100% attention to each, he simply
cannot do it. The assignment percentage defines how much work out we get
for each hour of time put in and while we might get less than the maximum we
can never get more. In one hour of duration it is physically impossible for
one person to generate more than one man-hour's worth of work output. If
the person is scheduled for 100% on Task A for Monday and also scheduled
100% for Task B, also on Monday, it is impossible for that to be worked as
planned. You might publish such a schedule but when the time comes to do
the work, he WILL be late for one or both of the tasks, guaranteed! That's
what Project is trying to tell your boss only he doesn't seem to want to
hear it. So how does Project resolve the situation? It moves one of those
tasks to Tuesday (assuming the resource is free) when you trigger leveling.
Your original schedule asked for 16 man-hours of work from one person during
an 8 hour duration, an impossibility - the new one calls for 16 man-hours of
work to be produced during a 16 hour duration period, something that *is*
possible for one person to do. Another option is to edit the resource
assignment level so he's working 50% on each task, thus extending the ending
of both of them from Monday to the end of the day Tuesday, again resulting
in 16 total man-hours of work being done in a 16 hour time period. A third
option is to take the guy off of one of the tasks and find someone else who
is presently idle to pick it up. Or finally just not do one of the tasks
altogether, drop it completely from the plan, if you can get away with it.
Anything else, the project will fall behind no matter what your timeline
says.

You *can* be in complete control of the timeline but you can't just
arbitrarily pull time frames out of thin air and expect them to happen. As
I've said in other posts, the command "Number One, make it so!" only works
in the Star Trek movies. For the real world those timelines are driven by
physical processes, not executive fiat, and to control the timeframe you
must manipulate the factors behind it that actually affect it. If I have to
assemble 100 widgets, one person can do a maximum of 10 a day, I only have
one assembler on the payroll, and my budget won't allow overtime, it will
take at least 10 days no matter whether you like it or not. If I need it in
5 to meet a contract deadline, my only options are to get a second assembler
somewhere or spend the money for overtime. Just plucking a mandate out of
thin air and declaring that I'll have the guy do 20 a day just simply won't
work.

Hope this helps ...

 

[lamby74]

Thanks Steve. You and Dale both gave really thoughtful (and time-consuming,
I am sure, ) answers. I am carefully studying both of your responses and
will be showing them to my boss shortly. I'll let you know how it all turns
out.
In the meantime, I welcome more opinions. The more upfront and honest (even
if hard-edged) the better.

Thanks all.

 

[JackD]

I can't type as fast or as much as Steve House has already done, but on top
of the truth he has told you, here are some helpful hints. They are
interspersed in your post below:

--
-Jack ... For project information and macro examples visit
http://masamiki.com/project

..

My boss has charged me with the task of:
being able to:

1)get back to a reliable schedule if we get off-track (meaning when Project
"messes up" our original timeline - which he wants FROZEN in time no matter
what resources we throw at it)

Go to tools menu. tracking. save baseline. Then switch to the tracking view
or any other view which displays the baseline.
There is not much you can do to screw up the baseline except deleting tasks
or overwriting it by accident.

2)PREDICT with 100% accuracy what will happen in Project with every button
click.

No one can unless it is a simple case, Project is supposed to do this for
you. One doesn't expect to know the bottom line in a complicated spreadsheet
before excel calculates it. Project is at it's heart just a schedule
calculator. You write the equation, it does the work. You can practice
writing equations by developing simple schedules (with two or three tasks)
and trying out the various settings. This is a very good way to learn.

3) EXPLAIN why Project behaves the way it does.

It is all explained in the help. You just need to read it and read it again
and then one more time to be sure. Did I mention practicing on small
schedules.

4) explain HOW does it calculate???

See above and above that.

I am afraid that in the end I will have to tell him I can't completely do
this and my rear will be in a sling (and then my kids won't eat, the mortgage
will fall behind, etc, etc).

My hypothesis to #1 was that by going to
Tool-Options-Calculation-Manual-and Click the Calculate button this would
un-do any shifts in our timeline (in Gantt view). however on testing this
hypothesis for consistency, I think this is not correct.(???)

No. When you have the schedule the way you want, save a baseline and a copy
of the file. Any edits from this point on will affect your schedule and
there is no undo.

My answer to #2, #3, and #4, I think, will be this:

I can predict in general what it will do, but that's it. I "get it" that it
calculates on w = d*u (why beat a dead horse? LOL!). But how can I predict
every time what it will do? I mean it all depends on how a task is set up
(task type), effot-driven vs. non-effort driven, what are it's
pred/successors, what are its resources, are those resources assigned to its
pred/successors.

This is true. It all depends on the equation and conditions you have set.
Try some practice schedules with tasks set to various types (effort driven
or not, Fixed work, fixed duration, fixed units). Project is supposed to
give you an answer. If you have a correct model it (generally - there are
cases where there may be a bug) gives you a correct answer. This is the
whole purpose of the tool.

I mean mathematically, I can't explain WHY (For Example...)it moved Resource
Person #1 from working 8 hours on a task today the 27th all the way over to
working on that task for .2 hours on Wednesday Oct 30. and so on....

Am I right? Is there a way to predict with mathematical certainty what it
will do based not only on inputs of w or d or u, but also of the rest of the
schedule that we all KNOW are also a part of this calculation. I mean w=d*u
is a completely watered-down explanation of HOW project schedules,

correct?

Yes, but at a certain point it becomes rather complicated and overwhelms my
brain. To retain sanity, I simplify my schedules to a certain extent and
only model what it important. I also do not worry about the occasional
minute or even day that it may be off. In any event, plans and predictions
of the future can not be 100% accurate. Expecting that they are is, to put
it mildly, insane.

Am I correct to when I say that I think my boss may be asking for the
impossible?
No.

I really need your input, everyone. I am desperate. My boss wants
bottom-line answers and I think because of the very nature of MS project,
that I can't give him bottom-line answers. Am I right about this?

I think you can give him bottom-line answers with a little practice. They
may not be the answer he wants, but project just does what it is told.

-Jack

 

[Rob Schneider]

No debate needed. Steve and Dale have given you the "right" answers.

Focus your energy on getting your boss re-orientated and re-trained.

 

[James G]

Excellent answers by all!

We are controlled by a Director (and not all that old) who prefers to run
multi-million $ projects via the use of pencils and colouring-crayons. He
wants what your boss wants....and its embarrassing to listen to his
tub-thumping, bible-bashing, Utopian expectations of the software. The only
certainty is that if each resource does exactly the quantity of work
scheduled, on whatever day, and absolutely nothing changes...then you will
complete the project on the day that the programme says. However, there are
very few people who really appreciate the complexities, subtleties and
nuances of the dynamics of design-engineering. This is mainly due to the fact
that they ignore the basic tenet: W=D*U, and each person can only do one
thing at a time.

MSP is not perfect...no software is perfect. It has some *interesting
characteristics*...and they have to be learned via basic experimentation.
I've been doing this for six years....and I can only predict with 98%
certainty what will happen if I press button *X*.

If it's any consolation, I was "politically removed" from a project. My EV
Analysis (directly from the programme) was telling me that we were incurring
a massive over-spend via a SPI of 0.76. I produced the graphs etc....but they
never bothered listening. It just so happend that the client was doing
exactly the same thing, but using Primavera...and his result was a SPI of
0.77. It was only when the client told our Director, that Mr. Director took
any notice. Anyway, they blamed MSP, blah, blah, blah...but they *had to be
seen to be doing something* so they removed me. Mr.Director still doesn't
believe in using MSP...but in using Primavera...but that's only because it
was the client who uses it....so it must be right,...mustn't it?? He
conveniently forgets that it was our programme data that was fed into the
client's programme in the first place.

Tell you boss that even though MSP appears simple...and almost anyone can
get a pretty-picture from it (that being one of it's major advantages)...it
is really a highly specialised piece of software. Many things take a minute
to learn, but a lifetime to master.

Best of luck.

James.G

 

[lamby74]

I am very excited, everyone. I go into a meeting with my boss within the hour.

I took all of your posts to him between yesterday afternoon and the new ones
I found this morning. He is now onto a new line of thinking. Because of all
of you, my boss is ceasing to try to "fit a square peg in a round hole" as
Steve House put it, and is willing to discuss just letting MSP "do it's
thing".

He is willing to try freezing (saving) a baseline, which is the timeline as
he wants it, saving a copy of if in another file so he can see it in Gantt
view if he wants, then let MSP schedule us as it will. He is willing to
discuss just trusting the software, instead of charging me with trying to
predict it with 100% accuracy (only truly possible if I had access to the
algorithms in the code behind the software).

Wish me luck...I'll let you know how it turns out.

 

[Dale Howard [MVP]]

lamby74 --

While you are educating your boss, show him the Tracking Gantt view in your
project. In this view, he can see the baseline schedule for the project
(the gray Gantt bars) compared with the current schedule for the project
(blue/red Gantt bars). This view is incredibly useful to learn whether the
project is on schedule, ahead of schedule, or behind schedule. If it is
behind schedule, you can then make educated decisions about making revisions
to the project to bring it back on track. Hope this helps.

 

[Steve House [MVP]]

You might want to keep in mind and present to your boss that by doing its
calculations Project is actually giving you a model that can predict the
consequences of exercising the management controls you have over the
project. That, in turn, allows you to manage proactively, able to actually
reliably manipulate the project environment so the outcome really does meet
your business requirements. It's not enough to say "we need to be finished
by the first of next year." Project allows you to actually figure out
exactly what steps to take, in terms of organizing the work and deploying
the resources, to make that happen.

Best of luck

 

[John Sitka]

Nice.

You might want to keep in mind and present to your boss that by doing its
calculations Project is actually giving you a model that can predict the
consequences of exercising the management controls you have over the
project. That, in turn, allows you to manage proactively, able to
actually reliably manipulate the project environment so the outcome really
does meet your business requirements. It's not enough to say "we need to
be finished by the first of next year." Project allows you to actually
figure out exactly what steps to take, in terms of organizing the work and
deploying the resources, to make that happen.

Best of luck

 

[lamby74]

Hi all! As promised, I am posting the results of my meeting. Sorry it took
so long - I am only a very very part time employee.....

As a result of your posts, which my boss and I eagerly read, we are both
going to be thinking about Project in a different (and more agreeable) way.
We are going to start to try to use Project in the way it was intended - to
have it schedule us, not the other way around.

We are going to freeze a baseline on set up and view it in Gantt view to
compare how we WANT the timeline to go vs. how MSP says it will go.

I will update as we go, since you have all been so helpful.

 

[Steve House [MVP]]

Excellent! Saving such "trial balloons" is what the 10 Interim Plans are
for and if you're using Project 2002/2003 you have multiple baselines you
can play with as well. The one simply called "Baseline" is the one most
often used to monitor progress. When you get your schedule optimized and
approved you save the baseline before beginning work. This represents the
project as you plan to work it. Then as you work, you update the plan with
actuals. At any point you can use variances and earned value analysis to
compare the work that is actually taking place to the plan you hoped would
go and see if you're on track, ahead, or behind schedule and budget. With
multiple baselines, you can have your desired plan entered as one of the
other baselines or you could use one of the 10 interim plan slots if all you
need is start and finish dates preserved.

(The difference between interim plan and baselines is that interim plans
only retain gross data like task start and finish dates and durations while
the baselines also hold timephased data such as work, costs, etc)

To reflect your business rules in the working plan, take a look at deadline
entries for the tasks. You may need to complete widget waxing no later than
15 Dec according to your contract. Setting that as a deadline on the
"Widget Completed" milestone will give you an indicator in the Gantt chart
where you can see at a glance how you're doing and also a big red flag comes
up if something happens earlier that would push the milestone past its
deadline. Yet another way to compare the plan you need or want versus the
plan you're getting.

 

[Just U S]

Steven Jobs (Billy Gates old Partner)
at apple does movies long long ago easy

 

[Rod Gill]

Hi,

Freezing a schedule in time is very counter-productive. If you don't
accurately update a schedule you:
1) Can't schedule what you need to do to recover the lost time
2) Can't improve schedule accuracy which requires predicting times, tracking
actuals and then learning from mistakes

You can save a baseline that you track progress against. This is recommended
practice.

Yes you can predict what Project will do, but this is difficult and time
consuming if you use Auto levelling.

I suggest:
Saving to Baseline1 after the planning phase
Saving to Baseline2 after the next phase
Save to Baseline before updating your schedule every week

Create copies of the Tracking Gantt for Baseline 1 and 2 to show where you
are now against original baselines.
Use Baseline to show changes each week.

Calculation in Project is basic. w = d*u is a driving formula, but once
Project has a Duration value (which is always in working minutes) it goes to
the relevant calendar to find enough working minutes after the Task's start
date and uses the last working minute needed as the finish date (repeat
where you have multiple resources and use the last minute needed to finish
all resource work as task finish date and time.

So yes you can predict accurately what Project will do but why do it? Why
have a dog and then bark yourself??!!

Project 97 will highlight every field that gets changed when you edit a
field.

Use the baseline to highlight changes made to Tasks when you make edits.

So, I suggest you learn a little more about what drives a Task and I suggest
your boss learn about baselines so that you can have a flexible schedule and
let Project do all the work for you!

Good Luck!

 

[John]

Project 97 will highlight every field that gets changed when you edit a
field.

Rod Gill
Project MVP
Visit www.msproject-systems.com for Project Companion Tools and more

Rod,
I think you meant to say that Project 2007 will highlight changes.
Project 97 (i.e. 4.x) is a bit of a relic in today's world

John

 

[Rod Gill]

Thanks John, maybe me that's becoming a bit of a relic?!!

 

[vikas]

W=DxE has exceptions.
take a task. say duration = 10 days
assign resource A (100%), so work = 10 days
so far so good.
ensure task type is FIXED UNITS
ensure task is effort driven.
assign another resource B (100%)
work remains at 10days - good
duration reduces to 5 days - good
resource units = 200% (A and B)
so far so good..

NOW increase assigned units for A to 200%
total units 300% (A @ 200% and B @ 100%)

duration remains at 5 days, work remains at 10 days. WHY WHY WHY?

below is a cut and paste of from MS Project.

task name/dur/type/effort driven/work/resource names
task 5 days Fixed Units Yes 10 days "A[200%],B"

For Lamby, I would suggest, as the PM, you drive MSP, dont let MSP drive you
(crazy). use KISS.

Regards,

Vikas
(e-mail address removed)