A project’s dependency on resources’ (average) utilization time (UT) and quality expectations expressed as a quality factor (QF) doesn’t come as a surprise, as hopefully one is acquainted with project’s triangle which reflects the dependency between scope, cost and time in respect to quality. Even if this dependency is intuitive, it’s difficult to express it in numbers and study the way it affects the project. That was the purpose of the model built previously.
From the respective model there are a few things to ponder. First, it’s a utopia to plan with 90%
UT, unless one is really sure that the resources have enough work to bring the idle time close to zero. A single person can achieve maybe a 90% UT if he works alone on
the project, though even then there are phases in which the input or feedback from
other people is necessary. The more people involved into the project and the
higher the dependency between their activities, the higher the chances that the
(average) UT will decrease considerably.
When in
addition there’s also a geographical or organizational boundary between team
members, the UT will decrease even more. In consequence, in big projects like
ERP implementations the team members from customer and vendor side are allocated
fully to the project; when this is not possible, then on the vendor side the
consultants need to be involved in at least two projects to cover the idle
time. Of course, with good planning, communication, and awareness of the work
ahead one can try minimizing the idle time, though that’s less likely to
happen.
Probably, a
better idea would be planning with 75% or even 60% UT though the values depend
on team's experience in handling similar projects. If the team members are involved also
in operational activities or other projects, then a 50% UT is more
realistic.
Secondly, in the previous post was considered in respect to quality the 80%-20% rule which applies to the various deliverables, though the rule has a punctual character. Taken on the average the rule is somehow attenuated. Therefore, in the model was considered a sprung between factors of 1 to 2 with a step of 0,25 for each 5% quality increase. It's needed to prove whether the values are realistic and how much they depend on project's characteristics.
On the
other side, quality is difficult to quantify, and 100% quality is hypothetical.
One discusses in theory about 3 sigma (the equivalent of 93,3 accuracy) or 4
sigma (99,4 accuracy) in respect to the number of errors found in the code, though
from there on everything is fuzzy. In software projects each decision has the potential
of leading to an error, and there’s lot of interpretability as long there’s no
fix basis against to compare the deviations. One needs precise and correct specification
for that.
I think
that one should target in a first phase 80% quality (on average) and further
build from there, try to improve the quality iteratively as the project goes on
and as lessons are learned. In other words, a project plan, a concept, a design
document doesn’t need to be perfect from the beginning but should be good
enough to allow working with it. One can detail them as progress is made into
the project, and hopefully their quality should converge to a value that is
acceptable for the business.
Thirdly, in
case a planning tool was used, one can use the model backwards to roughly prove
timeline’s feasibility, dividing the planned effort by the estimated effort and
the number of resources involved to identify the implied utilization time.
No comments:
Post a Comment