Legal advice and case law provided on:
The above database provides information on relevant case law within the areas mentioned. Readers will find throughout the database that legal summaries provide the points of law being addressed, background to the cases and summary of the court's decision.
Note:
Click-on, above: "Employment case law database"
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:
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.
The Company and its People -
There are various things we should consider before any attempt is made in developing systems. One of the most important tasks is to understand the components of a company (in other words, its people). Strange as it may seem, the typical systems analyst is unaware of what his business counterparts looks like. 99% of analysts underestimate the capabilities of user’s and furthermore probably do not even listen properly to the user’s real problems. This is exactly how problems start and continue, in an unsolved state, as companies and organisations attempt to move forward.
When you look at a company, there are several aspects that should strike you: For example, the building, the revenue, social impact, number of workers, market penetration, output quality, etc. However, just for a minute imagine you have a microscope in your hands and intend using it to inspect one of the company’s basic components: the man who is right there in a corner, performing his daily work and filing a computer data-entry form. He has a 78.5% chance of doing it right (you know it because your system says so); the other 21.5% is covered by your validation programmes. Let’s now have a look at the output of the same company. Let’s ask a customer. Now we are due for a surprise: the goods are always right, not just 78.5% but maybe 99%. Ever thought what makes the difference? The employees, who can deliver an astoundingly good output at their practical work, somehow become substandard when it comes to filling out forms.
People may argue that the functional workstation to which I refer has been there for time immemorial, while the information system is only two years old. This maybe true, but then again, has the ability to be more technically proficient in recent years given us all an opportunity to be more effective through the use of IT and related systems? Maybe the difference lies somewhere else; maybe the workers and their predecessors have been refining the workstation for the last 100 years, but the modern information system has not yet had that same refining treatment. In other words, the environment has humanised the working procedures, but has yet to shape efficiently the information procedures. Some companies and organisations do have advanced information systems that are highly effective in providing reports and information for fast decisions to be made. IBM for example, is highly geared in meeting with the cut-throat world of globalisation. However, many smaller organisations, particularly those with a smaller client base are still far from the dynamic and efficient ways that is afforded through digitised systems. Information systems and their automation are as much relevant to the smaller scale company as it is to the multinational conglomerate.
We may represent the basic problem as understanding first what a company is and how it works - always remembering that a company is composed of people.
When scrutinising a company it will be found that the components are distinctly unique from each other. Each man or woman worker has individual targets and an individual reality, not necessarily in line with those of the company as a whole. It is these same people that later on re-organise as interest groups within the same company.
A simple example of how personal interests may differ from company interests can be found in the case of the executive who undertakes extensive and needless cost-cutting measures solely to exhibit his achievements at a later stage for justification for his next salary increase. Another simple case is when a company decides to reduce costs and therefore fire/reduce manning levels. It is obvious that in this case the company interest and those of the affected employees are not the same. However, a closer look at this last example shows that it is not really a faceless monster ("the company") that is dismissing people. In fact, the company compromises people: what is happening is that some people are getting rid of other people. (With a sinking ship, some people decide they will save themselves and let others drown, almost literally). Look around - where is the top executive who decided to fire himself as a means of reducing costs?
From a consultancy point of view the point to remember is that a company comprises groups of people: clerical, management, technical, production, etc. It is these groups that we should be interested in: they are the ones who will ultimately utilise our systems. Therefore, as a fundamental tenet of systems-design it is important that these groups be happy and comfortable with what is being done. This is not merely an extension of the user-friendly concept, it is in essence a completely new approach in the field of systems implementation and development.
Under ‘normal’ conditions, everybody will perform within expected standards. Nevertheless, when conflicts arise (and implementing a system is often a conflict in itself), a technician may suddenly become an ‘old’ technician, while his boss may suddenly be labelled as a ‘newcomer’ and therefore inexperienced. In this fact alone we see the elements that will make the difference between success and failure, no matter how well tested our system or how much effort we put into the development.
Though it may sound strange, it is important to view the firm as a living being that reacts according to external or internal stimuli. Hence, we must be prepared to overcome a natural hostility and rejection when we attempt the degree of intervention involved in systems development and implementation.
When problems are imminent, various symptoms become apparent: we should be ready to recognise them as such. Some executives may admit inadequate knowledge of technology and computing, thereby ducking the obligation of having to make decisions. Other staff may doubt the real benefits of the system, at the same time wondering if the new working demands will decrease or increase as a consequence of fresh procedures. After system implementation, the red lights may appear as complaints such as: “we didn’t have so many mistakes in the past” and, “our young computer and IT people don’t really understand the Company’s business”.
IT watchdogs often react with such weapons as user manuals and training, supported by executive briefs in which the user-friendliness of the system is widely demonstrated. The practical responses from staff are akin to saying things like “this is not what we need”, “this is not what we were promised” and, “this is unreliable”. With such sentiments the project manager soon realises the importance of understanding staff and employee concerns at an early stage during any systems implementation programme.
Anyone who has been engaged at management computer level will understand how systems start to mysteriously exhibit bugs, output becomes unreliable, and procedures become difficult to apply – as trained staffs are re-allocated to other departments. The final result is comprehensive discouragement to all the project team.
These are classical signs in any systems development implementation programme. It happens with amazing frequency, despite overwhelming efforts to avoid it.
As consultants, we must ask: “Why does this happen?” How is it that well-trained experts repeat the same mistakes? How can we rebuild from chaos and transform these fiasco's into future success?
In answering this question we must look at the approach we have previously used – it is likely that project managers have been fighting the SYMPTOM instead of the CAUSE. In other words, we must direct the systems development process in such a manner that it will become part of the organic firm, instead of an artificial adjunct, an alien prosthesis. On the other hand, we must remember that IT power continues to grow at an exhilarating pace, while our management techniques change, if at all, much less rapidly.
One final point to consider: it has become an accepted truth that for somebody to perform at a certain post, he must exhibit a psychological profile that matches the job requirements. In other words, what anybody could do in the past now requires special people to perform. This already says something about the poor quality of our work, and also explains somehow why we are not always welcome in transforming business.
Case studies in action:
Understanding the concept of information as a resource is not really as easy as it sounds. What we must be aware of is that information rarely exists in isolation. It is significant when one human being attempts to communicate with another. It flows from one person to another, and this is the type of relation that our systems must handle. We should even consider during the design phase that during this communication process, one of the two persons may not just be in the right mood, and any slight design mishap - such as something wrongly positioned on the screen - will be highlighted and thoroughly criticised, with bad effects on productivity. The line can sometimes be that fine. Like it or not, that's the way things can sometimes be. Overlooking such matters could, arguably, result in operational inefficiency or a rejection of the system that is being offered.
Design must have human factors, not just ergonomics, in mind. In a way, any consultant or advisor engaging within the role of supporting a new IT implementation programme must adopt a similar approach to that of a salesman (i.e. somebody eager to satisfy); the service concept must be there and must become apparent to the users, such that - however good our design is - we get the user to adopt the system as his own. Something that he feels comfortable with. Ownership, in a personal sense, can make the user want to learn more than the fundamentals which has to be good for any business who are often heavily reliant on what there technology and IT systems can do.
