One of the least understood components of the SDLC model is the Discovery phase. As is common with many concepts which are difficult to grasp, it is often cut, particularly by companies that are non-technologically oriented, and who wish to reduce the bottom line on a large project. Undermining the importance and details in this phase, many such companies will jump right to project planning and estimation phase with a vaguely defined Request for Proposal.
A common pattern in such initiatives involve the following:
- Too many stakeholders with ideas being passed around and noted down.
- Lack of prioritization (“Everything is a priority”).
- Lack of a clear product-market fit.
- Urgency to go to market with “something”.
- The belief that they already know what they want. Hence, no budget allocated for planning.
- Belief that a single developer can build it in a week.
They have a list of bells and whistles that they have seen on other sites, and just want a quote for the project. Many design and software development agencies are willing to adapt to this. Give the customer what they want, right? And by doing this they can cut a significant amount of the early expense and enable them to underbid their competitors. It’s a win-win, right? The client gets what they asked for and the agency gets the contract.
What’s the Problem?
The more the above pattern holds true, the more vague the RFP becomes, the project will have a higher chance of having scope-creep, budget overrun and unexpected delays. Most importantly, it will be less scalable and maintainable in the long run. This particularly happens for any project that has a potential development span of more than 6 months.
As the common phrase goes, “you get what you pay for.” However, in the case of large projects, without a thorough discovery and analysis phase, often the client won’t even get that.
Client gets what they asked for, but it may produce nothing of value
Maybe the site comes in cheaper than expected. Unfortunately, just on time and under budget does not necessarily mean that it is a “success.” It is possible (if not likely) that the client had done too little advance work on their own, and ended up paying for a product that is not equivalent to the sum of its parts. Maybe the project came in cheaper than quoted by other firms, however it produces no value to the target market or to the business itself, and the money spent becomes wasted and they realize that it needs to be re-developed.
The project faces cost-overruns resulting in mediocre results
This commonly occurs in cases where the contract is fixed-price. The amount bid is too low to handle all of the details requested and the details that are missing but expected. The client and the vendor have not understood the nature of the technical requirements. In the process of trying to get the contract, the vendor underbid the cost of the work. While the project is completed to the provided specifications, the quality ends up being lower than it could have been and a lot of details are missed out from “unwritten” expectations. It does all of the things, the client stated they wanted (in general), but the development is weak, or buggy, and it falls flat.
Inarticulate goals create scope-creep sending costs far above initial estimates
The actual goals or desires of the project are not necessarily well-articulated in the initial request period. Without vision, projects can easily lose focus and can spend too much time on unnecessary details. In this case, the client may be willing to pay an hourly rate, however the project starts to lose focus; new features are introduced in the middle of the project, resulting in more hours spent.
Problems arise that have not been anticipated, so that adds to the time. The client ends up with a behemoth of a site, that tries too hard to be too many things, and lacks true purpose. Because it never knew what it wanted to be in the first place, the result is an expensive project that confuses the end users, and may not even deliver what the client wants, to its users.
Project provides no outward gains for the client
This can happen even with extremely well-designed and functioning sites. The project was built, and is highly impressive in itself, however the target market was missed. Without any understanding of the desires of the end-users, or the nature of competition, or even that the project itself may have had no outward appeal, this can become a real possibility. The project becomes a nice feather in the cap of the vendor, however the client achieves no positive outcome, other than having spent capital that may have been better focused.
The Importance of a Discovery Phase
Creating a well-structured Discovery Phase can avoid the problems above and make a huge difference in the success of a project. Before even starting any development or even a Product Requirements Document (PRD), it is extremely important to understand not only how to construct this document, but to also examine the feasibility and scope of what is to be built.
A well-run discovery phase provides:
- Vision and goal
It looks at not just what the client asks for, but what they actually want. It analyzes the drivers behind the project. In other words, it goes beyond the specifications a client might bring to the table and helps identify the short-term and long-term goals of the product.
- Market Research
Analysis during this phase involves performing market research and competitor to determine the product-market fit. Does it already exist? Does the target market want this, or at least would they want this if they have it presented to them? This exercise also includes prototyping quickly to test the needs of the users by making them interact with it.
- Accurate Development Costs
The discovery phase helps clients understand better what the costs involved are going to be. As they are involved deeply in the planning process with experts in the agency, they can get many of their questions answered and arrive at a budget that is not only more accurate but can be very granular.Often, with limited technical knowledge, it is hard to realize as a client which features could be more expensive and ultimately may or may not meet their business goals. Alternately, they may not be able to recognize that there may be ways of achieving what they want in a much more effective manner than they thought possible. Working with a vendor with a detailed understanding of technology, combined with a solid level of research and knowledge of how to achieve these goals, can help the budget to be managed more efficiently.
- Phased Rollout Plans
Prioritization is key in any product development and is best performed in the Discovery Phase. Although the initial analysis of the product-market fit can yield promising results, it is very important to prioritize features to form a Minimum Viable Product and perform phased roll out. This streamlines the process of learning from the users and iterating accordingly. Also, it will tremendously help to keep the budget under control.
- Better Budget Planning and Allocation
Results from the discovery phase can provide a itemized view into many components and it is much easier to plan the budget according to individual roll out phase and resources needed.
- Better Team Buy-in
Processes in discovery phase are mostly based on interviews, thorough analysis and user mental modelling, which ensure a much better alignment of expectations among stakeholders and significantly reduce the likelihood of scope creep.
Through this process, there is always a likelihood the the project may not be feasible given the budget and goals of the client. By building a Discovery phase into a project, while there may be some up-front expense, the research involved combined with the technical costs could result in discovering the original plan may not be something that would provide an optimal cost-benefit ratio based on existing goals. This would enable a client the opportunity to choose an alternate solution instead of going down an expensive rabbit hole.
Result of a Discovery Phase
The final result will be a detailed Product Requirement Document – PRD. Ideally a well-structured PRD should be something that is portable and has value in itself. It is something that the client, if they so choose, could issue as a supplement to an RFP and get bids from any vendor.
One of the most important points is that because this phase of the project is paid, there is no conflict-of-interest for the firm providing the research to overly inflate the value of the project. If it turns out for any reason that the project contains a high risk factor, or is not feasible, this information should be explained and demonstrated to the client. While it is not up to the agency to make the final decision, the discovery phase enables an agency to accurately and honestly communicate the results to the client.
Important Roles in a Discovery Phase
With everything said above, to create true value to a client, it is important to meticulously examine each of the details during the discovery phase and to communicate this to the client.
Ideally, a discovery team should include the following roles at a minimum:
- Marketer/User researcher, who will be responsible for understanding those in a target market. Ideally this will involves creating everything from focus groups to using existing market data, to analyze what it is that the target market desires or needs in relation to the client’s goals.
- Business Analyst who will gain a full understanding of the client’s business itself, ranging from the operational functions, to its relationships with its shareholder.
- UX Designer takes the information given by the customers and convert into a user-friendly design concept.
- Technical Architect performs technology exploration according to the given scenarios and client’s internal expertise and finds ways how to best architect the system for scalability, maintainability and cost-effectiveness.
In some cases, these roles can be handled by multiple people, however, depending on the nature of the project it will need at least the above roles.
While many businesses may balk at paying for a discovery phase, the results for saving money in the long run far outweigh not having one at all. Development is focused specifically to meet the overall goals of an organization. Projects stay focused, and are far less likely to run over budget, and if for some reason projects are not feasible, the risk of creating a money pit of a website which is not successful is reduced drastically.