Comparison of Change Management Systems

14
Management
behavior. They all looked very worried,
stopped the usual small talking and
stayed until late at work. It turned out
that all three were assigned some extrawork
from the CEO (of course, with the
mandatory comment ‘don’t tell him about
this…’). And, as a logical implication, all
three were now behind schedule for the
testing tasks.
The classical scheduling
method major problems
Test managers build the schedule and
fix the deadlines from estimates of
duration required by the various tasks
that comprise the test project by doing
first a high-level estimation based on
historical data, and then by asking the
team members about their personal
tasks estimation. There are also other
effort estimation techniques, but anyway
the historical data and the personal
task estimation are often used. Testers
know that they will be held accountable
for delivering against their estimate.
Therefore, it is prudent that they include
not only the amount of time they expect
the work to take, but also some extra-time
to protect their estimation. So testing task
estimates have plenty of safety in them,
supplementing the
The test manager then uses these
estimates and builds them into a list of
dependent tasks with associated startdates
and due-dates. It’s not unusual
that the test manager will add an extrabuffer
to the initial task duration, often
expressed as a fixed percentage (let’s
say 10% of the initial task size). Testers
plan their work around these dates and
focus on delivering their deliverables by
these dates [2,3].
But, in practice it often happens that a
tester receive some other urgent job,
regardless on his current assignment. And
he has plenty of time until the promised
date to finish the original work, which at
this point looks like a long way off due to
the safety included in the estimate. So,
in the most cases, he is easily putting
off or delaying the original work in favor
of other stuff because the due date is
out there, in a ‘safe’ future. This “urgent
job” takes precedence until he sees the
scheduled due date coming up on him.
Now the originally scheduled project task
is hot. He starts working hard to finish the
original task on-time…but, usually, it’s
too late for this.
The first problem which strikes now is
that he can't know what problems will
impact him until he starts the work. And
he started the work later than planned,
after eating up most of his ‘safety interval’
because of the other important work.
There isn't time left to recover from the
problems in time to meet the due date,
at least without heroics, burnout, or loss
of quality because of bugs that ‘escape’
unnoticed. So, this way the testing task
deadlines get hard to meet...and cascade
through the testing project, putting the
promise of the final delivery into jeopardy,
which creates new “urgent stuff” which
impacts other projects...and so on and
so forth.
The second problem is the Parkinson
law ("work always expands to fill the time
available"). Even if, by some miracle, a
tester will finish a testing task early, will
the required ‘next’ tester be available to
pick it up? Or will some other tester feel
an urgency to pick it up? The answer
is no, because everybody will strive to
‘protect’ its own ‘safety’. So, in these
circumstances, the testing project is
pretty well doomed to meet the final
target date at best, but in all likelihood
missing it, or just making it with burnout
heroics, bad testing quality or poor test
coverage. There is also the so-called
“Student syndrome” - many people will
start to fully apply themselves to a task
just at the last possible moment before
a deadline. This leads to wasting any
buffers built into individual task duration
estimates.
This all occurs due to the combination
of task due dates and realistic, prudent,
“safe” estimates. We protect our testing
project due dates by protecting testing