Discovery is the single most underrated phase of software development. Too often companies rush through the discovery process because they think they already know what they need. Then, halfway through development, they get blindsided by something that would have been easy to handle at the beginning but now threatens to derail the entire project.
The situation is all the more frustrating because—while it’s never possible to plan for everything—so much chaos could be avoided with a solid discovery. It’s like a flexible roadmap for development. Read on to find out why discovery is so important, how it fits with agile methodologies, and what good discovery looks like.
The value of discovery
Discovery is a journey of definition. This is when goals, expectations for success, and preliminary requirements are given measurable form. End users and stakeholders are identified. Sometimes prototyping and wireframing happens during discovery as well. It’s common to end by drawing up a risk assessment and a timeline to guide cost estimates.
More than 70 percent of development firms require discovery. It usually lasts anywhere from two weeks to a few months depending on the project’s scope. The more complex the project, the longer discovery should be. A modified 80/20 rule applies here: 80 percent of problems are from 20 percent of causes. Finding as much of that 20 percent in advance as possible saves a disproportionate amount of time and money.
The consequences of cutting discovery short can be substantial.
- Misaligned goals: The biggest risk is creating a product that doesn’t meet the client’s needs at all. This is a complete failure, and while it’s not common it can ruin a developer’s reputation.
- Incomplete requirements: When developers don’t have the full picture up front, they have to add features on the fly. That doesn’t leave room in the schedule for new requirements discovered naturally during agile development. The project then suffers from scope creep, blown deadlines, and inflated budgets.
- Unrealistic price estimates: Developers who work with incomplete requirements can wind up locked into an unfavorable bid.
- Lack of adoption: Users who weren’t consulted during discovery may not be interested enough to use the new software. The client’s investment is wasted, and the developer probably loses his or her customer.
Why otherwise smart people trip over discovery
If discovery is so useful, why do developers rush through it?
- Enthusiasm: Excitement to jump into an interesting project causes clients and developers to cut corners with discovery to get to the fun stuff.
- Overconfidence: Developers sometimes assume they already know the scope and needs of a project, especially when they’ve done similar projects before.
- Price and schedule: People tend to view time spent anywhere except actual coding as padding. They trim discovery to free up resources for “more valuable” tasks. That decision is based on faulty logic. In reality, emphasizing discovery is the single most impactful thing companies can do to keep software development projects on track.
- Misunderstanding agile methodologies: Agile is about small, functional goals, failing fast to learn what doesn’t work, and pivoting to embrace shifting priorities. A longer discovery process outwardly seems out of place with that philosophy. However, information promotes agility. Thorough discovery provides the foundation for making better choices in response to change. It helps to think of discovery as a warm-up sprint instead of wasted time.
Case study in discovery failure
FoxMeyer’s failed ERP system is a classic example of how much damage insufficient discovery can cause. It’d planned a $35 million efficiency-boosting SAP and warehouse automation system project. Unfortunately, poor discovery set the project up for failure from the start.
For one thing, the development timeline was unrealistic. There was no room for any changes or repositioning. When the company took on a new contract mid-project, the software suddenly had to stretch to meet requirements that were far outside the original scope. It was woefully underpowered for the task.
Part of the problem lay with tool selection. FoxMeyer’s development partner didn’t do enough research and recommended early adoption of a system that processed less than one-fortieth the number of orders the old system could handle.
Only after the system began rolling out to users did the company realize it lacked the experienced talent to operate it. It turned to its contractor to fill the gap but still couldn’t muster enough technical experts to run training.
FoxMeyer neglected to seek stakeholder support, too. IT led the project without considering expert advice, users, or the potential effect on the community. Workers who feared for their jobs actively opposed the software’s rollout. They ignored incoming orders and implementation tasks, and even went so far as to actively damage product. More than $34 million in inventory was lost or damaged.
The ERP failed hard, and it took the company with it. In 1993 FoxMeyer was the fifth largest drug distributor around, with a $5 billion valuation. By 1996 it was bankrupt and sold for a paltry $80 million. There’s no reason this should have happened. The vast majority of problems should have been anticipated during discovery, when FoxMeyer had plenty of time to make adjustments.
What good discovery looks like
Every project is unique, but in general there are four phases every discovery process should include.
- Research answers to the questions that define the project’s goals.
- What problem should the software solve?
- Is there anything else like it on the market, and if so how is this different?
- Who are the users and stakeholders?
- How broad is the project’s scope? When is it needed?
- What technology best addresses the problem? Will this be a mobile app, desktop software, or something else?
- Gather requirements. Work with stakeholders to generate ideas, then order features by priority. Having priorities in place helps developers make the best use of unexpected time and reorganizations. Construct use-case diagrams to guide the design. Lay out a flexible timeline of what can be done when, noting the best and final points for certain features.
- Sketch the information architecture and build wireframes. What can the client expect to see? How will it work? Does this meet their expectations?
- Clarify the initial and stretch goals and gain final approval. The project will change with a client’s needs, but it’s critical to have an idea of the intended direction and scope up front. Know what success looks like and how to tell if things are going wrong.
Agility requires preparation
Cutting discovery short is like hitting the road after only a brief glance at a map. Developers have a general idea where they’re headed and know how to find food or lodging, but they’re unprepared for detours. They wind up paying more for last-minute hotels, missing opportunities for side trips, and showing up later than they wanted. The result is a bad vacation—or to step outside the metaphor, a bad software development process.
This article is published as part of the IDG Contributor Network. Want to Join?
