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.

Systems Development (3)

"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" ...

[Legal & Financial Guardian, 19 March 2007] Systems Development (2).


--------------------


Someone might argue that every building effort in the world exhibits the same kind of pattern, but I would reply that we are talking about the only information-processing building effort. The fastest element to change in our world is information, so our problem bears no resemblance to any other building process. On the other hand, why don't engineering works have the same type of standards? For example, why are there not common procedures in, say, designing a new car or bringing any other new gadget to life? The effort in building any kind of management and financial information system is made much more complex than traditional structures because of the human factor.

As a simple example, consider house building standards. There are many books that describe the process of building a house, so that we can predict the actual cost and time it takes to build one square foot of wall. But, there is no standard to predict the cost of satisfying someone's personal choice of co-ordinated curtains, furniture, floor-plan, garden layout, etc.

At systems level we have exactly the same problem. We can predict the cost of writing 100 lines of code and compare performance to any standard we wish, but actual systems building and implementation is much more than that. In fact, coding is accepted to be no more than 20% of the actual time and cost (and probably also no more than 20% of problems arising from systems design and implementation), so we see that fairly good estimating standards exist for only about 20% of our project. So, how do we budget for the other 80%? How do we estimate the time the user will take to reach a fairly good user specification? How, for example, do we handle the ever-present change requests?

At this stage it is probably worth addressing some of these problems in more detail:


User Evolution in Time –

The user who defined the system some time ago is normally not the one that derives the benefits. Also, and more importantly, today we work with a third user and when we reach implementation stage yet more people will be handling our system. In other words, we build according to instructions from somebody that has gone and we expect the next customer to accept the finished goods.


Technology –

Technology, for example, that was available when the system was requested may now be obsolete. It is likely that a different technology, or variations/adaptations to the existing package will be available either when the system is implemented or at a later stage.


Change -

As time passes, new technology and fresh users will generate changes. The organisation as a whole will also request changes, as it is forced to adapt and adjust to a changing environment.

As a quick guide there are generally three elements under permanent potential change during the development of any system: the client, the problem and the available tools. This particular issue explains, in basic terms, the requirement and need for a Project Manager - who himself must be prepared to face continual changes within the systems process. A colleague once suggested to me that a Project Manager should be prepared to face anything.

A quick way out of this difficulty is to freeze requirements. However, this is not only impractical but may even be suicidal: changes are inevitable, and all of us must accept that some of them might well be outside of our control. In fact, we ourselves should expect to operate in any organisation as 'change agents'.

On ending this topic today, I would like to draw readers to the feature that is becoming so important within any systems development programme: it is a SERVICE. This means that when a client comes to us, he has a problem that probably requires a dedicated approach to problem solving. It doesn't necessarily mean a quick-fix approach as this philosophy generally renders weaknesses in itself. As a service, whether it be within systems development or within certain areas of finance, we are somehow doomed to varying degrees of criticism.

I will now offer a definition:

... In my opinion systems development is a service intended to implement a technological change in a highly dynamic environment, a change that is necessary in maintaining a competitive edge. This should not necessarily imply a cost-base that is increasing because, by definition, systems should be designed in creating economies and greater effectiveness.

The value of information –

Accountants should aim to provide the right information to the right people in the right quantity at the right time, and at minimum cost. This raises the question as to what is optimal quantity, content, accuracy and speed of transmitting information. These alternatives have different costs and values, and it is clear that accountants should bear this in mind when collecting and presenting accounting information. Any design and implementation of a management or financial information system must bear these factors in mind. The system must be robust enough in meeting a variety of different requests. At the core of such requests and analysis will be the information itself. The quality of data should be aimed at reducing long-run costs for business in areas such as search costs, bureaucracy and labour. Also, better quality decisions might be made by postponing a decision until more information or information of greater accuracy is available. An effective and efficiently designed MIS will aid the process of making informed quality decisions, quickly.

In general terms there is normally a trade-off between speed on the one-hand and accuracy and quantity on the other. We should therefore compare the costs of improving information systems with the potential benefits that will likely accrue in the future. The relationship between costs incurred and the value of information provided is an important one.

How do we ascertain the value of the benefits of providing information? In theory, we should evaluate the consequences of taking each decision with a given amount of information; we then evaluate the consequences of taking each decision when extra information is available, and we use the difference between these two figures as a measure of the value of the extra information. If this value is in excess of its cost then the information should be produced.

…