This document discusses shifting the paradigm of requirements gathering from traditional meetings to using serious games. It outlines some common problems with traditional requirements gathering meetings, then introduces the concept of serious games which can provide a more structured, participatory approach. Examples of specific serious games that could be used for requirements gathering are listed. The document concludes by providing contact information for the presenter and references for learning more about using serious games.
2. Housekeeping
• Please turn off all electronic devices or set them to
vibrate.
• If you must take a phone call, please do so in the hall
so as not to disturb others.
• Follow SharePoint Saturday Indianapolis on Twitter
@spsindy and hashtag #spsindy
• Join us for SharePint @Rathskeller after the closing
28. Sample List of Games
• 20/20 Vision • Speed Boat – Sail Boat
• Buy a Feature • Spider Web
• Give Them a Hot Tub • Start Your Day
• Me and My Shadow • The Apprentice
• Product Box • Low Tech Social
• Prune the Product Tree Network
• Requirements Rainbow • Remember the Future
• Cover Story • Show and Tell
A Paradigm is a set of assumptions, concepts, values, and practices that constitutes a way of viewing reality for the community that shares them, especially in an intellectual discipline. – simply put a pattern of behavior
How are most requirements gathered?In meetings right? Let’s look at how productive the average meetings isApproximately 11 million meetings occur in the US every day.Most professionals attend 61.8 meetings a monthOf which 50% of them are unproductiveSo if each meeting is approx. 1 hour long, then a professional loses on average 31 hours per month due to ineffective meetings.Approximately 11 million meetings occur in the US every dayMost professionals attend 61.8 meetings a monthOf which 50% of them are unproductiveIf each meeting is approx. 1 hour long then professionals loose on average 31 hours per month to ineffective meetings
Mistaking a high-level vision statement for requirements“We want better collaboration” “We want to share better” “We want to find information faster”Why is this requirement problematic?This type of high-level and abstract narrative can be a useful motivational tool because the lack of detail invites us to form our own ideas as to how this vision might be realized. But although we might all intuitively agree with the vision at first, we soon need more detail. If you can’t answer the questions “What are we trying to achieve?” and “How will we know when we’ve done it?” then you’re not ready to start.Many organizations struggle to define a clear business case or to measure the success of SharePoint initiatives.Result:Solution doesn’t meet the need (s) of the stakeholder and is thus viewed as a failureDesired business outcomes are not capturedAnd the list goes on and on……..
Stakeholder(s) don’t have time to be engaged on the project so they send a representative in their placeThis doesn’t really workWhy? – ever play telephone?Result:Solution doesn’t meet the need (s) of the stakeholder and is thus viewed as a failureDesired business outcomes are not capturedAnd the list goes on and on……..
Silver Bullet - Do you have a Solution Looking for a Problem to solve?Pursuing a solution looking for a problem is obviously monetarily costly but, even more dire, can cost thousands of hours of scarce time. Going too deeply down a technical rabbit hole can literally waste years of IT hours that could have been more wisely invested. Furthermore, technical solutions looking for problems make IT appear out of touch. Just as I’m subjected to rolling eyes from my spouse when some component of our AV system demands firmware, your CEO is likely to deliver something far worse than an askance glance when you deliver the invoice for a disused or irrelevant technological adventure.Luckily, the answer to technical solutions looking for a problem is fairly simple: continually ask yourself what problem the technology is solving, and if the cure is better than the disease. Any time you change the scope of the technology, or deviate from your original plan, ask yourself these two questions to ensure you don’t gradually stray too far away from the original problem. When you have any doubts, review your progress with the community that will actually be using the technology. While any new system will have a learning curve, if it’s looking untenable at any point, reconsider the technology at hand. It’s nearly always better to pull the plug on an immature or unusable technology than throw good money after badThere’s no such thing as a SharePoint project — there are only organizational change projects; and executives are in a unique position to be able to drive change in an organization. Visibly active and participatory executive support gives credibility to a program or initiative. Without such support, SharePoint-based initiatives can fail either because the proposed projects don’t gain approval and funding, or projects deliver solutions that are then not adopted and used by the business.
Let me show you what SharePoint can do and we can use the demo to define your requirements.This doesn’t really workWhy? – you are focused on technology features instead of gaining insight into the business challenge that needs to be solved – furthermore SharePoint is not the solution for every issueResult – Poor requirements analysis – understanding is based on features instead of organizational goals and potential cultural barriers/benefits
Requirements gathering meetings using only questionnairesThis doesn’t really work?Why? –Most stakeholders will only give you a very small % of what their requirements are on paper. It takes human interaction and a skilled facilitator to draw out and refine the “unknown requirements” Stakeholders may respond superficially because the questionnaire takes too much time to fill out, Stakeholders may not respond at all, Result – requirements that are not captured/discovered because they were not articulated in the responses. This results in the constant evolution of requirements. Potentially information can be collected from a large portion of a group. This potential is not often realised, as returns from questionnaires are usually low
STOP - Instead seek to understand and solve business problems
Paradigms are the maps you have in your mind – but you need an accurate map in order to get to where you want to goMental image - of the way things areComes from our backgrounds and own experiences - we see the world the way we are (my perceptions and point of reference - we project this on the outside) It is a map - like a map of this facility He asks someone - if you came here with no knowledge (it was a map of Columbus but on the top it said a map of Indy) what would you do? You call your friend and ( I have never been so lost (double you speed) I'm lost twice as fast - he says think positively - he says rise to the occasion - now you don't even care you are lost - The Map you have in your mind - but you need an accurate map - Paradigms are the assumptions of the way things arehttp://www.youtube.com/watch?v=XwvTZ_m4rxo Thomas kuhn - The Structure of Scientific Revolutionshttp://www.youtube.com/watch?v=3cp6pEzx3uw Destruction of old paradigm/theoryAdditon of new observations
“A clear, compelling vision for SharePoint is a must if want to have the best chances of success. However simply asking a bunch of stakeholders the question “So what is the vision for SharePoint?” is probably not going to get you the results that you are hoping for. An effective way to get users to describe their vision for SharePoint is the Cover Story game.”In the next set of slides I will explain how this game is setup What if – you approached each problem as if it "involves redesigning the organization on the assumption that it was destroyed last night... The most effective way of creating the future is by closing or reducing the gap between the current state and the idealized design". – Russell Ackoff
Cover: Tells the story of their big successHeadline: The substance of the cover storySidebars: Interesting facts about the storyQuotes: Quotes from potential end users of the solutionBrainstorm: documenting initial ideas (this is important!)Images: Supporting the content with illustrationsCover Story is a game about pure imagination. The purpose is to think expansively around an ideal future state for the organization; it’s an exercise in visioning. The object of the game is to suspend all disbelief and envision a future state that is so stellar that it landed your organization on the cover of a well-known magazine. The players must pretend as though this future has already taken place and has been reported by the mainstream media. This game is worth playing because it not only encourages people to “think big,” but also actually plants the seeds for a future that perhaps wasn’t possible before the game was playedThe reason that this works particularly well for SharePoint is that there are a number of possible visions that an organization may have for the platform. The Cover Story game gives you enough structure to ensure that you get tangible examples without constraining users from being able to really explore the many possible end states.At the end of the time period, usually an hour, get the groups to present their cover story, essentially their vision of SharePoint, to the rest of the groups and then discuss.
Here is an example of a completed coverstory
Basically we want to find out what hurts and how bad…….I have found the most profound success using workshops (like the ones RuvenGotz speaks about and writes about) and my personal favorite is Collaborative Play (Innovation Games specifically for this activity) The game Speedboat is a quick and painless way to gain insight and understanding into the current state of the situation – lets run through an example (something everyone should be familiar with that is a business process)
The principle of the game is to draw a boat with couple of anchors and engines. (in this example we simply used post-its) The boat should be named to represent a focus area (especially if you are going to examine large group of problems).Ask team members to write what is slowing down the boat (one idea per card/post-it) and to pin the card to anchor or below water level Let team members to write ideas what can speed up the boat and pin cards to an engine (if you have a speedboat) or above the boat (if you have a sailboat) to represent “wind in the sails”. After that you can apply grouping, sorting and/or voting the same way as you know in retrospective in agile/scrum.Result: a lot of ideas get presented without any hassles and participants freely promote possible/expected solutions that can be immediately changed into action items Speed Boat game allows not just open minds, but efficiently provides a strategy how to solve your problems. Additionally, trust and expectations are more clear.
Here is a sample template I threw together for a customer a while back in paint in a couple of minutesIf you are interested in using any of these templates I will tweet the link to these in my skydrive – you can also find template for this game online at the innovations game website
Product Box lets you leverage your customer’s/stakeholders collective experiences by asking them to design a product box for the solution/project.Not just any box, but a box that represents the product that they want to use. Benefits:In the process, you’ll learn what your customers think are the most important, exciting features of a given solution/project.
Here’s how to setup and facilitate the product box gameCollect materials for making product boxes: Example list-plain cardboard boxes (cereal box size is good – you can buy them in a number of places I order mine from Staples)-Markers-Scissors-Glue-Magazines-pompoms-foam shapes-stickers (stars, happy faces, etc.)-pipe cleanersAsk your customers/stakeholders to imagine that they’re selling their product at a tradeshow, infomercial, or public market. Give them a few cardboard boxes and ask them to literally design a product box that represents the solution they want to use. The box should have the key marketing slogans that they find interesting. – 40 minutesWhen finished, each participant takes turns selling their box to the rest of the group – max 2-3 minutesSometimes at the end of the selling you can setup the boxes and have anonymous votes for the groups top three or you can use the data collected in this session to prepare a list of features you can later prioritize with the group leveraging a different exercise
Here are some finished examples of Product box
Gardner's prune trees to control their growthSimilarly when collecting requirements we need to control the requirements sprawlPurning is desined to build a balanced tree that yields high quality fruitThe process isn’t about cutting it is about SHAPINGIf we want project that in essence yield high value return then we need to prune/shape the requirements to maximize the value of the investment being put forth by the project resourcesBy facilitating this activity you put the customers/stakeholders in the copilot seat to help you shape what requirements/features will shape the end result
Here’s how to setup and facilitate the Pruning the Product Tree GameStart by drawing a very large tree on a whiteboard or printing a tree as a poster.Thick limbs represent major areas of functionality within your system. The edge of the tree – its outermost branches – represents the features available in the current release. Write potential new features on several index cards, ideally shaped as leaves. Ask your customers to place desired features around the tree, defining the next phase of its growth. Questions/ObservationsDo they structure a tree that is growing in a balanced manner? Does one branch – perhaps a core feature of the product – get the bulk of the growth? (for example Collaboration)Does an underutilized aspect of the tree become stronger? (for example Social)We know that the roots of a tree (your support and customer care infrastructure) need to extend at least as far as your canopyProduct tree can not only help you understand what the next phase looks like but it can also be used to help you build out your SharePoint Roadmap and Assess your organizations current and future Collaboration Maturity
Now that we know what the overall scope of which requirements we will be targeting to implement in our next release of our solution/project We need to understand the details of each elementSimilar to building a house – you have decided you need walls, floors, windows and furniture (hopefully a roof too) but we haven’t defined yet what type of walls – (how tall, what will be the finish on the wall’s etc.) what kind of floors/ how many floors – you get the idea
This is where The SharePoint Requirements Rainbow game comes inThis collaborative game originated by the ‘21apps’ team is a game to help teams clarify the requirements and user stories they create. It provides a way to help teams ensure the requirements that are defined add value, have some way of measuring this and importantly aligning them to the vision with a clear Why?The facilitator lists all the finalized requirements on the outermost requirements rainbow.Once the customer agrees to the listed requirements, project team and the customer move the in-scope requirements into the scope rainbow. This helps in clarifying the scope of the project or the product.How to measure the success?The customer define the success criteria of the in-scope project requirements to the project team.The customer brainstorms on how to measure the benefit to the organization for the in-scope requirements.Eventually in long run, the customer’s executive management needs to know the value addition the project is bringing to the organization in order to get a continuation or further funding.
Here is an example:Here is how to setup and facilitate the Requirement Rainbow gameDraw or Print out a requirements rainbowHave the team stand around the rainbowYou need 1 facilitator and 1 scribe/observerIn order to play have teams place their requirement at the top of the rainbow (in the “requirements band)Help facilitate the discussion around how would the team define/describe the scope (example is mobile)Once the team agrees to a scope then you move down to the measure bandHelp the team determine how they will measure weather or not the requirement has been metNext move to the value band – have the team map the requirement value back to the overall vision/value statements of the project Lastly ask the team Why? Why is this requirement important/must have – document that and put it on the boardOnly then do you move onto the next requirement and repeat the same processThe end result is a set of well defined, well understood, measurable requirements that have value statements that map back to the vision. This process can also help flush out requirements that don’t belong or add value to the overall solution
Analysis is brokenStep Away from the questionnaires!We don’t know what we don’t know………. And if you don’t know what the need is how can you solve it?Requirements aren’t tech features
So where can you begin?Easy games to get started with is Sailboat/speedboat and Pruning the product treeBe brave to try something new
Founding member of BuckeyeSPUG (COSPUG)Been working with SharePoint since 200515 years of IT experienceLead a team of 45 SharePoint consultantsProfessional Scrum MasterSix Sigma CertifiedSharePoint Saturday Speaker and OrganizerDog Food Conference Planning Committee