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.
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.
