Systems comprising hardware and software form significant elements in many people’s working lives.

Systems allow human users, for example, to process bookings in call centres whilst allowing management oversight, they facilitate military mission planning to balance effect and risk and they allow allocation of radio frequencies to those who demand access to the radio spectrum for wireless communication.

Many offer simplicity to the human user whilst running hugely complex algorithms in search of multi-dimensional goals.

Many are achieved through multi-million Pound or Dollar projects.

Some systems are developed to meet a market need and are commercial-off-the-shelf (COTS). These can evolve with the market that buys them. Some are completely bespoke, developed by analysts and developers to meet specific needs. And the middle ground is made up of the plethora of implementations that modify off-the-shelf (MOTS) hardware and software, to some greater or lesser extent.

In the true COTS case, a firm’s management, wishing to buy the system to gain efficiency or reduce costs, pay their money and take their choice. One hopes they choose well.

In the bespoke and MOTS cases, managers needs to understand something of the options available in the bespoke element of the system specification. Those options for change and customisation allow the system to be changed to better meet user need.

In any new system implementation, users are not passive, compliant beings. They have choices. Faced with a new system on Monday morning, they can react in one of four ways: adoption, compliant acceptance, reluctant acceptance or rejection. The more negative the reaction, the more they’ll work round and ultimately defeat the controls embedded in the system that encourage them to use the system the way managers want.

This article discusses the relationship that these users might have with the system.

It looks at how well the industry specifies systems considering the user. It considers that the more the users are regarded as part of the system, the more chance there is of achieving a sound specification and in turn in realising the intended benefit from the system. It closes by looking at what managers, analysts and developers should do to maximise outcomes through better specification and greater user involvement.

This article focuses on systems where users are the primary actor, aided where appropriate by a computer running programs. It covers development lifecycles of all types from Waterfall to Agile.

Today’s Specifications

Economists would argue that there are only two assets in any firm – capital and people. Capital buys assets that are then employed to do things or make things for sale. This degree of reduction removes the unique value of customers and intellectual property, arguing that even these assets can be bought with the capital or developed by the people.

Boiling things down to capital and people is useful because it highlights that for success in any venture within a firm or indeed any organisation, people are unique. It is those people who create wealth for economic entities and effectiveness for not-for-profit organisations.

Computers and software can be bought but user commitment can only be gained through employment and psychological relationships.

There have been some systems that have failed momentously in recent years. Every reader will be able to reflect on at least one problem system. Many such failures remain obscure, blocked by confidentiality agreements or national security constraints. But one very public system failure is the National Health Service NPfIT system, started in 2004 with the aim of computerising medical records across the UK. In 2010 it was abandoned after consuming £12bn. And it failed because the system was rejected by the clinicians who were to use it.

This theme of user significance pervades systems and dictates system success.

If analysts and developers want to solicit the commitment of users in order to avoid negative reaction to the system once implemented, they need first to gain user participation when the system is first muted – at the specification phase.

Participation and positive experience leads to involvement. Involvement leads to commitment and adoption. Users should talk about the system specification and work in the project in order to transition during the project from participation to system adoption.

Thinking on system lifecycles has changed.

Initially it was popular to write a specification and design and develop towards that. User and business needs were difficult to capture fully at the start of a project and iterative elements were accommodated. More recently systems ceased to be specified at low levels of elaboration, leaving detailed specification to the development project itself. Then detailed specification became the subject of fortnightly iterations following user exposure to early prototypes.

Despite this substantial abandonment of the original idea of specification as a singular device created at the start of a project, specification is alive and well and user involvement is still an option.

With that, user rejection is still a risk.

So do analysts and designers involve users? Certainly on NPfIT, it seems not, or at least not sufficiently to secure system adoption. Without study of other projects, it’s difficult to make evidence-based assertions but it’s possible to get some sense of current practice by polling what software engineers are taught in their professional development.

A brief analysis of course content from institutions such as Imperial College London and Carnegie Mellon University show that the user features little. Language is about ‘the system’ and not ‘the user’ as actor in the system.

System: a definition

In their defence, analysts and developers might be inclined to respond that they regard the system as comprising both machine and human actors whose boundary encompasses both materiel and user (and indeed other human stakeholders).

Definitions in common use do not, however, support this view.

A majority view from a web search suggests that a computer system comprises hardware, operating system and software. Indeed the Open University technology management MBA and software engineering Masters electives add only that the system is of interest to someone.

Again the user exists by inference rather than expression.

But to progress the argument, we need to deconstruct both system and user.

Systems comprise policies and processes. Users define or obey these policies and benefit from or direct processes. Psychologists consider that users can be described by competencies, personalities, traits, behaviours, beliefs, attitudes and abilities. Users make use of these human characteristics in their policy and process interactions. Users will apply their beliefs and attitudes in interpreting policy instructions. They will use their abilities and competencies in interpreting the outputs of processes. And their beliefs, attitudes and other characteristics will be modified during that interaction.

Imagine that Monday morning when user first meets system. Negative user modification of beliefs and attitudes is understandable.

So what of the inverse path – from user to system? Systems comprising policies and processes exist to generate outcomes. Users can, to some greater or lesser extent, modify both policies and processes and hence can influence outcomes – perhaps not the answer from any computer-defined algorithm – but certainly its application, interpretation and subsequent use.

So the system modifies the users and their characteristics and users can modify the system and its outcomes.

Modification assumes that users are able to take agency, embracing the role of an engaged actor.

Taking agency depends on human characteristics. Before a user can interact as intended (let alone to modify or be modified), they must have the characteristics needed to use the system. Characteristics foremost initially are abilities (as proxies for intelligence) and competencies.

And so it is that users must be ready for system implementation or upgrade. If users don’t have the necessary characteristics, they’ll arguably not be able to interact.

To use a military mission management system, users must be competent somewhat in managing missions. The computer helps outcomes. Whilst in military mission management, the user needs to be able to click to enable a map display (an interaction), they need to understand the concept of a map as a metaphor for the battlespace. To use a spectrum management system, users must understand the concept of frequencies and have the mental models needed to understand conceptually the inputs required and outputs provided in frequency assignment.

The need for match between human characteristics and system specification is a key element in realising benefit from systems. And it’s a key reason for training users to achieve the competencies needed to start learning system use. Users without the necessary competencies and abilities will not be able to realise benefits from the system.

The role of the specification

Whatever the form of specification, its importance has only increased in recent years.

In supporting change, the specification aids management in preparing the users for the upcoming new functionality. As argued above, congruence is required between system specification and user characteristics. Any gap between the two reduces system effectiveness when implemented. And any gap tells management where to invest further – both in recruitment and in training – to assure benefits after implementation. The specification allows such manpower planning to take place a priori. Waiting until the system is in is way too late.

Computers typically replace human effort. In many cases, management aims to reduce the amount of effort and change the competencies, personalities, traits, behaviours, beliefs, attitudes and abilities of the users (by changing the users and de-skilling the jobs they do). In other cases, users will need to up-skill to comprehend and exploit the new computer power. Mostly such change is in support of cost reduction or increased sales, both in search of higher profits. And reduced competency and ability will conveniently score lower in job evaluation, correspondingly reducing the salary bill.

So the specification is an important element in quantifying, justifying and subsequently managing such improvement in business position.

Without the specification, management are just guessing the future business outcomes.

Observant readers will identify a paradox here. Only management can balance user involvement in search of business outcomes whilst de-skilling jobs and making these very users redundant. Such strategy only intensifies the argument for careful planning and user involvement.

By defining the user and the system at various points in time, the specification provides the junction between the way the organisation is and the way it wants to be in the future. The specification is therefore a key document in organisational development.

And of course, the specification must exist before the system can be designed and made. Even using an Agile methodology, the business or client must define what they want to achieve, even if the developers use an iterative process to achieve that.

And often third-party software suppliers develop the system. Without specification it is then difficult to prove compliance and hence get acceptance and payment for development activities and resulting software.

Specifying Systems

The above discussion assumes that a system specification is one entity with one approach to its realisation. UML and more prescriptive approaches like MODAF, the UK military’s architecture framework, show that specification is a series of views. Like human characteristics, one can describe a system from many different viewpoints. There’s the state transition model, the process model, the data flow model and a host more besides.

Those views can be taken at varying levels of abstraction. At the highest, it’s convenient to be reminded that the system does something in pursuit of goals – a specification for senior managers and shareholders only perhaps.

As the specification is elaborated, so the user becomes ever important for it is the user that is afforded the ability to achieve the outcomes that aggregate to these goals. Without the user, no such affordance exists.

That brings us round to the beginning again to ask who it is that should specify the system.

Industry expects that the analyst specifies on behalf of the user. This is supported by the argument that the user is unable to express what they need in order to secure the business outcomes. This rather arrogant argument assumes that only an analyst has the total command of the user’s activities and the current state of art to predict that affordance.

But the analyst is generally a technologist without the psychology and human behaviour training to understand the human characteristics of the user.

The analyst risks developing from a narrow technology viewpoint, thus risking system rejection.

So it seems that for a rich view, the analyst should provide the state of art, the user should provide the affordance perspective and management should provide the goals.

Specification is a team effort.

Reaching conclusion

This article has argued that a system specification is a political entity. It influences the users’ competencies, behaviours, beliefs, attitudes and abilities. And the users in turn will influence the policies, processes and outcomes of the system. Such influencing is inevitably bi-directional.

The specification also influences management and it's propensity to spend capital to get desired returns.

This article has argued that without user involvement during specification phases and later in the implementation project, there’s no guarantee of a favourable user reaction when training day comes. And hence without user involvement, there's no guarantee of those desired returns.

Users can reject the system and design work-arounds – like the spectrum manager user of the £10m system who insists on calculating the price of spectrum frequencies on a separate Excel spreadsheet. He was not party to the system specification and the resulting system does not calculate price the way he and his international committee of experts decree. Such reaction reduces management’s intended benefits.

Surely therefore it must be in everyone’s interests to work with the users, developing them, involving them and having them understand future technology and the benefits it affords?