Optimization Tool for MS Project?

[Riko Wichmann]

Dear all,

I'm sure this must be a question many people asked, but google did not
come up with any useful answer.

Is there an add-on or otherwise tool, which helps you to optimize MS
Project plans?

Of course, there are numerous criteria to which you may want to
optimize, e.g. total project duration, project cost, resource usage etc,
etc, etc.

We are currently interested in a duration optimization. How do I have to
arrange my tasks with given resources to get the shortest possible
duration of the project?

Does anybody know of a tool/add-on which performs this kind of tasks?

Thanks,
Riko

 

[Rod Gill]

First get a realistic critical path, then remove resources from non-critical
tasks and add them to critical tasks to shorten them until you have little
or no slack left.

WARNING: you now have a schedule with little slack which means any task that
is delayed delays the finish date of the project. A high risk project
time-wise!

A tool would be little help here as to provide enough information to be
useful you would spend as much or less time doing it manually!

 

[Rob Schneider]

In addition to Rod's right-on comments, an add-in tool that I do like
(but it will cause you to add time to projects!) is @risk which allows
you to compute a probabilistic view of most probable project durations.
I consider "most probable" as being "optimum" as it's a compromise
between the extremely high-risk "minimum" that the critical path will
give you, and even longer project durations one can imagine.

 

[davegb]

In addition to Rod's right-on comments, an add-in tool that I do like
(but it will cause you to add time to projects!) is @risk which allows
you to compute a probabilistic view of most probable project durations.
I consider "most probable" as being "optimum" as it's a compromise
between the extremely high-risk "minimum" that the critical path will
give you, and even longer project durations one can imagine.

Rob,
I'm curious. How does straight up CPM give you an "extremely high risk
minimun"? In my experience, that only happens if you crash the CP. Can
you elaborate?

 

[Rob Schneider]

I can't give appropriate due this subject justice in this short note,
and in the time available to me right now, but I'll try anyway. Add to
the "to be blogged" list as I'm busting at the seams to explain and
teach what I've learned ...

By definition, the critical path is the sequence of activities with the
overall longest duration which determines the shortest time possible to
complete the project. Cracking the critical path, in my understanding
and experience, means critically looking at each activity on the
critical path and make changes to the project execution plan to reduce
the duration, or to do something different to get it off the critical
path. Doing this over and over keeps reducing the project schedule.

Now, depending on how you compute/assume/agree the duration of the
individual activities which form that path, determines the "risk". If
these were all "optimistic" and "shortest possible", e.g. no buffers or
breathing room, then the likelihood every single one of these durations
being completed as exactly as expected all in minimum time is extremely
remote, hence the overall program would thus be "high risk" since it has
low probability of being achieved. Each delay to each takes has a
cumulative overall affect on the overall project. So the "high risk" is
the improbability of things happening as it's assumed to happen.

I'd say a target schedule with 20-50% probability (stretch) is one you
should agree with your project manager, and one with 50-80% (more
likely) probability is one to agree with the stakeholders. The goal is
to end up somewhere in the middle.

The problem is to figure all this out, often without real data and/or
metrics. If you do have experience data, so much the better.

Simplistically, what using @risk the tool allows you to do with some
ease is to express (amongst other things) some or all of the durations
as a "probability" (and specifically assign a particular probability of
distribution). For example, the task "dig foundation" has an absolute
minimum duration of 10 days (digger can't physically dig faster than
that). The maximum is infinity e.g. could be started and never get
done. Between those two extreme end points on the distribution of
possibilities lies a "probability distribution curve". It's not "normal
distribution" (the one everyone is familiar with from Stat 101 at
university) since it's skewed to an open-ended right side (on the
infinity side). But none-the-less, some sort of curve. Historical data
can suggest the form of this curve, but let's just assume that the
minimum is 10, the mean is 20, and the 90% (90% of the curve is to the
left) is 40 days. Instead of picking 1 point for the duration (10), use
this "distribution". Select a distribution of points for a few or many
of the tasks on the project. Then try all combinations of all durations
one at a time to find out the computed end-date of the project. That's
called Monte-Carlo Simulation. Collecting the results of all the
computed end points can be drawn up into it's own probability
distribution curve to give you an assessment of the overall result
(expressed as the duration, cost, or whatever). From that point you can
start making judgments, thinking about risks, comparing the risk of
different cases, etc. and start driving your thinking about what to set
as the target dates, how much "space" or "buffer" to put into the
programme (even if on the critical path and adding duration/cost), etc.

The idea is to de-risk the project to make project success a possibility.

I hope this makes sense. Easier to explain all this with a white board
in front of me. And many others have written so much more about it in
eloquent ways. There are a number of good books.

 

[davegb]

I can't give appropriate due this subject justice in this short note,
and in the time available to me right now, but I'll try anyway. Add to
the "to be blogged" list as I'm busting at the seams to explain and
teach what I've learned ...

By definition, the critical path is the sequence of activities with the
overall longest duration which determines the shortest time possible to
complete the project. Cracking the critical path, in my understanding
and experience, means critically looking at each activity on the
critical path and make changes to the project execution plan to reduce
the duration, or to do something different to get it off the critical
path. Doing this over and over keeps reducing the project schedule.

I've never heard the expression "Cracking the critical path" before.
Unless you tell me different, I'll assume it's the same as "crashing".

I agree that crashing is high risk. I guess I thought in your first
post you were saying that doing CPM was by definition high risk. A CPM
schedule doesn't have to be crashed. I've worked in places where most
of the projects being done were done in what we considered "optimal"
time. That is, a time frame that got the project done in an
economically desireable amount of time, but not anywhere near crashing.


What I'm trying to say is that CPM doesn't automatically mean crashing.
Ergo, it doesn't automatically mean high risk. In many, if not most
environments where projects are done frequently, they are always
crashing because they don't know how to manage their portfolio of
projects. So crashing becomes the norm, incurring the risks associated
with it. I could write pages here about why projects still come in
consistently late even when all PM's have been thoroughly trained
because management hasn't created an environment where projects can
consistently be on time. It's a common misconception that if the PMs
know what they're doing, most projects will be on time. In fact, I
teach a class called "Project Management for Management" which explains
why projects will rarely come in on time and within budget if there
isn't an environment created in which this is possible. And that is has
to be created by management.

I just want to clarify that CPM, in a project friendly environment,
does not mean crashing. In the environment I'm advocating, crashing
becomes so rare, it's acutally fun because it's unusual and
challenging!

 

[Rob Schneider]

Cracking, crashing ... yes, slip of the fingers.

No, I don't think that CPM is by definition "high risk", but it's
"higher risk" compared to other "later" scenarios. All depends on how
much flexibility in the assumptions of the plan.

Like you I think, I believe "crashing" often done by desperate
organisations. I also believe that "crashing" is not a required part of
critical path. Unfortunately, for some who get an understanding of what
the critical path is, it becomes an attractive "target" to go after.
Then risk increases.

Like you, I also believe in ensuring to the best of our ability, that
projects are designed to be "possible", and "achievable". [In the world
I currently work in, we seem to go around making high risk projects all
the time, hence I've done a lot of thinking about this topic.]

 

[davegb]

Cracking, crashing ... yes, slip of the fingers.

No, I don't think that CPM is by definition "high risk", but it's
"higher risk" compared to other "later" scenarios. All depends on how
much flexibility in the assumptions of the plan.

Like you I think, I believe "crashing" often done by desperate
organisations. I also believe that "crashing" is not a required part of
critical path. Unfortunately, for some who get an understanding of what
the critical path is, it becomes an attractive "target" to go after.
Then risk increases.

Like you, I also believe in ensuring to the best of our ability, that
projects are designed to be "possible", and "achievable". [In the world
I currently work in, we seem to go around making high risk projects all
the time, hence I've done a lot of thinking about this topic.]

I agree, Rob. I think most organizations today are "designed", not
deliberately, to create an atmosphere of crisis management, for a lot
of different reasons. One of them being that it can cover a lot of
incompetance while making management feel like heroes.

 

[tadk]

I must admit the dialogue between you two on this thread was very helpful,
outside of the actual content. It is pointing me in some directions that i
was not aware of knowing about, in a conscious sense, but it made lots of
things clear to me about my current situation....I am now the project
scheduler and so i am working on keeping things on time, hit deadlines, run
all our stuff in MS Project, etc.

In reading this thread you explained a lot about what was going on before i
got here. No ideas how to correct things yet, but some clues.

again thank you

Tad

Cracking, crashing ... yes, slip of the fingers.

No, I don't think that CPM is by definition "high risk", but it's
"higher risk" compared to other "later" scenarios. All depends on how
much flexibility in the assumptions of the plan.

Like you I think, I believe "crashing" often done by desperate
organisations. I also believe that "crashing" is not a required part of
critical path. Unfortunately, for some who get an understanding of what
the critical path is, it becomes an attractive "target" to go after.
Then risk increases.

Like you, I also believe in ensuring to the best of our ability, that
projects are designed to be "possible", and "achievable". [In the world
I currently work in, we seem to go around making high risk projects all
the time, hence I've done a lot of thinking about this topic.]

I agree, Rob. I think most organizations today are "designed", not
deliberately, to create an atmosphere of crisis management, for a lot
of different reasons. One of them being that it can cover a lot of
incompetance while making management feel like heroes.