Monday, 26 July 1999
Last week's Nut described how a project went to the dogs. This week an analysis why things went wrong.
  1. Fun
    There is no enthusiasm. 'Fun at work' is a critical success factor (www.businesstown.com/...-fun.asp). However, none of the participants seems to enjoy the project.
  2. Gap
    There is a communication gap between the analyst and the customer. The analyst does not bother to communicate in the user's language and fails to see that the technical schemes deter the user. The user's enthusiasm fades away. The analyst realises that things are not going smooth, but does not get beyond the phase 'Conscious Incompetent' of the 'Unconscious Competentí theory (dogwoodshelties.net/...).

    To make things worse, the analysts passes the buck to the user, right at the beginning of the project. It is wrong as the customer only knows what he gets, when he sees what he has got. That is way too late. The customer should have had a clear view, right from the beginning at drawing the first specifications.

  3. Shift off
    The idea to save time by shifting off issues to the next phase is really bad.
    • A job half done always gives problems. In a later phase nobody will know which half was ready. Very often, the whole analysis gets redone, or just half redone due to time pressure.
    • As a project progresses, it will take more and more time to investigate things and correct errors. 'Save' on analysis like this, and you can be sure that problems will strike back double during the construction phase.
    At the start of the construction phase, the programmers unjustly accept the incomplete design. They grumble a bit, but fail to take action.
  4. Manpower
    Additional manpower is not always effective. The law of diminishing returns goes for extra manpower too. Additional manpower might decrease productivity. Proverb: What 2 man can do in 2 days, a team of 10 can to in 10. Moreover, new staff need to work their way in. And the experienced employees won't have any time for guidance.
The leading thread that runs through the entire project is a lack of quality with 'time pressures' as excuse. There is never time to do things right, with the hope that future will provide time to correct errors. Those who know something of Total Quality Management (www.dbainc.com/...) realise that quality does cost time and money, but it is peanuts compared to the costs of non-quality.

So much for this analysis. Next week, in the final chapter of this triptych, an alternative approach.

Till next week!