Re: PERT distribution/risk

Hi, sorry for the slow response but I'm afraid it will be quite normal 
during summertime.
On Thursday 11 May 2006 19:17, Jim Sabatke wrote:
> Dag Andersen wrote:
> > Hi, need some guidance on this.
> >
> > I find the following in the requirement spec:
> > <quote>
> > Durations are calculated for a task based on the resources
> > assigned to it. The following factors need to be taken into
> > account: The effort required from each resource
> > The risk associated with the resource/task pairing
> > The availability schedule of each resource
> > The other task commitments of resources
> >
> > Note  [Jim Sabatke]
> >   Allow task durations to be calculated from the following
> > columns:
> >
> >          "Optimistic Hours"
> >          "Pessimistic Hours"
> >          "Expected Hours"
> >          "Risk"
> >          "Duration"
> >
> >          The "Duration" would be calculated like:
> >
> >          "Risk" = Low        Duration = (OH + 4EH +PH) / 6
> >          "Risk" = High      Duration = (OH + 4EH + 2PH) / 7
> >          "Risk" = None      OH = EH = PH = "Duration"
> >
> >          If Duration is entered, then OH, PH, EH all will be set
> > to "Duration" and "Risk = None"
> > </quote>
> >
> > It's the Risk that makes me uncertain. AFAICS it's a way to
> > handle the fact that some people are created more equal than
> > others and hence, that the time it takes to complete a task is
> > dependent on the specific resource(s) assigned to do the work.
> >
> > Selecting a "High" risk thus effectively says: I don't think the
> > people assigned to this task is able to finish it within the
> > normal estimate, so I increase the estimate.
> >
> > Also I think the risk must be interpreted to be for "resources
> > (plural)/task pairing" and not for "resource/task pairing" as
> > stated above? (Maybe what was meant anyway?)
> >
> > IMHO it's not the estimate that should be modified but the
> > efficiency of the resource. To register this may be sensitive,
> > though, and might even be illegal in certain countries?
>
> I had spent a lot of time thinking on this subject.  One of the
> first things I noted is that resources are not only more equal than
> others, but more or less equal on the type of task.  For example: a
> resource might be much better at SQL coding than C++ than C than
> shell, etc.  I first thought that creating an inventory of resource
> skills might be a good idea and let the program assign risks.
>
> The more I thought about that, the more I realized that maintaining
> that inventory set would be a huge task.  For example: a resource
> not good at SQL probably would improve significantly over the
> course of the project if assigned such work and mentored properly. 
> That means that learning curve would have to be included in the
> inventory.  You can see that it becomes very complex quickly.
Yes, agree.
>
> Then you have the situation of highly motivated vs. unmotivated
> employees.  Some resources like to stand around and talk or surf
> the net more than work, at least in my experience.  Then sometimes
;)
> they do quick, sloppy work to make the hours allotted.  I think
> this may be problematic for a resource inventory and probably where
> any legal questions might come in.
Agree.
>
> Finally I realized that project managers are there for a reason; to
> ensure that a project is properly planned, resourced and to
> control/motivate the resources as required.
>
> I don't think it is unreasonable to assign a higher risk for
> inexperience; it's simply a fact of life.  You can assign lower
> risks to tasks for those employees as they get over the learning
> curve for the technology involved.  
Agree.
> If you get stuck with a less 
> motivated employee, you need to deal with that situation according
> to your own methods and company policies.
>
> The key here is that KPLATO should not be a project manager.  It is
> a tool to plan, evaluate and communicate the progress of a project.
>
> Thoughts, ideas??
When I look at what "Risk" can contain, it seems to be a "catch-all" 
for almost anything that may cause the execution of the task to take 
longer than it "normally should". (Normal meaning what has be 
estimated with optimistic/expected/pessimistic.) Just look at your 
points above, add those from your next mail and the mail from Thomas.

As I see it, *implementation wise* risk must be coupled to the task. 
*Concept wise* it is coupled to a "task/resources (plural) pairing",
(by this I have answered my earlier question) and thus the ui should 
probably go with the resource allocations pane. Hmm, but Risk=None 
should actually deactivate the whole PERT thing (using only the 
expected estimate, not optimistic/pessimistic) so maybe risk should 
go with the estimate ui anyway? We'll see.

If we keep it at this, I think it's fairly easy to implement. 
It doesn't give the user very fine-grained control, and what risk 
actually means is up to the user, but still...
I have been trying to see how to implement this in a way that makes it 
understandable to the user, both in the sense "what is risk" and 
"what is it's effect on the project", but I think that is too 
ambitious. Explanation will have to go into tool tips, what's this 
and documentation.
>
> Jim
> _______________________________________________
> kplato mailing list
> [email protected]
> https://mail.kde.org/mailman/listinfo/kplato

-- 
Mvh,
Dag Andersen