N00b looking to juggle resources & shorten project

[Baron Samedi]

Hi,

I have been thrown in at the deep end and have to produce a project
plan. I don't know if it is complex or not, but it has about 150 tasks
(which I could break down further, I guess).

The point is that I have been a developer for decades, always on this
seize of system and it generally takes about 10 men for 2 years,
whereas my plan is lasting 3 years.

Are there any easy ways to optimize the plan? Or to tweak it a but and
say "what if"?

It's a pure software project, to be done in three phases (skeleton,
success code only, then everything including error handling & feature
interactions).

One thing - I have 10 subsystems, and for each phase I have all 10
completing design, review, code, review, unit test then integration,
before moving on to the next phase.

However, the subsystems have differing levels of complexity. In
theory, some guys could finish early and move on. Or, maybe we don't
need to wait for the completion of integration of phase 1 before
moving on to phase 2 - maybe each could unit test phase 1, pass it on
to an integration guy and then move on to design for phase 2...

On paper, that shortens the overall duration, but in practise the
integration guy for phase 1 is going to be coming back to guys who are
no busy with design on phase 2 and make them rework because of errors
found during integration.

Any advice on how to shorten the project without throwing in too much
risk or rework?

Thanks in advance.

 

[DavidC]

Hi Baron,

The first thing is to foget about resources. Set up the schedule in a
strict logic sequence. Always ask the question "what tasks need this to
finish before they can start?". This sets up the correct logic. It wil then
show tasks which can be completed in parallel. Now assign resources to the
tasks and level this will show how long the project will take with the
assisgned tasks and resources, it will also show you (prior to levelling) how
overloaded your people would be if the schedule worked as developed. Look at
the graph and it will give you an idea of how many people are needed. At
this stage it becomes an iterative process and intuitive process to get the
right mix of time and resources.

If you are likely to have rework then include that as a task but don't link
it to any unrelated task even though both maybe using the same resource, use
the lvelling feature and the information about when your resorucves become
overloaded.

I don't believe there is any quick and simple way to do what you are looking
for, but then project is 'dumb' and only calculates based on information you
give it.

Hope this gives some guidance.

regards

DavidC

 

[Jim Aksel]

Well you have your work cut out for you don't you? Congratulations? First
thing you will need to do is a critical path analysis. For now, let's assume
you have listed tasks that are required and only those that are required.

Second, examine the relationships between the tasks as for predecessors and
successors. Are you comfortable with them? You don't have test code as a
predecessor to write code, right? Deliver Code to Customer is not the first
task? To keep it as simple as possible, make sure that every non-summary task
has both a predecessor and a successor. We always have two milestones in the
schedule: Authority to Proceed, and, Project Complete. That way you always
have something you can link to. We also set a deadline date (there is a
deadline column as well) on the Project Complete date. This makes sure you
will get a critical path.

Take a look at any constraint dates (you can insert constraint date and
constraint type columns). At this point you want all your tasks to be of
type "As Soon As Possible" so that MS Project drives your logic. You should
almost never key a date into a start or finish date column.

Assign resources to the tasks. Only assign resources to discrete tasks,
never summary tasks. Keep in mind the skill of your workers as you do this.
Although nine women can't have a baby in one month, nine women can certainly
write more code in a day than any one person. So you can recover some
duration by manloading tasks but don't use that as the cure for the schedule
all by itself. At this point, don't try to recover schedule with manpower,
just put in the resources you feel it will take to get the job done in the
time allotted and pray you have enough resources available.

Next, turn on the critical path so you can see which tasks are truly driving
your project finish dates. There is a wizard that does it for you:
Format/Gantt chart wizard.... select the critical path as you go through the
steps. Now your critical path shows up in red. You can also insert a column
called Total Slack. Total slack is the number of days a task completion date
can be delayed without impacting the critical path. This means if total
slack is less than or equal to 0 days those tasks are ON the critical path.
Positive Total Slack represents your (temporary) safety margin on those
tasks. Tasks with negative total slack are your problem children. A word of
advice, do not agree to any schedule containing negative slack; doing so
ensures failure.

The critical path is the longest path through the network that also
represents the minimum amount of time it will take to complete the project.
There are a few ways to shorten the critical path. The only way to compress
schedule is to shorten the duration of the critical path... if it isn't on
the critical path, shortening the task duration buys you nothing.

1. Manload tasks on the critical path if doing so allows them to be
completed in a shorter period of time and you have the resources available.
For example you can assign overtime but you don't want to go there out of the
box. It may be possible for two additional coders to get the work done in 4
or 5 days less time assuming resource availability. You can also just
challenge the team and request they get the 7 day task done in 5 days but
they better have a sellable story since they have a 95% chance of running
long anyway (no, I am not cynical). Throwing money/resources at crtical path
tasks allowing them to finish earlier is called network crashing.

2. Change the predecessors/successors allowing some tasks to run in
parallel. This is called fast tracking. For example, you may normally
schedule a project to develop requirements and sign off a formal System
Requirements Review (SRR) prior to starting the System Design Documentation
(SDD) development. In reality, once a portion of the SRR is underway you can
certainly start writing requirements and performing prelminary design.
Remember that fast tracking increases risk. See if you can fast track
anything on the critical path.

3. Re-examine your critical path. It is possible you crashed and fast
tracked so much that the critical path changed. Keep polishing until you
obtain something you can live with. Remember, no matter what, do not sign up
to a schedule just because you are forced to meet a date... you are just
lying from day one. Sign up to what you think it takes to do the job and
nothing shorter.

4. Think out of the box. Example - is there legacy code that can be
modified or do you really have to start from scratch? Can you reuse some of
your documentation?

Remember, you have to make a crucial decision up front. Is this going to be
a delivery driven schedule where the customer gets a release on a specific
date, or, will it be a capability driven schedule so that the customer will
receive his software after performance criteria are vetted. In the case of
the former, what usually happens is the capabilities that will be in Release
"X" are all forgiven in order to meet the delivery date...so you end up with
"Hello World." In the latter, customers tend to complain about cost alot
since they are not receiving any capability at all until this big bang and
all the capability magically makes it through test and integration. In either
case, manage your customer expectations at all times and keep them informed.
Keep confirming that baseline assumption and get buy in when you need to
change your schedule.

Piece of cake, right? Post back with your additional questions/comments. I
am sure you will receive some additional input as well.
--
If this post was helpful, please consider rating it.

Jim

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

 

[Mike Glen]

Hi Baron,

Welcome to this Microsoft Project newsgroup

You might like to have a look at my series on Microsoft Project in the
TechTrax ezine at this site: http://tinyurl.com/2xbhc or this:
http://pubs.logicalexpressions.com/Pub0009/LPMFrame.asp?CMD=ArticleSearch&AUTH=23
(Perhaps you'd care to rate the articles before leaving the site,
Thanks.)

FAQs, companion products and other useful Project information can be seen at
this web address: <http://www.mvps.org/project/>

Hope this helps - please let us know how you get on

Mike Glen
MS Project MVP

 

[graham.keellings]

Hi Baron,

The first thing is to foget about resources.  Set up the schedule in a
strict logic sequence.  Always ask the question "what tasks need this to
finish before they can start?".  This sets up the correct logic.  It wil then
show tasks which can be completed in parallel.  Now assign resources tothe
tasks and level this will show how long the project will take with the
assisgned tasks and resources, it will also show you (prior to levelling)how
overloaded your people would be if the schedule worked as developed.  Look at
the graph and it will give you an idea of how many people are needed.  At
this stage it becomes an iterative process and intuitive process to get the
right mix of time and resources.

If you are likely to have rework then include that as a task but don't link
it to any unrelated task even though both maybe using the same resource, use
the lvelling feature and the information about when your resorucves become
overloaded.

I don't believe there is any quick and simple way to do what you are looking
for, but then project is 'dumb' and only calculates based on information you
give it.

Thanks for the good advice. That makes sense, and I have considerably
shorten the overall time already.

 

[graham.keellings]

Well you have your work cut out for you don't you?  Congratulations?  First
thing you will need to do is a critical path analysis.  For now, let's assume
you have listed tasks that are required and only those that are required.

Second, examine the relationships between the tasks as for predecessors and
successors.  Are you comfortable with them?  You don't have test codeas a
predecessor to write code, right? Deliver Code to Customer is not the first
task? To keep it as simple as possible, make sure that every non-summary task
has both a predecessor and a successor.  We always have two milestones in the
schedule: Authority to Proceed, and, Project Complete.  That way you always
have something you can link to.  We also set a deadline date (there is a
deadline column as well) on the Project Complete date.  This makes sureyou
will get a critical path.

Take a look at any constraint dates (you can insert constraint date and
constraint type columns).  At this point you want all your tasks to be of
type "As Soon As Possible" so that MS Project drives your logic.  You should
almost never key a date into a start or finish date column.

Assign resources to the tasks. Only assign resources to discrete tasks,
never summary tasks.  Keep in mind the skill of your workers as you do this.  
Although nine women can't have a baby in one month, nine women can certainly
write more code in a day than any one person.  So you can recover some
duration by manloading tasks but don't use that as the cure for the schedule
all by itself. At this point, don't try to recover schedule with manpower,
just put in the resources you feel it will take to get the job done in the
time allotted and pray you have enough resources available.

Next, turn on the critical path so you can see which tasks are truly driving
your project finish dates. There is a wizard that does it for you:  
Format/Gantt chart wizard.... select the critical path as you go through the
steps.  Now your critical path shows up in red.  You can also insert a column
called Total Slack.  Total slack is the number of days a task completion date
can be delayed without impacting the critical path.  This means if total
slack is less than or equal to 0 days those tasks are ON the critical path.  
Positive Total Slack represents your (temporary) safety margin on those
tasks.  Tasks with negative total slack are your problem children. A word of
advice, do not agree to any schedule containing negative slack; doing so
ensures failure.

The critical path is the longest path through the network that also
represents the minimum amount of time it will take to complete the project.  
There are a few ways to shorten the critical path. The only way to compress
schedule is to shorten the duration of the critical path... if it isn't on
the critical path, shortening the task duration buys you nothing.

1. Manload tasks on the critical path if doing so allows them to be
completed in a shorter period of time and you have the resources available.  
For example you can assign overtime but you don't want to go there out ofthe
box. It may be possible for two additional coders to get the work done in4
or 5 days less time assuming resource availability.  You can also just
challenge the team and request they get the 7 day task done in 5 days but
they better have a sellable story since they have a 95% chance of running
long anyway (no, I am not cynical). Throwing money/resources at crtical path
tasks allowing them to finish earlier is called network crashing.

2. Change the predecessors/successors allowing some tasks to run in
parallel.  This is called fast tracking.  For example, you may normally
schedule a project to develop requirements and sign off a formal System
Requirements Review (SRR) prior to starting the System Design Documentation
(SDD) development.  In reality, once a portion of the SRR is underway you can
certainly start writing requirements and performing prelminary design.
Remember that fast tracking increases risk. See if you can fast track
anything on the critical path.

3. Re-examine your critical path.  It is possible you crashed and fast
tracked so much that the critical path changed.  Keep polishing until you
obtain something you can live with.  Remember, no matter what, do not sign up
to a schedule just because you are forced to meet a date... you are just
lying from day one.  Sign up to what you think it takes to do the job and
nothing shorter.

4. Think out of the box.  Example - is there legacy code that can be
modified or do you really have to start from scratch?  Can you reuse some of
your documentation?

Remember, you have to make a crucial decision up front.  Is this going to be
a delivery driven schedule where the customer gets a release on a specific
date, or, will it be a capability driven schedule so that the customer will
receive his software after performance criteria are vetted.  In the case of
the former, what usually happens is the capabilities that will be in Release
"X" are all forgiven in order to meet the delivery date...so you end up with
"Hello World."  In the latter, customers tend to complain about cost alot
since they are not receiving any capability at all until this big bang and
all the capability magically makes it through test and integration. In either
case, manage your customer expectations at all times and keep them informed.  
Keep confirming that baseline assumption and get buy in when you need to
change your schedule.

Piece of cake, right?  Post back with your additional questions/comments.  I
am sure you will receive some additional input as well.

Wow, great advice, thanks!

This is starting to make sense .. and just to seem like common sense.
Thanks, everyone.