Tasks too detailed?

[Inquisit1]

Our team is struggling to identify the level of detail necessary to
effectively structure a timeline. We need a balance between having enough
detail to adequately track our costs, and not being too detailed that our
resources will not want to update tasks.

The problem we are faced with is that our projects are extremely dynamic,
and may change scope from one day to the next, and we need to be able to
account for these changes, and we need to be able to relay these changes to
our resources in a timely way, so that at any given point our PM's will know
when/if their resources are out of scope; projects remain within budget, and
our clients can get an accurate progress reports.

What is the best way to handle situations where projects may rapidly change
(should we be worried about 'actuals' being lost if we decide we need more or
less detail on a task), and how do we best determine the level of detail that
we can reasonably manage?

What are any other concerns that we should be aware of?

Thanks for any suggestions

 

[salgud]

Our team is struggling to identify the level of detail necessary to
effectively structure a timeline. We need a balance between having enough
detail to adequately track our costs, and not being too detailed that our
resources will not want to update tasks.

The problem we are faced with is that our projects are extremely dynamic,
and may change scope from one day to the next, and we need to be able to
account for these changes, and we need to be able to relay these changes to
our resources in a timely way, so that at any given point our PM's will know
when/if their resources are out of scope; projects remain within budget, and
our clients can get an accurate progress reports.

What is the best way to handle situations where projects may rapidly change
(should we be worried about 'actuals' being lost if we decide we need more or
less detail on a task), and how do we best determine the level of detail that
we can reasonably manage?

What are any other concerns that we should be aware of?

Thanks for any suggestions

A general rule of thumb is that task durations should be between 1 and 10
days. Less that a day, micromanaging. Longer than 10 working days, you can
be more than 2 weeks late before you are aware.

Of course, this depends on the type of project and other factors.

HTH

 

[Rod Gill]

Scope changing every day?!! Agile methodology suggests you should offer the
client blocks of work (Eg 10 lots of x,xxx hours of effort), then let them
choose what's in the next block of work based on their business needs and
your work load estimates. You then freeze the scope for that block but
client gets to decide what's in next block and so on. You can now still
deliver to original price plus or minus a little but if client wants more
blocks of time they can pay for them.

Schedule now shows in detail how current block will be successfully
delivered and remaining blocks are very high level only. The more the
customer cannot fix what they need up front, the more productive agile
methods become and the happier the client.

Alternatively only schedule next 4 weeks in detail and remaining time after
that at high level.



--

Rod Gill
Microsoft MVP for Project - http://www.project-systems.co.nz

Author of the only book on Project VBA, see: http://www.projectvbabook.com

Our team is struggling to identify the level of detail necessary to
effectively structure a timeline. We need a balance between having enough
detail to adequately track our costs, and not being too detailed that our
resources will not want to update tasks.

The problem we are faced with is that our projects are extremely dynamic,
and may change scope from one day to the next, and we need to be able to
account for these changes, and we need to be able to relay these changes
to
our resources in a timely way, so that at any given point our PM's will
know
when/if their resources are out of scope; projects remain within budget,
and
our clients can get an accurate progress reports.

What is the best way to handle situations where projects may rapidly
change
(should we be worried about 'actuals' being lost if we decide we need more
or
less detail on a task), and how do we best determine the level of detail
that
we can reasonably manage?

What are any other concerns that we should be aware of?

Thanks for any suggestions



__________ Information from ESET Smart Security, version of virus
signature database 4974 (20100325) __________

The message was checked by ESET Smart Security.

http://www.eset.com

__________ Information from ESET Smart Security, version of virus signature database 4974 (20100325) __________

The message was checked by ESET Smart Security.

http://www.eset.com

 

[Steve House]

The rule is you need to show however much detail is necessary to effectively
schedule and manage the resources. If I'm painting a room I have lot of
different activities to perform ... removing furniture, taking down wall
fixtures, blending the paint, etc. If a painter and his assistant are going
to do the whole job, I can just show one task "Paint the Room", estimate the
time for the entire job, put the painter and assitant on it, and I'm done.
But if a crew from IT has to move out the computers and then a team of
labourers moves the furniture, and a union carpenter has to take care of the
fixtures and then a colour expert blends the paint and then the painter
applies it, I have a whole series of resources and activities to coordinate.
I'd show "Paint the Room" as a summary and detail out all the subtasks
within it so I can assign and control what resources show up when to do
their individual parts of the job.

 

[Jim Aksel]

Something else to consider is how often you status the schedule. In our
circumstances, we generally require tasks to be from 1 to 10 days. We
report status weekly.

If you read the PMI Standard on Scheduling, they recommend twice the
reporting period, never more than 2x or 3x the reporting period.

How short? I think that has to be in comparison to the other activities as
well. It is useless to schedule a 30 minute task when other tasks are 5 or
10 days. So, I guess I am pretty much with Steve on this one.
--
If this post was helpful, please consider rating it.

Jim Aksel, MVP

Check out my blog for more information:
http://www.msprojectblog.com