You have all your requirements in front of you on a piece of paper. You smell the paper. You feel the paper. You sense the emotions that are attached to the requirements. You close your eyes, and you have these images, these colorful blurs, you are in touch with the minds of the stakeholders. You are the stakeholder profiler. You have to get the stakes out of the requirements.

Group all the requirements together per stakeholder. Try to formulate the stakes that are behind them. It's difficult, it's rather vague, it's very "soft", but it's the information you are after. Remember, the requirements will likely change during the course of the project, but stakes remain the same.

The requirements itself will be represented in the way you defined in the preparation of the workshop. All the participants will have their own version, and are confronted with the stuff they wished for; every requirement has a name attached to it who said it.

For project management and perhaps some key stakeholders, it may be wise to have some representation of the stakes. Such a presentation may help to refine the definition of the stakes. Taken from a professional FBI profiler, you could use some great slides with, for every stakeholder, a photo and the crimes (stakes) he or she committed.

 

Related articles

Use case modeling for software requirements

Part Two

Two important pieces of advise come from D'Herbemont and Cesar (Managing Sensitive Projects). First: focus on your allies. If you have to get some points across, and people are against it, the natural reaction is to win them over by paying a lot of energy to them. Instead, you should support the people who agree on the matter in convincing the disbelievers.

In this way you have more people to spread the word and mostly from the same environment as the 'don't wanna's'. And we all have the tendency to accept something faster from someone out of the same environment, then from a total stranger.

The second tip is to create lateral projects. Try to formulate the project or end result in such a way that it appeals to a specific group of people. Perhaps you have to focus differently or to include some stuff to make it interesting. It's a good and funny mechanism to work with.

Getting the right information

How can you get the right information out of the people that are in front of you (remember, you are hosting a workshop)? I thought about this complex question for a long time. I came up with one answer: ask.

If you know from yourself that you are no talker, introvert and have problems with your communication skills, this workshop leader thing is nothing for you. If you have them, be yourself and just ask.

Here are some strategies that work for me.

• Be stupid. Don't be a smart ass. Even if you already know all of it, let the participants be the stars. They are the experts.


• Ask what you know. Start for example with asking something you already know. Tell something you know is not correct. Try to get the attention and see who corrects what. Most of the time it gives you some glimpse of stakes.


• Repeat. If some one tells you what, just repeat what he said, but using different words. In this way, you can get similarity in words used.


• Ask 5 times. Ask five times why. That will give you the highest level of reason. Ask 5 times how, and it will bring you to the lowest level of operation.

While the workshop leader is going through the process from left to right and top to bottom, the scribe should record all the statements made. Every statement should have a label who said it. In distribution of the statements, and, later on, the requirements, the name should always appear. This will keep people committed to what they said. If they just yell something, and their name is attached to it, the will be more careful what to say.

At the end of each day, for example, at least at the end of the workshop, the statements should be reviewed by the participants and be approved. Group statements together by subject, try to rephrase them with the participants so that they use the same 'language' and try to avoid, or at least clarify, conflicting statements. The last action is to mark statements as requirement, and try to establish some priorities in them. A mechanism often used is to classify requirements as 'must-have', 'nice-to-have' and 'oh-well-this-is-just-a-suggestion'.

I stated in the beginning of this section, the purpose of the workshop is to establish requirements on the end result of the project (the product, which may also include organizational issues and procedures). However, some times statements are made on the way the project will be conducted (the process). Create a separate list for these statements, and provide them to project management for consideration. But make sure you tell the workshop participants that these process-statements are treated differently.

You are standing in front of a room. You are not alone. There are more people in the room. Some you know, some you don't. They all stare at you. You have an idea what they are thinking. Or at least you think you do as you prepared this workshop as described. These people come here to defend their ground, to conquer new ones, to enhance power, to reduce influences from others, or just basically to kill time.

Thinking back about the Flow of stakes, you remember what you are supposed to do. You have to fulfil everyone's wishes today. The people in the room have their issues, their stakes, and they will project it on the topic of the day.

If you are trying to defend your department's independence, you will not be happy with an information system that integrates all processes and makes your employees, or at least the things they do, obsolete. You want to have separate systems for all processes, and your empire in between. You will probably use a different argument. Terms like 'easier to maintain', 'better to control', and 'more transparent' will more likely be used.

Formulate requirements

So there you are, sweating in front of the room. You have to formulate, together with the members of the workshop, the requirements for the end result of the project. It's a software project; a system will be a large part of this end result. This set of requirements should address all the stakes of the stakeholders, and, in the same time, not be conflicting to each other. If one requirement says the button should be blue, and another it should be green, you will have requirements that you know will be impossible to fulfill.

This sounds difficult. It actually is. But, with enough time and patience, you can get a long way. But time is normally not on your side, and you should actually try to get a reasonable set at the end of the workshop. Compromises, concessions and a little force enter the mix of actions of the project manager. Everybody should be a winner, and today!

Can you satisfy all the needs of every one? Can you take care of all their stakes? Can you make every one happy on this day? Probably not everyone. If people don't want to be concerned with the project in the first place, they can frustrate the process of conducting the workshop. If they are out to sabotage and are not into the win-win mood, you will not get them. Today. You can handle them later on. You cannot tolerate them having an impact on the flow of the workshop. They should not have been invited anyway. Sometimes, sadly, you have to. But you can block it by having some colleague sitting in that also feels differently about the subject. Or a senior manager, who shuts him or her up.

Part Two

Controversies

"How a new information system will have to support our order entry activities for 24 hour deliveries. The new order entry activities as described in Large Document X and approved by Big Guy Y have to be considered." A purpose like that for your workshop, and you know you will have some trouble. Probably someone in the workshop is no fan of Big Guy Y. Thinks he doesn't know a thing about order taking. However, the Large Document X is approved and is the basis for the workshop. T, R, O, U, B, L, E.

Perhaps one of the workshops subjects is reorganized for the 100th time. Maybe "ISO Certification" is the "soup du jour" (hype of the day) at the company, so everyone just wants to write large documents. Possibly the same workshop has taken place last year, and no one heard a thing about that one… Controversies on the subjects of the workshops. Find them. You really need help with this one. Again talk to people and listen to them.

Strategy

Given the controversies and the list of subjects you put on the form in the previous steps, you should determine how to handle things, how to approach the subjects strategically. I know, I said the goal is to make everyone a winner. Take care of all stakes. But probably not every one in the workshop is feeling lucky due to the controversies. If people don't want to be concerned with the project in the first place, they can frustrate the process of conducting the workshop. If they are out to sabotage and are not into the win-win mood, you will not get them. Not during the workshop. You can handle them later on. Be pragmatic, you also need an end result, so don't let them block your workshop.

For the Big Guy Y hater, bring it as a given. This is it, you can't do a thing about it, so stop whining. Be passive, confronting, whatever flavor you have up your sleeve (smell that shirt!).

For this ISO thing, you might try making the issue bigger, bolder, more abstract. Like, if someone yaps about "documenting every thing", make it in little steps bigger: "Yeah, you are right. You should document it, and have a great structure to support that. You want every thing stored in one place. So you can access it from everywhere. But of course, to be effective, you should also register this, and that. So you can cross reference it with…." If you can avoid the sarcasm and sound sincere, they will bring up that they're not ready for it. I love this one.

The purpose of this step in the preparation of the workshop is that you think up front the strategies you might have to use. In this way, you can prepare some information or invite some one to the workshop to neutralize the controversy.

Result

What will be there when the workshop is over? The requirements of the end result can be written down as a story, as a formal specification in some cryptic scientific notation, or some cool graphics. There is so much research done on this subject. How to check the set of inconsistencies? How to create a graph from Here To Eternity?

Just use the medium the key stakeholders are used to. If they like to tell stories, tell a story. If they are mathematicians, use formal calculus. If they are computer scientists, use bloody graphs. I like to tell stories myself.

Specify how the result will look like. How you can read it. Close your eyes, and see it!

And finally, the rest

To close your preparation, you can specify the participants of the workshop. Who are they, what is their position within the organisation, and, most important, why are they invited for the workshop; what role do they play in the discussions; leader, chairman, scribe…

If you want to use tools, you should write them down, and arrange that they are there.

This one deserves some emphasis: On which way will the results be communicated back to the participants, and what are the next steps for these results?

And only at this stage, you are able to create an agenda for the workshop. Only here, at the end of the preparation you have enough information to create a good agenda.

Enough swimming on the side of the lake, let's jump in.

Part One

In the preparation of the workshop you can follow this checklist of aspects to consider:

• General information (title, place and time)


• Purpose


• Scope


• Subjects


• Controversy


• Strategy


• Result


• Participants


• Roles


• Tools


• Feedback/follow-up


• Agenda

In the remainder of this section the aspects will be treated in more detail. With these points you cover the basics for a successful workshop.

General information

Starting off with some general information, your workshop's got to have a title, a name to call the beast by. Make it short, clear and not a novel… "workshop on order entry" is a good one. Pick a date and place.

Concerning "time", I just want to mention that the unit of duration for a workshop should be a part of the day (two parts make one day, so morning and afternoon). Don't drag people out for one hour. That's not a workshop, that's a discussion.

Purpose

What is the workshop all about? Purpose, scope and subjects, that's what defines the actual workshop. The purpose is important to inform the workshop participants correctly up front, so that they have no wrong expectations, or at least make the chance on that a little smaller. By the way: you don't have to yank all info into one sentence. It's ok to make a paragraph out of it. "Partial requirements in the preliminary decision making phase" is a sentence, but it tells nothing. If the requirements coming out of the workshop are not final, but will be reviewed and approved by some hot shots afterwards, write it like that! It won't give you the Nobel prize for literature, but it sure will save your workshop.

Scope

The purpose will place the workshop within the context of the project, the scope tells us all about the actual content, e.g. "order entry for 24 hour delivery". The scope should determine the field that will be covered, including a good definition of it's borders. "How a new information system will have to support our order entry activities for 24 hour deliveries. Current activities may be subject to change." The second ("..may be subject to…") sentence is very important. If things may be altered, make them explicit, try to avoid that people have to read between the lines, or have to be sensitive to the words chosen. The opposite holds also, of course. If it's not allowed, state it. "How a new information system will have to support our order entry activities for 24 hour deliveries. The new order entry activities as described in Large Document X and approved by Big Guy Y have to be considered."

Subjects

To create a good list of subjects to cover, some homework has to be done. A good preparation would be joining stakeholders in their work for a short time, mentioned earlier in this section. In addition to this, you should talk with someone with knowledge about the scope. A good starting point, if possible, is to take the tasks that fall into the scope. Like, for order entry…

• Getting the order


• Finding the customer


• Checking for stock


• Placing the order


• Tracking the delivery

Another way is to make a distinction in categories of the subject at hand. If you order an ad in a newspaper, you have the little public announcements and the larger display ads. You can discuss about large customers and small customers. Blue balls and yellow balls. Take your pick.

So, there are a thousand ways to organize your subjects. They should be clear, logical, "feel good" and make immediate sense to the participants.

Preparing A Workshop - Educating

The end result of the requirements determination activities should of course be a set of requirements. The representation of this set will be treated later on in this chapter. A point to address at this moment is the depth of it all. How far should one go into detail? There is, as you might have expected, no concrete answer. The criteria one should handle at all time is that a requirement is unambiguous, that all stakeholders have the identical view on what the requirement means. You must use your own judgment on this one. To be able to judge, you must know the tasks that will be changed as part of the project.

And that's where it all starts. Educating the project manager. The project manager should follow the stakeholders for a while in their daily tasks. This is the only way to get a feeling for the subjects. How urgent everything might be, take the time to do this. It will pay off in the end. It helps building a sense for the processes, for the business case, for the entire organizational context. It is important to go at the issues from these angles, the wider and broader perspective.

Most users, and other stakeholders, tend to formulate their requirements based upon their current situation. They see where they are now, and can talk about the two or three steps they want to make from their current point. This is a handicap, because it limits the possibilities. Seen from a market, business and process perspective, more opportunities could be taken. Instead of talking about "extra data fields in our customer entry screen" one should address the things one wants to do with a customer, and reason from this back to what information is needed to do it.

It sounds obvious. It is. For an information analyst this might be peanuts. But for most people it tends to be very difficult. During the actual requirements determination you need the stakeholders to be completely holistic ("Ahum, let your mind flow freely in the space that surrounds you."). So, you have to educate the stakeholders before starting the phase. Let them visit a seminar on the future of the market, let them brainstorm about how their job is an integral part of the company's process, whatever. Let them view their tasks as part of the whole.

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