Tracking and forecasting

[Guest]

Hi,

I'm looking for the opinion of more experienced project managers when
it comes to forecasting milestones and tracking projects with MS
Project. I may demand too much precision in my approach, or I overlook
more simple things ;-)

I manage a software development project which takes about 12 months
and 12.000 hours of effort. I have set up a complete plan with the
help of Eric Uyttewaal's book (Dynamic Scheduling with Microsoft
Project, with all the checklists). I update the plan weekly (actual
hours and remaining hours per task and person). So far so good.

Yet, I still struggle with forecasting anything beyond the next, say,
6 weeks. Even the effort to forecast the next 6 weeks is high,
particularly when it comes to resource leveling. I'm interested to
spread the workload among the team members, so I level resources on a
bi-weekly level (anything between 60h to 80h for two weeks is ok).
Sending resources home for a couple of weeks is not an option so I
constantly change assignments (which makes updating the plan even more
cumbersome).

Yet I still feel that the plan rarely matches reality. People work on
different things, bring other things forward, dependencies change,
etc. I have no pool resources (e.g. availability > 100%) and many
tasks are done by more than one resource, which makes manual leveling
a PITA.

Spending the same effort updating the time frame +6 weeks until end-of-
project seems enormous. Do I demand too much if I want to forecast
milestones beyond 6 weeks? How do other project managers accomplish
this?

My idea is to do a more coarse resource leveling for the time frame
+6 weeks until end-of-project (say on a monthly basis). But the
effort is still high.

I know that the remaining effort divided by number of resources is
less that remaining duration to the deadline. So, things look not too
bad, if you ignore dependencies. But that is just a very rough
approximation...

-Stefan

 

[Rod Gill]

Firstly it reads like your development team has no plan for what features
need doing when. Secondly it reads like their estimates are a bit random,
hence tasks taking very different times than forecast.

Firstly when forecasting, Predict work (effort), not duration. The most time
efficient way to work is one developer on one object with the object
completed in one go. Murphy says some work ends up getting interrupted!

I think you may also be scheduling to too low a level. Use your development
tools task manager to manage the blocks of code that need doing, use Project
for a higher level of task. The PM along with the team should be setting the
goals for each week. You could just have a block of work for one week with
code blocks managed by your development tools.

Wherever possible, no task should start until everything needed to complete
it (information decisions etc) are available. The best person to do a block
of work is the person with appropriate skills to complete that work in one
go.

The approach of developing a chunk (maybe 2 weeks or even 4) of
functionality then fully testing it and reviewing with client and other key
stakeholders works well.

If you have 200h of work to get done in a week and 200h of effort available
+_ 20% then I wouldn't worry about leveling.

There is no point in scheduling low level tasks when the project is not
running at that level of maturity.

For that project it will be very important to predict hours of work for each
object and have timesheets to record how many actual hours it took to sign
off. Comparing original predicted (baseline) with actual hours will lead
very quickly to much better work predictions. Actual hours recorded against
the whole project are next to useless, hours have to be against blocks of
development of no more than 2 weeks.

Once work predictions get more accurate, you can track against physical
progress:
Definition 5%
Design 15%
Design peer review and changes 5%
Code 50%
Code peer review 5%
Test and integration 15%
Sign off 5%

As each step is completed, so the block of code's progress gets updated (no
matter how big or small the block of work). Use project to automatically
delay incomplete work or bring forward work done early.

--

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

Hi,

I'm looking for the opinion of more experienced project managers when
it comes to forecasting milestones and tracking projects with MS
Project. I may demand too much precision in my approach, or I overlook
more simple things ;-)

I manage a software development project which takes about 12 months
and 12.000 hours of effort. I have set up a complete plan with the
help of Eric Uyttewaal's book (Dynamic Scheduling with Microsoft
Project, with all the checklists). I update the plan weekly (actual
hours and remaining hours per task and person). So far so good.

Yet, I still struggle with forecasting anything beyond the next, say,
6 weeks. Even the effort to forecast the next 6 weeks is high,
particularly when it comes to resource leveling. I'm interested to
spread the workload among the team members, so I level resources on a
bi-weekly level (anything between 60h to 80h for two weeks is ok).
Sending resources home for a couple of weeks is not an option so I
constantly change assignments (which makes updating the plan even more
cumbersome).

Yet I still feel that the plan rarely matches reality. People work on
different things, bring other things forward, dependencies change,
etc. I have no pool resources (e.g. availability > 100%) and many
tasks are done by more than one resource, which makes manual leveling
a PITA.

Spending the same effort updating the time frame +6 weeks until end-of-
project seems enormous. Do I demand too much if I want to forecast
milestones beyond 6 weeks? How do other project managers accomplish
this?

My idea is to do a more coarse resource leveling for the time frame
+6 weeks until end-of-project (say on a monthly basis). But the
effort is still high.

I know that the remaining effort divided by number of resources is
less that remaining duration to the deadline. So, things look not too
bad, if you ignore dependencies. But that is just a very rough
approximation...

-Stefan


__________ Information from ESET Smart Security, version of virus
signature database 4972 (20100324) __________

The message was checked by ESET Smart Security.

http://www.eset.com

__________ Information from ESET Smart Security, version of virus signature database 4972 (20100324) __________

The message was checked by ESET Smart Security.

http://www.eset.com

 

[Guest]

Hi Rod,

first of all thanks for the detailed feedback. I may have expressed
some points of the project incorrectly: all estimates are based on
effort (not duration), actual hours and estimates of remaining effort
are updated weekly (manually by me). Every two weeks, all key players
meet and update the entire plan (effort, assignments, dependencies,
etc.). The plan has a WBS with each major deliverable taking anything
between 3 and 8 weeks (of duration), so I have milestones every 3-8
weeks. After every milestone the team has a lessons learned session
which reflects estimates. This processs works well for the time
horizon 4-6 weeks into the future - everyhting beyond that (including
forecasting milestones) is very coarse (and cumbersome).

The part which confuses me the most, is the part "chunk of work",
"block of code" and "level of scheduling".

I understand your definition of "chunk of work" or "block of
development" as one piece of a deliverable consisting of steps
"Definition, Design, Design peer review and
changes, ..., Sign off". Each step is also referred to as "block of
code". Is this correct?

Than you project plan would look like

Deliverable Foo
Chunk X -> Resources A,B,C
Chunk Y -> Resources B,C
Chunk Z > Resources C, D

Each chunk 2-4 weeks long, You would only track the chunk level
(people claim to chunk X and estimate remaining effort of chunk X) not
the "step" level, right?
How often do teams start chunk Y and have not yet completed chunk X
(maybe due to reasons outside the team). Would I not run into the same
problems (albeit on a
higher level)?

You recommendation that only one person (the one with the best skills)
works at one object in one go refers to the "step" level, right?

-Stefan

 

[Rod Gill]

Hi,

The level of detail you need is that driven by governance and resource
needs. If your developers do not use or need your schedule, only governance
drives your schedule. Schedule to deliverable level with only enough detail
to provide reasonably accurate tracking.

Tracking of remaining effort should be by chunk.

One person per task where each task is approx 1 week long or less is most
efficient. The more you multi-task the less efficient you get. More than 3
people on a task creates significant overheads managing that team and
coordinating it. Obviously this has to happen sometimes, just recognize the
cost and try to minimize multi-tasking etc.
--

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

Hi Rod,

first of all thanks for the detailed feedback. I may have expressed
some points of the project incorrectly: all estimates are based on
effort (not duration), actual hours and estimates of remaining effort
are updated weekly (manually by me). Every two weeks, all key players
meet and update the entire plan (effort, assignments, dependencies,
etc.). The plan has a WBS with each major deliverable taking anything
between 3 and 8 weeks (of duration), so I have milestones every 3-8
weeks. After every milestone the team has a lessons learned session
which reflects estimates. This processs works well for the time
horizon 4-6 weeks into the future - everyhting beyond that (including
forecasting milestones) is very coarse (and cumbersome).

The part which confuses me the most, is the part "chunk of work",
"block of code" and "level of scheduling".

I understand your definition of "chunk of work" or "block of
development" as one piece of a deliverable consisting of steps
"Definition, Design, Design peer review and
changes, ..., Sign off". Each step is also referred to as "block of
code". Is this correct?

Than you project plan would look like

Deliverable Foo
Chunk X -> Resources A,B,C
Chunk Y -> Resources B,C
Chunk Z > Resources C, D

Each chunk 2-4 weeks long, You would only track the chunk level
(people claim to chunk X and estimate remaining effort of chunk X) not
the "step" level, right?
How often do teams start chunk Y and have not yet completed chunk X
(maybe due to reasons outside the team). Would I not run into the same
problems (albeit on a
higher level)?

You recommendation that only one person (the one with the best skills)
works at one object in one go refers to the "step" level, right?

-Stefan

__________ Information from ESET Smart Security, version of virus
signature database 4980 (20100328) __________

The message was checked by ESET Smart Security.

http://www.eset.com

__________ Information from ESET Smart Security, version of virus signature database 4980 (20100328) __________

The message was checked by ESET Smart Security.

http://www.eset.com