Will Project Work For Us?

[Construction Scheduler]

I work with a residental construction company considering switching to MS
Project for project management. One feature is particularly important to us:
We need software that auomatically updates expected schedule dates as
projects fall behind schedule. Specifically, we don't want a schedule that
displays expected start/completion dates that are in the past. We're not
concerned to see that a project is behind schedule (we track another way),
only concerned at what the most likely scenario will be for future work
start/end dates. Is this something that MS Project does?

 

[Jim Reid]

Yes MSP will work very well for you. If you are using MSP Pro alone it will
not be as easy to see resource utilization but it can be done. MSP is very
good at showing the results of a task being late or early and the effects on
the balance of the project

 

[davegb]

Yes MSP will work very well for you. If you are using MSP Pro alone it will
not be as easy to see resource utilization but it can be done. MSP is very
good at showing the results of a task being late or early and the effects on
the balance of the project

I agree with Jim's comment but would like to add that Project is not
very intuitive. To fully utilize it, you need to understand Critical
Path Method scheduling, which is what Project does IF IMPLEMENTED
CORRECTLY. It doesn't automatically do this. The tricky part is to find
training where the instructor knows CPM and how to implement it
properly. There are very few Project trainers around who know this
aspect of using Project. To paraphrase Lewis in Project Management,
Scheduling and Control, "Using sophisticated scheduling software
without an understanding of Project Management merely allows you to
document your failures accurately". I've seen a few clients in this
quagmire, and it ain't pretty. There are a number of such people here
in this forum. I advise you to find such a person and carefully plan
your implementation of Project so you get what you're looking for.
Hope this helps in your world.

 

[John Sitka]

I'd like to know what it is the original poster is actually asking.
It appears that once a task is late, it merely falls off the map,
Therefore one has to ask why was that task in the project in the first
place. Completeness Has to be measured and evaluated or else there is no
definition of the current and future body of work.(remaining). It that remaining work has
no running calculation, it never shrinks, no calculation of future dates is possible.
You are simply rebuilding a new project everyday with a smaller scope. Things that are behind
schedule still eventually need completetion so what's the point, just tell everybody who asks it will
be done in "two weeks". It's as good an answer as any other.

 

[davegb]

I'd like to know what it is the original poster is actually asking.
It appears that once a task is late, it merely falls off the map,

Not following you here, John. What did the OP say that led you to this
conclusion? My interpretation of his message is that he wants to see a
task rescheduled when a predecessor is late, and not shown at it's
originally scheduled dates. I don't think he's saying he wants it
hidden. Am I missing something?

 

[John Sitka]

Specifically, we don't want a schedule that
I think I may have read these two sentences as being the same concept.
I see now they can be read and interpreted as two distinct concepts

1.) Assume the obvious and reschedule all uncompleted work.
2.) the schedule is an operational defintion with no concern to the contractural one.

I read this one
as "It's late", therefore, don't track it.

 

[davegb]

I think I may have read these two sentences as being the same concept.
I see now they can be read and interpreted as two distinct concepts

1.) Assume the obvious and reschedule all uncompleted work.
2.) the schedule is an operational defintion with no concern to the contractural one.

I read this one

as "It's late", therefore, don't track it.

Ok, I see how you interpreted it now. I took that line to mean, "If
it's in the past, don't track it anymore".

 

[Construction Scheduler]

Thanks for all the responses. Please pardon me if I wasn't too clear. You are
on the right track. We're basically looking for scheduling software that is
intuitive, that is, can make 'assumptions'. If a task has missed it's
expected completion date, we'd like software that makes a best-case
assumption that the task will finish, for instance, the next day (best
possible scenario). This will then push forward the expected dates of all
taks that are linked up to the task that has been delayed.

The reason we need this is that, when tracking 80-90 projects at once, it
takes too much time to individually update each one, frequently. The goal is
to give management and subcontractors the most accurate expected schedule we
can. After posing this messege and doing more research, it seems that project
will not do this. Please correct me if I'm wrong. Thanks again

 

[davegb]

Thanks for all the responses. Please pardon me if I wasn't too clear. You are
on the right track. We're basically looking for scheduling software that is
intuitive, that is, can make 'assumptions'. If a task has missed it's
expected completion date, we'd like software that makes a best-case
assumption that the task will finish, for instance, the next day (best
possible scenario). This will then push forward the expected dates of all
taks that are linked up to the task that has been delayed.

The reason we need this is that, when tracking 80-90 projects at once, it
takes too much time to individually update each one, frequently. The goal is
to give management and subcontractors the most accurate expected schedule we
can. After posing this messege and doing more research, it seems that project
will not do this. Please correct me if I'm wrong. Thanks again

Project doesn't make assumptions. If a predecessor task slips 4 days,
it's successor slips 4 days under "normal" circumstances. It depends on
it's relationships to other predecessors. It won't assume that because
you missed a start date, it should reschedule that task to start the
next day. It waits until you reschedule the start. However, when you
reschedule it, all it's successor's automatically move out accordingly.

You could write a macro to move tasks that have missed their start
dates one day out to get the functionality you want. I don't know of
any scheduling software that assumes when a task that missed it's start
date should begin. It would have to have some sort of algorithm to make
such decisions. Sounds tricky to me, unless you just want it to
reschedule a day later in all cases. The Project macro could do that.
Hope this helps in your world.

 

[John Sitka]

The default behavior of Project does have a single button solution to the
"assumption" that you seek. The tracking button allows
Update Work as complete through a settable date
Or
Reschedule uncompleted work to start after.

But either way, you take away value from a schedule with either of those assumptions.
Like I said, you have removed any "real" calculation of the body of work that you have remaining.
And if you don't have that how can you expect to have a calculation of when estimated
completion will occur. Based on assumption? Well at it's most basic that "assumption" can be expressed
that with each passing day progress is made, "the sun rises therefore we must be closer to the goal."
I think that is dubious and I've never seen an example in the real world.
In order to accomplish anything (other than radioactive decay or intrest growth on loans), focused
effort has to come to bear directly on a task, and that progress needs evaluation to know if anything was indeed
accomplished. Walking up and down stairs you do work but you end up in the same spot, no closer to the goal.

So you say it is too much work to track everything...
It can be a huge amount of work At some point you have
to evaluate how you can gather the reality of what is going on "out there".
Evaluate this sooner rather than later.
Consider these rules
Update tracking on...
Task change
Task completeion
End of shift.

Seems like a lot right, but look around your everyday life and see how many tasks have a little final step
that signifies the end of one and a beginning of another. Wake up and drive to work for example...
Brushing your teeth finishes with a rinse(track),
getting dressed finishes with shoes(track),
leaving the house finishes with locking the door(track)
and the most definitive one of all.
A crap ends with a wipe(track).
Each one of those tasks is incomplete without the final step, just like any task someone is getting paid to
do is incomplete if tracking is "NEEDED"(see how to define the NEED, below). There is to be no discussion about this.
Now the problem is software solutions to help with this are weak, and even the people who manage
for a living would rather deal with the assumption model rather than fix the tracking problem. Get a robust
disciplined tracking system/process in place, and then move on once the solid foundation that tracking collection provides.

Lets put this into a construction scenerio,
Pour driveway and sidewalk.
maybe this breaks down as
tasks =
remove topsoil,
bring in gravel,
form,
pour and finish remove forms
OR it could be
task =
pour driveway and sidewalk / remove forms

so your task definition is the basis of tracking as well, the task definition should not only help the level and clarity on the
plan, the big
grin I see on so many peoples faces when they build pretty Gantt charts, beaming with pride about how "organized" they are,
But they should support and encourage a good tracking model. It's simple for anyone looking at the task "pour driveway and sidewalk
/ remove forms"
that this represents a completed task when tracking says it's done, All other tasks have been absored in an abtracted obvious
concept.
So the cell phone rings and the the report comes in "forms are off on lot 691"
Now here is a valid "asumption" . The driveway and sidewalk are done. (single tracking point and in your case x 80 but doun't be
put off by high tracking
point counts. They take almost no time, it is just human nature that fights accountability that makes them seem like or argued as
"extra work", that's BS. In fact
each tracking is indeed a celebration that needs to be shared, the punch list complete but sitting in the cab of the truck should
not be kept private, it's the most
valuable part of the company)

Just one tiny example, Apply this IDEA to any task or set of tasks. Think negatively about task definitions, the obvious is not the
always the best because we
have a lifetime of planning then "internalizing" tracking becasue it's so obvious to us. But now, in a multi project team
environment, internalizing is no longer an
option and the basic transparency of event progress needs to be recorded.

So central to what you want to achieve is how are you going to "feed the beast" of a scheduling engine
with the data it needs to be anything more than just some pretty static pictures.

I wanted just to present the idea of how vital collection of tracking data is. Compromises will always have to be made
but as you look for solutions keep this in mind that if the tracking model is based on too much assumption, of what value
is the schedule?

 

[John Sitka]

oops, this

just like any task someone is getting paid to
do is incomplete if tracking is "NEEDED"(see how to define the NEED, below).

should read..
just like any task someone is getting paid to
do is incomplete if tracking is "NEEDED"(see how to define the NEED, below) and not done.

 

[davegb]

The default behavior of Project does have a single button solution to the
"assumption" that you seek. The tracking button allows
Update Work as complete through a settable date
Or
Reschedule uncompleted work to start after.

But either way, you take away value from a schedule with either of those assumptions.
Like I said, you have removed any "real" calculation of the body of work that you have remaining.
And if you don't have that how can you expect to have a calculation of when estimated
completion will occur. Based on assumption? Well at it's most basic that "assumption" can be expressed
that with each passing day progress is made, "the sun rises therefore we must be closer to the goal."
I think that is dubious and I've never seen an example in the real world.
In order to accomplish anything (other than radioactive decay or intrest growth on loans), focused
effort has to come to bear directly on a task, and that progress needs evaluation to know if anything was indeed
accomplished. Walking up and down stairs you do work but you end up in the same spot, no closer to the goal.

So you say it is too much work to track everything...
It can be a huge amount of work At some point you have
to evaluate how you can gather the reality of what is going on "out there".
Evaluate this sooner rather than later.
Consider these rules
Update tracking on...
Task change
Task completeion
End of shift.

I disagree with John on this point. I think, on most projects (plant
turnarounds come to mind as an exception), that tracking once a week
is sufficient. If everyone has to notify you immediately when the
finish each individual task, the reporting time itself can become an
issue. It might even have to be scheduled! Weekly reports documenting
progress are sufficiend in most cases. Remember, the PM is not just
monitoring the schedule. S/he's also monitoring risk, quality, etc.
Time is of the essence!

 

[John Sitka]

disgreement is fine but I would like to see how you would handle the
buldozer that needs to be on five residential builds at once when there are three rain days that week
It is undeniable that if the original poster had daily tracking he would not have his original question,
or lack confidence that the best possible decision was made with regard to those rain days.

So that brings up the question? Where is the software that allows a group of construction supervisors to
dial in on his cell phone and punch in a task ID and a remaining work value. I think the acceptance
of once a week reporting as sufficient is what has kept this software from being commonplace.
And why Project server is viewed as acceptable even though it can't calculate beyond the desktop.

If no one understands what the real solution is they won't ask for that software to be built and we stay in
our current state of "assumptions". Where meetings are spent bickering over priorities and opinion about
best course of action, when speculation about downstream impact is based on instinct and hope rather than
calculation, and resource contention (heck some folks don't even use levelling) is solved by who yells the
loudest rather than by what is in the best intrests of the company (and my profit sharing check).

Again my appeal is to understand the the act of reporting should happen as a few second interaction,
distributed to the individuals who are actually doing the work, This old model of weekly reporting is crippling, but since everyone
is in
wheelchairs no one notices. Project has patterned us to see this as a practical way to operate, and by now is so intrenched in the
business of management that the obvious solution is obscured. The PM should not be part "data entry clerk", making judments on the
validity
of a task update. Work is done or it is not, tasks are complete or they are not. Each resource can be trusted or trained to provide
that information continuously, many times a day if desired, in an optimized fashion.


These comment dosen't help or original poster's question but it is the core of the goal he seeks.
(knowing)

what the most likely scenario will be for future work start/end dates.

I think he should understand where that solution can be found, in the recording of remaining work

 

[davegb]

disgreement is fine but I would like to see how you would handle the
buldozer that needs to be on five residential builds at once when there are three rain days that week

As I said, there are exceptions. The have the bulldozer's progress
reported at least daily, and possibly when he finished each task on his
list. But this doesn't mean that the carpender nearby needs to be
tracked daily.

It is undeniable that if the original poster had daily tracking he would not have his original question,
or lack confidence that the best possible decision was made with regard to those rain days.

Most everything in life is deniable, John! Just browse this and other
NG's!

So that brings up the question? Where is the software that allows a group of construction supervisors to
dial in on his cell phone and punch in a task ID and a remaining work value. I think the acceptance
of once a week reporting as sufficient is what has kept this software from being commonplace.
And why Project server is viewed as acceptable even though it can't calculate beyond the desktop.

If no one understands what the real solution is they won't ask for that software to be built and we stay in
our current state of "assumptions". Where meetings are spent bickering over priorities and opinion about
best course of action, when speculation about downstream impact is based on instinct and hope rather than
calculation, and resource contention (heck some folks don't even use levelling) is solved by who yells the
loudest rather than by what is in the best intrests of the company (and my profit sharing check).

Again my appeal is to understand the the act of reporting should happen as a few second interaction,
distributed to the individuals who are actually doing the work, This old model of weekly reporting is crippling, but since everyone
is in
wheelchairs no one notices. Project has patterned us to see this as a practical way to operate, and by now is so intrenched in the
business of management that the obvious solution is obscured. The PM should not be part "data entry clerk", making judments on the
validity
of a task update. Work is done or it is not, tasks are complete or they are not. Each resource can be trusted or trained to provide
that information continuously, many times a day if desired, in an optimized fashion.


These comment dosen't help or original poster's question but it is the core of the goal he seeks.
(knowing)
I think he should understand where that solution can be found, in the recording of remaining work

My experience, probably quite different than yours, is not that the big
problem on most projects is the immediate reporting of progress. I see
far more cases where:
1. The entire project has been poorly planned. Immediate tracking is
impossible because there isn't a good enough plan to track in the first
place.
2. Quality is paid lip service only.
3. A dozen others I won't go into here.

I worked with a client 2 yrs ago who frustrated me immensely. They
brought me in to show them how to track their projects better. They
were tracking every resource to tenths of hours! But they had nothing
but a preliminary schedule to work from, which changed every week as
they figured out what they were really going to do next. They were a
classic example of Lewis' statement that "giving people sophisticated
scheduling software without any knowledge of Project Management merely
enables them to document their failures very accurately" (paraphrased).
All their projects were slipping every week. And they knew by exactly
how much. I don't think that tracking their progress more frequently
would have helped them in the least, any more than tracking to tenths
of hours was helping. They simply had no viable plan. Accurately
tracking to a poor plan is like accurately machining the pistons and
the cylinders to an engine, but not coordinating that they match!
If your initial plan is ill-conceived, daily tracking will only
illiminate that fact on a daily basis. It will do nothing to solve the
problem. That's my considered opinion. You may disagree, and I have a
feeling you will!

 

[Steve House [Project MVP]]

To be blunt, it is impossible for software EVER to be "intuitive" in the
sense you describe. No matter what the application, the software is only a
tool to help a human expert do his or her job easier or more efficiently.
But it can NEVER actually do the job of that human nor can it replace that
human when it comes to making decisions, nor should it try. You simply
cannot buy MS Project (or any other project software) and turn the job of a
skilled project manager into a clerical function limited to pumping data
into the decision-making machine and reading off what the machine in turn
tells them to do.