Skip to main content

A Guideline for Discovery Phase

When you start working on a service in the discovery phase, you can easily get lost if the service has many features. However, the discovery phase is an important and sensitive phase of the development process. Skipping this phase can lead to incomplete services in addition to new bugs and unreported features during the development phase. However, not doing the requirement gathering and documentation in the right ways would lead to the same consequences. You need to take your time researching all the requirements, and do not leave any questions unanswered.

So, how to collect the requirements in the right way? How to cover every corner of the service? Sometimes you need to dig deeper into the services and ask questions that the client can not remember for the time being. 

How long does the discovery phase take?​

It usually takes 2 to 8 weeks, but it can take more than that, depending on the project. However, in the discovery phase you should take your time with researching the service. Because, it is crucial to understand the service very well, and collect the right requirements.

Where to start your research?​

Follow these steps throughout your research. While going through the steps, do not assume any detail of the service and skip steps. 

1. Find the problem​

At the very beginning of the research, you must know what is the problem with the current service, then ask for details of the service. Knowing what the problem is will help in understanding the situations your client is going through, and it will lead to a better solution.

2. Define the objectives of this service​

Now that you know what is the problem of the current service or the client is going through, you have to define what are the objectives for this project. The objectives later can be used as a metric for how far you have come to solve the problem in the discovery phase. Later on in the development can also be used to see if the service is achieving its purpose.

3. Find the stakeholders​

Find out who all the users of this service are? What are their roles? And What is their responsibilities? Finding all the stakeholders is important, but finding the right ones will lead you to a better understanding of the service. Who are the right stakeholders? Users who are heavily involved in the service, the ones that use the service almost all the time and know exactly how it works. These stakeholders need to be interviewed in detail, because they have faced every disadvantage and advantage point of the service.

Key points​

  • Who uses this service?

  • Find the right stakeholders (The one who uses the service the most)

  • What is their role in the service?

  • What is their responsibility?

  • Build a mind map representing all the stakeholders

4. Research the service​

After finding all the stakeholders, you need to go through the service with them, and ask questions on any actions you don't understand. Especially researching the right stakeholders, you need to take your time with them, and ask detailed questions. It is important to take those requirements from the stakeholders and turn them into user stories, because they are fresh in your mind, you know why these requirements are needed, and how important they are. Use the template for user story in the documentation guideline. After you write all the user stories, build a flowchart representing the workflow of the current service, and try to re-engineer the workflow until you come up with a workflow that meets the objective of this service. When you find a solution for the current service workflow, design a new flowchart according to the documentation guideline for the newly proposed workflow. While re-engineering the current workflow, you have to take the KRG rules and regulations into consideration that will be mentioned in the next step.

Key points​

  • How does the old service work?

  • How do they want the new service to be?

  • What are the tasks of the users in the current service?

  • What will be the tasks of the users in the proposed service?

  • What is the purpose of each task?

  • Turn the requirements into user stories

  • Build a flowchart for the workflow of the current and proposed service

It is important to understand the legislation for building this service. It will help you in coming up with the right solution for the problem, or in deciding whether to push this project into the development phase or not. These constraints can be:

  • Processes that can not be improved (e.g. paper based processes)

  • Legacy systems

  • Legislations

  • Contracts

There are constraints that can not be changed and constraints that can. Primary legislation or contracts is an example of constraints that can not be changed, you have to find a solution that can work with those constraints. Paper based processes are an example of constraints that can be changed, you can turn that process into a digital process. It is important to deliver the best possible service and not just work around the constraints, that is why you have to push the client for changes in the constraints in certain situations.

This step will help you with:

  1. Whether to forward this project to the development phase or not.

  2. Prioritizing the requirements.

Key points​

  • What are the KRG rules and regulations related to this service?

  • Which of these rules will be removed or amended when changing to the proposed service?

  • Will there be any new KRG rules and regulations added to the proposed service?

  • How do the rules and regulations affect the proposed service?

  • Why do these rules and regulations exist?

  • Are there any paper based processes? And how can we improve that?

  • Are there any legacy systems that are used for this service?

  • Are there any contracts that prevent this service from improving?

6. Share the document with the clients​

After you have done your research and documented all the requirements, share all the documentations with them. It is important that you go through the documentation again with the clients, to make sure that you have everything documented and all of them are correct.

Key Points​

  • Go through the flowchart with the stakeholders

  • Do not make any assumptions in the requirements, make sure the requirements are correct

When to stop discovery phase​

At the end of discovery there is two decision available to be made:

  • You have enough requirements to start building a viable product that fits the users needs, and move the project to the development phase.

  • It is time consuming to solve the problem at the moment or there are some constraints that prevent us from improving the service, and the project will not be moved into the development phase.

To make sure it is the right time to move the project forward into development phase, keep these key points in mind:

  • You understand the context of the service, constraints, problem, and the user's needs.

  • You have documented the solution and enough requirements to hand it over to the Development team.

  • Those requirements and solutions are confirmed by both the client and the discovery team.

If at the end of the discovery phase you came to a conclusion that the project should not move forward to development, it is okay to stop and save time for other projects that have more priority.

Now that you have been through all the steps,  you are ready to prepare the final document using this template with the help of the documentation guideline. It is mandatory for you to use the template for documentation and follow the guideline for ease of understanding the service by the development team.