Executive in wait

Running a Requirements Workshop August 31, 2005

• In collaborative workshops, participants share a common goal, and they agree to join together to create work products in the pursuit of that shared goal.
• Workshop participants, some-times called a task group, are pro-ductive
  because collectively they have the right mix of skills and knowledge
  to create the work products.
• Members of the task group act interdependently, relying on one other’s knowledge, experience, skills, and perspectives. They are cohesive, meaning that they are motivated to act together. With appropriate direction, such a group can be highly productive.
• JAD (joint application design),workshops are structured events in which a carefully selected group of stakeholders and content experts works together to create, correct, and document a predefined deliverable, or work product.
• The group agrees ahead of time on the deliverables, and the participants often produce someof them before the workshop; this sort of timeboxing enables the group to focus on what’s really important.
• The most successful workshops are composed of a healthy mix of business experts (or product development peoplerepresenting those experts) and IT people, led by a neutral facilitator and a scribe who documents the group’swork as it proceeds.
• The facilitator is responsible for managing the group’s activities, dynamics, and work products. The scribe documents the group’s work as it proceeds. Neither facilitator nor scribe operates as a content expert.
  As a result, they are free to focus on the process.
• A workshop is authorized by a sponsor, who ensures that the right participants are present.
• Advantages:
• Commit users to the requirements definition process
• Promote ownership for the deliverables and, ultimately, the system
• Shorten the requirements phase
• Eliminate nonessential requirements
• Form or reinforce effective communication patterns
• Build trust among project participants

Mind Your Six Ps

• Purpose:The statement of the workshop’s purpose outlines the reason and
  justification for the workshop.
• Participants:The people involved in a facilitated workshop are the workshop sponsor, the participants, a facilitator, a scribe, observers, and on-call subject matter experts. Not all of these roles are necessarily
  present during a given workshop. For example, the workshop sponsor may be present only at the beginning and end of the session.
• Principles: Codes of conduct that participants agree to follow. The facilitator works with the workshop sponsor and group to establish principles, which must be clear and acceptable to all participants.The facilitator and participants are responsible for monitoring the adherence to the principles.E.g: Guidelines for participation, Ground rules, Group norms
• Products : For your deliverables, you can choose from a number of representations—text, use cases, data models, business rules, events, scenarios, prototypes, scenarios, and dynamic models instead of or in addition to ue cases.
• Place: The location of a workshop can influence the outcome.
• Process : Plan the workshop’s activities so they follow a logical flow in which the outputsfrom one activity are used by the next activity in the session. E.g: Steps. Activities, Order, Concurrency etc.

Planning a workshop

• Prepare a workshop checklist. Typical checklist may have:
• ~General information (title, place and time)
• · Purpose : Partial requirements or Final etc
• · Participants
• · Scope : “order entry for 24 hour delivery”
• · Subjects : · Getting the order
  · Finding the customer
  · Checking for stock
  · Placing the order
  · Tracking the delivery
• · Controversy : Disagreements between participants
• · Strategy : To handle things disagreements
• · Result : End result can be written down as a story
• · Actions
• Indentify stakeholders. Use PM. He will need them for business case.
• Communicate with them and set expectations on purpose, scope, subjects depth, results, context , big pucture etc and get a feeling on their response.Let me know if you need them todo any home work like future market etc.
• Keep PM in loop
• Organise a venue, time and communicate. Plan for atleast half day session
• Prepare room with white sheets, markers etc

Conducting a workshop

• Open workshop: Give an introduction on purpose,scope,subjects, results and big picture.
• Conduct workshop: Ask questions however silly they are, even though you know the answers.
• Get someone to scribe.Every statement should have a label who said it.
• If some one tells you what, just repeat what he said, but using different words
• Try to establish some priorities on the requirements. A mechanism often used is to classify requirements as ‘must-have’, ‘nice-to-have’ and ‘oh-well-this-is-just-a-suggestion’.

Post workshop

• Send your checklist and meeting minutes and ask it to be approved or otherwise by certain date

Dealing with difficult People

• Having a chat with the stakeholders before hand gives you a feeling as to how stakeholders will behave.
• May be you can invite another stakeholder who can neutralise.
• 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.
• People come to defend their ground, to conquer new ones, to enhance power, to reduce influences from others, or just basically to kill time
• 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 people don’t want to be concerned with the project in the first place, they can frustrate the process of conducting the workshop
• You will not get them. Today.You can handle them later on. You need to be prudent enough to decide when you have to move on. You cannot tolerate them having an impact on the flow of the workshop.
• 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.
• If you cant do anything just document it in Controversy and carry on.

Sample workshop

Stage 1

• First 3~4 , 2 days each workshops concentrated on feature catalogue.
• E.g: Recommendations, Search, Personal Details, Calendar, Find nearest etc etc
• Agreed product was a ‘Feature Catalogue’ with:
• Proposed features with summary title, description and unique feature number for each (done in first pass in a couple of meeting)
• Business prioritisation and scoping of the list. (Done in second pass)
• Scoping for each feature. E.g: Basic search using post codes in phase one, reordering by recommendations for next phase etc.
• Ground rules were agreed. Client had complete say on scope of the project. We had a say on scoping between phases.
• This doc was ultimately linked to SRS to see that all features were covered with a table listing feature and requirements.
• By end of Phase 1 we had:
• Feature list prioritised and scoped appriopriately
• Issues with the features
• Uncut version of Glossary

Stage 2

• Before the workshop, the team had decided that use cases would be a good way to represent user requirements.
• We could alternatively use user stories if creating usecases is too time consuming.
• As a part of homework we work on subjects within each feature that we had to talk on. E.g: How does the user come to the search pages, How does he input criteria for search etc etc.
• We also worked on and documented a list of potential use case names and a set of scenarios and a glossary of terms for SRS.
• Stakeholder communication, planning for the meeting followed.
• We took each feature and started asking questions on the subjects.
• At the workshop, participants created detailed use cases and wrote business rules.E.g: Basic search for unregistered users. Advanced for registered users etc.
• As they specified the use case steps, our scribe recorded them using a laptop using Rose.
• They were also posted on the wall in sequence, left to right, on big blue adhesive notes.
• Beneath each use case was a list of business rules.
• The team then used the scenarios to walk through each use case along with its associated business rules and the prototype screens
• We first worked through the “normal” flow of a use case.
• As we tested the use case with the data provided from each scenario, I would ask a question such as, “How do you decide which…?” or “How does the system select…?” or “What does the system have to know to…?” and so on.
• After working through three or four normal scenarios, we attacked the exceptions: those scenarios that would occur less often or those that would cause errors.
• As we walked through an exception scenario, sometimes the participants realized that they needed to add another exception.
• Our scribe, working on his laptop, projected our Use Case Completion form on the wall.
• At this point, I polled the group for input.
• Using a predetermined decision rule, the sponsor made the final decision. As specifics were discussed,the scribe captured notes and the final decision on the form.
• Non functional requirements

Stage 3

• Signoff from client for requirements and prioritisation
• HTML Prototype
• PM did contracts for engagement

More:

Requirements Workshop Work Breakdown Structure:http://www.ebgconsulting.com/Book%20Assets/Requirements%20Workshop%20Work%20Breakdown%20Structure.pdf

Planning a Requirements Workshop: http://www.awprofessional.com/articles/article.asp?p=27632&seqNum=1