Handling Technical Pre-Sales Process in Consulting Agencies

Technical Pre-Sales Process

The technical pre-sales process is initiated whenever a new qualified lead appears in the company sales funnel. The primary goal of the following process is to gain a fundamental understanding of the business problem the potential customer is willing to solve and get an idea of the terms the contractor will contribute to it. The second goal is to leave a solid impression of the company capable of helping the customer.

Scope

There is a wide variety of services that can be requested: design and implementation of the new system, re-implementation of the existing software, technology stack migration, empowering current customer teams with ongoing software development, and so on.

The agency has to understand the nature and technical aspects of the problem that the customer is solving to provide quality services. Basically, there are two ways of doing so:

1. Request for estimation. The customer provides software requirements specification documents or any other artifacts that allow a technical person to deliver an estimate on the suggested scope of work. This is a standalone piece of work that includes mostly digging into provided documentation and delivering the result.
2. Technical pre-sales call. Either the customer or the agency may request a technical pre-sales call to discuss the requirements, type of cooperation, the scope of desired work, and so on. This is a collaborative event together with a salesperson, a project manager, and a person from the engineering department.

More often than not, the request for estimation with the requirements provided is not enough to produce a meaningful result and to discover the quality of the scope of upcoming work. The technical pre-sales call is conducted in such a matter to cover the missing gaps.

Request for Estimation

This is a standalone work that requires a relatively solid amount of time to be devoted to producing fine-grained estimates based on the suggested scope of work. The engineering person often receives a set of documents, such as work breakdown structure, wireframes, and rough architecture design from the client. This is usually more than enough to produce the estimate.

As a result of the following activity, the engineering person provides a feature breakdown document with estimates per each feature and overall system development estimate. The one should be provided in human-day metrics. Pretty straightforward. The spreadsheet with the breakdown and estimate calculation will do just fine.

Technical Pre-Sales Call

More often than not, there are no software requirements whatsoever on the client side.

But customers still have working software and are willing to deliver a new version of it or update the existing one. This is what pre-sales calls are made for. Simply put, you have to literally take a footprint of their ideas out of their heads and understand how you can help them solve the problem.

How to nail the call down? There are 5 domains (or contexts) through which the conversation has to be led: business, application, data, technology, and delivery. All these domains form a holistic view of the customer’s business and help people, who participate in the pre-sales process, better understand the problem and ways of cooperation that will result in solving the latter. Let’s take a look at each one of them.

Business Context

The business context is all about the fundamental understanding of the business and the customer: problem to solve, goals to achieve, people to work with, and organizational structure to be integrated within.

What should an engineer look for:

1. The actual nature of the problem the customer is trying to solve.
2. Milestones and goals the customer is willing to achieve.
3. The operational model of the customer’s company. How do they build software?
4. Presence or absence of requirements for upcoming activities.
5. People responsible on the customer’s side for the upcoming work.

The following context should give you a good sense of what the actual problem is, how seriously the customer treats it, and how confident they are in the software development field in general. If you understand the problem, feel free to move to the next set of questions.

NOTE: Sometimes what you hear as a proposed solution from the customer is not what they need. This is why they ask us for an expert opinion as well, not only to be obedient in building whatever their desire is. Keep that in mind when joining the process.

Application Context

The application context questions are aimed to understand the existing software ecosystem that is already used on the customer’s side, what are the potential connection points with the new solution they’re trying to build, and how the customer’s suggestion is going to help them solve the problem.

You may discover a whole room of improvements during the following phase, which may lead to trustworthy long-term relationships. But for the purpose of one specific call, you should concentrate on what should you contribute in terms of the requested solution.

What should an engineer look for:

1. The current state of the software ecosystem and architecture.
2. Ways of integrating the new solution into the existing ecosystem.
3. External connection points within the system, like payments, reporting, etc.
4. Desired approaches to building a new piece of software: specifics on front-end, mobile, and back-end implementations.
5. Any additional artifacts the customer is willing to receive as a result of cooperation: documentation, automation tests, design documents, etc.

NOTE: The technical person should anticipate hearing a lot of legacy solutions present in the ecosystem. This is a completely normal situation, don’t stress out about it. The goal of the customer is to deliver value and produce revenue, not to be a fancy tech-savvy company with software built using the latest nightly builds of different technologies.

Data Context

The following context is all about the system’s information flow and how the suggested piece of software should handle it. Also, in the case of the existing ecosystem, it is important to understand the established way of communication and data flow between the services, specific data formats used, and so on.

What should an engineer look for:

1. Basic information flow and business processes to handle it.
2. Type of data to be processed (video, audio, files, confidential information, etc.)
3. Data storage approaches used in the company (databases, file storage, streaming data, etc.)
4. Data transmission channels (Web sockets, REST API, GraphQL, SOAP, etc.)
5. Specific industry standards that define the information the system possess
6. Standard compliance limitation over information to be stored (HIPAA, PCI/DSS, etc.)

As the result of the discussion of the following context, the engineer should have a solid understanding of what type of information is going to be processed, how is it stored, and whether there are any specific requirements applied to the latter.

Technology Context

The following context is about what infrastructure and tools the company uses in its development routine, source code provisioning, and deployments.

What should an engineer look for:

1. Type of infrastructure in customer’s possession: on-premise/cloud.
2. The overall setup of the software development and delivery environment.
3. Presence of continuous delivery, integration, and deployment practices.
4. Any specific pieces of hardware used in the existing ecosystem.
5. People who are responsible for maintaining the infrastructure and provisioning, and ways to communicate with ones.

This section should give you a good sense of the infrastructure, the engineering team will have to work with. Obtaining such knowledge gives leverage in understanding any possible complications that may happen during the cooperation, especially in the delivery field.

Delivery Context

The delivery context is about how the work is going to be done and how the contractor is going to be integrated into it. The ways of delivering the code, deploying the software, verifying and testing the software, communicating with the customer’s engineering department, and so on. Questions with regard to the following context are used to understand what the daily software development routine will look like.

What should an engineer look for:

1. The daily process of software development on the customer’s side.
2. Ways of communication between engineering departments and agencies.
3. The process of software delivery quality assurance.
4. The methodology used to produce software.
5. Expectations on integrating the agency team into the development process.

The following context should give you a good understanding of how the engineering team is going to be treated and how smoothly the cooperation may happen. It is important for us to see that customer knows how to deliver the software and what a bumpy road it truly is. Otherwise, there is a huge risk of miscommunication in the delivery process, which will make things much worse during the actual development.

NOTE: Agencies hold substantial expertise in delivering quality software, hence we can kindly suggest ways to establish a proper delivery framework for the customer. Don’t be afraid to throw in suggestions for agile development, sprints, defining acceptance criteria, and receive feedback from the customer on such matters.

Different Points of View

It is also important to understand, that the following process is a two-way road. As much as we are looking for information during the call, the customer is also looking for the way the company is able to represent itself: technical confidence, a good understanding of the context they are operating in, the ability to communicate freely, and so on.

The overall cooperation during the following call is hard to underestimate. It will mostly lead either to acquiring the upcoming scope of work or may lead to a loss of a potential customer, depending on the quality of the call.

You don’t have to follow the proposed list of questions (below) on the call blindly. It is rather a reference point to make sure you cover all the necessary details. The conversation itself will lead to new logical questions after answers are revealed by the customer. Follow the lead of the conversation and refer to the list of questions to move forward within the dialog.

Do not rush the conversation, let the person end their speech, and listen carefully. Don’t hesitate to repeat the question if you don’t feel like you get the point. Also, it is okay to not know parts of the hardware/software used by the customer. You’re not a complete software development machine. Feel free to ask additional questions about anything you’re not aware of. Do not fall out of the context of the conversation. Customers often throw some jokes and giggles or suggest small talk. Be friendly and respond appropriately.

And it is just fun! It is all about helping people that came to you, not about your justification of competence.

Summary

A person from the engineering department takes a crucial place during the following process. Below you will find reference to supplementary documents, such as a list of questions to ask about each domain and a pre-sales call checklist to ensure you haven’t forgotten crucial points.

Each process should result in a single or a set of tangible artifacts. Technical pre-sales are not exempt from the following rule. In case of a request for estimation activity, it is just a spreadsheet with a work breakdown and numbers.

The situation is slightly different with the pre-sales calls. Firstly, the engineer has to present a short summary document outlining the key points on the call. Secondly, the risk assessment note has to be delivered, hence there are no clear requirements yet.

The risk assessment document is a short note written in a free form about anything that may delay the delivery of the system or imposes any risks on agency’s being able to produce quality software. This includes:

• Risk of not meeting the suggested deadline,
• Tight dependencies on other teams
• Black box implementations/custom software in possession of the customer
• Absence of clear requirements
• High chance of constant changes to the development process along the road

These documents will be shared across departments to help make decisions in the upcoming steps of the pre-sales process.

Please feel free to reach out to me in case you have any questions or need an advice via email (pavlo.sobchuk@gmail.com) or directly at LinkedIn.