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.
For more business analysis resources visit www.iag.biz