Analysis Planning

There are rather simple business problems, and analyzing suitable solutions to them could be easily managed by a single analyst. Since, in such cases, there is no communication within the analysis team, and the overhead is minimal, it is not necessary to create a formal plan of how to carry out the analysis. In contrast, there are significant changes that involve complex process modifications and information systems updates. These projects could include dozens of people, and even the analysis itself could be a many-month and many-person activity. In such an environment, the analysis cannot be done ad hoc. It must be first clear who will be involved and how, who will be the decision-makers, what will be the overall analysis approach, how the whole activity will be timed, and what outputs it will produce. It is all part of the analysis planning. Despite the word "planning," it is not a one-time activity performed just in the beginning. Planning typically occurs more than once to continuously address changing conditions as the team is gaining more detailed information.

Stakeholder Analysis

The first step of the planning is figuring out who the stakeholders are relevant to the change, meaning who do we need to talk to understand the requirements. It involves identifying all entities that are possibly impacted by the change. There is nothing worse than to be approached by a very influential person bringing crucial requirements, right after the whole analysis finished. Being agile and welcoming change is one thing, but being ignorant, not doing stakeholder analysis properly and missing core information which could have been easily spotted in the beginning, is another thing. There are various classes of stakeholders, such as software end-users, subject matter experts, sponsors, senior managers, project managers, developers, operations staff members, auditors, and others. These are all important for the smooth run of the project. They will typically not be all known right from the beginning so that analysts will be identifying them on the go. But in the beginning, the analyst should be at least aware who the sponsor is and who are the right people to help understand the business problem and the constraints.

Stakeholder Engagement

An essential part of stakeholder analysis is understanding the roles of the individual parties in the context of the change, their level of power and influence, type and frequency of collaboration and communication with them. It should be analyzed why the stakeholders are essential for the change, how the change influences them, or how they will participate.

Analysis Governance

On an average project, there are many various stakeholders with different opinions and priorities, and it is therefore not very likely for such heterogeneous groups to always reach an agreement. As a result, it will be necessary to decide who will be responsible for setting priorities and who will approve changes - to create a governance process.

A governance process describes how approvals and prioritization decisions are made for requirements and designs.
(source: BABOK)

Analysis Plan

Analysis plan defines what analytical tasks will be performed, by whom and when they will be performed, what will be analysis deliverables, and how formal they will be. An analysis plan is typically created just for bigger projects where the amount of stakeholders, communication, and outputs is significant enough to justify the overhead and formality connected with creating and following the plan.

The overall method that will be followed when performing analysis work is called analysis approach. It defines how and when analysis tasks will be performed, fundamental techniques to use, and the deliverables that will be produced. Depending on the environment, the approach could be lightweight, creating rather informal artifacts, focusing on personal communication and collaboration, or it can be more rigid, following a formal process and producing predefined documents. Or it could, of course, be anything in between. The selected approach depends on the type of organization, on the development process chosen, level of uncertainty on the project, the number of stakeholders, and the size of the change. The general trend is to move more and more towards the lightweight approaches, but the concrete situation should always be assessed before selecting the analysis approach.