Episode 297: Still No Time to Manage Project Requirements (Free)

Play Now:

This Interview with Elizabeth Larson was recorded at the PMI® Global Congress 2014 in Phoenix, Arizona.

Many of us know that poor requirements management is a major source of failed projects. But who has time to manage requirements? Elizabeth's presentation "Still No Time to Manage Requirements - My Project Is Later Than Ever" and our interview answers frequently asked questions about requirements management.

• Why should we manage requirements?
• What is the definition of requirements management?
• Do we really need a requirements management plan?
• How does business analysis play into requirements management?
• Is business analysis just a synonym for requirements management?

Elizabeth also dispels common misconceptions and provides tips for managing requirements when you don’t have the time. She gives us three time saving techniques for requirements elicitation and management.

Episode Transcript

Below are the first few pages of the transcript. The complete transcript is available to Premium subscribers only.

Podcast Introduction

Cornelius Fichtner: You are listening to the Project Management Podcast™ at www.pm-podcast.com and we are coming to you live from the PMI Global Congress 2014 in Phoenix, Arizona and I'm sitting here in the exhibition hall with Elizabeth Larson from Watermark Learning.

Podcast Interview

Cornelius Fichtner:Hello, Elizabeth!

Elizabeth Larson: Hi, Cornelius.

Cornelius Fichtner: We've had you on before about requirements of all things.

Elizabeth Larson: Yes, yes!

Cornelius Fichtner: Yes and we're going to be talking about requirements again.

Elizabeth Larson: I'm delighted to be back!

Cornelius Fichtner: Yeah, wonderful! But before we talk about requirements, let's talk about requirements and in particular you're a presenter here. Did PMI have any specific requirements for you about what the presentation had to be like? Was there any kind of sort of frame of mind they wanted you to be in?

Elizabeth Larson: There was! Although there were no requirements for the length of the presentation as the number of slides or what they needed to look like, there was a requirement that it be interactive and that's my presentation…

Cornelius Fichtner: Oh so, group interaction. That was a requirement.

Elizabeth Larson: Yes, yes, by interaction, exercises, discussions with the group. Get the group engaged.

Cornelius Fichtner: Okay! Little difficult here with the interview or the people who are sitting at home. But we're going to do our best anyway to get them engaged at least mentally. So why should we manage requirements? What's the importance?

Elizabeth Larson: Yeah, why indeed should we spend the time when there aren't enough hours in the day to manage our projects, why should we manage requirements? Basically, it comes down to the fact and there have been so many studies and so many reports if we don’t get our requirements right, we're not going to get our projects right. We're not going to have projects success. And so we really do need to learn how to get our requirements right, requirements management helps us do that.

Cornelius Fichtner: Absolutely and this plays very much into the statements from other interview guests that I've had here at the Congress. Some people say, we have to define the scope up first up. If we don’t have the scope defined correctly, we will fail. Others like you, they use the word 'requirements'. We need the requirements to be correct, otherwise, we will fail in our projects. So it's a theme that I'm seeing emerging here in the interviews that we're doing.

What is the definition of requirements management?

Elizabeth Larson: That's a great question. Requirements management is about planning requirements. It's about analyzing requirements and communicating requirements and monitoring against our plan and about managing changes. That's a little bit different from business analysis and there's a lot discussion about business analysis.

While business analysis does all of these things, in addition, we are determining the business need, what business problem are we trying to solve and recommending viable solutions. So business analysis actually starts prior to the project beginning and extends beyond the project. There is that overlap of the planning and the analyzing and the communicating and the monitoring and the managing changes.

Cornelius Fichtner: Okay, so business analysis starts before the requirements happen or the need to be elicited. But oftentimes, is it not the job of the business analyst to elicit the requirements as well?

Elizabeth Larson: The requirements can be elicited by any practitioner who does the work of a business analyst.

Cornelius Fichtner: Of a business analyst.

Elizabeth Larson: Exactly! A lot of project managers actually function…

Cornelius Fichtner: A lot of them, yeah!

Elizabeth Larson: A lot of them, company included, operate in the role of a business analyst. My title might be project manager, but I need to have that hybrid role where I also get involved in business analysis. There's a lot of overlap between business analysis and requirements management. Both are about the elicitation, the documentation, the modeling of requirements.

Cornelius Fichtner: Okay.

Elizabeth Larson: And as a matter of fact, requirements management is a subset of business analysis. That's one way to look at it. I don’t know if you're familiar with the PMI 2014 Pulse of the Profession®. It's a report that came out the [indistinguishable] a lot of organizations and in that report, in the introduction, they talked about how requirements management is a subset of business analysis and that's why I say business analysis starts prior to the project beginning. We end up with the business need and the business case with your input inter-project initiation has been out. And there's a piece of the project stems to evaluation beyond.

Cornelius Fichtner: Do we need requirements management plan?

Elizabeth Larson: You need to give thought to how we're going to get through our requirements activities. It could be a formal plan that's documents and signed up or it can be an agreement between the team members: "Hey, how are we doing to do this?" "Oh we're going to be working on an Agile project so we're going to write up our requirements, its user stories and get them prioritized and product backlog." Or "we're going to get through them in a very formal way." So we have to give that thought. We're not talking about, the presentation doesn’t talk about the specific elements or components of a requirements management plan.

Cornelius Fichtner: While we're talking about the requirements management plan, at some point the requirements, they have been elicited. They have been written down. Now they're set in stone and they will never ever change.

Elizabeth Larson: Right.

Cornelius Fichtner: So how do we deal with changes? How do we deal with scope creep when it comes to the plan of managing requirements?

Above are the first few pages of the transcript. The complete PDF transcript is available to Premium subscribers only.