Feature suggestion: 2 times for "duration of task": optimistic and pessimistic

Dear Mr Project developers!

Thanx for all your effort you put into this product.

He some of my 0.02c thoughts.

You are making a copy of MsProject, but you might consider some optional
additions of good functionality to be attractive even to people currently
using MsProject.

Please don’t overload the software by MsProject incompatible functions,
really make them optional features (configureable in an option menu). Only
when the feature is switched on, the menu items and features should be
accessible and visible to the user.
This is in the interest of the people coming from Ms.Project (and
unexperiences users) feeling at home when using MrProject. Afterwards they
can add step by step more functionality to their interface as they learn to
use the software.

As I am doing projects since 15 years, I consider myself as a little bit
experienced
about what does work in projects and what doesn’t.

The best literature about projects is “The Dilbert principle, p.235”.  A lot
of project managers I talked to about this agreed with me.

The definition of Project Management software in this book is:

“The software collects the lies and guesses of the project team and
organizes them into instantly outdated charts that are too boring to look
closely. This is called planning.”

You should recall every day the following sentence:
“Learning and making mistakes is allowed and needed!"

Each day working on a project means that you learn something new.
1) You find out that some things you have planned are not possible the way
you were planning. They take longer, they cost more money or they are not
possible to do at all (due to bugs in your tools).
2) you find out about new ways of doing things or find out about products,
materials, tools, suppliers you didn’t know when you were doing the project
plan. This might result in faster implementation than planned. Usually this
things are kept secret by the implementers (the project manager should not
get knowledge of it) because it gives them some time to rest.
3) You get a better insight into the problem you should solve (understand
what the user really needs) and what you tool can actually do and how the
needs should be implemented.
3) Requirements change constantly while a project moves forward. So you
should have a clear policy on requirement change.

All this means that what you plan to do is in a constant fluctuation.
You need to change schedules, structure, resource assignments, deadlines.

When you change the project plan while implementation, you do loose
oversight about
what was intended originally, what resources/budget were assigned originally
and who changed where and what.
So it might be a good idea to have a kind of CVS integrated and be able to
show at what time what changed.


To reach a Milestones it takes **one** person to take responsibility for the
timing and resource of this milestone.
Is has to be **taking** responsibility and not **assigned** responsibility
by the boss.
If the responsibility is assigned, a person can not be made responsible if
failing reaching the milestone. The person has to be given enough resources
so that she is willing to take responsibility.
A person which is responsible for a milestone must be also responsible for
all prior tasks and structure of the tasks  to reach the milestone. This
might be defined as subproject.
It might be needed that the project plan is stored in a database.
It might be needed that different people responsible for different
subprojects work on the project plan of their subproject and have the right
to do so, but don’t have the right to change the plan of other responsible
subprojectmanagers, but has the right to look at it.

It is the greatest thing for a subprojet manager if his subproject depends
on a milestone of some other subproject manager and the other
subprojectmanager does not meet his milestone. Because this is a great
excuse not to meet his own milestone.
This for, a subprojectmanager doesn’t want to have the progress of his own
subproject be transparent to others.

This is the reason why Project managers split projects into subprojects
which depend as little as possible.

I as a project manager try to build buffers into those milestones where
subprojects depend on each other.

In a project management software, you can assign the duration a task will
take.
But: You never can know how long the task will take really. So the duration
guess of a task
give by the implementers is most of the time on the save side, if the tasks
has to be implemented by the planner itself, he usually is more on the
optimistic side.

When implementers give to long times, implementation time is lost and the
structure of the implementation might be even not optimal. When planners
give too optimistic times, delays do cost a lot of money because a lot of
dependend tasks have to wait for the delayed task and the whole project
might be delayed.
And waiting does cost a lot on money.

I suggest that every task is give to durations of implementation. The
optimistic one and the pessimistic one.

Why this? At some tasks you can give quite good estimates how long they will
take (like “Concrete needs 7 days to dry”), other tasks can have quite
diverse estimations of duration (like “implementation of bug fix for bug
1223 will take between 1 day and 1 week”).

This way you avoid to assign resources to other tasks you don’t have because
one tasks takes longer than hoped. It is true that as a result you might not
use all resources all time when things go well, but this is better that not
to have the resource needed by a task which lies on the critical path and
therefore delays the whole project. For a more detailed explanation please
read “M.Goldrath 1984, The Goal. Excellence in Maufacturing”

It also helps you to structure the tasks in a manner that more unsecure task
durations doesnt have a big impact on the whole project.

You also can calculate a duration and cost structure of the project if
everything goes well or everything goes bad. So you can say: “This Project
will cost somewhere between 1.2 and 1.8 million Euro and will take something
between 6 and 9 months”.
This is much better that telling the client: “The project will take 234
working days and 789 man-days” . This is definitely unserious. When the
project duration approaches 200 working days, and the milestones are not
reached as written in the project plan as an exact date, the bosse just
cancels the project. Then it is added to the 60% of projects which are never
finished. This is not needed if it is properly communicated to the bosses
how long it might take.

You are right when you say that in this case a lot of projects would not be
started then when knowing and communicating the real risks upfront. You are
right. But you are always free to lie and not use this project management
tool and then not finish the project or get more budget from the management
because so much money was already invested. I personally prefer to know
upfront the risks.

As an advanced feature for your project management software, you even might
add a probability function between the shortest and longest time of duration
of a task. The result would be a probability function for time and costs of
the whole project.

Yours

Edmund Humenberger