Let’s say you’re a consultant starting the conversation with a potential new client. They’ve decided to kick off a new technology project. Sweet! It’s an investment for them that carries a lot of opportunity… and risk.
Success could increase your client’s revenue, reduce their costs, and save them time. An unsuccessful project could have immeasurable costs, particularly for companies that rely on tech as a big part of their business model.
It’s your responsibility to do everything possible to make sure that your projects are successful. While every project and business is different, I’ve learned a few key things the hard way. One of the things that proves its worth every time is focusing on business goals - before starting to build. This sounds cliché but here’s what I mean:
Ask your clients about their BUSINESS problems and offer a BUSINESS solution. Before talking about development or technology or process. What is it that is costing them money or not making them money?
Sounds simple. It should be. For some reason, it’s really common to skip this and go straight to solutioning. Maybe if we give it a name, it’ll be taken seriously. Let’s call it Discovery...
What is Discovery?
Discovery means exploring and pulling the unknown out into the light. A Discovery phase is a paid consulting engagement which comes before the part where you build the solution. The reason a company might do it is to reduce or eliminate risk during the build, saving both time and money by avoiding costly mistakes.
Discovery can look like:
- a series of conversations between you and people across the client team
- diving in and checking out your clients’ current operational & technical systems
- researching different options that might be a good fit for your client
Discovery can result in:
- written documentation of your findings (discoveries)
- recommendations for the best method or approach to your solutions, including platform selection, systems architecture, apps, extensions, custom features, & integrations
- technical solution requirements, roadmaps, planning resources to tee up the build phase
Here are some things you should try to nail down during Discovery:
- Business Goals, Opportunities, and Objectives
- Project Risks
- Who’s Involved (Stakeholders)
- Expectations
- Dependencies
- Technical Unknowns
- Functional “Must Haves”
- Solution Definition
- Project Delivery Timelines
- Costing
My Project Doesn’t Need A Discovery
For projects with tight budgets and timelines, a Discovery might seem like an unaffordable luxury. I get it. Experience has taught me that even smaller projects can save time and money by thinking strategically upfront.
With the information collected, you can be confident in what’s being developed and the cost. Discovery doesn’t have to take a long time. Everyone wants to cut as much overhead as possible.
It’s easy to jump straight into building when you start on a project. It feels productive. Everyone loves shortcuts to save time. I’ve made that mistake before. The reality is that most times it will end up taking longer and being more costly this way.
What’s usually missing a realistic and informed plan. In this world of agile everything, planning gets a bad name. Being aware of the unknowns isn’t wasteful though. It lets you see speed bumps coming and avoid them.
Often business owners will come to you self-diagnosed and self-prescribed, seeking specific solutions. In these instances, it is your obligation as a professional to validate these assumptions.
How Is This Going To Help?
The truth is, technology is always changing. Often there are many different ways to use technology in solving a problem. Sometimes technology isn’t needed at all. Sometimes a change in process will get you a better result. For these reasons, your ability to understand, diagnose, and solve your clients’ business problems will always be more important than your application of a specific technology. Your clients don’t pay for the creation and application of technology - they pay to solve business problems.
The Discovery process protects the much larger investment your clients are making in building a technology solution. Better planning leads to less expensive projects.
Other consultants might offer “cheaper” projects without a formal discovery process. When you come up against this, ask your clients: “If we’re not doing a discovery process, can we trust the accuracy of the quote? Are we confident that this group really understands your needs? Can we trust that the proposed solutions address your goals? If not, do we believe a project without discovery will truly be cheaper long-term?”
How To Communicate This
As an added bonus, here’s an actual template for an email I’ve used to get a new client onboard with the Discovery process. Feel free to use it!
Hi NAME, thanks for the information. I can get started quickly, though I would love to learn more about your needs and goals so that I’m better positioned to help you.
I use a standard process in helping to develop solutions for this type of challenge, starting with a fast Discovery. Experience has taught me that even smaller projects can save time and money by creating a realistic and informed plan of attack. With the information collected, we can both be confident in what is being developed, the timeline, and the cost. It removes risk and improves the outcome for us both.
Let me know your availability to start exploring solutions. I’m looking forward to getting started.