The User, Which one?
During recent posts on systems implementation and delivery over the last few days, I have mentioned frequently the various users that inevitably access and use an organisation systems for various purposes.
On today's journal I would like to consider who those users are and what there requirements are:
. The political User -
Because of the various elements that a system comprises, and the ever changing environment to which most organisations are party, we should remember that a system interrelates with several users at the same time.
At the highest level, we find a user in search of a 'political' target. For example, sales increase, improved positioning, client loyalty, etc that are normally related to company-wide goals and objectives. This is not necessarily the person who actually requests the system, but in practice he can destroy the whole project by simply changing his mind. For didactic purposes, I shall call him the political user.
. The Asking User –
Somebody must take the political user thoughts and produce a concept that can somehow be measured; in other words, the wish must be shaped so that constraints, basic features and other aspects can be established. I usually identify this individual as the concept user. He is permanently close to the project and my experience is that if this user disappears for any reason, projects proceed anarchically, and then die, because of the inadequate conceptual guidance. The asking user should see that the project maintains proper coordination with the high level company policies that brought it to life.
. The Managing User -
A more common user appears now, frequently referred to as a user representative and sometimes confused with the business analyst. From my point of view, what we actually have is a technical user, somebody to whom we can talk in a meaningful way, such that he will understand our technical limitations and eventually even agree on necessary trade-offs. This user is extremely important. The nature of his job implies that you should never accept a system with two technical users, since some decisions will imply that one function loses and another wins; we try to avoid being left in the middle, operationally. However, many final users or functions the system will have, the concept of having one centralised voice to negotiate features or final operational models cannot be emphasised enough.
. The Operating User -
Another kind of user exists as staff that will actually fill in forms, key in data on the screens, read listings and so on. They are all operational users and they bring their thoughts to the technical user. They will even press for certain features to be in place, but it will only be the technical user who can actually decide what to do, because operational users will normally recognise his authority and knowledge. If we realise that something wrong is happening, we should ask our technical user to handle the problem with the rest of the users. No matter how right we are, they recognise his authority, not ours.
The operating user exists at different levels throughout the firm, from clerk to manager. I am often amused to hear computer people declaring that their system will be an incredible success, since the user has been actively involved. I ask myself: all users?
. The Real User -
When faced with the alternative of multiple end-users, we actually feel tempted to request one single end-user representative to deal with. However, there is rarely a single person that can handle the many problems likely to be encountered during the systems development process. We can have a single representative, but we still need to interrelate to more than one user, and to collate information from several places to obtain meaningful results.
Once we are convinced, after extensive discussion with all the individual users, about the nature and structure of the solution to be implemented, we can attempt to convince our technical user of what should be done. He will then be left with the full responsibility of undertaking other people's motivation and manipulation. This may not sound polite, but it works.
Case Study:
Several years ago, a project manager to whom I was assigned decided to build the company's Information Systems Plan, all on his own: in a short time something very like a plan was announced. Each and every administrative step was specified and the necessary resources allocated, yet we failed to identify users. The main problem lay in the fact that all the top management had 'approved' the plan, but their political requirements were not included, so they were not prepared to 'support' it: it was not their plan, but ours. Needless to say, there were considerable delays and difficulties when we attempted implementation, and of course the final result was far different from that expected. Actual costs incurred was way, way over budget which again, asked questions concerning strategy and effectiveness. Effective teamworking is certainly part of the solution.
