[kplato] PERT distribution/risk
Dag Andersen
danders at get2net.dk
Tue May 23 13:24:54 CEST 2006
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
> kplato at kde.org
> https://mail.kde.org/mailman/listinfo/kplato
--
Mvh,
Dag Andersen
More information about the kplato
mailing list