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

On Sun, 18 Aug 2002 21:33:50 +0200 info <[email protected]> wrote:

i> Dear Mr Project developers!

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

I am happy to hear that they are not. The good things should be taken,
obviously, but I guess it would be very good to explore new ways to do
things.

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

You mean that MrProject should have a configurable MSProject mode?

[...]

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

Are thinking of something like impact analysis?
It would allow to check how some of the potential dangers to the project, which
usually are identified at early stages, would affect the deadlines.

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

Versioning, together with baselines, could be a rather powerful thing.

[...]


i> In a project management software, you can assign the duration a task
i> will
i> take.
i> But: You never can know how long the task will take really. So the
i> duration
i> guess of a task
i> give by the implementers is most of the time on the save side, if the
i> tasks
i> has to be implemented by the planner itself, he usually is more on the
i> optimistic side.
i> 
i> When implementers give to long times, implementation time is lost and
i> the
i> structure of the implementation might be even not optimal. When planners
i> give too optimistic times, delays do cost a lot of money because a lot
i> of
i> dependend tasks have to wait for the delayed task and the whole project
i> might be delayed.
i> And waiting does cost a lot on money.
i> 
i> I suggest that every task is give to durations of implementation. The
i> optimistic one and the pessimistic one.

Nice idea. 
On the other hand it may be simpler to  give a date with a standard
deviation as a measure of the 'error'. This would allow to get an estimate
of the deadline error bar.
The standard deviation could be assigned to resources, e.g. if Joe give better
estimates than Bill, this should reflect in the delivery date error bar if
I change the task assignement from the one to the other.
BTW, I do believe that (human) resources are people with different
caracteristics and that this should be considered in a planning tool.
 
i> It also helps you to structure the tasks in a manner that more unsecure
i> task durations doesnt have a big impact on the whole project.
i>
i> You also can calculate a duration and cost structure of the project if
i> everything goes well or everything goes bad. So you can say: “This
i> Project will cost somewhere between 1.2 and 1.8 million Euro and will take
i> something between 6 and 9 months”.

A kind of Value at Risk could be computed, saying something like 'there is
a 5% probability that we will overshoot by 30% in time and cost'.
Definitely and interesting idea.

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

I agree, risks should be presented upfront as clearly as possible. It is
then up to the client to decide if his business case is strong enough.
Have a look at Prince2.

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

Oh, I was commenting while reading therefore I've seen the above only at
the end ;o). However, I would use some distribution around a given
date and not a probability for each date. It is more generic.
One could even use another probability distribution than a normal one.
I would assume that the probability to miss the deadline is usually larger
that the one of falling short of it ;o), therefore an asymmetric
distribution would be better.

Ciao

-- 
Michele Ravani                  [email protected]
"Those who live hoping, die singing" My Gran