In Part three of this six-part series of articles, we will continue to explore the basic skills and concepts of business analysis (BA). In this section, we will review and analyze the business analysis planning process. As we stated in Part one, there are a variety of techniques and tools suggested by PMI that should be in your business analyst toolkit.
“The Planning domain focuses on the preparation required to effectively manage the business” that will occur within the project (PMI, 2013). This process involves determining the “tools, policies, and procedures needed for the requirements management plan, requirements traceability, change management, document control, and acceptance criteria” (PMI, 2013).
In this article, we will describe the five basic tasks involved in the planning process:
1. Review the business case
Business analysis activities need to have context. They are best provided by reviewing the business case and project goals. When building the business analysis plan, the business analyst should include an explanation as to how prioritization will be conducted for the project. Some common factors to consider when defining the prioritization process are:
- When requirements prioritization will occur
- The likelihood that priorities will change
- The stakeholders that will be involved in the prioritization process
- The techniques that will be used for prioritization
- The criteria that will be used to prioritize
- The stakeholders who will approve the prioritization decisions
Projects using predictive or waterfall lifecycles will conduct prioritization up-front before product construction begins. Priorities may still shift in a waterfall project, but incorporating such changes are more difficult than in a project that utilizes the iterative development cycle.
Requirements are prioritized based on a number of factors such as:
- VALUE – First identify any valuable requirements for financial or goodwill.
- COST – Evaluate requirements based on financial costs or opportunity costs.
- DIFFICULTY – Consider how difficult the requirements will be to fill.
- REGULATORY – Address any regulatory or legislative requirements that have impending compliance deadlines first.
- RISK – Implement high-risk requirements first to flesh out any issues early on.
2. Define a strategy for requirements traceability
In order to provide traceability so that the project team will understand the impact of the project as it relates to a change, traceability tools and techniques must be defined and documented immediately. The goal here is to make sure the change assessment is correct and will help keep the project guidelines in order.
Understanding the project context, the type of project, and any organizational processes or compliance standards that are required, the business analyst must document the traceability approach in the business analyst plan.
The types of traceability decisions a business analyst should consider are:
- The types of requirements that need to be traced
- The level of detail to trace
- The relationship that will be established and maintained
- The requirement attributes that need to be tracked
- The requirement states that drive the requirements lifecycle
- The tools that will be used to perform the traceability
- The process for any decisions concerning how traceability will be established and maintained
3. Identify requirements
In order to create a roadmap that will deliver the expected solution, the business analyst will need to ensure proper requirements management. This can be accomplished by defining the answers to questions who, what, when, and how.
Two business analysis activities that often confuse stakeholders are requirements verification and requirements validation. Requirements and associated requirements models are both verified and validated.
Conducting a structured walkthrough provides an opportunity for the business analyst and stakeholders to collaborate and to ensure the requirement as stated is clear and correct. Requirements validation ensures that the requirements accurately reflect what the project is expected to deliver and that the right product is being built.
4. Develop a change control process
For projects that use a formal change control process, the business analyst should consider documenting the approach so that stakeholders know how to request a change and how the impact of those changes will be assessed. Change to requirements may involve a change in scope; a restated business objective, or “the addition or deletion of features to the product or service” being developed (CRAM, Wilterdink, 2016); therefore, the business analyst will need to determine how requirements documentation should be updated once a change is approved.
Consider the following types of information when defining a requirements change control process:
- How the requirements changes will be proposed
- How the changes will be reviewed
- How the change management decisions will be documented
- How the requirement changes will be communicated
5. Identify and implement document control procedures
Business analysts should consider the following when planning the business analyst documentation:
- What documentation will be produced
- How will the documentation be used
- How will changes to the documentation be managed
- What is the level of required formality of the documentation
As we discussed the planning process is an important part of a business analysts job; it involves five major tasks which includes reviewing the business case, defining a strategy for requirements traceability, identifying requirements, developing a change control process, as well as identifying and implementing document control procedures.
Stay tuned for part four of this six-part series which will discuss analysis.
Similar Content:
Part 4 – Basic business analysis skills and concepts: Analysis
Business analysis planning considerations
How to develop an effective change management plan
Jerry Foley, PMP, PMI-PBA, PMI-ACP, RTPM, CCNA, MCSE, ITIL has over 25 years of Enterprise Project Management experience. His expertise is in multi-million dollar, multi-year IT Infrastructure projects for municipal, healthcare, and military clients, and Fortune 500 companies. He lectures and teaches PMP prep classes, serves as a board member of the local PMI Chapter, and participates in the PMI Day of Service for non-profits. A former Marine, Jerry’s teams benefit from his creative solutions, passionate leadership, and implementing his “improvise, adapt, and overcome” tenacity for successfully completing his projects. Jerry writes about Business Analysis and Document Management.
