• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Effective requirements gathering workshops
 

Effective requirements gathering workshops

on

  • 2,061 views

PLEASE DOWNLOAD TO VIEW ANIMATIONS & SPEAKER NOTES....

PLEASE DOWNLOAD TO VIEW ANIMATIONS & SPEAKER NOTES.

Analyst: What would you like SharePoint to do?
Customer: Well, what can it do?
Analyst: Tons! Let me show you…

All too often, this is how conversations between analysts and customers/stakeholders begin, and it isn’t helpful to anyone. SharePoint has a vast array of capabilities, but if you start by describing or demonstrating what SharePoint can do and how the technology works, you will end up with customers who are confused and don’t know where to begin, or who have massively overblown expectations.

In this session, you will learn how to set up and conduct workshops with various stakeholders that will allow you to understand their real needs. You will then learn how to document and organize this information so that it is useful to the stakeholders and that will allow you to guide them through prioritization and planning.

You will learn when NOT to do demonstrations of SharePoint, and when and how to do demos that are powerful and effective.

Statistics

Views

Total Views
2,061
Views on SlideShare
2,031
Embed Views
30

Actions

Likes
1
Downloads
108
Comments
0

4 Embeds 30

http://www.linkedin.com 15
https://www.linkedin.com 8
http://paper.li 6
http://us-w1.rockmelt.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • (Thanks to Richard Harbridge for this title slide.)
  • (Thanks to Richard Harbridge for this title slide.)
  • Requirements is not the right word!(First heard this distinction from Sue Hanley)
  • Requirements is not the right word!(First heard this distinction from Sue Hanley)
  • Because I said so, and I’m the customer.If you don’t include my requirement, I’ll shootOne of my biggest jobs as a SharePoint BA is to manage this desire. My three rules of SharePoint: Simplicity, simplicity, simplicity
  • Go for it!
  • Wait a sec – maybe we can think of some alternatives(Hey! Maybe it’s no longer a ‘requirement’)
  • So, what happens when the customer says “I need this”This is the “we need it all” solution – often arrived at before defining the problemThe “Hammer” problem
  • So, what happens when the customer says “I need this”This is the “we need it all” solution – often arrived at before defining the problemThe “Hammer” problem
  • Think about alternatives:Is it close by?
  • How fast do I need to get there – who needs to come with me
  • Is a less flexible but more cost-effective solution already out there
  • Is the destination specialized and particularly hard to get to?
  • Maybe we need to really think outside the box
  • Simple is not ALWAYS the best solution: There are times when a complex and expensive solution is the only way to get the required destination
  • Bottom line: Arrive at outcomes, not requirements
  • The other problem with requirements is that you only have one time to mention them, so you want ALLLLL of them to be met.So, you put everything in that you can think of…SharePoint lets you be ‘agile’Start with the three rules: Simplicity/Simplicity/SimplicityIdeas from: PragPub Feb 2011 – Pragmatic ProgrammersWay of the Agile Warrior - by Jonathan Rasmusson
  • But the reality is that most requirements never get used as designed because the landscape changes under your feet.
  • And this causes you to change course, sometimes even before that ‘required’ item is even finished being built or tested.
  • Leading to a bunch of rusty tools lying around that cause trouble for years.e.g. what happens when you need to upgrade or migrate? Someone has to chip the rust off to see if this stuff is even useful anymore
  • The result is wasted money
  • So, shifting gears: I’ve explained what we should not be doing. What CAN we do?
  • What would you like SharePoint to do?Well, what can it do?Tons! Let me show youWhat do I need that for?Well, it depends… what do you want it for?Well, it LOOKS cool – sure: I want it.
  • I’m going to share the tools and techniques that I have built up out of painful experience.
  • My goal for you: Ability to move forward confidently, knowing that you have increased your chances of delivering a solution that really works for your customers.
  • Favorite phrase: If you don’t know where you’re going, any path will get you there.
  • Discovery, Road-mapping, Navigation, Document Inventory/Taxonomy, Wireframing, Business Process
  • But First: DO NOT DEMO SharePoint Confuses peopleSets unreasonable expectations
  • The focus here needs to be on pain points and outcomes: NOT RequirementsTry to stick to one team at a time3 – 8 people is ideal – up to 12-15 can work.Need to make sure you hear from everyoneDon’t let manager dominateMake SURE you get front-line workers, not just managersBook 1.5 hours – plan on an hour and a bit.People love some extra un-booked time at the end.
  • The following slides are a sample deck that I use in workshops
  • If you are lucky, you can take the results of these workshops and create a roadmap for a phased, rational approach to SharePoint deployment. Push HARD to do this step.Summarize workshop resultsBuild Gap AnalysisIdentify dependenciesLay out a timeline (not a project plan at this point)
  • Use their language, colors, logoShow ‘day in the life’ type scenario
  • A little detour into shared understanding
  • To achieve success, you need shared commitmentTo get that, you need to get to shared understandingSing from the same song-book: Get onto the same pageIf this area really interests you, speak to Ant Clay of 21 Apps – they run the SharePoint IA Master Class
  • What is this a picture of?With a lot of experience, training or imagination, you may figure something out – but the concept is ABSTRACT
  • This is something that people understand and agree on.It is concreteVisual tools can help make the abstract into the concrete
  • MindManager (from MindJet) is a tool that has changed the way I work. Here is a quick demo of how it works.
  • Now lets get back on-track
  • Site navigation/Menus
  • Using Mind Maps for navigational design makes this process MUCH faster and more efficient.
  • First, I do a presentation about what metadata is to a collection of groupsGive them homeworkThen, bring them back to build taxonomy: This needs to be done with just one group at a time
  • Folders/Folders/FoldersShow a familiar tool – Excel – to simulate a document library
  • This is the homework for the stakeholders: Go and examine your files and, for each type of document, list the potential metadata that may be used.
  • Note: Picture of ‘tacks’ is a visual joke – it doesn’t mean anything
  • This taxonomy map is built interactively with the client based on the homework that they’ve done
  • What is wireframing?Creating page mockups that show the function and structure of the page without the fonts/colors/images, etc
  • This tool called ‘Balsamiq’ makes it extremely simple and fast to make wireframes.They look cartoonish, but that makes it easy to focus on what’s important (not color, font, etc.)
  • Even without building an automated workflow, it’s essential to understand the business process of your customers.Use BizAgi (which is free to download) or Visio 2010 to map these processes.
  • Solve the Chicken and Egg problemAvoid the pain of past mistakesGive you tools that you can learn that will make your projects go better.

Effective requirements gathering workshops Effective requirements gathering workshops Presentation Transcript