Analyzing a proposed business change is a vital skill for business analysts, as it helps them evaluate the feasibility, impact, and value of a potential solution. In this article, you will learn how to apply a systematic approach to analyze a business change, using some common tools and techniques.
The first step in analyzing a business change is to define the problem that the change is trying to solve. You need to understand the root cause, the current state, and the desired state of the situation. You can use techniques such as problem statements, fishbone diagrams, and SWOT analysis to clarify the problem and its scope.
The most critical considerations when analyzing proposed business changes is: 1. Objective Alignment: Ensure that the proposed changes align with the overall objectives and goals of the business. 2. Cost-Benefit Analysis: Assess the potential costs and benefits, including financial, operational, and strategic implications. 3. Risk Assessment: Identify and evaluate potential risks and uncertainties associated with the proposed changes. 4. Stakeholder Impact: Consider how the changes will affect various stakeholders, including employees, customers, shareholders, etc. 5. Legal and Regulatory Compliance: Verify that the proposed changes adhere to applicable laws and regulations.
Identifying the root cause and not hovering around with pre conceived notions of available solutions in our kitty is so important. Having patience and re evaluating the root causes multiple times helps a lot to come to a conclusion which leads to a solution.
One thing I’ve found helpful when analyzing a proposed business change, it's crucial to define the problem effectively. This involves crafting a clear problem statement, identifying root causes, analyzing the current state, defining the desired future state, setting the scope and boundaries, and conducting a SWOT analysis. This comprehensive understanding of the problem serves as the foundation for evaluating the proposed change and determining its feasibility and impact.
Define the problem as best as is possible. In the modern world, a failure to accept the complexity of our system, the environment, and the pace at which others are generating is perhaps one of the leading causes of unsuccessful business planning/exploitation of opportunities. Spending too much time analysing and planning, often means lack of real world feedback. We should definitely define the problem, but engage broadly and deeply, move quickly and fail fast. More will be learned about the problem by engaging directly with it, than sitting in a room and analysing it. Analysis and learning should become an integral part of the continuous process that supports successfully overcoming the challenge.
The next step is to identify the stakeholders who are affected by or involved in the business change. Stakeholders are the people, groups, or organizations that have an interest, influence, or dependency on the change. You can use techniques such as stakeholder maps, RACI matrices, and power-interest grids to identify and prioritize the stakeholders and their needs, expectations, and concerns.
The third step is to define the requirements that the business change must meet to solve the problem and satisfy the stakeholders. Requirements are the features, functions, or characteristics that the change must have or perform. You can use techniques such as interviews, surveys, workshops, and user stories to elicit, document, and validate the requirements.
This is the most critical step. Execution can be remediated etc, but the requirements ultimately determine the success of a project once it is fully delivered. Don't rush past it. In a Technical Solution design, the requirements can be reused many times. They can become user guides, test cases, use-cases, integration test cases etc. Requirements are critical regardless of the methodology. I know Agile prefers working software over documentation, but the sprint needs stories/deliverables that communicate the functionality required with hints on paths forward if helpful.
The fourth step is to evaluate the alternatives that can meet the requirements and deliver the business change. Alternatives are the possible solutions or options that can solve the problem and achieve the desired state. You can use techniques such as feasibility studies, cost-benefit analysis, and decision matrices to compare and rank the alternatives based on their benefits, risks, costs, and alignment with the business strategy and vision.
Please involve the actual stakeholders (customers and users). Too often there is a representative appointed that lacks familiarity with the end-user or an understanding based upon limited perception of what they are used to rather than the wider market. Evaluation itself is an art-form struggling to be a science and experience certainly helps as well as involving a diverse set of people with different perspectives. It is easy to state that Decision-Making should be driven by data, but of course data can be manipulated. I would say though that decisions should be augmented by data at the least, and this data should be heavily validated.
The fifth step is to recommend the solution that best meets the requirements and delivers the business change. The solution is the chosen alternative that provides the most value and addresses the problem and the stakeholders' needs. You can use techniques such as business cases, solution proposals, and prototypes to present and justify the solution and its expected outcomes, benefits, and impacts.
It does not have to be a solution, but rather a path to solution. A Proof of Concept or Minimum Viable Product. It is better to document the requirements and KPIs that can be tracked like Required ROI and Timeline than come up with a solution. This is methodology agnostic, so it does not matter whether Agile, Waterfall or Hybrid. Too many projects underachieve or outright fail as they lock in a solution without fulling understanding what is needed. A project that delivers on time and on budget something that no-one wants is perhaps the worst type of failure as it could have easily been avoided. Delivering sub-optimal outcomes is far too common.
The final step is to plan the implementation of the solution and the business change. The implementation is the process of executing, monitoring, and controlling the solution and its effects. You can use techniques such as project plans, change management plans, and risk management plans to define and manage the scope, schedule, budget, quality, resources, communication, and risks of the implementation.
The Rolling Wave Technique is a project planning and management approach, where detailed planning is done for the near-term activities, while the planning for future phases is kept at a higher level of abstraction. - Iterative Planning: In the Rolling Wave Technique, project planning is done in iterations or waves. - Detailed Planning for Near-Term: During the near-term phase, the project team goes into detailed planning. - Higher-Level Planning for the Future: For the phases beyond the near-term, the planning is kept at a higher level of abstraction. - Detailed Planning as Phases Approach: As the project progresses and the near-term phase becomes the current phase, the planning for the next near-term phase becomes more detailed.
To analyse a proposed business change. 3 questions I am following: 1. Qualify the problem need a change? Why the existing process could not naturally catch the problem? How frequent and Size the impact? 2. Rationalise the root cause finding? Are the root causes really address the problem? Controllable vs uncontrollable factor? 3. Practicality check on the solution ? - Does the solution fix the root cause? - Would it create any unseen challenge? - Does the investment/cost justify? - If invest on technology, does it compatible to existing portfolio and no loophole in operation? - Stretch in resources? - Impact to dependent processes (internal/external)? - Compliance? - Transparency? Remaining are project management routine!