The discovery phase is a crucial part of a project if you are hoping for an accurate understanding of what the client needs, who will be using the end product, and what the technology behind each step is. At the end of this phase of the project, you will know the scope of the project and you should be able to deliver a document for each piece of the puzzle you “discovered” along the way.
This process is not free. Either the client pays for it, or your company eats the cost.
Some people might not even recognize that they do discovery. Asking a few questions over the phone, having a conversation via email about the project, etc., is discovery.
I’ll always start off asking the client a few questions because you have to start somewhere. It becomes a problem, though, when, after a one-hour phone call with the client, you are no closer to understanding what they need built or designed.
I’m going to walk you through two scenarios that I have dealt with in the past two years that might help you recognize when discovery is needed, and how you can save time. And as always, time is money. One scenario I did correctly, the other I did not.
Discovery phase done wrong: ‘We have a dream’
I met with a colleague who had a small agency and she had a client that needed a massive web application built. First off, I asked what had been written down, and unfortunately, nothing had been written. There were a lot of conversations between the client and my friend, but nothing written. No bullet points, no requirements, nothing substantial. Being the nice guy that I am, I decided to meet with them anyway.
One of my developers from Sideways8 and I sat with my colleague and her client for two and a half hours. We asked them question after question like:
- Can you give us a five-minute explanation of what you need built?
- Who is the target market?
- How do you want it to be managed?
- How are payments going to be handled?
- Which user roles — Admin, Organizer, Coach, Parent and Player — will we need and who should have access to what?
- Which user roles will be interacting with each other?
- Does a Coach need the ability to modify a Player or should only a Parent need the ability?
- How do you want notifications to work?
Then we went through a few user stories and had a massive whiteboard diagram of how things should work. By the end of the meeting, we basically helped them figure out what they didn’t think about and we were able to work on a rough draft of a proposal based on what we uncovered.
We gave them five hours (two of us times two and a half) of free coaching, not including the time we spent before with my friend talking through the project. This “free discovery session” helped them understand the scope of what needed to be done. With that information, they were able to get more organized and have a clearer vision of the application they needed built. Armed with that information, they were able to go to the next vendor well prepared. Unfortunately, we did not land the project.
What I learned from this is that I need to ask for some type of written document, whether it be formal or just two pages of notes.
Asking clients to write things down does two things:
- Lets you see immediately that a discovery phase is needed.
- It helps you, before a meeting, ask questions which makes you look more like a pro.
Discovery phase done right: ‘We don’t want to pay for a quote’
This web application that the client needed was simple, in their eyes. But isn’t that the case most of the time? Just because it is simple, it doesn’t mean it is easy. I would say the opposite: because it is simple, chances are, someone spent a lot of time building it so it seems simple.
We had the opportunity to build something that we knew was complex, but it would have taken 10 hours to get a good grasp on what exactly they needed and how everything was supposed to work. We needed discovery, and this is what the client said about it:
“To be upfront and honest, we have a fundamental philosophical problem with what I can’t help describing as paying for a quote.”
We parted ways and someone else got the project. We knew that there were a lot of moving parts and we needed a discovery phase to be able to give an accurate estimate of time needed to complete the project. We’d rather lose the work than to try to guess at development costs and then come back later asking for the client to give us more money for completion.
Seven months later we landed the project. They came back to us with an incomplete application. My guess is that no one realized how complex the project was and it caused disappointment on both ends.
My team now has a 15-page documented scope of work because the client paid for discovery. Of course, we didn’t lock them into using us to build the application. If they wanted, they could have gone to another vendor to actually build it. And, because it is documented, there is an attainable target. It is much easier to hit a target once it exists.
What I learned is that I could have moved forward hoping the estimate held up, but I would have wound up like the first company. Instead, we insisted on discovery and both parties are happy.
How do you move forward with a discovery phase?
It might not even be necessary to do discovery. If you are building a simple brochure site, and you don’t see any red flags, great. You probably just need to make sure you are asking the right questions like “This form only needs to capture the data, not pass it along to a third party, right?” If you start seeing hidden functionality, you might need to start talking about discovery.
Here is one of the major selling points: Discovery will be helpful for the organization that needs the project built, not just for the ones that are doing the building. It helps an organization see, on paper, what is being built and how it needs to work.
The discovery phase doesn’t have to be looped into the cost of the website. In fact, it shouldn’t be. It is a separate project and should be treated as such.