Success with Requirements

Volume 1 :: Number 3 :: 2007
ISSN: 1936-3583

Welcome to our Newsletter

I am sending Success with Requirements to you because I think you might find it valuable, and I would like to keep in touch. If you'd prefer not to receive it, you can unsubscribe by clicking on the "manage your subscription" button below.

I am excited about Success with Requirements. Each month it will include a short article from me, along with links to resources for professionals in our field.

In this issue:

Free eLearning Pilot
Success with Stakeholders
New Website
Upcoming Event
Resources of Interest
New Course Offering

If you have a requirements problem you would like me to address, or if I can do anything to make Success with Requirements more valuable to you, please let me know.

Ellen Gottesdiener,
President and Principal Consultant
EBG Consulting, Inc.
http://www.ebgconsulting.com


	Free eLearning Pilot

Are you interested in participating in our next eLearning pilot? It's free.

Your only obligation is to provide feedback on the training immediately after participating.

The pilot is for a module in our Analysis Modeling: The Road to Success blended eLearning offering. Please let us know your experience level with analysis modeling in your response. We will select a cross-section of people from novices to experts. We will be conducting additional pilots as we proceed through development, so stay tuned for more!

If you are interested, please contact us: pilot@ebgconsulting.com
Thanks!


	Success with Stakeholders

I can't get my business customers to tell me what they want. And, if I do, they keep changing their mind!
~ Common IT complaint

The IT staff wastes hours and hours of our time in tedious requirements meetings. Then, they keep coming back to us with more questions. Our staff dreads getting assigned to work on the IT projects!
~ Common business complaint

1.Successful projects depend on excellent requirements.

2.Getting excellent requirements in optimal time requires honest collaboration.

3.Both "sides" of the business-IT relationship have information that's critically relevant to an excellent set of requirements.

4.Successful projects require early, genuine, and continual collaboration between "business" and IT.

Common sense, right? Any experienced business analyst (BA) and project manager (PM) will tell you it's not always common practice.

I'd like to share a few business-IT collaboration tactics that have saved my clients money and frustration:

Collaborate for Quality

Business people complain about IT wasting precious time and money in tedious meetings to review requirements documents. Stop the meeting madness! Jettison your "classic" meetings and instead use facilitated workshops for requirements elicitation and review.

Facilitated workshops, unlike classic meetings, are structured for productive collaboration. The premise is straightforward: a carefully-selected group of stakeholders are led by a neutral facilitator through pre-planned activities to help them define, invent, refine, and reach closure on requirements. Classic meetings, on the other hand, tend toward information sharing, partial group participation, minimal requirements formulation and verification and little or no little closure.

Workshops are participatory, productive, and require careful planning and design. The payback, however, is significant: reduced scope creep, increased requirements quality and healthy project team relationships. Workshops can be used at the start of the project to charter, envision and scope the effort, and then to elaborate on requirements as the effort proceeds. Bringing stakeholders together in this way tends to commit users to the requirements definition process, promote business ownership for the deliverables and, ultimately, the solution. Best of all, workshops go a long way toward bridging communication gaps among project stakeholders.

Multi-Model

Too many projects rely on text-based requirements statements ("system shall" or "system will") to communicate requirements. Instead, employ multiple models to communicate needs.

Requirements models (also called analysis models or user requirements models) are representations and approximations of reality. They take the form of a diagrams, lists, or tables -- sometimes supplemented with text -- to represent user's needs from a particular point of view. Examples of requirements models include event-response table, use cases, data models, business rules, actor maps, and prototypes. Each view is separate, yet related, to other views -- facilitating separation of concerns. All these views are integrated together to provide a view of the overview system.

Business and technical stakeholders share a common set of requirements models for articulating requirements, avoiding dependencies on ambiguous natural language sentences. Requirements elicitation is, after all, a process learning and discovery. Requirements models are useful for facilitate requirements development. They are independently of software development methodology or technology, and can be tailored to be more or less detailed to suit your project process.

Serious Play

In his book Serious Play (Serious Play: How the World's Best Companies Simulate to Innovate", Harvard Business School Press, 2000), author Michael Schrage reveals the role "play" takes in product innovation. That is, "playing around" with models and prototypes unleashes ideas, confirmed needs, and feeds successive revision of products.

Playing with requirements can take multiple forms. For example: role-playing usage to elicit requirements models, stepping scenarios through draft models, or trying out prototypes or demonstrations of working software.

Because business stakeholders often do not really know what their requirements are or should be -- or their initial ideas often morph with time and exploration --aking this form of play productive is essential. Playing with models grabs and engages stakeholders in the requirements process -- and engagement is key to success. Playing with models is serious business.

Foster Feedback

Like natural systems, requirements work is also rife with complexity and chaos. We face a stew of unclear and conflicting stakeholder needs, multiple interfacing parts, changing market demands, and sometimes shifting strategies. To simplify and stabilize, feedback is needed during requirements development. Efficient and effective feedback involving customers is best acquired with this troika: reviews, retrospectives and metaquestions.

Reviews (also called technical reviews) are short, focused meetings with three to seven participants in which portions of one or more work products are examined to find defects. Reviews can be tailored to be more formal or less formal by having predefined roles and processes. Business and technical stakeholders are needed in requirements reviews. Any review should be adapted to include both formal and informal methods focusing on risky requirements information that has the highest risk of missing, erroneous, or inconsistent requirements. Reviews, which rely on "wetware" (the brain), are one of the most effective ways to increase the quality of delivered software.

Retrospectives go beyond "lessons learned", postpartums, or postmortems. They are specialized workshops that engage the team, including customers in reviewing a specific timeframe or milestone of teamwork. Product and process evaluated. You identify specific corrective actions needed to improve work practices and project deliverables. This includes openly and transparently retrospecting on stakeholder involvement practices.

Metaquestions are questions about questions. Metaquestions should be used in a variety of requirements contexts such as interviews; facilitated workshops; prototypes walkthroughs; focus group sessions; surveys; user observation. For example, asking in an interview, Do my questions make sense?; What other questions might I ask you?; Do my questions seem relevant? leaves room for adapting the interview process. Metaquestions about the requirements process such as: How will we know we are using the best approaches to developing and managing requirements?; Do we have the right people involved in developing requirements? allows the team to take corrective action to maximize your requirement efforts.

The Big Picture

I've found that developing and maintaining healthy relationships as a project community is probably the single most challenging matter facing business analysts and project managers. Business stakeholders must be involved in discovering, defining, questioning, revising, and validating requirements, and they often aren't because BAs and PMs don't have the awareness, skills or support to do so. The most productive techniques include active participation in workshops, developing and playing with multiple, interwoven models, and seeking self-corrective feedback through reviews, retrospectives and metaquestions.

~ ellen

Stay tuned: Participation using these techniques in workshops necessitates getting people to "show up", the subject of the next newsletter.

If you want to learn more now, and you don't already have a copy, you can click to try my book Requirements by Collaboration. To learn more on requirements practices, check out Software Requirements Memory Jogger.

Standard citation for this article:

Ellen Gottesdiener, "Success with Stakeholders", Success with Requirements, Vol. 1, No. 3 (March 2007).


	New Website

We recently updated our website with a new look, easier navigation, and more content. You will find additional resources, links and information useful to your work as a business analyst, project manager, facilitator, requirements engineer, developer, or tester.


	Upcoming Events

1. Mary Gorman, EBG Consulting's Senior Associate will be presenting two workshops (full day sessions) and a track session at Business Analyst World/ProjectWorld,Toronto, Canada on March 26th and 27th.

2. Both Mary and Ellen Gottesdiener will be presenting workshops and track sessions at Project World & World Congress for Business Analysts-Boston, the week of June 18th. For a speaker discount from EBG Consulting, register using Discount Code SPKRM1910EG.

3. Consider sharing your expertise and experiences as a business analyst or project manager, this November with your colleagues at Project World & World Congress for Business Analysts-Anaheim, California.


	Resources of Interest

Each month we'll provide a few resources we think are worthwhile. We welcome you comments and suggestions for future issues!

Joel Spolsky wrote wrote this entertaining and provocative piece on

painless functional specs -- an oldie but goodie!

Do you know ROI (return-on-investment) on your requirements work? Find
ut on EBG Consulting's new ROI page.


	New Course Offering

We are pleased to announce our latest instructor-led course:

Business Rules: A Roundtrip Journey on the Road to Success.

This one-day advanced course focuses on the heart of functional requirements: business rules. Business rules are an essential part of business analysis. Find out more by visiting our website.