“Can’t we just get started developing? What is this Discovery period for?  We know what we want, can’t we just start working on prototypes with the developers?” Questions like this are hard to answer as it seems like an easy road to just start wireframing or prototyping. Who cares?  Well, you should! Beginning development without a complete Discovery phase will lead to so many inefficiencies that your project will surely miss its cost and time budgets as well as not meet your users’ needs.

So, what is the outcome of a proper discovery? It answers the How? How Much? and How Long? for a project. Its outcome creates well-defined requirements, aka User Stories in Agile parlance, and it uncovers the “got cha’s” of a project before they have a chance to “get cha!”

Let’s use an example. A customer may ask “How much and how long to build a fast car?” It seems easy enough to estimate, as we all know the price of a car, right? Well not really, a proper discovery would uncover the requirements under this request. Let’s determine how fast is “fast”? The cost of a car that goes 80 mph vs 200 mph is huge! How many people need to be in the car at one time? Will the cargo be on a road or does it need to navigate rough terrain off-road? Will it be used on public roads or will it be for farm use? You get the idea. Any one of these requirements will change the scope of the project which impacts time and cost.

To take this example to SharePoint, we often get requests to build out a records management solution for documents that currently exist on a shared drive. What is the ballpark estimate for that? Well, we need to know a lot of information from many different sources to figure that one out. Things like how people use this information: Are all the documents still relevant? Have some not been touched in years? What is the current folder layout and what is the desired information architecture? Do the documents need to be cleaned up prior to migration? What is the life cycle for these documents? The answer to all of these will set up the tasks for a successful project.

Of course, the other big item a discovery process helps with is the budget. Yes, projects can be simplified to meet budget requirements.  Tight budgets make the Discovery engagement even more critical. Separating “wants” from “needs” allows us to deliver a minimum viable product to the users and to ensure we can do it on time and on budget.

Don’t forget that the value of consultation is not only the delivery but determining the right approach to a project before it starts. Start with the wrong information architecture, database design, third-party products and you won’t know you are wrong until a user says “well that’s not the way we do that” or the security group says their policies won’t support the deployment of your solution. All scary realizations after 100 hours have been used and time is now tight.

So, what is the cost of not performing a proper Discovery phase before you start a project? Double. Typically we see projects run twice as long and cost twice as much if they are not set up properly. In the worst case, the project may not be complete or is abandoned or the user adoption never happens as their user stories were never considered when building out the technology.