What is Systems Development (2)

If we were to somehow define our typical attitudes, requirements, etc while developing systems, we would probably mention some of the following:

. answers for every query or doubt that may arise;

. quick answers and solutions;

. if we do not have a particular query, "we have already considered it";

. if we have not even considered a particular problem, "it is scheduled for the next plan";

. impressive statements to smash the audience, such as: "hardware costs will decrease by 30% during the next 12-months" and, "end-users are bound to improve their technological perception";

. complex concepts in closing a conversation, such as: "channel saturation" or, "natural system overhead".

During a major systems implementation programme I was involved in during 1996 the project manager began a serious investigation within this field when he was told that the staff were not exactly happy, since they thought the project team in general expected more than they could deliver.

Then there was the case when the manager of a user department queried the probable implementation date for his system and was advised: "two or three weeks". After a few seconds, I distinctly recall how he increased the unit of time from weeks to months and then doubled the given number, concluding that a reasonable time 'for him' for actual system availability would be 4 to 6 months.

Organisations and people that lead them have probably encountered these sorts of situations before. Perhaps they can be summarised as two or three simple points:

• Team members are permanently concerned about the future;

• The ability to produce and project a self-confident image frequently fails;

• Promises are generally made that cannot always be kept.

What then is the origin of this paradox? What is it that causes highly qualified professionals to use cheap communications and selling techniques? Why, in some instances have we become the worst estimators? Why the need for always being concerned about the future?

Perhaps the reason for most of our problems lies within the nature of systems development itself, since we find ourselves today building a system that was defined yesterday but will be implemented tomorrow.