Everyone aims to achieve the best results with minimal effort and maximum efficiency. In today’s fast-paced world, streamlining workflows and automating routine tasks are essential. With the right tools and strategies, productivity can soar while effort is minimized.
Let’s say you, as a customer, are looking for a vendor that will offer you the best solution for your idea of creating software for your needs. You want a team that not only understands your vision but also has the expertise to bring it to life efficiently. Choosing the right development partner can determine the success of your project, ensuring scalability, performance, and long-term value. The more the chosen vendor will be in connection with you, the more efficiency both sides will gain.
Therefore, you need to know what to expect from the vendor, which details to prepare for them, and how the process can be optimized. Having experience in working with different clients and helping them in achieving their goals, we want to guide you through the presale process. So, let’s see what you should look forward to.
Efficiency Depends on Both Sides: Customer and Vendor
When a customer is looking for a very particular vendor with specific skills, it means that they already have a certain set of requirements and want to get a software solution with unique features. Sometimes, with full ownership as well. All of these details should be communicated to the IT vendor to help the outsourcing team to have a full picture of the expectations regarding the solution functionality.
Besides that, all stakeholders shouldn’t forget that the presale process includes particular steps to follow. And both sides will have to perform their own duties during the stages of presale.
Now, let’s see which steps both vendor and a client should pay their deliberate attention to during the entire presale process.
Step 1. Full Preparation
It is important to understand that both parties should approach the process with due diligence: poor attention to details at the beginning will generate additional costs and significant compromise in quality of the process and results later on.
First of all, the customer has to be fully prepared beforehand for stating the business goals. As an IT vendor, we specify the solution requirements by asking the following questions:
- Which business idea is behind the application, and which goal it will serve?
- Who are your potential users?
The answers to these questions form the roadmap, therefore it’s vital to provide as many details as possible. Despite the doubts you may have about sharing the specific details, it is better to share them as they can impact the result. Of course, you may have a quite well-known high-level business idea that you plan to reach, like to make money, make the world a better place, save nature, save costs in your business, or similar. In any case, we offer to sign an NDA to provide you with more assurance if you feel you need it. As for us, as a vendor, of course it would be an honor to know the high-level goal and to participate in something great.
Keep in mind that a vendor has a very similar goal with the customer: to make a successful solution on the market. So, sharing a business idea gives a chance to the vendor to help the client to reach the goal. That is why we suggest building transparency from the very beginning. There is no need to provide all small details at first, but the direction where to go must be clear for both parties.
Let’s say you want to develop an e-commerce marketplace for used vehicles and ask us to help. So, for the first question, it is better to adjust the formulation with a short description of the application you want to have and define the key features. But if you have any difficulties, our team can help you and also offer additional features that may be useful at the beginning to bring more value to the solution. For example, talking about e-commerce marketplace for used vehicles, we may offer to consider the following features:
- verification of the car history (car mileage, crash incidents, etc.),
- user-friendly search and filter options,
- advanced vehicle comparison tools,
- mobile-responsive design, etc.
Some of the features may influence the development process, so it’s better to determine them at the start.
As for the second question, we want to know about potential users to understand which expectations and experience they may have, so we can convert them to certain user roles and provide them with particular permissions.
Usually making an application with customizable user roles is more expensive than with fixed user roles. So, providing enough information for defining fixed user roles will save some budget that can be used for application marketing and promotions later on. There is no point of doubt here: in case a role is not considered at the beginning, it can be added during next steps of web development.
Read Also The Intricate Art of Maximizing Value. How To Make Every Coin Spent Worth its Weight In Gold
Step 2. Project Scope Evaluation
Then we are on the point to understand if we have a “white clean paper” (greenfield project) to start the solution development or if some groundwork has been done previously (brownfield project).
As a customer you may already have (but not necessary) the following:
- A portion of code or application functionality you consider useful to reuse in the upcoming project;
- A list of defined technologies to be used in the project;
- A list of environments where the application must operate, like browsers stack, devices, screen resolutions, etc.;
- A list of standards/laws to follow during the development process, such as security, coding rules, etc.;
- API and ready-to-use backend;
- Server capacities;
- Completed Software Requirement Specification (SRS) or a part of it;
- Task tracker with the required tasks;
- Any other documents useful for the project.
It is recommended to provide all these documents and details before the project starts, as the earlier we get them, the easier it is to plan their cost-effective utilization in the project. Late sharing may require partial rebuilding of the solution and part of the previous result may become irrelevant.
Let’s look at some examples to better understand the issues that may arise in the process.
For example, a customer is not able to share the existing code with our team at the beginning of the project. The code could be reused in the newly created software, however, the client doesn’t have the full rights to it or is not able to get it in time and share. In this case, the client might think that it is not an important detail to mention, and we wouldn’t even know about the existing code in the first place. Then, somewhere at the middle of the project, the customer shares the existing code. In the worst scenario possible, the code can become completely useless considering that we have already spent a significant amount of time on creating the same functionality.
In other cases, it may lead to the following consequences:
- Old code may not be created on the same technology and language as the new one, so simple integration will not be possible. Most probably, architectural changes may also be required, which will lead to cost increment and possible schedule elongation;
- Unknown code may have its own bugs and can bring more issues to the solution after the integration. As a result, the product quality will decrease, which will lead to additional costs and cause possible schedule elongation to resolve the issues;
- In case old code will be eventually integrated with the new one, the application complexity will grow. Thus, more difficult and costly support will be required later on.
Another example is that the customer has not introduced an important stakeholder in time. This may cause misunderstanding between the teams and even the loss of some vital data about the project. If some requirements are not met, this stakeholder will not be satisfied as the product will be not as full as they expected.
The more details you share, the better the vendor can bring your vision to life.
Read Also Client Through the Looking-Glass, or How Not to Devalue a Project by the Lack of Documentation
How Clear Requirements Help to Choose the Right Vendor
When dealing with a vendor, you need to understand that your partnership will be built upon the application requirements. Reflecting customers needs, they are the foundation for all the other elements of the presale stage, such as Scope of Work or similar documents, estimations or cost forecasts, contracts and other legal documents, resources, experience approvals, and other communications. Without the defined requirements, everything else is derivative.
Detailed requirements also may impact the choice of the vendor you want to work with. So, there are several factors that are usually considered by clients to help them form their opinion:
- Price of services and pricing model;
- Contract type and conditions offered by the vendor;
- Experience and qualifications of the IT team;
- Comfortable communication;
- Software development model;
- Other quite individual factors.
In the majority of cases, the first point matters the most, especially when unique and narrow qualifications are not required.
Providing a vendor with all the details of your requirements ensures both parties agree on reliable pricing. But, here is where the difficulty emerges. Having experience with many different projects allows us to say that the detailed documented requirements may take several hundreds or thousands of pages for a full-stack project. And this is months of work for a professional requirements analyst.
Well, it sounds like a long story and many people cannot wait for such extensive time, because:
- The customer has no time for this, as there is a need for getting the solution “tomorrow”;
- The customer is ready to try the waters for just a few months, not being ready for a serious long-term game;
- The customer does not have sufficient budget at the moment and is ready to have the result (even a part of it) as soon as possible;
- The customer prefers an Agile development approach with fast results, experiments, and the ability to get users feedback faster;
- The customer may have other valuable reasons.
If a client needs a detailed and reliable pricing, we have to work under detailed documented requirements. Let’s say one of the vendors that you were considering promised reliable pricing while you haven’t even provided detailed requirements. In this case, you should keep in mind that this is not what is usually done and can be a manipulation or serious misunderstanding. Of course, you can meet charity and willingness to work for free, but it is more of a one-of-a-kind type of situation than the common practice.
You still need some reasoning to choose among vendors even if reliable estimation is not reachable. So, what can be done? It is possible to make an approximate cost forecast, based on high or middle level requirements. In many cases, it is not the final cost of the developed solution but something to start on. But, even this kind of approximation will require your participation in providing the requirements.
Read Also The Challenges of Project Estimation: Exploring the Variations
Let’s imagine you chose us as your reliable partner. Thus, here’s some options of what you can do:
- Share an analog or some examples of what you want to have for your software. This will help us to study the reference you provided and see if the features you want can be implemented in a similar solution.
- Explain in detail key features to be included in the application.
- Share your current software with us to review and explain which additions are required (in case the additions are needed to the existing application).
- Provide a Business Requirements Document.
- Share mockups, wireframes, and prototypes.
- Provide requirements in another form.
Of course, you will need to invest time in creating such a document, or delegate the responsibility of outlining the requirements to a trusted individual who can effectively communicate your needs. During our discussions, there’s no need to worry about mistakes or incomplete information — both parties can learn and grow through this process. After all, when developing a new application, no one has all the answers upfront. We fully understand this and are here to help guide you in structuring your requirements in a clear and organized way that will make the cost forecasting process smoother.
Once the requirements are properly prepared, you can expect the following outcomes:
- A well-structured document ready for cost forecasting;
- An accurate cost forecast;
- A realistic schedule approximation;
- A basic outline of the software architecture.
In addition, savvy clients will recognize several additional benefits:
- The requirements document can be used to evaluate multiple vendors, giving you the flexibility to compare offers.
- During the preparation of these requirements, you’ll gain valuable insights into a vendor’s competence and the overall experience of working with them.
- You’ll also learn how to better identify unrealistic or unreliable ideas, which can save you time and resources in future projects.
- Most importantly, the process helps to build a foundation of trust and honesty between you and the vendor, which is crucial for a successful, long-term partnership.
These hidden advantages are particularly important when looking at long-term projects. Many initiatives don’t go as planned in terms of initial cost forecasts due to unforeseen challenges, but with a strong level of trust, vendor competence, and mutual understanding, you’ll be better equipped to navigate those challenges and avoid costly issues during execution. Ultimately, this is what adds the most value to the project. So, do you still think that the lowest initial cost forecast should be the determining factor when choosing a vendor for a new software development project? That’s a good question for consideration.
Conclusions
In today’s competitive environment, it’s easy to get caught up in the allure of a low initial cost estimate when choosing a vendor for your software development project. However, as we’ve seen throughout the process, the true value lies in the quality of collaboration, transparency, and the thoroughness of your requirements. By investing the time to carefully communicate your vision, goals, and essential features to create a well-structured set of requirements not only helps in accurate cost forecasting but also strengthens the foundation of your partnership with the vendor, fostering trust and reducing the risks of future surprises.
If you want to develop software suitable for your particular case, please contact us, and we will be honored to become a part of your project idea.