Project Management

Eliciting Requirements... Creatively!

From the Project Management 2.0 Blog
New technologies, concepts, and Web 2.0 tools are popping up everywhere. How can you use them to help your project team collaborate, communicate - or just give your project an extra boost? [Contact Dave]

About this Blog


Recent Posts

Are You Prepping For The PMP 24/7?

Are You Just Too Darn Busy?

Eliciting Requirements... Creatively!

What To Expect When Your Stakeholders Are Expecting

8 More Templates to Save You Time

Categories: Interviews

We recently had the honor of speaking with Mary Gorman, Business Analysis Guru and VP of Quality and Delivery at EBG Consulting. Mary will also be a speaker at the PMI Global Congress 2014 - North America, delivering "Creative and Collaborative Business Analysis for High Quality Requirements

Mary's session is all about creative approaches and techniques for developing requirements - an incredibly useful topic for all of us. Here she offers a taste of what she will deliver in Phoenix. She touches on some really thought-provoking points: keying off of "events", understanding what your stakeholders really "know"  and much more.


Q. In your presentation you will be discussing how to make business analysis practices both engaging and collaborative. Are there common elements of the way you approach business analysis that encourage engagement and collaboration?

A: Business analysis is a team sport—to succeed you’ve got to get the right people to work together productively and transparently. By right people I mean stakeholders from the customer, business, and technology realms—a team of product partners. First, you have to identify who these people are, then you have to help them collaborate as partners, which isn’t easy considering they all come from different backgrounds and perspectives. Once they begin to work together, though, the results are powerful.

To help build a team of product partners out of such a diverse group, I often facilitate focused activities that get people up, moving around, and exploring. I design a physical space so that people can conveniently and spontaneously interact as they converse. I encourage visual thinking, inviting them to sketch on posters, walls, or whiteboards, using symbols, colored posts and markers to explore product possibilities. I ask focused questions to stimulate structured conversations among the product partners, helping them to succinctly yet deeply clarify product needs (a.k.a. requirements).


Q. Could you describe your very favorite BA technique and how it’s best done?

A: As a long-time practicing BA and facilitator I have a toolbox of proven, even cherished, techniques. And I continue to seek out new ones. Choosing a favorite is tough! Please allow me to provide two answers.

One of my favorite business analysis techniques is a context diagram—an analysis model that invariably spawns rich conversations. I ask the product partners to create this diagram together, interactively exploring, discussing, and clarifying the product’s scope. (I prefer to keep the drawing low tech, using markers and colored stickies.) First, we draw a circle in the middle to represent the product, which may be a service or a system. Then the product partners add the known external entities, and draw the interfaces to and from the product. As they do this, they typically uncover absent and misunderstood requirements, such as interfaces, missing or extraneous stakeholders, and even key data needs.

My stealth analysis model is the state diagram. I use it selectively, pulling it from my toolbox when a team needs to analyze a product that has an event-rich lifecycle. I start by asking the product owner and subject matter experts to list the key events. For example, when analyzing an insurance claim some events might be submit, register, adjudicate, and pay. We discuss the associated states of the claim, e.g., registered, approved, rejected, pending investigation—the pre- and post-conditions related to the events. Invariably the diagram stimulates conversations among the domain experts. Together, they learn and share rich details about the product’s users, actions, data, and business rules—details that might otherwise have been overlooked or misunderstood.

One of the beautiful things about the appropriate use of these tools is that the participants do not need to be experts in the models themselves—their form, format, and semantics—but only in the content. The creation process itself is about mutual exploring, questioning, and learning. These and other analysis models help build powerful and trusting partnerships among stakeholders.


Q. You talk about discovering the right requirements at the right time. Could you tell us a bit more about that and perhaps offer an example? 

A: Let me start with a story. In a recent engagement I was asked to help a team that had spent considerable time laboring over very detailed wireframes. What was wrong? After a brief assessment, the team quickly realized it had no grasp of the underlying business rules, was confused about the source of the data, and had at least three unsupported users. The team’s deep dive into the user interface had been too narrowly focused! I helped them readjust and take a holistic approach, exploring the full range of product needs using the 7 Product Dimensions to incorporate both functional and nonfunctional requirements.

As the team began to focus on the right requirements, we worked together to understand how to explore them at a consistent level of detail. As I noted the team’s UI work was very specific. It needed to be supported and validated with detailed business rules and data on an ongoing basis.

By the same token, teams need to discover and define detailed requirements at the right time—just shortly before they are developed—so they are “fresh.” It’s risky to invest in detailed requirements well before development begins—because as business and technology needs change over time, so must the requirements.

Really, it’s all about value! The right requirements are those that are highly valued by the customer and business, at that particular time. 


Q. What do you see as key strengths in the new PMI-PBASM certification? Where should applicants focus their efforts when studying for this credential?

A: PMI’s Professional in Business Analysis (PMI-PBASM) Exam content outline offers a practical overview to business analysis. (Disclosure: I served on the task force that created the Examination Content Outline.) By reviewing the five domains (along with the 28 supporting tasks) anyone can quickly grasp the key aspects used to discover and manage requirements. Say you are a project manager assigned to a new project. You and the business analyst can easily review the domains and tasks to better assess what work needs to be done and consider the level of effort needed. 

Well before studying for the examination, it is wise to calculate whether you meet the certification requirement of at least 7,500 hours of business analysis experience. Do a thoughtful and honest self-assessment. Review the five domains and see if you have balanced experience in all. Consider your level of expertise in the 40 skills and knowledge topics listed in the Examination Content Outline. What are your strengths? Where do you need to learn and grow? Search out stretch assignments to help you grow in those areas. And most importantly, remember doing business analysis work is the best preparation for passing the exam!

Posted on: October 11, 2014 09:17 AM | Permalink

Comments (24)

Page: 1 2 <prev

Please login or join to subscribe to this item
As mentioned business analysis is a team sport - it becomes all the more important for the team to be aligned towards the goal and should work symbiotically in achieving the goal.

We need to understand, to be successful, that we NEVER elicit requirements. We EVER elicit needs/wants/desires/whishes that we must transform into requirements. If we do not understand that we will fail.

interesant !

Excellent useful stuff

Page: 1 2 <prev

Please Login/Register to leave a comment.


"The only thing to do with good advice is pass it on; it is never of any use to oneself."

- Oscar Wilde