Should Discovery be Separate from a Software Development Process?

16 Jan 2015

The Current Process

One of the paradoxes in software development is the idea that, before a project has even been sold, the developer will have enough knowledge about what the final product should look like to give even a remotely accurate time and materials estimate. Anyone who has been either a client or a vendor for a custom software development process knows that the requirements gathered prior to making a sale are so preliminary that you're lucky if 50% remain when they are fleshed out later in the project.

The Current Problem

On the other hand, no one would expect a software vendor (whose expertise is in writing high-quality software) to spend hours of their own time and money to gather all the requirements, interview key stakeholders, and assess the true value of the project, knowing full well that they will only win a percentage of these sales. (We'll come back to this point later, so if that statement is not as compelling as it sounds, just hang tight.)

A Possible Solution

So what's the solution? The 'standard' software project estimate commonly used to make a sale is a gamble from all perspectives: the client trusts that they understand the problem well enough to communicate it to the developer within the scope of the agreed-on budget, the vendor trusts that they understand the scope and goals of the project and that the proposed budget will cover their costs of development, the developer trusts that they'll get access to everyone they might need to interview to fully understand the detailed requirements, and the client trusts that at the end of the project they will get a piece of software that meets their (often unarticulated) goals.

The new trend in software development is some form of paid discovery phase, a low-cost standardized service that a company can provide to any client they're thinking of doing work for which, unlike the main software project, has a clear, attainable time frame with clear deliverables for a documented and fixed price. The result of this service is more than just a proposal, but a document outlining the high-level requirements as collected from multiple people within the client organization, the value the organization hopes to achieve, and the vendors recommendation on how to proceed to attain that value.

Why it Works

This service has multiple benefits over the traditional 'throwing a dart blindfolded' approach:

Nothing is risked other than the sticker price of the report. There's no fear that halfway through the project everybody will realize that the budget was insufficient and the project will cost twice as much or have half the functionality. There's also no fear that a deadline will be missed. The information in the report also minimizes the risk that any of these things will happen during the real project.
Both parties are invested in ensuring the report has the best information available. The client has invested financially and it is therefore in their best interests to involve as many people in the discovery phase as are relevant (in larger organizations, it is difficult to justify scheduling meetings with people who are not directly involved in choosing a contractor prior to the exchange of money), and it's in the vendor's best interest to accurately judge the value and requirements of the project to provide a good recommendation to the client and build a strong, trustworthy relationship.
Undertaking a specifically discovery-oriented project emphasizes the importance of answering the most impactful questions up front, meaning that this information is available to make an educated decision about whether a software project is ultimately necessary.

Those familiar with the 'waterfall' model of project management might think this looks a lot like trying to force a specific subset of what goes into software development throughout the process into a step right up front. However, it's really just a matter of ensuring that everybody has all the information they need to make an educated decision.

After all, would you rather spend $50,000 on something that might work, or spend $1,000 to make sure that (a) it will only cost $49,000 more and (b) it will work?

photo by Ryan McGuire