|
Sister Sites

www.coppertrees.com

www.agilearchitect.org
| |
Multiple
choice: your regular progress checks suggest to you that a task on the critical
path is likely to exceed its budget and timescale by about 50%. Do you:
- Run around the office shouting "Oh my God, we’re all going to
die!".
- Have a quiet chat with the group responsible for the task and find out
what the problem is. There are three likely cases:
- There is a difficult technical problem. The best solutions to this are a
brainstorming session, or temporarily moving your best problem-solver onto
the team with the problem. You will need to re-plan the tasks he or she
was working on.
- There is nothing intrinsically difficult about the task, but the
individual(s) working on it are not sufficiently skilled to make good
progress. The short-term fix is probably to have someone more skilled work
alongside them or take over part of the task. If you do decide to swap
tasks between people, then make sure you re-plan allowing for the lower
skill level which will now be on a different task, and for familiarisation
time for all concerned.
- The team are making reasonable progress, but the task is just much
larger than expected. You may be able to make up some of the lost time by
switching other resources onto the task or working overtime, but there are
limits to this: no-one ever recouped more than about 20-30% this way. If
you need more people or time you’ll have to ask your managers for more
budget, and revise your plan to take account of the slippage.
- Go down to the pub on your own and get very drunk.
- Hold a meeting of the team at the pub to discuss the nature of the problem
and possible solutions (see option b).
- Stop your reporting and checking - it’s obviously not working.
- Increase the frequency of reporting and checking while the problem
remains.
- Cancel all holidays and tell everyone to work an extra 5 hours a week.
- Immediately move your best resources onto the task with the problem,
abandoning whatever they are working on.
- Revise your plan, moving resources around if necessary. Note that if you
move resources from other tasks onto this one, the tasks they were working
on may now, because of the lower staffing, be on the critical path.
- Review your plan to see whether the same problem is likely to occur on any
other tasks which you haven’t yet started.
- Write a memo to your managers and the key user saying what you’ve found,
what you’ve done about it and the net effect you think it may have.
- Write a memo to your managers and the key user resigning your post.
- None of the above (and hope the problem will go away).
Score 5 points (very good) if your answer was some
combination of b, d, f, i, j and k. Score 0 points (depressingly average)
if you included any of a, c, e, g, h, l or m.
Obviously, the earlier you know, the better. Unless you have
good, regular reporting against a plan you won’t find the problem until it’s
too late (and some combination of a, c, e, g, h or l are your only way out!).
Overtime is a very limited solution to anything. If you are
making good progress on a job which is just bigger than expected you might get
an extra 10% effort through overtime. You’re unlikely to get any more than
this without either reducing the quality and productivity of the work, or
damaging other areas of the work, and you can’t keep it up forever.
Unless you’ve just got the wrong man on a job (and the
right man or woman can be moved onto it) you’re not going to get more than
about a 10-20% improvement by adding manpower to a task. Remember Brooks’ Law.
What this means is that you have to recoup any slippage over a number of tasks,
not just one. You must revise your plan, both to take account of the new
resources and known slippage, and to look for any other tasks which may have the
same problem.
A problem shared is someone else’s problem too! Don’t be
afraid to discuss things promptly with your team and managers. They may
see a solution you may be missing, or at least they’ll be better prepared for
adjustments to the budget or timescale if these have to be made.
© Questa Computing Ltd. 1999
Page last updated
20 April, 2007 15:54
|