David and his team of programmers started working on this very ambitious software project with great fanfare in the office. It was the biggest project bagged by the marketing team so far and many believed that the software firm had reached its tipping point and from there onwards, there was no looking back.
When the brief was sent to him by the customer acquisition department he suggested that the cost of Discovery be included in the final quotation.
The marketing team’s response was that since the client was negotiating with multiple vendors, they didn’t want to do anything to jeopardize their chance of getting the project.
It was a $ 300,000 project that was to be completed in four months, and if they also included the Discovery phase, they would have to add another $ 20,000, and probably another month, and the team was already working on thin margins.
Reluctantly, David decided to go ahead with the project with the little information he had received.
Within a couple of weeks, everything was chaotic. The client suddenly demanded to see a wireframe about which he had read on another website.
While they were still trying to explain to him that they were beyond the point of the wireframe he started demanding a prototype. They tried to explain to him that they were already deep into coding.
Nonetheless, they quickly gathered up some modules to present to the client and when he went through them, he outrightly rejected them because this wasn’t what he had communicated.
Besides, he said that he wanted Ruby on Rails as the programming platform (his IT consultant friend had advised that) whereas, David’s team was using PHP.
Even the features that were listed by the client somehow hadn’t been conveyed to his team and the client complained that 60% of the features were missing in the prototype.
The coding needed to be started from scratch, adding an extra month to the project life-cycle.
In the absence of documentation and a blueprint, the programmers mostly worked in their own silos and used their own whims and fancies.
To make matters worse, after two months, the client came up with a new set of features that would totally change or alter the previous list. The entire backend would need to be revamped. 3 more months added.
Finally, it took them eight months to install a working version of the software. The entire list of features was still to be implemented and the client had already spent $ 400,000, with more costs in the pipeline. After spending $ 550,000, the client gave up, and the project was shelved.
According to The Standish Group Chaos Report, only 29% of software projects see the light of the day and the rest are either abandoned midway or are totally disastrous.
This Tech Republic article says that 86% software projects experience some sort of failure, due to various reasons.
Building a software that provides real-world solutions is a complex undertaking. Thousands of lines of code are written. Multiple programmers, sometimes sitting across the globe and connected through collaboration tools, have to collectively create a singular piece of software from start to finish.
Why do such Ambitious Software Projects Fail?
There might be thousands of reasons, but one of the most prominent reasons is the lack of discovery. Many stakeholders take this phase of the project development process very lightly and often, have to pay a great price for it.
In this blog post, you’re going to learn what is the discovery phase of a project development life-cycle and why it can be lethal to ignore it.
What Exactly is the Discovery Phase?
The discovery phase is a phase when you clearly define what you want to achieve through the project. During the discovery phase, you create the entire blueprint of your software development project.
During this phase, every team member who is going to work on the project gets to know
1. Why the software is needed
2. Who needs the software
3. What is the scope
4. User research and user behavior
5. How should “success” be defined for the project
6. What sort of competition the project has
7. What should be the interface features
8. What technology platform should be used to build the project
9. Desktop, Cloud, mobile-based or all platforms-based
10. Deadline
Coding, designing, and development doesn’t happen in this phase. A blueprint is created.
The discovery phase may also include
1. Brainstorming and analysis
2. Online and off-line research – going through white papers and case studies
3. Sketch of the interface
4. Wireframe of the interface
5. Mockup of the application
6. A prototype of the application
7. Confirmation of the blueprint and project go-ahead
Who is the Discovery Phase For?
The discovery phase is for all the stakeholders. If you are a software company, you will have more successful software projects under your belt. If you are an individual software developer, you will have greater work satisfaction and success rate. If you are a business getting the software developed for you, you will have a more efficient and economical product at your hand.
All said, the discovery phase can save you lots of time and money. An unfinished project doesn’t just cost you money and effort in the short-run, just imagine the number of opportunities you miss by not being able to implement and use your software.
What is Discovered in the Discovery Phase?
You can discover the viability of the project during the discovery phase. Aside from this, you can find out
- How is it going to stand up to competition?
- How is it going to serve the target audience?
- What is the persona of the individual software user?
- What are the intermediate and final deliverables?
- What is the philosophy that drives the inspiration behind the project?
- How is the interface actually going to look?
- Who are the actual stakeholders?
- What research data is to be trusted?
Different Activities that Take Place During the Discovery Phase
A typical discovery phase team may comprise of developers, designers, business analysts and other stakeholders who have a say in how the software is going to shape up.
The activities during the discovery phase will give you a total understanding of what is needed and how it is to be achieved. It helps you understand the problems being faced by stakeholders and how they expect the software application to solve those problems. These activities may include
Study of the Organizational Structure
The organizational structure defines the hierarchy within the organization, clearly defining who does what. By studying the organizational structure, especially if the software application is to be used by the employees of the organization, will allow you to prepare a map of different functions accessible to different members of the organization in the hierarchy.
All the stakeholders including those who will be using the software and those who will be designing and building it, are the key people who are going to get involved in the entire exercise.
Interviewing the Stakeholders
You would preferably want to speak to the CEO, the managing director, or some of the senior staff that knows what is needed and what is at stake. They will also be able to help you define the KPIs for the project.
If customers and general staff are going to use the software, it will also be prudent to talk to them.
When talking to different stakeholders make sure that you use their language and you can totally empathize with the problems they might be facing with their current setup or the lack of it.
Competitor Analysis
Studying and analyzing competition will give you a fair idea of how they have handled the various aspect of the same software product and its users. It will also help you understand the strengths and weaknesses of the existing solutions.
User Research and Understanding User Persona
Detailed user research gives you an understanding of how a typical user may interact with the software application. A big part of your success depends on how people are going to interact with not just the interface but also the various functions of your software.
In this stage, the discovery may go through the following stages:
- User interviews
- Creating the most ideal personas
- Creating user journeys – where they will begin and where they will end up interacting with your software
- Surveys – they make it easier for people to respond
- User needs – understanding exactly why the software application is needed
Internal Document Review
There might be a cornucopia of documentation available within your organization or the organization/business for which you’re supposed to build the software application.
You may have to access the company’s archives or the database. There might be different sources and you may have to find them out through contacts.
Internal documents shouldn’t be neglected because they are prepared over the years and the sort of information that they may contain, may not come to you through direct interactions with the stakeholders and prospective users.
Existing Research
Why re-invent the wheel? In many cases, lots of research data might already be available because many businesses commission researches or conduct their own surveys routinely to get the pulse of their employees and their market.
You may contact project heads of the people responsible for research, within the organization to get access to this data. It may save you lots of time.
Contextual Research
Doing contextual research means putting yourself in a situation that may require the use of software you are about to build. For example, if you’re going to build a software for a retail store, you should spend some time in a retail store and try to find out how the people at the counters interact with their software and how the software contributes towards creating an efficient work environment.
Also, make note of things that are missing or might be improved.
What are the Common Deliverables of the Discovery Phase?
1. Functional Requirements Document
This document contains the details of the requirements that are to be implemented in the software solution. It puts into words what the software solution is supposed to accomplish in terms of data manipulation, data processing and other real-world functions that will be performed digitally.
Functional requirements documentation may contain related information such as performance requirement, security details, and constraints within which the software application may have to function.
2. Technical Design
Technical design is going to be the backbone of your entire software development project life-cycle. It is the blueprint. Technical design, without hardcore programming, takes the problem, dissects it, and then turns it into a software solution, hypothetically. By the time you have the technical design ready, you have the entire picture in front of you. You just have to turn it into code.
3. High-level Project Plan
The high-level project plan maps the scope of the project with the budget and the timeline. It is mostly management-oriented and project managers and managerial stakeholders deal with the information within the high-level project plan.
4. Cost Proposal for the Larger Development Effort
The knowledge of the cost involved in the development of the entire software project as well as individual stages is critical both for the stakeholders as well as the team responsible for designing and coding.
An overall cost proposal will give the stakeholders an idea of how much investment will be required over the timeframe needed to build, test and install the software application. Further planning can be dependent upon your cost proposal.
The Team Needed to Optimally Run a Discovery Phase
User Researcher
A user researcher is someone who can extract himself or herself from technicalities and step into the shoes of the users who will eventually use the software application.
The primary responsibility of the user researcher is to understand what problems people are facing and how these problems can be solved using the software that is going to be developed.
He or she should be a good listener, a good communicator and someone who can empathize with people. He or she should also be comfortable with documenting people’s opinions and points of view.
Service Designer
A service designer can take all the available resources, technical assets, and opportunities and combine them into a workable software solution.
During the design phase a service designer may not create an entire software, but with him or her around, you will have the qualified person who understands the internal functioning of an enterprise-level software and during your various interactions, he or she will be able to grab the ideas and turn them into digital models.
Business Analyst
A qualified business analyst will help you understand the nitty-gritty of the business so that you can represent it through the software.
The business analyst can analyze an organization or business and help you document its various processes and systems so that it’s easier to understand them in terms of changing them into functional software modules.
UX Designer
User experience is going to be one of the most important components of your software. After all, everyone will be interacting with your software through the user experience.
Having a UX designer in the discovery phase can help you create meaningful sketches, mockups, and wireframes that you can brainstorm on with the stakeholders. Then finally, the UX designer will create an interface around which the entire application will be built.
How Long Does a Typical Discovery Phase Take?
Normally, 4 to 8 weeks – it depends on the scale of the software project one is undertaking.
You need to remember that a major part of the process takes place during the discovery phase. Once the entire team has understood what needs to be done, it can be easily built. If there is confusion, if there is lack of understanding, these are the attributes that will cause delays and disasters.
What Happens if the Discovery Phase is Not Included in the Software Project Development Life-Cycle?
The cost of not investing in the discovery phase can be monumental. The entire process can be thrown into disarray. The development may go on a tangent. The team members won’t be able to stick to the schedule because haphazard changes and alterations will be introduced. No one will have a clear direction. Your costs will escalate. The chances of having the workings of the application will diminish with every proceeding day.
Tips for having a highly productive discovery phase for your software project
1. Get the entire team involved: This way your designers, software programmers, project managers, systems analysts and user experience designers will be on the same plain and there will be no communication gaps.
2. Make sure you that you have a one-on-one interaction with the end users: This is a very important aspect of your discovery phase. The more you understand the end-user, the better will be the product.
3. Keep the channels of communication flowing among all stakeholders: Constant communication is a must. This will save you from surprises. It will also prevent costly mistakes from happening.
4. Consider discovery a separate aspect of software development with clearly-defined deliverables: The deliverables of a typical discovery phase are not tangible. These are not pieces of software code that the stakeholders and the customers will be able to see and experience. These are basically quality-control measures without which there is a minuscule chance of your project succeeding. It’s like the air: people miss it only when they can’t breathe. This is why it is difficult, and also, very important to consider it an inseparable part of software development.
Conclusion
As they say, “A good beginning is half the battle won,” as in the context of this blog post, the discovery phase is that “good beginning”. In the absence of a good beginning, things are going to go haywire, eventually and you will end up spending more money and more time than you had initially envisaged.
Our experience has demonstrated multiple times that if the requirements of the project are identified correctly before the actual coding and interface design work begins, it significantly reduces the overall project budget and also ensures the deadline is met.
Unfortunately, in an effort to save time and money (which is a misunderstanding), this aspect is overlooked. When people are trying to save time and money on the discovery phase, they are actually increasing the cost and delaying their project.
The biggest benefit of discovery is that you have almost full idea of the finished product before even the first line of code is written.
The entire blueprint is in front of you. You have the interface sketches, you have the workflow diagrams and you have the dry run results to see right in front of your eyes how the entire thing will shape up. This eliminates the scope for communication gaps, assumptions, and misplaced priorities.
Alphalogic has vast experience helping programming teams and businesses identify the core strengths and weaknesses of the upcoming project. We can help capture – visually as well as diagrammatically – the various processes, hierarchies, workflows, feasibility, deliverables, and dependencies so that you know what will be delivered, and the development team will know what is to be delivered.
Our discovery services can help you bring down development costs and shorten development time. Get in touch with us for a Free Quote.
Dhananjay (DJ) Goel is the CTO at Alphalogic, passionate about technology, startups, game of thrones and coffee. He enjoys working on challenging problems with innovative startups.