Pattern 1: Establish the business objectives ***
AKA:

You are about to create a new web site or modify an existing one. The organization has a strategy, but there are possibly several stakeholders with conflicting requirements. If you do not know what they are or how to resolve these conflicts, you will almost certainly produce a site that is unfit for use. However...

Many people think that writing down a few use cases for the site is coextensive with understanding the requirements. Jackson (1998) has amply demonstrated that this is not so and that specification and requirements are quite different things. Furthermore, business objectives are not the same as requirements. For example, the statements ‘we must double our DVD sales’ and ‘the site must make the DVDs more prominent than books’ are quite different, though related of course.

When you decide to use TIMEBOXES (4) to control iterative development you can only negotiate sensibly on evolving requirements if you have consensus on the things that will not change during the project.

Therefore

Hold a workshop involving as many stakeholders as possible. Make sure that potential users are represented by marketing personnel or the results of focus groups, surveys, etc. Find a good facilitator. Agree a mission statement. Find measures for each objective. Agree a numerical rank ordering of the priorities.

Each mission statement is now linked to several measurable and prioritized business objectives. We can now begin to construct a BUSINESS PROCESS MODEL (2) within the workshop and manage the project beyond it using TIMEBOXES (4).

This pattern is one of several in this language whose applicability is far wider than web design and could – no should – be adopted usefully on non-web projects. We include it because it is as fundamental to the success of web projects as to others and because it is, in our experience, one of the patterns most often ignored by web developers– to the ultimate detriment of their projects. It is a process pattern.

Business objectives allow teams to validate their use case and business process models. How should they be discovered?
Historically, system requirements were captured from users during a series of interviews. Systems analysts would interview individual users or, sometimes, small groups of users, on an aspect of the required system. The results of these interviews would be collected into a systems analysis report, which would then be circulated for comments. Based on the comments received, a revision would be issued for further comments, and so on. Such reports were usually very large and often quite unreadable. It is difficult to believe that anyone ever both read and understood them all. One suspects that they were often signed in default of a full understanding, rather than provoke a fruitless confrontation. Other significant defects of this approach include the following.

• Often different stakeholders and groups will present contradictory opinions, which lead to contradictory requirements specifications. These may be uncovered later during use case modelling but are usually not noticed until the site has gone live.
• The approach is inclined to inculcate an ‘us and them’ attitude in the business and the developers. The business people ask for features and state requirements. The developers go away and produce something. What is produced rarely matches the – perhaps unarticulated – requirements exactly. Squabbling and finger-pointing follow inexorably.

A facilitated joint requirements workshop can be run to address these problems directly. Such a workshop will:

• ensure that all participants hear the contributions of others at first hand, which eases the problem of arriving at compromises where these are necessary;
• help developers gain a first-hand appreciation of the real goals of the business, as opposed to a mediated set of requirement statements;
• develop a shared ownership of the project between and among developers and the business;
• reduce the elapsed time needed to establish the requirements;
• establish the tempo of a rapid development process.

A workshop will focus on a particular process-oriented business area and its mission. Agree and write the mission statement for the site on a flip chart page and place where everyone can see it – and possibly amend it as discussion proceeds. Next, the facilitator asks participants call out and discuss the specific objectives of this site. These are written on a flip chart. Experience has taught that there are usually about 13 objectives, either due to the fact that people run out of ideas after that much discussion, that 13 objectives comfortably fills two flip chart pages or, as a more remote possibility, reflecting some obscure law of nature yet to be articulated by rational Man. No activity should be allowed to produce a deliverable without it being tested. This principle is applied to the objectives by seeking a measure for each objective. For example, if our business is running an hotel and an objective is to provide a high quality service then the measure might be a star rating system as provided by many tourist boards or motoring organizations. Of course, there are cases where a precise measure is elusive. Discussing the measures is an important tool for clarifying, elucidating and completing the objectives shared and understood by the group. The discussion of measures helps a group think more clearly about the objectives and often leads to the discovery of additional ones or the modification of those already captured. Setting aside plenty of time for the discussion of the measures is seldom a waste of time.
The minimum requirement is that it must be possible to prioritize all the objectives. A formal preference grid can be elicited by asking that each pair of objectives be ranked against each other. In workshops, this is too time consuming and a quicker, more subjective technique is needed. One way to come quickly to the priorities is to allow participants to place votes against each objective. We usually permit each person a number of votes corresponding to about 66% of the number of objectives; e.g. 9 votes for 13 objectives. A good way to perform the voting is to give each eligible participant a number of small, sticky, coloured paper disks, of the sort that are sold in strips by most stationers. Then the rules of voting are explained: ‘You may place all your stickers on one objective or distribute them across several, evenly or unevenly according to the importance you place on the objectives. You need not use all your votes; but you are not allowed to give – or sell – unused votes to other participants.’ Then everyone must come up to the flip charts all at once. No hanging back to see what others do is permitted. This helps inject a dynamic atmosphere into the proceedings and stops people waiting to see what the boss does before voting.

Two rounds of voting should be done, under different interpretations, and the results added to reach a final priority score for each objective. Of course, two colours are then needed for the sticky disks. An example of two possible interpretations that can be combined is:

1. Vote from your point of view as an individual.
2. Vote from a corporate viewpoint.

Another pair might be:

1. Vote from the supplier’s viewpoint.
2. Vote from the customer’s viewpoint.

The results often generate further useful discussion. Also one should allow for re-prioritization at this point, if surprising results have emerged. This is often due to overlap between objectives that is highlighted by the priorities given.

An objective that cannot be measured and/or prioritized must be rejected or, at least, consigned to a slightly modified mission statement. The priorities are a key tool for project management since they determine what must be implemented first from the point of view of the business sponsor. Technical dependencies must also be allowed for, of course. Often a discussion around these issues elicits new objectives, clarifies existing ones or leads to their recombination or even placement in the overall mission statement. Issues that cannot be resolved are recorded with the names of the people responsible for resolving them. Specific assumptions and exclusions should also be recorded.

Priorities will be used to resolve conflicts later. They should be numerical. The DSDM (Stapleton, 1997) MoSCoW ratings system will not usually work for this – every stakeholder insists that his pet objective is a Must Have.

Known uses
Detailed guidelines for organizing and running workshops can be found in Graham (2001). The technique has been used successfully on hundreds of projects around the world over ten years or so. About ten of these were web design projects.

Browse the language	What is Wu?	Look at an example pattern sequence	Structure of the patterns
Comment on Wu	Contributors	Return to TriReme home page	Links to related sites