Pre-development research activities tend to cultivate an air of mystery. Business analysis, the discovery phase, the vision and scope document, and other research efforts are optional paraphernalia in the eyes of business owners and customers. However, no matter how flawless your product quality is or how complete your project requirements are, you still need to make sure the application fits the market and user needs.
Here’s when the vision and scope document steps on the scene. This document is a single source of truth that details market needs, business risks, project objectives, and other crucial input to start your product development appropriately.
So, let’s look into the outline of the document:
A significant part of the vision and scope document is dedicated to business requirements. These requirements highlight the broad outcomes of the development project, define its business needs, and describe the criteria for the project's success and other business-related objectives. Let's have a closer look at this section.
A business analyst usually includes a general description of the background or situation that led to the decision to create the product. Here, a few words about the company, the client, and the domain they work with are enough to set the tone.
If you're building a corporate information system, a business analyst describes the business problem this product solves, the business processes it is required to improve, and the environment in which the system will operate. Alternatively, if it's a commercial product, your business analyst describes its existing market opportunities and the target market.
This section may also include a comparative evaluation of existing products and possible solutions, indicating the product's appeal and advantages. Here, we describe the problems that cannot be solved without the proposed solution.
Moreover, this section explains how the solution fits market trends, technology developments, or corporate strategy. We briefly describe other technologies, processes, or resources needed to meet the customer's or target market's needs.
In the Business Opportunity description section, a business analyst presents the customer challenges the new product will solve and provides examples of how customers will use the product. Any known critical quality or interface requirements are also specified here, excluding implementation and design details.
This part of the document is written in cooperation with the client. Here, we outline clear business goals and objectives that the company aims to achieve with the new product.
Business objectives are predetermined milestones that the company or entrepreneur intends to achieve over a certain period of time. These are the waypoints to the company’s main business goal.
A business goal is usually expressed as the company's mission. A stated mission is considered a broad goal as it lacks a single criterion for success. Unlike KPIs, broad goals are frequently used as a guiding star for your team, indicating the right direction instead of hinting at a numerical value.
To give you a complete picture, here are some industry-best examples of business goals:
"Bring inspiration and innovation to every athlete in the world.
*If you have a body, you are an athlete."
Nike
"Organize the world's information and make it universally accessible and useful."
However, you can also establish specific, measurable objectives that are easy to track as the team works toward them. We recommend applying the SMART methodology to set defined objectives that can be attained within a certain time frame.
For example, your business objectives may look as follows:
As teams progress through the project, well-defined success criteria will help them measure their progress and ensure that they're meeting pre-agreed expectations.
Defining and measuring project success will also help your team to:
We recommend defining success criteria based on your business objectives, as the latter has already been specified; for example:
🧠 Pro tip: When preparing your success criteria, use the resulting value only (“15 employees at the department” instead of “the number of department employees has increased by ten people”). This way, you’ll have a clear objective.
Along with your business objectives, a vision and scope document also defines what your customer has in mind and how it relates to your digital product. A customer need refers to a set of specific requirements that a customer has for your software product to solve a particular problem. Customer needs vary by the stimulus and include functional, social, and emotional needs.
Another way to understand customer behavior is to think of it within the framework of the Jobs-to-be-Done theory. Pioneered by Professor Clayton Christensen of Harvard Business School, this theory states that people don't just buy products; they "hire" them to do a specific job. Therefore, a job to be done is a shorthand for what a customer strives to accomplish with a product.
By understanding the job that someone is trying to do, you can create a better product that meets their needs. But how can you better understand the job that needs to be done? Here are three strategies that help get a better handle on your customer needs:
The first method for identifying jobs to be done is to reflect on your behaviors and experiences. This allows you to see patterns in your decision-making process, step into your customer's shoes, and set a base for further research.
Along with pondering your own experiences, you should also pay attention to the behaviors of those around you. Start by analyzing the behavior of individuals at each stage of the purchasing process, from the moment the job to be done arises to the choice they make. Then, note what objectives or difficulties the product helps users achieve or eliminate by looking at how they use the product.
Pay attention to compensatory behaviors or activities users follow when a product doesn’t meet their needs. You can find an unmet market need and generate ideas for filling it by understanding the task at hand behind inconvenient alternatives.
Another alternative is to engage other people in your brainstorming session. To supplement your observations, you can interview current, former, and non-customers to learn more about their decision-making process.
Using this method, your current customers will explain the rationale behind their purchase and why they chose you instead of competitors. Former customers can provide insights into why they abandoned your company and highlight potential areas for improvement. Non-customers can elaborate on why they didn't need a particular product or opted to buy from a competitor.
Since the main opportunities and goals for the business have already been described in the paragraphs above, it is also necessary to mention the actual risks that may cripple project implementation.
The four major types of business risk are as follows:
Any business analyst professional worth their salt should also provide solutions or mitigating actions to manage potential risks.
This section focuses on the future state of the solution itself. The Vision of the Solution section must also describe customer and stakeholder needs along with the features and capabilities expected to satisfy those needs.
A vision statement is a brief, aspirational description of the highest ambitions of your product. It articulates what the organization hopes to achieve with the product and acts as the software product's compass.
More specifically, this subsection has to contain information about end users, the problems they face, and solutions to said problems. We recommend documenting your product vision statement based on a template proposed by Geoffrey A. Moore in “Crossing the Chasm:”
For example, let’s write the Product Vision Statement for the Nike Training Club app we mentioned earlier in the article:
For every athlete (from the previous Business Goals and Objectives section, we already know that every human is an athlete) who doesn’t want to hire a personal trainer, the Nike Training Club is a fitness application that provides intentional, progressive workout programs with specific nutrition, recovery, and mindset tips along the athlete’s way. Unlike the Sweat app, which also provides recorded workout programs and wellness tips, our product, Nike Training Club, is totally free of charge.
Keep in mind that both apps are used for demonstration purposes only as an example of the Product Vision Statement.
To create a compelling vision of the future product, you should also include a numbered list of its major features. Put a greater emphasis on those that set your product apart from previous or competing products. These features can be linked to specific user and functional requirements.
In this paragraph, business analysts usually prepare a list of assumptions made while developing the project and writing the vision and scope document. They take note of any significant dependencies on which the project relies for success, including specific technologies, third-party vendors, development partners, or other business relationships.
Below, you can see some examples of possible project assumptions and dependencies:
In the Scope and Limitations section, you define your product's broader capabilities and boundaries, including features that will make it to your product. This information provides a frame of reference against which business analysts can evaluate proposed features and changes in software requirements.
To understand why teams version features, you first need to know what a minimum viable product (MVP) is and why you need it for sustainable product evolution. An MVP is a test version of a product or service with a few core features (often only one) that still creates value for the end user. MVPs are built to test ideas and validate the viability of a product, as well as its value and marketability.
By building an MVP first, you can collect feedback from the target audience early in the development. Customer insights can give you confidence in your product idea and identify necessary strategic changes. Therefore, before the development kick-off, the business analyst, project manager, and client must identify the core features to include in the first MVP version and plan features for future releases.
The Scope of Initial and/or Subsequent Releases of a project is typically described as a list of features, but they can also be defined in terms of user stories, use cases, use case flows, or external events. In some circumstances, combining the items in a single table may be even more convenient; for example:
This section lists any features or behaviors that project stakeholders may expect but are not intended to be included in the project scope or a specific version. It is critical to identify the project's boundaries by listing the most evident aspects that are not included.
This section outlines profiles of major stakeholder types, software project management priorities, and a review of the scenarios to consider when planning the product’s launch.
Stakeholders are those involved in the project at any stage of its life cycle whose input can have a direct impact on the outcome. Therefore, you need strong stakeholder management and ongoing communication to establish stable and fruitful collaboration among all parties.
Profiles of stakeholders are typically loaded into a separate table with additional information such as:
Below, you can see an example of stakeholder profiles for a cafeteria:
| Stakeholder | Core value | Product attitude | Primary interests | Constraints |
|---|---|---|---|---|
| C-level | Improve staff productivity while lowering dining costs | Strong support up to release 2; support for release 3, depending on results of previous releases | The cost savings must exceed the cost of developing and using | N/A |
| Cafeteria employees | More efficient use of employee time during the day; greater customer satisfaction | Worries about union relations and potential staff layoffs; everything else is fine | Workplace maintenance | The necessity for online staff training; the need for people and delivery transportation |
Another way to describe stakeholders within the target audience along with their roles is to use a Responsible, Accountable, Consulted and Informed (RACI) matrix. A RACI matrix is a tool used to map out the roles and responsibilities of individuals or teams within an organization. It is a highly recommended methodology for determining roles and responsibilities as well as assigning tasks and milestones to the team members.
Let’s go over each component mentioned in the RACI matrix:
Hands-on front players that complete the task. Hence, each assignment, activity, or decision needs at least one Responsible, but complex tasks may need more than one doer.
Final approving authorities that are ultimately responsible for reviewing the correct and thorough completion of the deliverable or task. These are also masterminds that delegate the work to those responsible. You should only assign one Accountable per job to avoid confusion.
Subject-matter experts that provide essential information to complete jobs. They usually interact directly with the relevant parties.
Informees that need to be kept “in the picture” in terms of project updates. Each task, along with the project outcomes, has a direct impact on the Informed, although they do not contribute to the project directly.
Here is an illustration of a simplified RACI model for an example project:
| Team | Product Management | Design | Marketing |
|---|---|---|---|
| Jane | R | A | I |
| Alex | A | I | C |
| Max | R | C | R |
| George | R | I | C |
| Tina | C | R | R |
| Carol | I | R | A |
To make informed and effective decisions, all stakeholders must agree on the project's priorities. To get your priorities right, you should keep in mind five major dimensions every project is constrained by: features, quality, schedule, cost, and staff.
For any project, each dimension typically falls into one of three categories:
To articulate the project priorities, you can create a project priority matrix. Below, we've shared an example of the matrix for your convenience:
| Dimension | Constraint | Driver | Degree of freedom |
|---|---|---|---|
| Features | ✘ | ||
| Quality | ✘ | ||
| Schedule | ✘ | ||
| Cost | ✘ | ||
| Staff | ✘ |
This section describes the environment in which the system will be used, including major availability, reliability, performance, and integrity requirements. To gather the necessary input for this section, you should answer the following key questions about the target operating environment:
Software development has a raft of challenging aspects. Project management statistics attest to the complexity of digital product development, as only 34% of companies complete their projects on time and within budget. To improve the prospects of digital projects, you need clarity, concerted effort, and a rock-solid vision of your future product cemented in the vision and scope document.
The vision and scope document sets the direction for the project and ensures that all stakeholders are aligned on the same objectives. This document also helps identify risks and potential issues early on in the project, saving you time and money later.
If you need a helping hand with your project planning, Orangesoft experts are always there for you. Reach out to us, and we’ll get your project going — the right way.
