This is the first post in a series that our software consultants dedicated to the first stages of IT projects:
This three-part guide for IT clients is designed to provide them with essential knowledge so that they can kick-start their software development with less stress and no budget-sensitive mistakes.
We start with presales—perhaps, one of the most foundational phases in any IT cooperation story. From a potential client’s kick-off message to a vendor’s commercial proposal, this string of actions defines how successful the project will become in the long run. No need to say, it also checks the chemistry between a vendor and their client. While this may not be the final decision-making factor, it will certainly affect cooperation dynamics.
Presales emerged as a response to the complexity of selling a technological product, be it an off-the-shelf system or custom software.
On an IT vendor’s part, presales consultants are assigned to manage the vision and expectations of the client’s multiple stakeholders who are instrumental in decision-making in the project. Such consultants’ primary task is to cooperate with the client closely and elicit all the fundamental details before the contract is signed so that the proposed IT solution ticks all the boxes.
In comparison to sales, presales cling to the technical, not the commercial side. Presales consultants are frequently called engineers, which highlights their role in creating a conceptual solution design:
To back their solution development strategy, presales teams look into a client’s specifics to estimate the project costs and prepare a commercial proposal.
That said, the information coming from the client is critical for presales in IT, be it a formal RFP or a free-form request. In the following chapters, we will look at the steps IT vendors’ clients need to take to get a comprehensive vision of their future product.
Business goals are the cornerstone of project success, yet it’s easy to overlook them behind minuscule technicalities. These high-level, overarching goals should come from the client’s business itself—making the IT vendor guess them can hardly make any good. It’s also worth noting that for many startups that place a technological solution at the core of their business model, this stage can coincide with forming their actual business strategy.
Let’s illustrate the importance of having clear business goals with a hypothetical project request.
For example, you want to create an application to automate a food delivery service. Before you go to the vendor, consider running market research first to answer these questions:
- Who is your competition?
- How and where will you be delivering food?
- What is the size of your market (target audience)?
You can also read reviews of other delivery services to do a competitive analysis of sorts, to identify their strengths and weaknesses that you want to address.
If after all the completed steps you can say: “Hey, look, people in this area have nowhere to eat out! It’s risky, but may be worth the investment.”— you can go to the vendor with this business goal.
Once you have your key goal in place, your vendor will be responsible for taking it from there and developing it into their orchestrated solution. But without completing this crucial step, all further discussions of the solution will be just an empty shell—you simply won’t have a relevant benchmark for the project results.
To help you with this task—which in most cases is not a walk in the park—here’s a little list of sample business goals, both bad and good.
|Bad business goals||Good business goals|
|To make money||
Research shows this niche has low competition while the market size is considerable—I want to fill it.
|To “kill” Instagram||Stats show that this demographic group doesn’t use Instagram. We have an idea of how to fill this niche, but we’ll have to offer extended functionality.|
|I like cooking. I think it can be a good business||In this area, there is nowhere to eat out—we want to set up a food delivery service.|
|We want to be on top of the trends—let’s automate something in our company.||Right now we print all our documentation, but there is so much of it, it always gets lost. Our accountants and lawyers are ripping their hair out. How can we automate this?|
Once you understand and set your business goal, the vendor’s presales experts will get down to interrogating you.
It’s important at this stage to brief the project stakeholders and ask them clarifying questions. The answers will be then used to estimate the project scale, team size, person-hours needed, technologies to be used, and more. The number of questions will depend on the complexity of the problem, the specifics of the client’s business, and long-term plans, as well as on the vendor’s own project management style.
Going back to our hypothetical food delivery project, the list of clarifying questions could include the following:
To identify key roles on your project team and the preferred collaboration model, you’ll need to answer more detailed questions.
Presales in the IT industry only benefits from proactive clients. With as many project details as possible, your request can be processed much quicker. This translates into less time spent on prep work.
Defining your key project goal and answering the questionnaire will certainly get the ball rolling. Yet this is when it’s time to sit down with the vendor to discuss the specifics. This third presales stage will see both your and your vendor’s teams going through a few in-depth sessions, either remote or in person.
The definitive work you have done so far will serve as the baseline for discussion. If you have a detailed technical specification, it will certainly help at this stage but won’t be sufficient on its own—extra clarifications are always needed to get on the same page.
To make the discussion productive and insightful, you’ll need to make sure you bring the key people with you:
Presales in IT: vendor sessions
Key roles on your team
Key roles on your team
Project manager / analyst
Such clarifying sessions have an essential function—to help you avoid a few pitfalls by setting realistic expectations regarding your project. The following is just two examples of how presales in IT can be a kind of reality check for clients.
Some clients may have a lot of ambition yet have a very vague understanding of their real opportunities.
In our food delivery service example, you may want a system that would serve several continents, automatically create seasonal menus, take into account customers’ preferences in different regions, and give nutritional tips. Exciting as it sounds, it will likely take too long and cost too much for a start. In a scenario like this, the vendor’s team would rather suggest starting small and feasible: to limit the covered territory and only provide actual food delivery, adding auxiliary services later.
Sometimes, apparently simple tasks can turn out rather complex considering the technical effort involved.
Let’s assume you want to build a system to automatically check the freshness of products by their appearance. However, this task is not trivial, involving image recognition technologies and potentially machine learning as well.
It would be risky to jump at this project in its entirety so the advice would be to make a prototype and assess the limitations of implementing this solution, as well as whether it’s realistic to do it at all. If you are satisfied with this pilot project, it’s safe to carry on.
Once discussed, all these project specifics will find their way into a vendor’s commercial proposal. This is the culmination of presales in IT, a concise and effective demonstration of a vendor’s vision and capabilities.
After all the preliminary work, it’s now down to a vendor’s professionalism to calculate the effort needed to pull off the project.
We at Itransition typically divide the key overarching task—like, to automate a food delivery service—into a series of sub-tasks, each with its own respective goal. The estimations then are translated into the timeline and costs of the project. Clearly shown in the commercial proposal, these will be among the key decision-driving factors for you as a client.
In a well-drafted commercial proposal, you’re likely to find the following key points:
Once you get to assess the commercial proposal, the presales phase is formally over. Yet there is one last thing that can help you decide on the vendor.
If possible, before you commit to a particular vendor, show their commercial proposal to other vendors for their critical review. This can be helpful as they spot some inconsistencies, some vital aspects missing, some overestimations, or a strategy that still needs tuning.
Even the most professional vendors are not error-proof, so running commercial proposals through additional checks would help to avoid any impact on the project later. Of course, vendors shouldn’t just criticize others’ commercial proposals for the sake of it. The criticism should always be constructive, detailed, and well-founded.
Finally, we present a sample commercial proposal that our presales consultants drafted to illustrate the points covered above. While the specifics will certainly differ for each project, it contains the essential parts that need to be covered in any case.
Now that you’re equipped with the knowledge about presales in the IT industry, it’s time to move on. The first stage of prepping up for the project should leave you aware of the scope, complexity, cost, and deadlines. The second one—business analysis—is about discussing the practical details of implementing this plan.
Learn more about what to expect and how to interact with the vendor’s team during this stage in our next guide.