Stakeholders In The Mist

I have this friend who has a friend, who had a discussion with his girlfriend the other day. She accused him of not being romantic enough and that he never organized something nice for the both of them. So he replied a spineless "OK" and took her to this VERY expensive restaurant, with smooth music, wine and sophistication. She refused to go in, "cause it was too expensive and they could not afford it". He was like going "WHAT?!!"

Stop and think for a moment all the times that you thought you understood what someone was saying, and you later found out you were utterly wrong. Wilson, the neighbor of Tim Allen in Home Improvement would say: "The limitation concerns human bias in the selection and use of data. These biases arise because humans use less than optimal heuristics when retrieving and processing information." Basically, we are too narrow minded and not open enough.

At this point in a project we have to determine what the requirements are for the end result. We have to get it out of the heads of the stakeholders and on a piece of paper. For this, a lot of communication is needed between very different people. As a kid I played this little game at school we called 'telephone line'. Twenty kids were hurdled up into a circle. One started by whispering a sentence in the ear of his neighbor, so the other kids couldn't hear what was said. The neighbor would say the same sentence to his neighbor, and so on, until the sentence was 'round circle'. The fun of the game was comparing what the last one had heard with what was originally said. Mostly, they didn't even come close. Kids and stakeholders are almost the same. The sentence of the first stakeholders is often different from the software the last user will see.

The most widely used and efficient way of getting the requirements is by asking. By talking to key stakeholders, like future users of the system, the needed information will emerge. It might seem obvious that this should be as accurate as possible, however it is crucial to do it correctly at this stage. Although information systems are expensive to develop, changes made once a system has been completed are 50 to 100 times more expensive than making the same changes during the requirements determination activities.

And that's a hell of a job. We already mentioned the difficulties in understanding each other. But there is another catch also, you have to anticipate the ways the tasks will change when they are running under the new system. Watts Humphrey would even go this far in stating that…

…requirements by their very nature cannot be firm because we cannot anticipate the ways the tasks will change when they are automated. … Unless the job has previously been done and only modest changes are needed, it is best to assume that the requirements are wrong. (Managing the Software Process)

In this section the determination will be done by means of a workshop with the key stakeholders. A workshop is a kind of a discussion between key holders, with a conductor who manages the process. It is dynamic. It should be fun. White boards are used. Big screens and flashy presentations. People should walk around. And, of course, this show should produce a real end product; a set of requirements.

It can be one workshop or multiple, depending of the scope of the project. This chapter will handle preparing and conducting a workshop, and what to do with its results.

One thing should be stated at this point: the workshop mentioned in this chapter aims to handle requirements made to the end result of the project (the product). Requirements made to the way the project is conducted (the process) can be handled by the same concept as described in the section.

The activities in this section are not necessarily pure project management tasks. Of course the planning part is, but conducting the workshops isn't. However, because of its importance and the impact of requirements on the complete process of the project (remember, they're still a reflection of the stakes of the stakeholders), the software project manager should at least be aware of it's pitfalls. If the project is large (read "small") enough, it is recommended that the project manager also conducts the workshop, or is present in its discussions.

Related links

Specifications and Productivity and Defect Rate