Rebuidling a paper/pencil schedule in MSP2003

[Michael.Tarnowski]

Hi community,
we had built a schedule running from 14.04.09 to 25.08.11 from scratch
by paper work. Official project start was 30.05.08.
Now I want to rebuild a backward plan in MSP. I started the task list
with a rack of official agreed MFO-constrained milestones having
predecessor milestone inside the task list. The first task after these
milestones is a milestone called prjStart, at the end is one prjEnd.
All other tasks are between.
In our manually created schedule we estimated the duration and
determined start/end dates by viewing at a calendar; duration are
net work days only.
In MSP I entered all task only by this duration as Fix Duration, non-
effort, FS-linked with 1 full time equivalent assigned. For tracking
reasons I kept the manual start/end dates in two custom date fields
WBS_Start and WBS_End displayed in the Gantt chart.

I assumed that since durations in both schedules are identical, the
MSP scheduled start/end dates will be equal +/- one day with our
manual schedule. But in reality both are differing by month! For
example the first task (which was manually scheduled for 14.4.9)
starts in MSP at 15.08.08!

I know it is in way stupid too rebuild 1:1 a given schedule in MSP and
not let MSP do the planning; but the manual schedule was already
communicated to management before we decided to use MSP for tracking.
I read a lot of books and Internet sources on MSP, especially on the
duration equation. The most obvious approach in MSP is to schedule
forward, estimate and enter task durations, model the dependency
logic, assign generic resources and "accept" the MSP calculated
project end date.
We knew the project end (25.08.11), start of the schedule (14.4.9),
and the logic, as well the duration of each task in between; I agree,
we have no distinct slack.
Our goal is to come up with a schedule to baseline and monitor the
progress in relation to the estimated durations.

Could anybody explain me how I can achieve a MSP schedule in line with
our prior schedule
I appreciate your help very much
Have a nice day
Michael

 

[JulieS]

Hi Michael,

As I noted in my reply to your earlier post, when you schedule a
project from the end, all tasks are set to ALAP and will move as
close to the end date as possible. If you know when the project is
to start, set the start date and build your project. With a project
start date, all tasks will be set with an ASAP constraint and will
move as close to the project start date as possible.

You can set a Finish no later than constraints where needed, but I
have to assume if you could deliver one of the milestones before
deadline that would be good. I would replace the MFO constraints
with FNLT.

I hope this helps. Let us know how you get along.

Julie
Project MVP

Visit http://project.mvps.org/ for the FAQs and additional
information about Microsoft Project

 

[Michael.Tarnowski]

Hi Michael,

As I noted in my reply to your earlier post, when you schedule a
project from the end, all tasks are set to ALAP and will move as
close to the end date as possible. If you know when the project is
to start, set the start date and build your project. With a project
start date, all tasks will be set with an ASAP constraint and will
move as close to the project start date as possible.

You can set a Finish no later than constraints where needed, but I
have to assume if you could deliver one of the milestones before
deadline that would be good. I would replace the MFO constraints
with FNLT.

I hope this helps. Let us know how you get along.

Julie
Project MVP

Visithttp://project.mvps.org/for the FAQs and additional
information about Microsoft Project

Hi Julie,In general I agree - delivery before deadline is good; but
unfortunatels MSP schedules the first activities **before** they
actually started according the manual plan. Thus it doesn't reflect
the reality.
Michael

 

[JulieS]

"Michael.Tarnowski" <> wrote in message
<snip

Hi Julie,
In general I agree - delivery before deadline is good; but
unfortunatels MSP schedules the first activities **before** they
actually started according the manual plan. Thus it doesn't
reflect
the reality.
Michael

I think you'll find that the manual schedule you've created using
paper and pencil as well as the schedule that is created in Project
never mimics reality 100%. If we were that good at scheduling and
estimating, we wouldn't need Project.

We do as best we can to plan, and then save a baseline. To reflect
the reality, record tracking (progress). If you planned to start a
task on Monday but for whatever reason didn't get to actually
starting it until Wednesday, you record the Actual Start date,
update actual and remaining duration or actual and remaining work.
Project will shift the schedule of the tasks to reflect the result
of a two-day start delay to the task. If the schedule now forecasts
missing your deliverable deadline -- you need to replan how to
achieve the deadline.

The difficulty of scheduling from the fixed finish date is that the
schedule can't shift to the right (later) -- and now Project will
begin the series of scheduling error messages (assuming you've
turned calculation to automatic) that can be confusing and difficult
to determine what is going on. If you've scheduled from a fixed
start date (and once you begin to track actual work -- the start
date is fixed) -- Project will adjust the path leading to your
deliverables and you can more clearly see how much you are
projecting to miss the deliverable date.

I hope this helps.
Julie

 

[Michael.Tarnowski]

"Michael.Tarnowski" <> wrote in message

<snip




I think you'll find that the manual schedule you've created using
paper and pencil as well as the schedule that is created in Project
never mimics reality 100%. If we were that good at scheduling and
estimating, we wouldn't need Project.

We do as best we can to plan, and then save a baseline. To reflect
the reality, record tracking (progress). If you planned to start a
task on Monday but for whatever reason didn't get to actually
starting it until Wednesday, you record the Actual Start date,
update actual and remaining duration or actual and remaining work.
Project will shift the schedule of the tasks to reflect the result
of a two-day start delay to the task. If the schedule now forecasts
missing your deliverable deadline -- you need to replan how to
achieve the deadline.

The difficulty of scheduling from the fixed finish date is that the
schedule can't shift to the right (later) -- and now Project will
begin the series of scheduling error messages (assuming you've
turned calculation to automatic) that can be confusing and difficult
to determine what is going on. If you've scheduled from a fixed
start date (and once you begin to track actual work -- the start
date is fixed) -- Project will adjust the path leading to your
deliverables and you can more clearly see how much you are
projecting to miss the deliverable date.

I hope this helps.
Julie

Julie,
I agree with you in most points - the issue in my situation is, that
we actually started at Tue 14.04.09, MSP however calculated backward
Tue 18.11.08 whereas project end / final delivery is contracted for
Thu 25.08.11 - thus we are on the run accordxing MSP 4 month ahead.
Michael

 

[JulieS]

Julie,
I agree with you in most points - the issue in my situation is,
that
we actually started at Tue 14.04.09, MSP however calculated
backward
Tue 18.11.08 whereas project end / final delivery is contracted
for
Thu 25.08.11 - thus we are on the run accordxing MSP 4 month
ahead.
Michael

So, if you started the project four months late (April 14 2009) how
can you make a delivery date of August 25 2011? Did you set an
actual start date to tasks of 14 April 2009? Did the schedule of
the other tasks adjust?
Julie

 

[JulieS]

Julie,
I agree with you in most points - the issue in my situation is,
that
we actually started at Tue 14.04.09, MSP however calculated
backward
Tue 18.11.08 whereas project end / final delivery is contracted
for
Thu 25.08.11 - thus we are on the run accordxing MSP 4 month
ahead.
Michael

Michael,
I've been reviewing this thread -- let's start back at the
beginning. If you've plotted the schedule out on paper and are able
to achieve the schedule on paper starting the project on 14 April
2009 and ending on 25 August 2011 but once you enter the data in
Project you are getting different calculations -- I'd compare the
following:

On your paper schedule were you counting weekends (Sat & Sunday) as
working days? Were you counting holidays?

What modifications (if any) did you make to the project calendar
through Tools > Change Working time? The default standard calendar
is set to 8 hours per day from Monday through Friday. Saturday and
Sunday are non-working time. There are not holidays in the standard
calendar.

In Tools > Options, what have you set as your definition of a
"day" -- a "week"?

If, as you say all tasks are linked F to S and the durations match
your paper schedule and the calendar definition matches your paper
schedule -- all should match.

Please ensure that calculation is set to automatic.

About the only thing I can recommend is start from your final
milestone and begin to compare backwards. Where in the chain do the
plans differ?

I hope this helps.
Julie

 

[Michael.Tarnowski]

Michael,
I've been reviewing this thread -- let's start back at the
beginning. If you've plotted the schedule out on paper and are able
to achieve the schedule on paper starting the project on 14 April
2009 and ending on 25 August 2011 but once you enter the data in
Project you are getting different calculations -- I'd compare the
following:

On your paper schedule were you counting weekends (Sat & Sunday) as
working days? Were you counting holidays?

What modifications (if any) did you make to the project calendar
through Tools > Change Working time? The default standard calendar
is set to 8 hours per day from Monday through Friday. Saturday and
Sunday are non-working time. There are not holidays in the standard
calendar.

In Tools > Options, what have you set as your definition of a
"day" -- a "week"?

If, as you say all tasks are linked F to S and the durations match
your paper schedule and the calendar definition matches your paper
schedule -- all should match.

Please ensure that calculation is set to automatic.

About the only thing I can recommend is start from your final
milestone and begin to compare backwards. Where in the chain do the
plans differ?

I hope this helps.
Julie

Hi Julie,
I really appreciate how much time you spent to help me. I know that
you all work as volunteers in this groups and it' s great to find here
so much support.

On your paper schedule were you counting weekends (Sat & Sunday) as
working days? Were you counting holidays?

We counted only the net work days - no weekends and as I know no
holidays (we assumes that we could manage to have every day some one
working)
The MSP calendar assigned is the standard one (8 hours a week, Mon-
Fri, 40 hours/week); no holidays assigned. Work/Duration is entered in
days (same as our manual schedule).
Official project start: Fri 30.05.08; start of our schedule (to be
baselined later on for tracking): Tue 14.04.09; end of the project: 25
August 2011 - The time 30.5.08-14.04.09 was a kind of feasibility
study, and monitoring & control should start at the first activity
(14.04.09). Therefore I enclosed all activities between two
milestones: 30.05.08 and 25 August 2011. In Project>Project
Information I set backward scheduling from 25 August 2011, automatic
calculation enabled. For all activities I set fixed duration, ALAP,
and FS dependencies.
In between the activities we have several milestone, some are linked
as predecessors for contractual agreed milestones - on top of the
schedule, these "external milestones" are SNLT constrained.
As I mentioned, even the first activity in the chain differs from our
manual plan by 4 months.

The only one explanation I have at the moment Julie, is that the
designer of the manual plan used some "hidden" parallel starting tasks
(slacks) he didn't told me yet - since my MSP schedule is strictly
sequencial. Tomorrow I will a meeting with these guys to cover this
issue.

But nevertheless I found in the past MSP extremely difficult to use in
backward planning, when start and other certain dates were set.
Michael
I will come back tomorrow

 

[Michael.Tarnowski]

Hi Julie,
I really appreciate how much time you spent to help me. I know that
you all work as volunteers in this groups and it' s great to find here
so much support.


We counted only the net work days - no weekends and as I know no
holidays (we assumes that we could manage to have every day some one
working)
The MSP calendar assigned is the standard one (8 hours a week, Mon-
Fri, 40 hours/week); no holidays assigned. Work/Duration is entered in
days (same as our manual schedule).
Official project start: Fri 30.05.08; start of our schedule (to be
baselined later on for tracking): Tue 14.04.09; end of the project: 25
August 2011 - The time 30.5.08-14.04.09 was a kind of feasibility
study, and monitoring & control should start at the first activity
(14.04.09). Therefore I enclosed all activities between two
milestones: 30.05.08 and 25 August 2011. In Project>Project
Information I set backward scheduling from 25 August 2011, automatic
calculation enabled. For all activities I set fixed duration, ALAP,
and FS dependencies.
In between the activities we have several milestone, some are linked
as predecessors for contractual agreed milestones - on top of the
schedule, these "external milestones" are SNLT constrained.
As I mentioned, even the first activity in the chain differs from our
manual plan by 4 months.

The only one explanation I have at the moment Julie, is that the
designer of the manual plan used some "hidden" parallel starting tasks
(slacks) he didn't told me yet - since my MSP schedule is strictly
sequencial. Tomorrow I will a meeting with these guys to cover this
issue.

But nevertheless I found in the past MSP extremely difficult to use in
backward planning, when start and other certain dates were set.
Michael
I will come back tomorrow

Today I had a meeting with the planning staff - we identified more
than 4 pages of peculiarities in the manual plan - which we will solve
in the next days....
....I will come back tomorrow ;-)
Michael

 

[JulieS]

Today I had a meeting with the planning staff - we identified more
than 4 pages of peculiarities in the manual plan - which we will
solve
in the next days....
...I will come back tomorrow ;-)
Michael

Hi Michael,
Keep us posted. Julie

 

[Rob Schneider]

Michael,

This is good news. People often like to think that manual is best.
That viewpoint can be right when done with enough complexity so as to
not fool one's self. The trick is that it's easy to get fooled.

Hopefully at this point you can convince the planning staff to start
again and build the schedule model/estimate in Project (or equivalent).
In addition to providing some aids for dealing with the schedule
complexity, this approach will get you to one plan in which you can
focus on the plan instead of focusing on two plans and then having to
resolve differences.

And: for so many reasons, don't try to schedule with "as late as
possible" tasks using backward planning. do it on a forward-planning
basis ... develop a plan for which Project computes the completion dates
with "as soon as possible" tasks within your deadlines. If you don't
like the computed dates, change the plan.

--rms

 

[Michael.Tarnowski]

Michael,

This is good news. People often like to think that manual is best.
That viewpoint can be right when done with enough complexity so as to
not fool one's self. The trick is that it's easy to get fooled.

Hopefully at this point you can convince the planning staff to start
again and build the schedule model/estimate in Project (or equivalent).
In addition to providing some aids for dealing with the schedule
complexity, this approach will get you to one plan in which you can
focus on the plan instead of focusing on two plans and then having to
resolve differences.

And: for so many reasons, don't try to schedule with "as late as
possible" tasks using backward planning. do it on a forward-planning
basis ... develop a plan for which Project computes the completion dates
with "as soon as possible" tasks within your deadlines. If you don't
like the computed dates, change the plan.

--rms

Hi Rob,
doing forward planning although the end date is contracted / stated is
an impressive idea - I like that.
But what is wrong with backward planning and ALAP tasks - they will
schedule with most greatest slack possible, which can be adjusted more
easily - or I'am wrong?
In contrary doing forward planning "against" a given end, what can't
be shifted by several reasons is more difficult to hit the line and
made a touch down.
Michael

 

[Rob Schneider]

Hi Rob,
doing forward planning although the end date is contracted / stated is
an impressive idea - I like that.
But what is wrong with backward planning and ALAP tasks - they will
schedule with most greatest slack possible, which can be adjusted more
easily - or I'am wrong?
In contrary doing forward planning "against" a given end, what can't
be shifted by several reasons is more difficult to hit the line and
made a touch down.
Michael

There are others on this forum who have written repeatedly and more
eloquently on this over the years. Perhaps they will jump in.

First, the end date is *not* given. The project will take as long as it
takes. Yes, it is given that your organisation has signed a contract or
you have made some sort of promise. And surely someone high up in the
organisation has said "this will happen" and then made some sort of
suggestion about how heads will roll if it does not happen.

But that posturing and leadership is not good enough. You need a plan
that the team has confidence in that will lead them to the expected
finish point. In absence of a viable plan, then posturing and leadership
is all you have and you should not bother using Project or the manual plan.

If what you are suggesting is that when you model the project execution
in Project you have a project completion milestone and you make that
milestone a "must finish on" the committed end-date along with setting
all the predecessors to be ALAP, you will get just that. You will get a
plan that gives you the target start/end dates for all tasks scheduled
as late as they can be in order to satisfy the completion date. It will
give you the backwards plan that gives you the last possible date you
can start the project for which you can compelete the project on the
committed date. That means you have no slack and if any task runs late
not only will Project complain to you, but your project is at great risk
of slipping since all subsequent tasks now have to get done in durations
shorter than planned. As you can appreciate, once that understood and is
communicated to the project team, great stress will appear.

Instead, build a plan that will deliver the deliverables using a logical
procession of sub-deliverables and/or asks that build up the final
project deliverable that has been committed. Unless there is a special
reason to do otherwise, make all tasks ASAP since it's natural to
schedule things to be done as soon as possible. This can also give you
more slack in the schedule if you design it right. You need a plan that
can accomodate risks, changes in scops, delays, accelerations, change
requests, and mistakes. Based on your logic of how to execute the
project, let Project compute the end date. If you don't like that end
date, then you have to change the project plan. Put a Deadline date on
the final project completion milestone task. If Project computes a
completion date that is beyond the deadline, it will tell you (see the
Indicator field).

So along these lines, the most important decision you should ask your
leadership to make is the following: "We are committed to completing
this project by [insert date]. To which target date should we develop
an execution plan so as to increase the chances we can actually get done
as promised?"

Clearly, the more you bring the target date backward, i.e. nearer to the
start date, the more unlikely the achievement of that date is possible.
The more unlikely you make the plan, the plan will then not have
credibility. A plan with no credibility means a plan that will not be
used. This could lead to great stress imposed on the project team.
However, at the same time you should press them for something that is
earlier than committed to give you some contingency and flexibility.
It's a tough call. That's why you want the bosses to make this decision.

Me: Depends on the type of project it is, e.g. IT projects are
different than building construction. But I guess try to commit to an
80% probable schedule with the client and target the project to achieve
a 25-50% and perhaps relax that target at about the 50% progress point.

 

[Michael.Tarnowski]

Hi Rob,
doing forward planning although the end date is contracted / stated is
an impressive idea - I like that.
But what is wrong with backward planning and ALAP tasks - they will
schedule with most greatest slack possible, which can be adjusted more
easily - or I'am wrong?
In contrary doing forward planning "against" a given end, what can't
be shifted by several reasons is more difficult to hit the line and
made a touch down.
Michael

There are others on this forum who have written repeatedly and more
eloquently on this over the years. Perhaps they will jump in.

First, the end date is *not* given. The project will take as long as it
takes. Yes, it is given that your organisation has signed a contract or
you have made some sort of promise. And surely someone high up in the
organisation has said "this will happen" and then made some sort of
suggestion about how heads will roll if it does not happen.

But that posturing and leadership is not good enough. You need a plan
that the team has confidence in that will lead them to the expected
finish point. In absence of a viable plan, then posturing and leadership
is all you have and you should not bother using Project or the manual plan.

If what you are suggesting is that when you model the project execution
in Project you have a project completion milestone and you make that
milestone a "must finish on" the committed end-date along with setting
all the predecessors to be ALAP, you will get just that. You will get a
plan that gives you the target start/end dates for all tasks scheduled
as late as they can be in order to satisfy the completion date. It will
give you the backwards plan that gives you the last possible date you
can start the project for which you can compelete the project on the
committed date. That means you have no slack and if any task runs late
not only will Project complain to you, but your project is at great risk
of slipping since all subsequent tasks now have to get done in durations
shorter than planned. As you can appreciate, once that understood and is
communicated to the project team, great stress will appear.

Instead, build a plan that will deliver the deliverables using a logical
procession of sub-deliverables and/or asks that build up the final
project deliverable that has been committed. Unless there is a special
reason to do otherwise, make all tasks ASAP since it's natural to
schedule things to be done as soon as possible. This can also give you
more slack in the schedule if you design it right. You need a plan that
can accomodate risks, changes in scops, delays, accelerations, change
requests, and mistakes. Based on your logic of how to execute the
project, let Project compute the end date. If you don't like that end
date, then you have to change the project plan. Put a Deadline date on
the final project completion milestone task. If Project computes a
completion date that is beyond the deadline, it will tell you (see the
Indicator field).

So along these lines, the most important decision you should ask your
leadership to make is the following: "We are committed to completing
this project by [insert date]. To which target date should we develop
an execution plan so as to increase the chances we can actually get done
as promised?"

Clearly, the more you bring the target date backward, i.e. nearer to the
start date, the more unlikely the achievement of that date is possible.
The more unlikely you make the plan, the plan will then not have
credibility. A plan with no credibility means a plan that will not be
used. This could lead to great stress imposed on the project team.
However, at the same time you should press them for something that is
earlier than committed to give you some contingency and flexibility.
It's a tough call. That's why you want the bosses to make this decision.

Me: Depends on the type of project it is, e.g. IT projects are
different than building construction. But I guess try to commit to an
80% probable schedule with the client and target the project to achieve
a 25-50% and perhaps relax that target at about the 50% progress point.

Rob,
I like your detailed description and enlightning insides very much --
and I'am totally with you.
It depends from the project type whether the end is really fix or
could be shifted. In case for example, aerospace, you probably could
not shift a rocket launch easily only since your project plan
exceeds ;-) - Therefore you have to cope with no slack and high risks
in the project.
In the world of IT and SW development it happens more often that the
product launch deadline miss the xmas sales profit, without any
serious harm.

Michael

 

[Rob Schneider]

On May 26, 7:08 am, Rob Schneider
Michael,
This is good news. People often like to think that manual is best.
That viewpoint can be right when done with enough complexity so as to
not fool one's self. The trick is that it's easy to get fooled.
Hopefully at this point you can convince the planning staff to start
again and build the schedule model/estimate in Project (or equivalent).
In addition to providing some aids for dealing with the schedule
complexity, this approach will get you to one plan in which you can
focus on the plan instead of focusing on two plans and then having to
resolve differences.
And: for so many reasons, don't try to schedule with "as late as
possible" tasks using backward planning. do it on a forward-planning
basis ... develop a plan for which Project computes the completion dates
with "as soon as possible" tasks within your deadlines. If you don't
like the computed dates, change the plan.
--rms
Hi Rob,
doing forward planning although the end date is contracted / stated is
an impressive idea - I like that.
But what is wrong with backward planning and ALAP tasks - they will
schedule with most greatest slack possible, which can be adjusted more
easily - or I'am wrong?
In contrary doing forward planning "against" a given end, what can't
be shifted by several reasons is more difficult to hit the line and
made a touch down.
Michael

There are others on this forum who have written repeatedly and more
eloquently on this over the years. Perhaps they will jump in.

First, the end date is *not* given. The project will take as long as it
takes. Yes, it is given that your organisation has signed a contract or
you have made some sort of promise. And surely someone high up in the
organisation has said "this will happen" and then made some sort of
suggestion about how heads will roll if it does not happen.

But that posturing and leadership is not good enough. You need a plan
that the team has confidence in that will lead them to the expected
finish point. In absence of a viable plan, then posturing and leadership
is all you have and you should not bother using Project or the manual plan.

If what you are suggesting is that when you model the project execution
in Project you have a project completion milestone and you make that
milestone a "must finish on" the committed end-date along with setting
all the predecessors to be ALAP, you will get just that. You will get a
plan that gives you the target start/end dates for all tasks scheduled
as late as they can be in order to satisfy the completion date. It will
give you the backwards plan that gives you the last possible date you
can start the project for which you can compelete the project on the
committed date. That means you have no slack and if any task runs late
not only will Project complain to you, but your project is at great risk
of slipping since all subsequent tasks now have to get done in durations
shorter than planned. As you can appreciate, once that understood and is
communicated to the project team, great stress will appear.

Instead, build a plan that will deliver the deliverables using a logical
procession of sub-deliverables and/or asks that build up the final
project deliverable that has been committed. Unless there is a special
reason to do otherwise, make all tasks ASAP since it's natural to
schedule things to be done as soon as possible. This can also give you
more slack in the schedule if you design it right. You need a plan that
can accomodate risks, changes in scops, delays, accelerations, change
requests, and mistakes. Based on your logic of how to execute the
project, let Project compute the end date. If you don't like that end
date, then you have to change the project plan. Put a Deadline date on
the final project completion milestone task. If Project computes a
completion date that is beyond the deadline, it will tell you (see the
Indicator field).

So along these lines, the most important decision you should ask your
leadership to make is the following: "We are committed to completing
this project by [insert date]. To which target date should we develop
an execution plan so as to increase the chances we can actually get done
as promised?"

Clearly, the more you bring the target date backward, i.e. nearer to the
start date, the more unlikely the achievement of that date is possible.
The more unlikely you make the plan, the plan will then not have
credibility. A plan with no credibility means a plan that will not be
used. This could lead to great stress imposed on the project team.
However, at the same time you should press them for something that is
earlier than committed to give you some contingency and flexibility.
It's a tough call. That's why you want the bosses to make this decision.

Me: Depends on the type of project it is, e.g. IT projects are
different than building construction. But I guess try to commit to an
80% probable schedule with the client and target the project to achieve
a 25-50% and perhaps relax that target at about the 50% progress point.

Rob,
I like your detailed description and enlightning insides very much --
and I'am totally with you.
It depends from the project type whether the end is really fix or
could be shifted. In case for example, aerospace, you probably could
not shift a rocket launch easily only since your project plan
exceeds ;-) - Therefore you have to cope with no slack and high risks
in the project.
In the world of IT and SW development it happens more often that the
product launch deadline miss the xmas sales profit, without any
serious harm.

Michael

Michael,

We're going to have to agree to disagree. I understand deadlines are
fixed. The when projects get done are when projects get done.

My religion says to never build a project plan, especially one that uses
other people's money, where there is no contingency and high risks which
are unmitigated unless the benefits are sufficiently high. The problem
is that benefits are usually never high enough to justify such risky
investments, or if we think they are we are probably fooling ourselves.

And looking at the NASA Space Shuttle as just one example, I think there
are plenty of examples in aerospace where failure of project plans and
unmitigated risks contributed to schedule changes.