Solution Scope – An Insight

1. Understanding Solution Scope

Most of the projects inevitably struggle at some point or the other if the scope is not defined properly. The right note to start a project is to have a clear Project and Solution/Product scope at hand. It is very critical for a Business Analyst to clearly understand and define the Solution Scope in black and white before even going into the Requirement Elicitation phase. This article focuses primarily on key aspects of understanding and defining Solution Scope in traditional methodologies.

1.1 Project Scope & Solution Scope

The Project Scope generally depicts the “Scope of Work” for a particular project. Project Scope refers to the work that must be performed to deliver a product, service, or result with the specified features and functions. It is created by the Project Manager and driven by the project objectives.

The “Solution Scope” is purely related to “What” is included in the solution (functional & non-functional features, other characteristics etc) and is not focussed on “How” the solution is delivered. It refers to set of capabilities a solution must deliver in order to meet the business need. A business Analyst is the creator and owner of the Solution Scope.

It is often recommended to define Solution Scope prior to defining the Project Scope as it gives more clarity to the Project Manager in terms of complexity, risk associated, likelihood of success and creates a basis for estimating project cost and timelines.

1.2 Understanding Business Needs & Required Capabilities

This is first step for defining a high level Solution Scope. At this stage the Solution Scope is defined based on business needs and high level business requirements. This information may come through a formal RFP, an informal discussion with the customer, a problem statement or as part of recommendations/findings from a consulting exercise. The challenge for a BA is to create a well defined Solution Scope based on this minimal information available. However the key to solve this problem is to clearly understand the business needs, capabilities and conceptualize a solution which can address them based upon the information provided. Asking right question becomes important at this stage. A BA should take initiatives to ask right questions and validate the understanding with the stakeholders such as Domain SME, Implementation SME, Project Manager, Business Owners, and Sponsor.

In a formal RFP process there is generally a stage where vendors are allowed to send questionnaire for further clarification on scope and requirements. As there is limited time and information for defining scope, special caution should be taken to structure the questions. Too many open ended questions can lead to further doubts and confusion and too many close ended questions may lead to devoid of additional information. A right mix of questions should be smartly stated for addressing the focus areas.

It is to be noted that Assumptions, Constraints and Solution Approach are also inputs for defining a solution scope and are equally important to get validated by the stakeholders. The goal should be to create watertight scope using materials collated from the above inputs. Any crack or hole in the scope may lead to scope creep that can impact the overall project cost and timelines to a great extent.

After the requirement elicitation and analysis the high level Solution Scope evolves into a detailed scope and requirement specifications and the blurred scope boundary becomes more distinct and clear.

2. Defining Solution Scope

A Business Analyst should model and define scope in a way that it provides enough details to address the business need and capabilities. This will help stakeholders to visualize the solution and understand how the solution will deliver the required capabilities. This also becomes the guidelines for requirement elicitation when the BA actually works on capturing the detailed or low level requirements.

Imagine a BA entering a large dimly lit building at mid night with a torch to capture information about doors, windows, furniture, wall hangings and even nuts and bolts. He needs to also come out from the building before the sunrise. Without knowing which floors and which rooms to enter, the BA may get lost wondering where to focus the torch and what to capture. It’s a bit scary but that’s exactly how difficult an elicitation exercise can become if the solution scope is defined without much clarity and details.

The Solution Scope is usually defined in Scope statements and Scope Model. The Scope Statements describe the scope boundaries and address “What” is included as part of the solution deliverables. Scope statement should be written in very simple and concise manner to avoid any ambiguity. The Solution model can be a Context or a Data Flow Diagram which depicts the interfaces, boundaries and the key processes in the solution. It is highly recommended to use both options (Scope statements and model) to define and depict the solution scope. It gives two different views of the scope and helps stakeholders to relate them with the business needs and objectives and understand the entire scope in a better way.

2.1 Scope Statements

• In-Scope: These statements define what components, capabilities, interfaces, organizational units and processes are included in solution. If a solution is implemented in phases or iterations, the In-Scope statements should be described with respect to each phase or iteration.

• Out-Of-Scope: Some Business Analysts are hesitant to define Out-Of-Scope items as it can be anything under the sun and might not be relevant. At times it can be annoying to stakeholders as well. However it is very important that these statements are defined along with the In-Scope statements to crystallize the scope. These Out-Of-Scope items can be identified by visualizing the bigger picture and taking off items which are somehow related to the solution but are not covered in the scope. These can also be potential requirements which can become a part of the scope in future. This will provide more solidity and prominence to the scope boundary and will minimize the risk of scope creep.

If you imagine Solution Scope as a box, the In-Scope items will fall inside the box and Out-Of-Scope items will be outside the boundary of the box. It is comparatively easier to indentify organizations units, core capabilities, interfaces within and outside the box. However more often than not there are grey items (Borderline) which are tricky and difficult to identify as In-Scope or Out-Of-Scope items and more importantly their impact on the entire solution. These items can be related to certain capabilities or features which have little visibility while defining the scope. It is recommended to target these items with right questions to the stakeholders or look for assumptions which can justify their existence as In-Scope or Out-of-Scope items.

Apart from the In-Scope and Out-Of-Scope items a BA should also clearly state the following items as part of the Solution Scope.

• Assumptions and constraints which are taken into considerations while defining the scope

• Business or technical dependencies which are related to solution components or its implementation

• Risks associated with the Solution Scope

An internal Risk which is identified during solution scope definition should be immediately brought to the notice of the Project Manager. It can eventually become a Project Risk and there should be appropriate strategy in place to mitigate the risk.

The Framework for Solution Scope including key drivers, enablers, components and factors is depicted below.

2.2 Scope Model

Scope Models provides a visual model for depicting the scope of a solution. It helps to create a single and high level view of the boundaries of the scope and its associations with external entities. Scope Modeling can be done using Context Diagram or Data Flow Diagrams (DFD).

It is recommended to have a Single Scope diagram (either Context Diagram or Level 0 Data Flow Diagram) however if need be a Context Diagram can be supported or expanded into multiple DFDs. The BA should decide on the right level and details on Solution Scope under a give scenario based on stakeholder expectations.

The Scope Model can also be depicted in terms of Use Case Model or User Stories.

2.3 Checklist for Verifying Solution Scope

• Does the Solution Scope address specific business needs and objectives?

• Are the Solution Capabilities in Scope mapped / aligned with the business objectives / high level requirements / problem statement?

• Does it define In-Scope and Out-Of-Scope items?

• Does it address Assumption, Constraints, Dependencies and Risks?

• Does it have enough detail for stakeholders to understand and validate the scope?

• Is the Solution Scope defined in a clear and concise way? Is there any ambiguity in the scope statements?

The BA must get the Solution Scope approved by the sponsor / customer after the verification and validation exercise is done. This will ensure a structured approach to manage scope in case of any issues or conflict during the phases of the solution implementation.

3. Managing Solution Scope

Change is inevitable! The Solution Scope must change if there is a change in business need and objectives. Stakeholders may also add or modify solution capabilities / requirements at any given of time in the solution implementation lifecycle. It is very critical for a BA to manage scope in a way that it has minimum impact on cost, schedule, quality of the solution and the overall engagement with the customer.

The scope changes can be broadly classified into two types.

• Change in Business Need - If the Business Need is changed it may have a huge impact on the Solution Scope. The BA need to create a new scope or modify the existing scope to incorporate the change. It is advisable to go through the complete lifecycle for re-defining the scope (Understand – Define – Validate – Approve) for such scenarios. This may again change the Project Scope and overall cost and timelines.

• Change in Capabilities / Features - If the Business Need and Objectives remain unchanged and new capabilities / features are added or existing ones are modified, the BA needs to evaluate whether these changes are aligned with the business requirements or not. Accordingly the BA can identify the changes as In-Scope or Out-Of-Scope items. In case of conflict the BA need to facilitate an agreement between stakeholders where either the business requirements and scope will be modified or changes will fall outside the scope of the solution.

The scope change need be managed under the Change Control or Change Management process defined in the Project Charter. It is also essential for BA to understand what value a change is bringing to the solution and to the stakeholders. Focus should also be given to indentify alternatives which can address a change with minimal impact on the scope.

4. Conclusion

Defining Solution Scope requires a constructive and collaborative approach. The BA should involve stakeholders to understand and validate the context and scope of the solution. It requires lot of facilitation and analytical skills. Also selecting right techniques and tools becomes important for identifying and defining the scope. Some of the techniques for defining scope can be Functional Decomposition, Interface Analysis, Scope Modeling and User Stories.
A BA needs to wear multiple hats to question and justify each aspect of the scope. It is not a rush through task and needs sufficient time and thought to draw the correct scope boundary.

4.1 Recommendations

• Manage Expectations – Managing stakeholder expectations along with scope is the right strategy for success.

• Be Proactive – Proactively identifying changes and communicating with relevant stakeholders can help a great way to manage issues and conflicts related to Solution Scope.

• Get Approval – Every change in scope should be validated by the stakeholders and approved by the sponsor.

• Avoid Scope Creep – The BA should always be careful in dealing with changes. Any change should be questioned, challenged and evaluated in the right context. During Requirement Elicitation and Analysis phase the BA should give extra focus to ensure that coverage of the scope is fully established through requirement specifications and models. Deep knowledge of customer environment, business models and emerging trends also helps BA to anticipate future changes and build right strategy.

• Document & Communicate Changes – Proper recording, tracing, tracking and communication of scope changes is a must for avoiding issues and conflicts.

Author: Suman Das, CBAP

Suman Das, CBAP, has over 12 years of experience in Business Analysis in Travel, Transportation and Hospitality industry. As Manager Consulting at InterGlobe Technologies he drives designing of business solutions and services and mentoring of Business Analysts as part of BA Academy.