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:
Business requirements
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.
Background
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.
Business opportunity
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.
Business goals and objectives
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:
- Increase MAU by 100,000 points over the quarter
- Increase customer satisfaction rate by 20% by March 8th
Success criteria
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:
- Set milestones. A thorough understanding of project success expectations allows project managers to define clearer objectives and track the team's progress toward ultimate goals.
- Keep project risks to a minimum. Project success benchmarks help project managers identify risk factors and take proactive steps to mitigate those risks.
- Increase engagement. Defining and measuring project success promotes engagement among the project team and other stakeholders as all parties become more motivated to work toward a common goal.
- Establish transparency. Project success criteria help improve transparency among stakeholders by ensuring everyone understands the project's expected outcomes.
- Improve future projects. This exercise will help you collect valuable feedback that can be used to increase your chances of success in future endeavors.
We recommend defining success criteria based on your business objectives, as the latter has already been specified; for example:
- MAU is higher or equal to 400,000 on October 12th
- 15 help desk employees at the company on December 31st
- Employee satisfaction rate is higher or equal to 84% on March 8th
🧠 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.
Customer or market needs
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:
1. Consider your past experiences
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.
2. Observe behaviors
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.
3. Conduct interviews
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.
Business risks
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:
- Strategic risks, like a new competitor entering the market.
- Compliance and regulation risks, like the implementation of new rules or legislation.
- Financial risks, like an increase in interest rates on your business loan or a non-paying customer.
- Operational risks, like the breakdown or theft of critical equipment.
Any business analyst professional worth their salt should also provide solutions or mitigating actions to manage potential risks.
Vision of the solution
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.
Vision statement
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.
Major features
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.
Assumptions and dependencies
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:
- AD-1: The application design will be developed based on the functional features and technical requirements of the development team.
- AD-2: The project is not expected to change significantly in terms of functional features. Otherwise, project cost and time may vary considerably from the original estimate.
- AD-3: The design and functional content of the project will be approved by the client. The client is in constant touch with the development team.
- AD-4: It is expected to connect third-party paid services (such as Firebase, Twilio, etc.) for the correct operation and analytics of the application.
- AD-5: The existing database will be transferred from the currently used system.
- AD-6: For the Spanish version development, the client will provide the translation of all texts.
Scope and limitations
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.
Scope of initial and subsequent releases
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:
| Feature | Release 1 | Release 2 |
|---|---|---|
| FE-1: Order food |
|
|
| FE-2: Display and let users add/remove ingredient list | Not implemented | Implemented |
Limitations and exclusions
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.
Business context
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.
Stakeholder profiles
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:
- Core value
- Attitudes toward the product
- Primary interests
- Constraints
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:
Responsible (R)
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.
Accountable (A)
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.
Consulted (C)
Subject-matter experts that provide essential information to complete jobs. They usually interact directly with the relevant parties.
Informed (I)
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 |
Project priorities
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:
- Constraint — a limiting factor the project manager deals with;
- Driver — a significant success factor with limited flexibility for adjustment;
- Degree of freedom — a factor in which the project manager has some latitude to adjust and balance against the other dimensions.
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 | ✘ |
Operating environment
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:
- Are the users widely distributed geographically or located close to each other? How many time zones are they in?
- When do the users in various locations need to access the system?
- Where is the data generated and used? How far apart are these locations? Does the data from multiple locations need to be combined?
- Are specific maximum response times known for accessing data that might be stored remotely?
- Can the users tolerate service interruptions, or is continuous access to the system critical for the operation of their business?
- What access security controls and data protection requirements are needed?
Related: Why is a discovery phase crucial for your project's success?
Final thoughts
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.
