“Before you start building a product you need to define how the product has to be, all its functionalities, features, capabilities.”
This statement seems to apply only to a waterfall approach but in reality it applies to any type of implementation independently from the approach that will be used. Every project starts from a list of requirements: business users meet together and list what they need. Needs can be new functionalities, enhancements of old processes, simplification of as-is processes and solution. The requirement matrix is the starting point of any project. Often the first question a customer has will be: how much will it cost? When can this be developed?
Discovery phase is the time when a customer is asked to go through all the requirements and when the challenging will take place: what is the desired behavior? What has to be achieved? Can this be simplified? How would you like this behavior to be implemented?
As a result of this phase, the solution is fully designed and documented and both customer and solution provider are in agreement about the exact scope, the timelines and the cost of the project.
The internal requirements gathering process carried by a Customer to produce a requirements matrix sometimes is made of isolated phases and meetings and, as a result of this, often the customer is missing a full view of what is intended to achieve or the understanding of the requirements is spread across multiple stakeholders within the organization. Client organizations might be themselves unclear about their objective: within a company different departments will want the same new solution for different reasons. If there is no alignment among all the stakeholders, the project is going to fail.
Can the common view and understanding, which usually come at the end a Discovery phase, be reached earlier? Can a project be scoped before starting the Discovery and the landscape defined in advance? Can the alignment among all stakeholders be built sooner rather than later?
“Before you start building a solution you need to build up a picture of what the context for that solution is.”
Portaltech Reply have identified a new way to approach a project before the Discovery is started. The new approach is to support an organization’s thinking by helping them understanding the scope and the landscape of a particular project.
The new first step in the engagement with an organization is to layout the scope, objectives and to create a common and shared understanding of the requested solution. These goals are achieved through an intensive workshop called Flesh Out Discovery. A team of experts (a system architect, a business analyst and a project manager) with the deep knowledge of related business solutions spends up to six full days in workshops with all the stakeholders to define the landscape and understand the context for the solution. These meetings take place at client site to get a better understanding of the client’s situation by observing more of the client’s organization and the day-by-day operations.
The purpose of the Flesh Out Discovery is not to discuss all the requirements already identified by the customer one by one, but to let the users tell what they do and what they’d like to do and for them to listen to anyone else activities and needs. Knowledge and requirements sharing among users who eventually have not spent time together is the only way to create the context of the possible to-be solution. Sometimes, consensus was achieved through diagrams and outlines on a whiteboard. Key was the daily review of everything discussed with the users to agree on Portaltech Reply understanding.
On day one of Flesh Out Discovery, the team will draw the boundaries for the workshops’ scope: team will ask the customer representatives (individuals from all levels of the client organization) to divide the solution they are looking for into the processes that have to be fulfilled and map them into some areas that will be discussed in the following days. Also the team will try to identify and remove all the barriers which naturally are there: each user will be asked to list all the concerns and constraints that he/she feels; those are the barriers that the solution provider will have to consider during all the meetings, giving the customer the confidence that none of the expressed concerns are ignored at any time and that all the discussions are happening to identify a solution that will address all the concerns together with the requirements.
On the next days, the team will ask the business users to walk through all the processes identified, areas by area: the team will ask them to describe on high level how their processes work, which are the challenges they face on a daily basis, what they would like to have. The team will take notes and will bring ideas and examples, will ask for reasons without proposing any alternative solution.
Last 10 minutes of each workshop is for all the users in the meeting to review the common understanding that has been built so far: the team will walk everybody trough the notes, creating a continuum with the original scope defined on day one. Every day the team will map the notes taken with the requirements provided by the customer: this activity has the objective of validating the requirements itself and estimate those based on the technology that will be used.
Last two days are left to the team to build a hypothesis of plan based on what has been discussed with the customer together with a high level estimation.
What is the benefit for a Flesh Out Discovery?
From a customer perspective there are several benefits:
From a solution provider point of view, the biggest benefit is to deepen the understanding of business needs by talking directly to the business users without exploding all the requirements but looking at the processes for each of the main important areas.