For more business analysis resources visit www.iag.biz

Q&A – 5 Things You Must Know About Requirements Planning

5 Things You Must Know About Requirements Planning is a deep dive into requirements planning and is

partially about getting stakeholders on board with great requirements practices. If you treat

requirements planning as just another document to build, you’ve failed. You can add value by

solidifying consensus on what constitutes great requirements; what process will be used for the project;

and what is the commitment of the business in supporting the initiative.

Requirements planning is plagued by some very common pitfalls:

People don’t do it

People treat it as a form that must be filled out

People don’t see it as an opportunity to build personal credibility with their stakeholders

Avoid these pitfalls and focus on some key value-add points:

1) Set and Manage Stakeholder Expectations

2) Use Requirements Planning to Confirm Resource Estimates

3) Plan to Communicate Progress and Communicate with Transparency

4) Coordinate the Business Analysis Effort

5) Think Lessons Learned

Remember, it’s a process, not a document!

Below is a selection of participant questions from IAG Consulting’s webinar 5 Things You Must Know

About Requirements Planning with answers and explanations from VP Keith Ellis. To sign up for this,

and other IAG webinars, visit: http://www.iag.biz/resources/webinar-events/

Q: What's the difference between Analyzing Requirements and Reviewing Requirements?

Keith Ellis: Reviewing happens with stakeholders. You review to determine accuracy and gain sign-off.

Analyzing requirements happens to verify completeness, determine interdependency and project

impacts, assess scope, and assist you in looking at solutions

Q: Do you have any suggestions when your users are new to the company or project and don't

have the answers you need?

KE: Focus on isolating and knowing what you don't know - you can then isolate that the unknowns are

few, and chase down the answers. Use an elicitation technique that makes it easier to define the

For more business analysis resources visit www.iag.biz

process in business terms first. Then ASSUME they can't tell you the process - but need to be guided

through a questioning process. Also if you adopt group sessions you'll be better off since many people

can't answer questions when there is a group impact (the group collectively needs to determine the

answer).

Q: If the basic design of the solution has already been decided by the business and technical

teams, and then the BAs are engaged--can an effective requirements management plan still be

created and provide value?

KE: Yes. Think of the scenario that a company has run out and bought a commercial off the shelf

application. If it has any complexity, the workflow within the company still has to be determined in

order to implement. The requirements planning process executes - as is - you might just call it a

"customization planning" session. The second area is in triage and fix on troubled projects. This

process is a critical part of re-establishing credibility with the stakeholder team on the work-out plan.

Q: What types of tools do you use? Are they separate tools for requirements management /

modeling, etc., or are there tools you like that serve multiple functions?

KE: We use a host of different tools depending on the engagement needs and what the client has

installed. Favored are ones like IBM Rational Suite / Telelogic doors, Ravenflow, Borland, and

Enterprise architect.

Yes, there are different tools for managing requirements versus modeling or discovering requirements.

For instance, Raven or IBM Requirements Composer are on the modeling and capture.

Q: How can I apply this to a project that has already started, without a RMP?

KE: Depends on the size of the project and the condition of the project. If the project is likely to go into

a troubled state - you execute the planning phase - as is - to get in front of the work-out phase that is

likely to happen to correct the problem. If you are simply gold-plating an already successful project,

then do the work around the hand-off points to expedite project delivery.

Q: Do you ever find that there can be duplication between a Business Analyst role and a Project

Manager role, particularly in terms of documentation produced by each role?

E.g. communications and documenting stakeholders is often done by both the BA and the PM

For more business analysis resources visit www.iag.biz

KE: Yes. This is one of those areas of very high duplication as well. Clarity in the planning stage also

confirms role / responsibility between analyst and project manager to set delivery and service level

expectations.

Q: Does stakeholder engagement occur as a separate "requirements planning session" instead of

including it the initial "project planning session"?

KE: I'm going to assume that your initial project planning session is going to focus first and foremost on

establishing the scope of the project, scope of analysis, and business objectives. I'm thinking you'll

likely need a follow-on meeting to then look at the details of requirements planning given these

objectives, scope issues and details. I'm thinking you're likely two meetings, unless it's a very small

project.

Q: Any tips on how to persuade stakeholders to be onboard without being solely concerned with

their own agenda at the cost of other agenda items?

KE: Personally - I like folks that express themselves in terms of 'what's in it for me'. At least they are

being upfront about their agenda. Candidly, it is always better to express in terms of what service

people are getting and why this is beneficial, rather than dictating a process and set of templates that

are mandatory. Both are intending to achieve the same outcome - the former will get a better result.

However, sometimes you're just getting issues because people don't understand the details or are

afraid of bias, etc, etc. You may be better served to bring in an external facilitator in these

circumstances to break through the resistance issue.

Q: If the project has many stakeholders, how is the Requirements Management Plan

communicated - individually or as a group? If so, how much detail is necessary?

KE: Personally, I go for the group thing, but it depends on how many people are involved. Sometimes it

takes the form of a stakeholder briefing up front, sometimes it’s a formal written document, with clear

milestones and deliverable samples. The complexity and detail have to be context sensitive. Don't

shoot a mouse with a bazooka.

Q: I see organizations using DFSS (design for six sigma) methodology for business planning and

gathering requirements. What are your thoughts on it

For more business analysis resources visit www.iag.biz

KE: Well - there is no reason why you can't use DFSS - or the techniques of any other methodology -

outside the realm of requirements engineering that can be used. Just like we incorporate a lot of the

themes and principles of other methods (like 6 sigma) to build into our own methodology. In the case

of DFSS, it is a methodology that is designed to be "a systematic methodology to design products and

processes when a product or process is not in existence.”

It includes the following phases:

Define the project goals and customer (internal and external) deliverables

Measure and determine customer needs and specifications

Analyze the process options to meet the customer needs

Design (detailed) the process to meet the customer needs

Verify the design performance and ability to meet customer needs

I personally think that it's not ideally designed - in and of itself - for doing requirements gathering.

There are other techniques that are specifically designed for requirement elicitation that would be

faster to execute, give you better results, and still interact well with 6 sigma. There is no need to be

purist 6 sigma if it does not yield the optimal ratio of success - it would be against 6 sigma principles to

do this.