Eliciting Requirements... Creatively!

From the Project Management 2.0 Blog
by
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

RSS

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 next>

Please login or join to subscribe to this item


It's refreshing to hear increased efforts toward collaboration. In my opinion, it's the most important and readily available facet of interpersonal communications.



And by readily available, I simply mean that the opportunity to collaborate is often right in front of our eyes. Collaboration creates a learning experience, stronger relationships and often, increased productivity.  




I agree with Michael. It is refreshing to see more collaboration efforts coming to the forefront.

good insights on PMI - PBA certification but what is really cool is the final tip: doing business analysis work is the best preparation for passing the exam!

good insights indeed. Practice makes perfect. I am considering getting that PMI - PBA Certfication

I think this is excellent! Being an IT BA for the past six years, I appreciate this perspective. It often seems to me that projects occur with little input from end users. The project is important and it solves an important problem having to do with a required platform change or infrastructure upgrade, but the end users are given very little consideration in the planning.

In an attempt to remedy this, I occasionally see large meetings, with packed agendas and an hour dedicated to discuss everything.

I think that in addition to having the right requirements at the right time/s it is also important to include the right people at the right times. Avoid large meetings that run a long time. Avoid long agendas filled with unrelated items. Be sure that the team has fully explored a topic prior to moving on.

I like the facilitated activities that you describe and would love to hear about more of those.

More applause for this blog entry! Specifically, I copied (and linked) the reference to 7 Product Dimensions as one of the approaches to consider when making a Work Breakdown Structure.

Dave, do you know about any curriculum for the PMI-PBA? My chapter is interested in offering it, and we might have to develop some material, but an existing curriculum from a REP would be welcome. Do you know of anything?

Hi Michael,

I'm not actually sure. I know that you can get a general sense of "What to study "from the examination content outline. - but Im sure there's something better. I'll have a look around and get back to you.


Although Scrum Master or Project Manager is a person, however B.A should be a process to make business requirements more clear for development and solution delivery.


I do believe the most important aspect of an IT project is identifying requirements, so the entire project life cycle process should apply the best B.A practices to improve the success rate of project.

Hi again Michael,

I had an email exchange with Dave Bieg, our resident PBA guru, and he offered the following


Dave,


Here is a thread on LinkedIn that may be of assistance: https://www.linkedin.com/groups/PMI-PBA-Study-Group-PMI-6688787?home=&gid=6688787.


While I think they also offer courses and such for a fee, the fact that they have this Study Group may provide an opportunity for them to also provide materials to chapters.


Let me know if it works.

Thanks,

Dave

Thanks Dave Garrett, I reached out to Dave Bieg via this site and joined the study group. I'm working through the Practitioner's guide from PMI, and our chapter is planning to get a membership with the IIAB and get the current version of the BABOK.

I'm also taking a MOOC offering on business analysis. All of this is a lot of work, but I think it will pay off. I'll try to write something useful out of it when we are ready to run the PMI-PBA pilot course.

Thanks again for your research and feedback. I'm looking forward to seeing what the LinkedIn group offers.

--Mike Adams, PMP

Fascinating article! Is there such a thing as AN agile business analysis and how closely aligned is it with agile project management.

Hi Bill, others may have more information relating to your question, but my understanding of Agile is that the business analysis is sort of assumed at the onset, and requirements gathering takes place inside of user stories, which are short and succinct, and based on a presumed knowledge of the business context.

For a full business Analysis, I think the use cases are needed. Once that knowledge is widely known, Agile's user stories can be used.

Please don't mistake me for an Agile expert though...if someone has more or better information, please chime in.

Interesting post and comments! I think one of the biggest challenges to BA - and the post reinforces this - is getting participation from the stakeholders. Mary Gorman outlines and clearly illustrates the right way to do it - collaboratively, with team participation - but people are busy! The best tools and techniques are of little value without participation! So how can you determine the level of participation you absolutely need, and what is the payoff for each participant? Not easy questions to answer, and different for every project, but I think it needs to be addressed.

Great interview. I"ve often struggled with developing good business requirements documents. I've bookmarked the 7 product dimensions but am interested in the artifacts produced by the other tools: State Diagram and Context Diagram. I don't have a good toolbox and struggle to find the right tools to get the job done. Mary mentioned that she had a more extensive toolbox and I'd guess we would all like to know what is in there!
Thanks

With all my respect, the problem with the statement is: from stakeholders you never elicit requirements. You ever elicit needs/wishes/desires/wants that you have to translate into requirements. If we not understand that we are lost if we want to work as business analyst. And the second one is: do you understand why the word "elicitation" is used? Search from dictionary definition and you can see that it is used because the primary concern is to help the stakeholders in articulating their needs/wishes/desires/wants. So, diagrams will not help with that.

Page: 1 2 next>

Please Login/Register to leave a comment.

ADVERTISEMENTS

"If you are patient in a moment of anger, you will escape a hundred days of sorrow."

- Chinese Proverb

ADVERTISEMENT

Sponsors