Summary Tasks - Can Project Do This?

[aww91]

This is an unconventional question, so please accept my apologies
beforehand.

My estimates are sometimes done at the summary level. For example,
Frank says it will take 8,000 hours for his team to build a house. I
want to show this summary in Project without estimating how much time
it takes to complete each individual subtask. Frank knows what needs
to be done (lay foundation, build the frame, install plumbing, etc )
he just doesn't know ahead of time how long each task will take him;
he does know however that it will take 8,000 hours.

For Example:

Build House Start: 10/19/05 End: 12/31/2005 Work Effort: 8,000
%Complete: .25
Lay Foundation 20 hours
Build Frame 0 hours
Install Plumbing 0 hours

In the example above, I want to be able to enter to-date 20 hours spent
on laying the foundation with no hours recorded so far for the other
tasks. The work effort is still 8,000 hours, with 7,980 to go , and
the start/finish dates remain the same. The percent complete changes
from 0 to .25%. As the project progresses hours are added for the
other tasks eventually equally 8,000 and 100% complete.

It would be the same as this:

Build House Start: 10/19/05 End: 12/31/2005 Work Effort:
8,000 %Complete: .25
Do everything 10/19/05 - 12/31/2005 Work: 8,000
Completed: 20 hrs

My example is made-up, however based on my experience people provide
estimates in summary format all the time and the PM often ends up
fudging the subtasks with bogus hours just to make it work in Project.
I want to avoid that. Any ideas how?

Thanks,

 

[John]

This is an unconventional question, so please accept my apologies
beforehand.

My estimates are sometimes done at the summary level. For example,
Frank says it will take 8,000 hours for his team to build a house. I
want to show this summary in Project without estimating how much time
it takes to complete each individual subtask. Frank knows what needs
to be done (lay foundation, build the frame, install plumbing, etc )
he just doesn't know ahead of time how long each task will take him;
he does know however that it will take 8,000 hours.

For Example:

Build House Start: 10/19/05 End: 12/31/2005 Work Effort: 8,000
%Complete: .25
Lay Foundation 20 hours
Build Frame 0 hours
Install Plumbing 0 hours

In the example above, I want to be able to enter to-date 20 hours spent
on laying the foundation with no hours recorded so far for the other
tasks. The work effort is still 8,000 hours, with 7,980 to go , and
the start/finish dates remain the same. The percent complete changes
from 0 to .25%. As the project progresses hours are added for the
other tasks eventually equally 8,000 and 100% complete.

It would be the same as this:

Build House Start: 10/19/05 End: 12/31/2005 Work Effort:
8,000 %Complete: .25
Do everything 10/19/05 - 12/31/2005 Work: 8,000
Completed: 20 hrs

My example is made-up, however based on my experience people provide
estimates in summary format all the time and the PM often ends up
fudging the subtasks with bogus hours just to make it work in Project.
I want to avoid that. Any ideas how?

Thanks,

aww91,
I guess my first question is, why use Project at all? I think Excel
would be just as useful, if not more, for the process you want to use.
Project is an application tool for scheduling a project plan and
tracking its progress. If you know (??) the total work required and all
you want to do it track actuals, then use a spreadsheet - it will be a
lot easier to set up and maintain. The only thing you won't have is a
graphical output but that doesn't seem like its important anyway.

Even though your example is made up let me throw out a few
comments/observations.
1. How does Frank know the total job will take 8000 hours? His
guestimate must be based on something, probably historical data and that
means he also should have a pretty good idea of how much effort is
required for each element (subtask). If the number were truly pulled out
of the air, we both know what its worth. Anybody you talk to that has an
ounce of experience with project management will tell you the best plans
are built from the bottom up because those plans have a basis. Top down
is a popular approach for some management styles but any plan built that
way is a "forced plan" and is generally doomed to failure and/or
overruns.
2. If you know how long the whole thing is going to take, why bother
with the details (i.e. why track subtasks at all)? It would make just as
much sense to say, the project will take 8000 hours and we have spent
100 hours, therefore we are 1.2% complete - trust us - everything's on
track.
3. My experience must be different from yours. Anybody I have worked
with gives an estimate of the effort required for their particular piece
of the project and if it is a Summary level, they always have something
to back it up (i.e. buildup from the detail). Even in your example of
building the house, you will get separate estimates from each of the
subs. That is the only way you can cost out the job.

Thats my two cents.
John
Project MVP

 

[aww91]

Thanks John,

I agree, in this instance its better not to use MS Project and just go
with a spreadsheet like Excel. Skipping the subtasks and just noting
them as comments is the way I decided to go.

Thanks again for your input.

 

[davegb]

Top down
is a popular approach for some management styles but any plan built that
way is a "forced plan" and is generally doomed to failure and/or
overruns.

I feel compelled to disagree with you here. I believe that top-down
planning, properly executed, is the superior way to plan large
projects. I teach, and am a strong adherent of, Achievement Based
Planning. I start by defining exactly what it is we're trying to
achieve, as defined by the stakeholders. Then determine major
milestones, then the WBS. This process avoids many of the major
pitfalls of bottom-up (or task-based) planning. When you focus entirely
on the tasks, and not what it is you're trying to accomplish by doing
the tasks, you can get into all kinds of trouble. I've seen lots of
money spent doing what was clearly the "wrong project" when it was
done.

 

[John]

I feel compelled to disagree with you here. I believe that top-down
planning, properly executed, is the superior way to plan large
projects. I teach, and am a strong adherent of, Achievement Based
Planning. I start by defining exactly what it is we're trying to
achieve, as defined by the stakeholders. Then determine major
milestones, then the WBS. This process avoids many of the major
pitfalls of bottom-up (or task-based) planning. When you focus entirely
on the tasks, and not what it is you're trying to accomplish by doing
the tasks, you can get into all kinds of trouble. I've seen lots of
money spent doing what was clearly the "wrong project" when it was
done.

Dave,
Don't misunderstand. I am NOT advocating that the performers define the
project. I fully agree that a customer/management/performer agreement
and understanding of the end goal is essential to defining the project.
However, once the requirements are defined and the structure is laid
out, I believe the better approach is for the performers to lay out the
details based on the framework. That is an important step to "buy-in".
Unfortunately what usually results is a project that won't meet the
budget. Then the iterative process of negotiating begins - specs are
clarified, scope may be reduced, etc. to bring the "needs" and "wants"
together. I believe the end result is a project everybody can live with
and it was developed by all parties involved, not as a top down "this is
what we're going to do and how you're going to do it".

I'm not sure our approaches are all that different.
John

 

[John]

Thanks John,

I agree, in this instance its better not to use MS Project and just go
with a spreadsheet like Excel. Skipping the subtasks and just noting
them as comments is the way I decided to go.

Thanks again for your input.

aww91,
You're welcome. I think you are making the right choice.

John
Project MVP

 

[Jan De Messemaeker]

Hi John and all,

I beg to disagree.
When you ask a cabling installer he'll tell you that the very best estimate
willbe half an hour per drop, but thet includes preparation of the site,
making the holes in the wall, installing the cale, installing teh
switchboards, connecting the cables to the switchboard and installing the
drops.

And what is Function Point Analysis about? It is a highly rated method of
estimating a software development project starting from the quantities of
results, and this estimate includes all tasks you can imagine in the
project.

Still one wants totrack those tasks.
It's not because it doesn't fit in the Project methodology that it don't
exist, like our poster sais, it happens all the time.

Fact is that if he wants to track teh tasks using project, what I can advise
is to introduce a best (even wild) guess of the work per task, and when
all's entered you correct the individual guesses by a factor to meae the
total match the estimated total (which, believe it or not, is often more
trustworthy than detail estimates which are often "politically" colored).

Greetings,

 

[davegb]

Dave,
Don't misunderstand. I am NOT advocating that the performers define the
project. I fully agree that a customer/management/performer agreement
and understanding of the end goal is essential to defining the project.
However, once the requirements are defined and the structure is laid
out, I believe the better approach is for the performers to lay out the
details based on the framework. That is an important step to "buy-in".
Unfortunately what usually results is a project that won't meet the
budget. Then the iterative process of negotiating begins - specs are
clarified, scope may be reduced, etc. to bring the "needs" and "wants"
together. I believe the end result is a project everybody can live with
and it was developed by all parties involved, not as a top down "this is
what we're going to do and how you're going to do it".

I'm not sure our approaches are all that different.
John

Sounds like they're much the same. I misunderstood your description of
bottom-up. I agree with all that you say above. Basically, once the
achivements are set, how the project is done needs to be negotiated by
all parties directly involved.