cazh1: on Business, Information, and Technology

It's been a while since I've led an interactive requirements session for an interactive application - but it's kind of like riding a bike. After a few minutes, the old habits come back, and the iterative ideas and cascading creativity starts to flow. What has changed, however, is the application platform, the office environment, and the various knowledge capture tools at our disposal.

So, in the spirit of knowledge retention and sharing, here's a brain dump of ideas that make for a better requirements gathering session ...

• Think of it as an interactive presentation - so all of the classic prep rules apply. Arrive early, get set up and have everything running before people arrive
• Make sure you can bring the original application (if it's a rework) up on the screen: check in advance that you can attach to the network
• The best sessions are interactive, with application mock-up tools. Have a copy of Visio, PowerPoint or something similar ready to go - so you can paint screens and interactively work things while they watch
• Use a room with a big screen TV or projector, so your audience can "see over your shoulder" as you work. However, if possible, you should face your audience - have them look behind you at the screen / projection, while you look at the display on your laptop.
• This allows you to have a conversation with the folks opining on needs and wants, and lets you see their facial expressions as you dummy stuff up.
• This also allows your audience to see what you are typing. They are proofreading your work - not for typos, but to make sure their understanding of the words / ideas you are talking about are being captured correctly.
• Make sure you know where the local printer is, and can print to it. Waiting for a series of changes to be "painted" on the screen may take too long; it might be easier just to take a print screen and mark it up
• When sketching on paper, have a couple of different color pens on hand, and color-code your scribbles; red = follow up / things to fix, blue = talking points, etc. When capturing ideas on the hard copy, your fixes & follow-ups are easily distinguishable. A highlighter might be good idea, too.
• re: typing / data capture: Consider using a simple text editor, Notepad or something similar. Key is not to worry to much about formatting the text or correcting typos. As long a you can decipher your hacking, that should be ok
• However, a spell checking word processor might be preferable to Notepad - your typos will get automatically fixed up
• Always number your requirements / items to attack. Then you have a finite, trackable list of stuff that is either go or no go
• Consider creating an auto-numbered spreadsheet for a Requirements list - you can bring it up on the screen as well. Create additional columns for notes, resource assignments, effort estimates - stuff like that
• Bring a digital voice recorder to the session. Let the folks know that they are being "taped" - but it's only so you can go back and replay the discussion while cleaning up your notes. This will also allow you to stop typing and continue the in depth conversation - which is where all the value is
• Set clear expectations of what you want to accomplish in the meeting - and set a time limit; iterative work is easily digested when taken in small bites
  

There is a lot of power in truly collaborative requirements sessions - the ultimate users of your system will readily accept the results when they are truly part of the design process and experience.

Previously ...

• Three Best TLAs of all time, the hegemony of Excel, and the Intuitive Front End (August 12, 2006)
• The Iron Triangle - Quality is a Feature that We Choose to Omit from Projects (October 28, 2006)
• Another caveat for the erstwhile agile developer (January 15, 2007)
• Innovation That Matters - Substance Over Style (January 12, 2008)
• Do you want it good or fast? Prioritizing Time-to-Value over Requirements (February 10, 2008)
• Facilitating Innovation: Establishing an Environment of Possibilities (August 22, 2008)
• Agile Methods in a Waterfall World: Speaking In Code (September 29, 2008)

Technorati Tags: best practice, design, development, innovation

Invisible Technorati Tags: cazh1, James P. MacLennan, jpmacl, MacLennan