» Well formed outcomes

Well formed outcomes are essential for any service provider in defining or gathering requirements with a client. In fact, they are (or should be) the requirements.

An outcome is the answer to the question ‘what do you want to have happen?’. However that is not enough to get the requirements right. A well formed outcome is an outcome which satisfies certain reality tests (see later). Outcomes which aren’t well formed are usually difficult or even impossible to deliver, and are unlikely to be what the client actually needs.

All the discussion of well formed outcomes has to take place in the context of these principles:

Principles

1 Whenever anyone tells you what their problem is, all you know at that moment is that that is not the real problem.

2 If you ask someone what their business needs, they will tell you what they want. There is a huge difference between

○ what the individual wants (Aston Martin)

○ what the individual needs (Ford Focus saloon)

○ what the business needs (Ford Focus estate)

Symptoms and issues

People rarely think with sufficient clarity: this makes it hard for someone gathering requirements to be sure they have nailed what the client business needs. It can be convincing, but is it right? So let’s define terms:

The client has pains, difficulties, troubles: these are symptoms.

The symptoms have one or more causes: these are the issues.

It is important to be able to differentiate these two terms, issue and symptom. The issue comes first in time and gives rise to the symptoms. So, if Jane is annoyed because she has to stay late to complete the business mailings each day, because the printer is slow, the issue is not ‘Jane is annoyed’, nor is it ‘Jane has to stay late’. These are symptoms of the issue that ‘the printer is slow’. They may be issues for Jane, but they’re not issues for the business.

An issue should be capable of being expressed as:

○ X [the issue] is giving me pain because of Y [the symptom].

As a service provider, the issues are usually the things you can directly do something about (eg, install a faster printer) as opposed to things you indirectly influence (eg, Jane’s state of mind).

Outcomes and solutions

Once the symptoms and issues are sorted out, it is possible to ask the client ‘what would you rather have happen?’: these are the outcomes.

The outcomes can be achieved in one or more ways: these are the solutions.

Again, it is also important to differentiate between outcome and solution. If you install a faster printer, Jane is happy because the printing gets done more quickly. In that sentence, ‘installing a faster printer’ is the solution; ‘the printing getting done more quickly’ is the outcome (and Jane being happy is an effect—see later).

All too often one hears ‘we need a database/piece of software/faster comms’ as proposed outcomes. They’re not. They are solutions to an (undefined) issue to satisfy an (undefined) outcome.

In the example, I would say a better expression of the outcome is probably ‘to have the printing finished before the end of the working day’. This could be achieved by deciding not to write so many letters, writing shorter letters, starting the print run earlier, extending the day and paying Jane overtime, and so on. There will always be many solutions.

Choice of solution is partially dependent on resources

Resources may also restrict all the outcomes being implemented. But for each implemented outcome there will be effects.

The complete process

The client needs to be clear about, and be able to differentiate, these six stages:

Symptoms — the ‘pain’ the client has

…Jane has to stay late, the print run extends past the end of the day etc

Issues — the causes of symptoms

…the printer is slow

Outcomes — what the client wants to be the case

…the print run completes before the end of the day

Resources — what does the client have, or can call on, to achieve a solution?

…money, time, space etc

Solutions — what needs to be done to achieve the outcomes

…install a faster printer, or start print run earlier etc

Effects — what will it be like after the solution is implemented?

…Jane is happy.

This is the order in which you’ll probably discuss the stages with client. Chronologically, the sequence is:

Issues Symptoms Resources Solutions Outcomes Effects

(In reality, the symptoms and effects can be glossed over, provided the distinction between symptom and issue is understood, and the distinction between outcome and effect likewise.)

If this looks unnecessarily complicated, it simply reflects the reality when clients present with problems and you have to provide a successful solution. It has one big advantage: by getting the client to think about their issues—indeed the whole business—in a way they never have before, it means they are less likely to fall back on preconceived ideas and more likely to work things out form first principles. This means they will be less attached to their personal needs and more likely to follow you in thinking in terms of what the business needs.

Tips

1 Explain the six stages and the two principles to the client—the more they understand what you’re doing and what you need, the more helpful their input will be.

2 Address and sort out the issues, symptoms and outcomes first.

Having asked a neutral initial question, such as ‘So, how can I help you?’, the client will respond with a torrent of material. Divide your notepaper into the six sections above, and allocate each bit of information form the client to one or other category. (The client will be unable to resist giving you solutions and so on; you just note them for future use.)

When they’ve stopped, say something like ‘Can we see if I’ve got this right?’ and feed back what you’ve written: ‘issues A, B, C,… are giving rise to symptoms F, G, H,… . Instead of this you’d like outcomes U, V,…’ .

You should now probe:

○ ‘what other issues/symptoms/outcomes…?’

○ ‘how is this issue/symptom/outcome important?’

○ ‘what if you had P, Q,… as well/instead?’

○ ‘what is underlying issue A? What is underneath that?’

○ ‘what is under that?’

3 Only when you’re pretty certain you have all the outcomes, and you’re certain they are well formed outcomes (see later) should you start suggesting solutions (the meeting isn’t about your ability to suggest ideas!).

4 When you’ve finished—ideally take at least two meetings for this—say something like ‘Can we see if I’ve got this right?’ and feed back what you’ve written: issues A, B, C,… are giving rise to symptoms F, G, H,… . Instead of this you’d like [well formed] outcomes U, V,… which you’d like to see achieve with solutions P, Q, R,… . You have resources K, L, M,… for this project…’.

At this point you’re into establishing whether they can afford suggested solutions.

5 The probing and repetition are essential to shifting the client on to a realisation of what their business needs. You need to make the repetition as acceptable as possible. The client will benefit from lengthy time to think it all over, so exploit the time between two meetings: better still, have three half hour meetings separated by several days, than one ninety minute once and for all.

Well formed outcomes

A well formed outcome satisfies the following criteria:

Positive — it is expressed in positive language

eg, I want my staff to leave on time; not I don’t want my staff complaining because they have to stay late

Size — it is suitably sized: not too big to be unachievable (or unaffordable), not too small to be pointless

Control — it is within the client’s control: it doesn’t rely on the agreement of a third party (the classic example is the mother whose outcome is for her daughter to tidy her room—that is not a well formed outcome!); the client can afford it; any contributions needed from third parties are available; and so on

Resource — the client can identify, and have access to, the resources needed to achieve the outcome

Reality — the client can state how they will know the outcome has been achieved and will be able to measure it

Context — the client can identify, and be able to counter, any undesirable consequences (eg, effects on other areas and systems in the business; effects on suppliers, clients and others).

Depending on the time available, it is worth pursuing further analysis with the client. For example:

‘Given you determined well formed outcome X, how do you know this is the best outcome?’

‘How would you establish it was the best outcome?’—What does best mean in the context of the client’s business?

At a deeper level, it is worth asking:

‘What is the purpose of this system development?’

‘How does it fit into the business’s overall purpose?’

These questions will give you a valuable context for the conversation (providing you ask them first!)