What to expect when starting a project with Groove Technology (Part 2: Discovery and Scoping)

Part 2: Discovery and Scoping

Outsourcing software development to a third party can be fraught with risks such as budget risks, scope risks, quality risks and performance risks, to name just a few. Luckily, you can avoid all of these risks by partnering with a high quality, experienced software vendor. But how do you identify the quality vendors in an ocean of mediocre operators? The answer lies in the attention to detail vendors apply to the communication and processes necessary to understand your vision.

High quality vendors apply attention to detail to the communication and processes required to understand your vision

In the previous article in this series, we described the pre-sales process we apply at Groove Technology to identify your requirements at a high level, establish that we are an excellent fit to work together and propose appropriate solutions for your budget.

In this article, we will discuss the Discovery & Scoping process we apply to flush out the finer details and design a detailed solution. The goal of the discovery & scoping process is to tightly align your vision with what we will deliver so that there are no surprises on either side during the project’s development phase.

So, what is Discovery? 

The Discovery process is an opportunity for all of the project stakeholders on both sides to establish a shared understanding of the project’s goals and build the relationships, trust and agreement that will ensure the project is a success.

The process takes the form of a series of meetings or “discovery sessions” with discussions starting at a high level and with each subsequent meeting building on what was last discussed. We drill down further and further until the whole picture emerges and both parties are confident there is a consensus in what is understood. We will get the ball rolling by providing a series of questions for the customer to consider beforehand to be used as initial talking points.

There is no hard rule about who should be involved in the discovery sessions or how many people. The expectation is that the vision holder and decision-maker, which is typically the same person, would certainly be involved along with business domain experts, prospective users, customer side technology teams (especially if there are dependencies on customer systems), and anyone else the vision holder believes can contribute value.

However, the critical requirement is that a single person has the authority to provide final decisions, typically the vision holder. On our side, the Business Analyst responsible for the scoping work will be the primary contributor. There may also be a delivery manager, software architect, UI/UX designer and/or a project manager involved as well as anyone else we think will add value based on their expertise.

All of the project stakeholders will take part in the Discovery process

And then what is Scoping? 

Scoping is the formalizing of what is discussed and decided during the discovery process. The output of the scoping process is a set of detailed Functional Specification Documents that completely describe

1. What it is that the customer expects

2. What it is that we will deliver.

Both of these points need to be 100% in alignment before development starts; otherwise, surprises will arise, and the project’s success will be at risk.

The Business Analyst will perform the scoping exercise and begin concurrent to the discovery process, generally starting after the completion of the first discovery session.

The functional documents will go through a series of review gates to allow everyone to provide feedback and identify anything that has been misunderstood or missed.

What is included in the Functional Specification Documents?

The output of the Discovery & Scoping exercise is the Functional Specification Documents which will describe exactly how the system will behave for which users. Included in the functional specifications are:

Actors

The various types of users that will use the system and their motivation for doing so. 

User Stories

User stories describe every single goal that needs to be fulfilled for each actor to use the system. The user stories are the foundation in which the rest of the components of the functional specifications are built. An example of a very basic user story is “As a system administrator, I want to disable a user’s account”.

User stories define each specific goal for each actor to use the system.

Interfaces

Typically represented by a page on a web platform or a screen on a mobile app, emails and notifications may also be interfaces. Each interface must be associated with one or many user stories and details how they will be satisfied within the interface. including,

• Scenario 
  • The scenario that each actor finds itself in when it encounters the interface
• Actors
  • The types of users that may access the interface and who may not.
• Multiple Detailed State Wireframes
  • That illustrate exactly what elements will make up the interface.
  • There will be a separate wireframe for each possible state for the interface.
• Acceptance Criteria
  • To describe what will be accepted as satisfying each user story and how it relates to the interface.
  • The acceptance criteria will be the basis for the test plan in the development phase.
• Elements
  • A brief description of each of the elements on the interface such as forms, carousels etc.
• Calls to Action
  • A description of each call to action such as buttons, links, tabs etc.
  • The behavior of the interface when a call to action is executed.

User Permissions

A matrix of the permissions for each various actor and user role.

Notifications

A matrix of the system generated notifications, the actor who will receive them and the medium through which they will be delivered, i.e. email, push notification, etc.

Business Terminology

A glossary of business domain terminology and terminology created as a result of the discovery and scoping process.

Next Steps

Once the discovery sessions, documents, and review & feedback process have all been completed, we will have a finalized set of functional specifications representing 100% alignment in expectations between the two parties. We will then use the function documents as a basis for our work effort estimates and final quotation for the project’s development phase.