Requirements Management Ruminations

by , , , , , , , , , , ,
A collaborative blog with contributions from members of the PMI Requirements Management Community of Practice and various authors and presenters who have dealt with the topic of requirements management.

About this Blog


View Posts By:

Cameron McGaughy
Abdulilah Angaa
Mike Frenette
Beth Ouellette
Victoria Cupet
Jhansi Vijayarajan
Bobbye Underwood
Sally Elatta
Rich Larson
Elizabeth Larson
Ellen Gottesdiener
Mary Gorman

Recent Posts

Natural Language Processing to sharpen up your requirements

Automating requirements review using Natural Language Processing

Actionable Agile Tools - a book review

What’s Hot and What’s Not--Trends in Business Analysis Webinar Follow-up

Project Managers Find New Rhythm at PMI® Global Congress’ First Agile Open Jam

Viewing Posts by Elizabeth Larson

What’s Hot and What’s Not--Trends in Business Analysis Webinar Follow-up

Categories: Business Analysis

This blog is in response to some great discussion and questions that arose during and after the webinar I gave on on March 4, 2015. Some of these topics included the role of the BA and PM, certifications, and Agile.

1.       Can the PM and the BA play both roles? There were many comments and questions about the role of the PM and BA, how they worked together, whether it was one or two roles. The industry has swung wildly between recognizing the BA and PM as separate roles and thinking it makes sense to combine them. I’ve written several Trends articles on this subject, starting in 2009. So where are we in 2015? I have not changed my opinion since 2009. The two roles require different skills and competencies. We tell our clients to think of the analogy of building a house when thinking about roles. The sponsor is the homeowner, the builder/general contractor is the PM, and the architect is the BA. Mike Frenette also used this analogy when he asked the question during the chat, “Would you use an architect to build your house?” Are there people who have the skills to do both? Yes, indeed. Does it make sense for those people to do both roles? Not on large projects it doesn’t. However, even though I’m not jumping up and down about it, I still stick by my prediction that in the near future, business analysis work will be performed by a variety of different roles-- PMs, developers, business stakeholders, etc.

2.       What is the relationship between the two roles—does one work for the other? The question came up about moving from a PM to a BA role and vice versa. We used to think of the BA role as working for the PM role. Now we’re seeing the roles more as peer-to-peer. And interestingly, I’ve seen quite a few PMs becoming BAs, as well as BAs who had been promoted to PM going back to the BA role.

3.       What about the BA on Agile projects? BAs are used in a variety of ways or not at all on Agile projects. There have been heated discussions on LinkedIn discussion groups and at conferences about this role. While many organizations use BAs in the product owner role, the fundamental issue of the product owner having to make business decisions makes this problematic. Regardless of who does it, business analysis is essential to Agile projects, which still have requirements, and there is a need to go from high-level user stories to the detail needed to develop the features. This in-depth analysis is perfect for a business analyst. The BA can also coach the product owner and help ensure requirements are tested.

4.       PMI-PBA vs. CBAP. There was a great deal of discussion on the chat log about certifications—which is better the PBA or CBAP. Here’s a summary of some of the blogs and articles I’ve written on the topic:

a.       Whether it’s ideal or not, many people play that dual role of BA/PM.  If you do, the PMI-PBA is a perfect certification for you.

b.      The CBAP is a gold standard and will continue to be so in the area of business analysis. There are fewer than 5,000 CBAPS today—it’s a hard certification to obtain, but you might want to pursue it if you’re planning a career in business analysis.

c.       It makes sense to get both if you’re a consultant working or expecting to work in various organizations. Trainers, too, benefit from having both designations.

Additional questions:

·         What other projects, besides software development and process improvement works well with Agile? At Watermark we develop our courseware using Agile. We have also found that our marketing campaigns, and for that matter all things marketing, are best done with an Agile approach.

·         Is PMI's Business Analysis for Practitioners: A Practice Guide the same as the BABOK®? No, it’s not. However, all of us who were lead authors on the PBA Practice Guide were also lead authors on the BABOK® Guide. There are many similarities, but some very, very large differences. More on this subject for anyone interested.

·         Does anyone have suggestions for studying for the PMI-PBA exam. Absolutely! Among other things, my husband Richard and I will be giving another webinar on the PBA on April 17 at 11:00 CST. I’d be happy to provide more information –articles, blogs, and lots and lots of information--about the PBA and CBAP certifications, so please feel free to reach out to me.

For more information on articles, blogs, and free webinars, please visit


Posted by Elizabeth Larson on: March 13, 2015 01:25 PM | Permalink | Comments (16)

Be Satisfied With What I Give You--It’s Better Than What You Asked For - Part 2 Managing Changes

My Uncle Bill used to tell us that no matter what type of hotel or where it was located, no matter how many of the hotel staff he talked to in advance of their arrival, Aunt Roslyn would look at the assigned hotel room, find it inadequate, and request a change of rooms. When we were younger, we always felt sorry for Uncle Bill. How patient, how long-suffering he was to put up with the inevitable bother of changing hotel rooms.

However, as we’ve aged, my husband and I find ourselves changing hotel rooms more frequently. In Part 1 of this blog, I wrote about the feature fallacy, citing the example of a hotel front-desk clerk who gave us a hotel room with features we didn’t want, but without those we wanted. After trying unsuccessfully to convince us to stay in the assigned suite, he told us respectfully but firmly that no other rooms were available and change was not possible. In desperation we agreed to pay a fortune to upgrade to get what we originally asked for. Nevertheless, the clerk appeared unhappy. Clearly, the change request was an anomaly and upset his process.

I suspect that many of our sponsors and other business stakeholders are reluctant to request changes because of our body language, because of a burdensome change process, or because they are used to being told “you can’t have that change. It’s out-of-scope.”

In looking back, it seems that we’ve been less likely to change rooms when we’ve taken a virtual tour of the hotel prior to booking a room. Unlike photos taken at just the right angle to make a tiny, bare room look cozy and comfortable, a virtual tour provides a broader perspective of the room in relationship to the rest of the hotel. Pictures provide a structure for us to help the stakeholders discover their requirements, and one of the best ways to provide pictures is prototyping. Unlike static screen shots or wire frames, prototypes that allow our business stakeholders to “use” the end product help elicit not only their requirements, but also those hidden expectations. Even when the prototypes are low tech rough drafts drawn in PowerPoint or on easel pads, they are an effective elicitation technique.

I’m not sure much will change on future vacations. But that’s OK. Few hotel clerks are as crabby as the one above. We have generally found them to be friendly and flexible, like most of the business stakeholders we work with as well. We practitioners just need view change positively, knowing that it will happen, and with tools available to uncover as many expectations as we can. 

Posted by Elizabeth Larson on: September 28, 2014 05:29 PM | Permalink | Comments (10)

Be Satisfied With What I Give You--It’s Better Than What You Asked For! Part 1 – The Feature Fallacy

A sure way to disappoint our stakeholders is to deliver features and functions they never asked for without implementing their real requirements. We assume that our stakeholders will be awed by these new features, without first checking to make sure that they value and are willing to pay for them. We call this the feature fallacy—– a belief that the more features we deliver, the happier our stakeholders will be.

As a personal example, during a recent hotel stay my husband and I were assigned a room with a double bed facing a busy, noisy street, despite having asked for a quiet room with a king-size bed (my husband is 6’3”). When we asked to change rooms, the front desk clerk sighed with disgust and said, “But we gave you a suit with two TVs.” We didn’t ask for a suite or an extra TV. We asked for a quiet room with a king-sized bed. We got features we neither wanted nor asked for and didn’t get features that were important to us. Clearly in the clerk’s mind the extra features were more valuable than the features we requested. However, we were disappointed that our requirements were not met.

I suspect many of our business stakeholders end up with features they don’t want without getting the features that are important to them. Recently I spoke with an executive involved in a project where she had only one requirement related to the installation of a new software package—that the system provide information that was currently captured but not reported anywhere. The package was implemented without the report, much to her dismay. When she asked about it, she was told about all the wonderful new features and functions the system provided. But her report was still missing, and she was disappointed in the package.

To avoid the feature fallacy and related disappointment, we need to determine the business need and recommend a solution that meets the need and provides business value. In other words we need to start with consultative questions that give us the big picture. Instead, we often ask feature-related leading questions, such as have you thought about this feature, or how would you like to be able to do that function. What’s wrong with these leading questions?

·         When we make assumptions about what’s best for our stakeholders, we risk never uncovering their expectations, which inevitably leads to disappointment.

·         When we get bogged down in features without looking at the big picture, we take the focus away from those pesky expectations. No wonder requirements remain hidden.

·         Our stakeholders are likely to agree that this feature is cool or that function would be nice, which distracts both us and them from asking the hard questions needed to reveal their expectations.

So our advice is to listen to our stakeholders before we tell them which features they want. Sure, after eliciting requirements we can certainly recommend that features be included. However, those features must add value, and our stakeholders must have the final say. 

Posted by Elizabeth Larson on: September 21, 2014 05:29 PM | Permalink | Comments (3)

"I choose a block of marble and chop off whatever I don't need."

- Rodin