If you are one of our potential clients, it’s likely that you have been around the block and have heard the term “discovery” more times than you can count. The discovery process is the first step taken in moving from a prospective client to an actual client; it’s the time when a professional digs in deep, asking pertinent questions and figuring out what the client is seeking.

From what I can tell, this is becoming a standard in our industry. Why? Because building software (websites, apps, et al) is hard. One of our industry’s running jokes is that every project will be under-scoped and over-budget.

According to Hofstadter’s law, “It always takes longer than you expect, even when you take into account Hofstadter’s Law.”

This truth is magnified when estimates are requested before understanding the entire scope of the work needing to be done.

There are actually many reasons projects go over budget or time — some positive and some negative:

• A key requirement is missed during the requirements-gathering phase.
• A simple line-item balloons into days of work (For example,”Import items through ACME API” turns into days of digging through a massive API ebook PDF)
• Crucial information is brought to the table late in the game. (“By the way, that API requires NSA security level clearance passed through a token.”)
• Developers discovered a missed user-case problem and solved it without bothering to set up meetings/discussions/approvals.
• A feature was given a bit more pizzazz than was scoped. (Developers get carried away!)
• Straight-up underestimation of the work needing to be done and what it is going to take.

Building software is hard, but estimating software is even harder. After all, it’s rare for us to build the same thing twice. Though we work with WordPress, it’s actually quite impressive how little of our work deals with the actual blogging component. WordPress has the basic, expected features on lockdown, and so what we end up building is ways to make WordPress do something unique.

Uncharted territory

Let me remind you: Christopher Columbus’ intentions were to sail around the world to establish a shipping route to Asia. He estimated the distance to be about 2,300 miles (the true figure was much more vast at about 12,400 miles). This idea was controversial at the time; the prevailing theory was that the earth was flat. So Chris was spot on about the earth being round, but what he completely missed in his estimations was the existence of an entire continent between Europe and Asia. The United States of America is an example of massive scope creep.

What’s the point?

If we opt for skipping the discovery phase, we’re likely to run into this unfortunate truth: The short term gains are not worth the long-term pain.

At Zao, our goal is to give your project the best chance of success. The primary way we can help guarantee that success is by providing an accurate budget and timeline estimate (with some margin). As you have established by now, the primary way we establish an accurate estimate is through a discovery phase!

So enough about why…let’s talk about what.

What exactly is a discovery phase?

There are actually many ways to define a discovery phase, but the discovery generally involves gathering requirements, reviewing goals, identifying what is working, and what isn’t.

In order to do the work of discovery, we need access to all the relevant resources, which can include things like:

• Existing scoping documents
• Stakeholder requirements
• Admin access to existing solution (CMS login)
• Developer access to existing solution (FTP, GitHub repos, etc)
• Access to relevant documentation
• Project Review

Once we have access to all the relevant resources, we take time to review with you, the client. Some of the things we need to review together include:

• Current pain points with your existing solution (This involves in-depth conversations, and likely a demo walkthrough or two)
• The new proposed solution, and any of your accompanying wireframes, mockups, documentation, etc. (When possible, this can be accomplished through tools like InVision.)
• Any of the gathered resources which require additional context (e.g. internal API documentation)

This review process is a great opportunity for Zao to collaborate with you. Our intent is to work alongside you as a trusted partner and help you maximize the potential for your project. We can offer industry-level insight based on our years of experience, and even help you to determine if the proposed solution is the best way to accomplish your goals.

In addition to the collaborative review effort, this is also the time we do in-depth research into your desired goals, and audit any existing solutions that we may be building with or on. These audits may include things like your eCommerce platform, web hosting provider, codebase, performance, etc.

Delivery of the discovery document

When we have completed the previous steps, we compile a discovery document for delivery.

This discovery document is the concrete answer to questions like:

• “How do our requests align with our budget and timeline?”
• “What will the individual components cost, and can I prioritize based on costs/effort?”
• “What should be our MVP (Minimum Viable Product)?”
• “Where does the MVP fit into our long-term roadmap?”
• “How long will it take to launch our MVP?”

This discovery document represents a significant investment of time and energy and is the result of our collaborative efforts.

Completing the discovery phase and producing the discovery document brings a cohesion and clarity to the project that cannot exist otherwise, and provides a value far beyond the associated costs.

What…so what’s the point, again?

While our ultimate and obvious goal is to continue into the development phase with you, we also recognize that the discovery process may provide a broader insight into our working relationship. Zao is a small, focused team, and we recognize that not every project, timeline, or budget is a good fit for us. If, by the end of the process, it is determined that Zao is not the perfect fit for your project, the value you gain through discovery, and the resulting document is not wasted, and you now have much better clarity moving forward.

We’ve talked about the value of the discovery phase, but what if you don’t have the time, or budget for this important step? If we opt for skipping the discovery phase, we’re likely to run into this unfortunate truth: The short term gains are not worth the long-term pain.

Lacking the clarity of vision over the long-term work of the project, dealing with the surprises and scope creep, and pivoting on features mid-project — these are all very real risks of skipping this phase, which is why we consider it the first step in working together, and a high priority.

---

Have questions about the discovery phase? Or have any tales of horror of working without one? Let’s hear ’em!