:Some things I've learnt

Back to start page.

1. The human factor.
   Or pushing ENTER too fast. The person that did it usually realizes his mistake quickly and can immediately take measures to correct the mistake. If not quickly realized, the error will soon be discovered anyway, and the person with the quick fingers can by telling about the mistake be a good help in error recovery. People afraid of admitting their mistakes can be a complicating factor.
   This type of errors usually not cause any effects that fall outside an error probability calculation. And people tend to be forgiving with experienced fellows that sometimes do mistakes.
2. Late deliveries.
   A very common source of problems. Late or incomplete deliveries makes it hard or even impossible for expensive and time-limited consultants to do their job. Late deliveries is often about hardware or standard software, for example: At installation of Windows NT, no service pack is available at hand. The solution is to split a project in well defined phases, with checks before going to the next phase. The phases that leaps a risk of late deliveries must be identified and spare time should be planned between the phases.
   Surprisingly enough, late deliveries is seldom seen in an error probability calculation.
3. Uncommitted resources.
   The problem can be found in projects where many contractors are engaged, and by that cause only takes part in a limited time of the project. Then they have other commitments that seems to grow in importance in inverse proportion of their time in your project. I have experienced consultants that felt it more important to eat cake at the home office than configuring an ISDN line that 16 (more expensive) consultants are to use the next day. The solution is to have a tough project leader that can sense tendencies like this and push people to do their job. Note that the problem can occur even with one single contractor.
   This problem is never accounted for in an error probability calculation.
4. Technical errors.
   This type of errors ALWAYS occur. They are best foreseen and handled by people with top competency in the actual area. (See my CV for the areas that I can be expected to manage.)
5. Murphy’s law.
   A very competent colleague of mine spent a whole working day preparing an operation that involved system managers of two different machine parks, four different subsystems, five persons, file transfers, batch jobs and weekend work. After finishing the preparations he instructed the first person in the event chain. (This was Wednesday before lunch, the only possible time for the real operation was Saturday morning.) He did it "live" with the intention to stop "before the last click".
   My colleague tells that everything starts "by clicking there", and the instructed person clicks RIGHT THERE! The rest of the week was spent putting everything in order again... (See also item 1)
6. No project managing model.
   No matter what competency and experience you have, the result will ALWAYS be better of you have a project managing model to guide you in your work. Even if it's just a check list on a paper, it helps much. The bigger scope in the model, the bigger initial cost -and more expensive project leaders. But saving money by working "ad hoc" is seldom cost effective.
   Complicating factors are project members that are unused to work in projects, or even unaware that they are working in a project. It could be more cost effective to educate such project members than to employ expensive leaders or advanced project managing models.
   In a production environment a similar problem could be unsatisfying hand-over at production start, bad documentation or organisational problems. Another trap is members that joins the project/organisation after the initial start. Often, they do not get the same introduction of routines, documentation etc. as the members that has participated from the beginning.
7. People without limits.
   There are people that overcome almost any problem that is described here. They are accomplishing this by doing much more than what is expected from them: They do others work, fixes others errors, work nights and weekends. The only thing they are doing wrong is that they do not put up limits. Sooner or later something else will put up a limit for them, family reasons or illness for example. At that time you will discover that there has been an anonymous key person in the team.
   The solution is to have an observant leader that keeps regular meetings, not necessarily group meetings, where activity reports are gathered.
   Sometimes the key person isn't anonymous, but one doesn't realize the importance of this person. Work is planned as if this person will always be available.

Back to start page.