Do I Need a Project Discovery Phase?
#MVP #business analysis #project management
What is the Project Discovery Phase?
Project owners who believe they have a fully formed idea and developers who want to start coding may question the need for this phase.
Performed correctly, the discovery phase of a project encompasses critical tasks for the project's success, including requirements capture and verification, proof of concept, and feasibility study.
This phase of a project is the point in a program where the developers ensure that they understand the problem that the created service is looking to solve. It encompasses the process of turning an idea into a product, a problem into a solution.
This phase establishes a complete set of requirements. Before it can begin, the discovery phase requires collating all relevant project materials to be effective. This information gathering is the Pre-Discovery Phase.
Pre-Discovery Phase Activities
The goal of the pre-discovery phase is to prepare for discovery, gathering all the information required to inform the discovery stage activities.
It requires no original research activities but draws upon existing research materials. The discovery phase cannot begin until, as a minimum, the project establishes the business driver for the service and identifies a service owner.
Typical pre-discovery phase activities include:
1. Identifying the main business drivers for the project:
- What is the purpose of the project?
- What is the project trying to achieve?
- How does the project fit into the broader landscape?
- What is the value proposition?
- What are the success criteria?
2. Identifying the target audience:
- What are their demographics?
- What are the user needs and expectations?
- What are the competing services?
3. Gathering insights from existing comparable services:
- What policies and processes are in place?
- Is performance data available?
- What technology maps exist?
- Are any user feedback and insights available?
- Are any customer service records available?
- Is there existing market research available?
4. Identifying the stakeholders:
- Who is the project owner, the person responsible for delivering the new service?
- Who is the service owner, the person placing the order?
- Who will administrate and maintain the service?
- Are any subject matter experts required?
- Who are the end-users?
5. Identifying all relevant constraints:
- Are there any budgetary constraints?
- Are there must meet dates or preferred timescales?
- Are there any resource constraints?
Once the gathering of available information is complete, the discovery stage proper can commence.
The Importance of the Discovery Phase
There is no point in building a new service if the problems that the service is aiming to solve are not known and understood.
The success of development projects often comes down to delivering a solution that the market is looking for, exactly when it needs it. An imperfect solution provided at the right time may attract initial sales, but these will fall once better solutions expose the deficiencies. The perfect solution delivered after competitors have saturated the market won't attract those initial sales.
Software development projects often overspend and deliver late, some so catastrophically that they cause the development company to fail. Proper project planning can significantly reduce the chance of failure and increase the project's likelihood of completing on time and within budget. The software discovery phase provides the foundation for proper project planning.
The critical questions that the discovery phase should answer are:
- Who are the users of the service?
- What do the users want to achieve?
- How do users currently achieve this?
- What pain points do users currently experience?
2. Service Owner:
- What does the service owner wish to achieve?
- What are the target markets of the service?
- Are any regulative and legislative constraints relevant to the service?
- What technological constraints will affect the service?
- Will legacy services impose constraints?
- What existing policies and processes will impose constraints?
4. What are the possible pain points?
5. What are the opportunities for improvement?
The material collated at the pre-discovery phase will support the answers to these questions, but original research and stakeholder engagement will be necessary to produce complete solutions.
The discovery phase must have clear and agreed goals. These goals will ensure that all questions have been asked, they all have answers, and everyone knows when the phase has been completed.
Discovery Phase Goals
The project must have a tightly characterized scope, defining what the service is required to do and, importantly, what it is not required to do. The main driver for the scope definition is an understanding of the users and their behaviors.
- A benefit of understanding the user's context and behaviors is the opportunity to spot improvements. Developers can carry forward these opportunities for improvement to the later development phases,
- Another benefit is the opportunity for later development phases to be cognizant of any predicted and pain points.
The discovery phase in software development programs is particularly crucial in bringing in cross-domain viewpoints into what can sometimes be a discipline with a narrow field of view that focuses on detail at the expense of the bigger picture. It reduces the risk of effort spent producing software features with little marketplace demand.
The conclusion of the discovery phase is ultimately the decision to proceed with development or halt the project. This decision rests on:
- The viability of the service,
- The cost-effectiveness of the service.
The output of the discovery phase is a set of key deliverables that underpin the development phases. A complete and comprehensive collection of project discovery phase deliverables will make development quicker and more straightforward, reducing the risk of show-stopping issues and functionality gaps.
Deliverables must meet a duality of purposes. First, to provide stakeholders with sufficient information that sets out the feasibility, or not, of the proposed service. Second, provide the technical and management foundations for the development process documentation that supports traceability from the business drivers through user and system requirements and onto the software requirements and design decisions.
1. System Requirements Specification (SRS)
The SRS describes the service in terms of the goals it will meet, the features it will include, and its required behavior. Requirements can be functional (defining expected behavior in response to events) and non-functional (attributes of the service). Typical content includes:
- Project description setting out the business drivers and model that the service will implement,
- Process and information flows and state diagrams as applicable,
- Service goals ranked by user importance,
- Features List, broken down into primary features that are necessary to meet service goals for a minimum viable product (MVP) and secondary features that support or augment primary features as future planned enhancements,
- Technology stack required to operate the service, including an architecture overview,
- Constraints that inform the development process and assumptions upon which the discovery phase outputs are dependent,
- Acceptance criteria agreed between service owner and developers.
2. Preliminary User Experience (UX) Design
The initial UX design documents the results of the prototyping and user engagement activities and forms the baseline for the UX design process in the development phases. Typical content includes:
- User and usability requirements,
- Prototype wireframes where available,
- User feedback and insights to prototype wireframes where applicable,
- Branding and style constraints that inform the UX design process.
3. Discovery Phase Plan
The project plan generated by the discovery stage provides the first opportunity to establish reliable scheduling and financial metrics. Typical content includes:
- Resource requirements in terms of team member skill sets, numbers, and utilization,
- Development timelines that identify dependencies between activities that determine the ordering of tasks,
- Schedules that identify the critical paths in timelines that determine delivery dates,
- Spend profile over schedule linked with staged budget availability, related to investment and revenue stream availability where applicable,
- Milestones where the service owner agrees staged payments,
- Communications strategy detailing stakeholder engagement, progress reporting, and review processes,
- Project risks and opportunities, managed over the project lifecycle.
Running a Discovery Phase
The discovery phase is composed of discrete activities. It is crucial to approach each step of the discovery stage in the correct order to achieve the best results.
1. Identify and engage all the stakeholders. A typical list includes:
- Service owner,
- Service administrators,
- Service maintainers,
- End users,
- Subject matter experts,
- Marketing specialists.
2. Arrange stakeholder meetings to discuss and agree:
- Project scope,
- Business drivers,
- Target markets,
3. Review the knowledge base generated by the pre-discovery phase and identify requirements for additional research, such as consumer engagement, marketplace analysis, and competitor evaluations.
4. Conduct research activities to establish user requirements and business needs for the service. The use of techniques such as mind mapping can help visualize user journeys and define their goals.
5. Explore the UX options and opportunities. This step of the software discovery phase can deliver the most significant results in gauging user appetite for the planned service and its marketplace potential.
- Define the user journeys that satisfy the user requirements,
- Define the feature sets that the user journeys require,
- Create UX prototypes and refine them using user feedback.
6. Identify a complete list of assumptions, dependencies, constraints, including but not limited to business, technology, operational, financial, regulatory limitations. Review to confirm their validity and resolve conflicts.
7. Identify program risks and perform a preliminary risk assessment to identify any additional requirements and constraints needed for risk mitigation.
8. Define project timelines and resource requirements, generating a budget estimate from the resource utilization metrics.
9. Finalize, review, and quality assure the key project discovery phase deliverables.
10. Hold a stakeholder meeting to agree on feasibility and green light the discovery phase plan.
The effort expending on the discovery phase should be proportional to the overall project scaling. The greater the investment being made into the service, the more effort should be invested into the discovery phase. Similarly, a low-cost rapid development project will not be significantly improved by devoting more effort than necessary to the discovery phase.
The main benefit of project discovery is establishing an agreement between all stakeholders that the proposed service is what the service owner wants, what the end-users need, and what the developers will produce.
Eliminating misunderstandings, ambiguities, and misconceptions before development starts is the best way to reduce the likelihood of the project failing. Each stakeholder will bring a different understanding of the problem and a different set of skills to solving it. The list of stakeholders must be complete, covering all possible viewpoints.
Often projects have unspoken assumptions or unwritten requirements that cause issues at the end of the development phases when stakeholders realize the MVP doesn't do what they thought it would do.
Coming into a project with preconceived ideas such as a technology stack or an implementation method can often stifle innovation and miss the opportunity to take a different path that may have been quicker or cheaper to develop or deliver a better solution.
The discovery phase activities will help establish all the requirements, constraints, and assumptions upfront in forms that enable universal understanding and reduce the opportunities for failure.
- Ensure the requirement set is complete; there are no undocumented requirements that are not recognized until the development is ongoing, leading to costly redevelopment activities that delay the program,
- Ensure the requirement set is coherent; there are no conflicts between requirements that will require resolution upon the detection of a disagreement during development that will need a solution,
- Ensure the requirement set is correct; there are no misunderstandings or uncertainties about precisely what was meant, leading to the implemented function not doing what was intended. Ambiguity can be a particular issue with the use of natural language constructs to define requirements.
A firm scope and complete requirements set eliminates the potential for creep to extend timelines and consume budgets.
The problems that the service is looking to solve often need to be reframed and broken down into statements that do not pre-define a solution or rely on unchallenged assumptions and pre-requisites. Take the following example:
- The service needs an interactive map that shows directions to the nearest hospital.
This statement assumes the use of a map that needs to be interactive. Rewriting this as follows can allow exploration of other possible solutions:
- Users may need to locate the nearest hospital,
- Users may need directions to the nearest hospital.
Risk identification, analysis, and mitigation is an essential part of the project lifecycle. The earlier risks are identified, the easier and cheaper it is to eliminate them or reduce them to acceptable levels. The discovery phase facilitates this process.
The discovery phase of a project removes uncertainty by defining clear goals, forming a firm requirements baseline and features list, identifying risks, establishing the project's viability, and setting reliable development timescales and budget needs.
The conclusion of the project discovery phase provides the opportunity to make a fact-based go/no-go decision for the development phases.
It lets you know if a service will deliver a return on investment before development rather than afterward.
#development #mobile application #web applicationSeptember 30, 2021
#development #mobile application #web applicationSeptember 28, 2021
Rapid application development has always been a popular choice for delivering prototype code quickly to evaluate application concepts and feasibility and on the fly development of requirements.
Its main benefits for application development are the speed and flexibility to accommodate customer changes during the development cycle cost-effectively. In addition, the modular approach to code structure also brings maintainability and reuse benefits.The rapid application development model is fantastic where its use is appropriate, and it has plenty of advantages over other development processes.
Getting the Most from Customer Feedback of your MVP
MVP feedback is essential to improve a minimum viable product and customers are integral to this process. Here, we will consider everything you need to know about getting customer insight to improve your MVP. Getting input from customers helps you to maximize learning.
Time to Market (TTM) – What is it and why does it matter for my business?
Time to market (TTM) refers to the amount of time from the moment of conceiving the idea about a product through to launching the final product or service to customers. The term can also be used for the time for a new marketing campaign to get to market, or for a new process to go live.
How a Proof of Concept (PoC) Aids Development
Bringing a new idea to the market can be full of risks. The significant issues may be that the concept doesn’t work in practice, or the target audience doesn’t want it. A Proof of Concept (POC) is a faster and less expensive solution to testing the feasibility of an idea.
Agile or Traditional? Forming the Right Software Development Team Structure
One common factor identified as the cause of failure of several IT projects is an inefficient software development team structure. In this article, we delve into how an Agile team differs from a traditional structure, along with exploring common software development team roles and responsibilities.