Lead to Quote — What is it? And how to get estimating right.

I should first mention that this article is written purely from the perspective of a person who takes care in making sure things come together (well).

Estimating projects is one of the main challenges of any software-related business. It is a link between customers, sales teams, and developers. I also truly believe it is one of the most important pieces of client-facing communication that drives the whole business. It may seem simple to standardize and normalize a process with only two outcomes: “sale” or “no sale”, but anyone who has tried knows that it’s not so simple.

First of all, it is important to mention that at SwingDev we genuinely believe in the idea of coopetition. This means that we always want to share our ideas and improvements to help others so that we can get better as an industry. For years I have seen many companies (including my software house I used to run) struggle to get the estimating process right, so we want this to be as transparent as possible.

Why is giving a good-quality estimate so important to us?
Clients usually don’t pay for the time spent carefully analyzing every detail of a project. When giving estimates, we have a significant advantage on our side because we know all the details they may be unaware of. We minimize their uncertainty by sharing as much useful information as we can, as an investment into our long-term relationship. This analysis may be seen as extra work, but for us it also means we have everything properly figured out and we can dive into the project right after we get the green light to begin.

Given the nature of software, the seemingly small choices we make in the process can greatly influence the final estimate. There are an infinite number of parameters to work with that have to be taken into consideration, including the choice of technology, team members, communication/project management tools, and a plan for development. We want to make sure that our team understands the context of the client’s desired outcome and that during this analysis everyone can make the most informed decisions within their area of expertise. We take into account various options and encourage programmers and designers to think outside the box and look for entirely new solutions. This process has to be done under tight time constraints to ensure that the client gets our recommendation as fast as possible.

So how do we handle it at SwingDev?
We started from making this an important internal project and called it: “Lead to Quote” (yes, this is a necessary step — to name your internal projects). After that, we engaged cross-department teams into a series of brainstorms for a few weeks. The outcome is our own blueprint consisting of a set of rules and suggestions that makes things a lot easier and more consistent than before.

Let’s take look at general parts:

1. Intro Call
2. Project Introduction
3. Solution Discovery + Follow-up Call
4. Deep Dive Meeting
5. Solution Proposal
6. Board Final Approval
7. Proposal
8. Project Kick Off

Those may seem obvious and generic, but trust me, there is more quality and depth into each step. Lets dive into some of them.

In the fast-paced startup world, the speed of the whole process is highly important. It’s extremely crucial for the client to get solutions from us as fast as humanly possible.

Intro Call / Introduction to the project
The sales team gives the most accurate summary of the project, its limitations and general context of the solution we have to deliver. During an intro call, we are finding out more information about the project, asking questions, and presenting our understanding of what needs to be done. After this step, the Project Manager is introduced and takes over the communication between the client and the development team.

Solution Discovery + Follow-up Call
Estimation — we deliberately try not to use this word in the Solution Discovery meeting. The reason is that we want to change the whole “man-days oriented” mindset connected with the usual proposal.
The Solution Discovery meeting is a brainstorming session led by the Project Manager with the input of a Solution Architect, our CTO, and other members of the development team.

Solution Architect — a person responsible for coming up with an efficient solution that solves the client’s challenge. It has to be efficient, feasible and has to take into consideration all available data.
Who can take a SA role? Senior Developer, Team Leader, or CTO — generally a seasoned tech person that has a previous experience in the required area.

We sit together to come up with several proposed solutions to the problem. We check all possible options in terms of project size and type . We stir things up and look for ideas outside the box and compare results. We check if there are more optimal paths we can take and how much time they would take. We engage in many “what if..?” discussions until we come to a satisfactory result and we are ready to show the executive summary of the options we have found. Again, there is no estimation involved — we focus on quality. The client’s feedback will help us to check if we are on the right path and will confirm a mutual understanding of the scope of work ahead.

The not-so-obvious best practices:

• Ensure that everyone has all the most up-to-date information that may help understand the project.
• If possible, briefly describe the context to everyone before the discovery meeting takes place!
• Inform everyone about time frames and deadlines for the discovery phase. Remember that time is a very important factor.
• Remind everyone that this meeting is more about “Solution Discovery” than just numbers.
• Solution Discovery outcome: a set of initial assumptions that lead to a better understanding of how to deliver the project
• Be very careful with using 3rd party solutions that have not been implemented or used before. Maybe it requires a proof of concept?
• Try to use a blank/different document than the one describing functionalities sent by the client. It stimulates participants to figure out and understand all elements and requirements by themselves.
• Treat the initial Statement of Work like a flexible set of information. It may be changed! We highly encourage to come up with different and clever ways of meeting desired business goals. This is why it’s important to understand them well.
• Risks and bottlenecks — it is very important to identify them . After such element is identified:
• Try to find a workaround,
• Try to reduce the requirements,
• Remember to not spend all the time discussing one element (does not apply to everything, e.g. core functionalities)!

Deep Dive Meeting
The Deep Dive Meeting is a session devoted to assessing the workload related to the delivery of each solution. Our aim is to give the client information that will help them make an optimal decision taking into consideration the important criteria of time and budget. It also allows them to plan the future development of their software and coordinate the delivery, launch, promotional activities or testing sessions. We make sure to communicate any assumptions or limitations that are linked with the provided time estimates to minimize risk as early as possible.

Quick tip: Ranges — try to avoid using them. If there is an uncertainty this means that you most likely have to spend some time on research. If there are options — list them separately.

What comes next? Our proposal gets verified and approved by board members, and it is sent to the client. However, the project offer is not the only outcome of our Lead to Quote process. There is something more important.

Some time ago, when we decided to take this approach, we had a feeling that this hard work would pay off. Looking back we know that all these hours were not wasted. We gained more experience finding innovative solutions, built stronger relationships, became proficient in analyzing problems and planning our projects. Companies and startups come to us so that we can advise them on the best solution, not just write them some code. In the future we can only hope to be able to put even more thought into the planning process.