• Tomasz Soroka

Fixed price is not so bad - it just doesn't fit to typical software development challenges :)

Software development is a challenge that consists of many elements. What should you pay attention to? What is important in the context of bringing the project to a happy end? What factors can cause the project to fail or its costs will be much higher than originally planned? I will try to answer these questions based on many years of experience in running projects at Leaware.

Where are you currently?

Bill Aulet in the book "Disciplined Entrepreneurship. 24 steps to a Successfull Startup" describes the product life cycle - in our case it is software development. The cycle usually starts at the moment when someone in your company realizes that there is a need to improve some process, to digitize it. In the Ignitor phase (the first phase of the product life cycle described by Aulet), a decision is usually made to start looking at the market in search of a solution to the business problem you are struggling with. At this stage, the business need - defined requirements are usually well described. The second phase is Research, where all the potential solutions that can be applied are searched. They do not necessarily have to be associated with the creation of custom software. Sometimes it is better to buy a box solution, integrate one or more systems. By the way - in the present times, also creating a dedicated solution in a larger or smaller part, incorporates various kinds of integrations. At the Research stage, we often specify the business requirements that we want to achieve. The form of specifying the requirements is very different and a lot depends on the experience we have. At this stage, it is worth using forms for collecting and analyzing requirements. After the research stage, we move on to the next acquisition phase. In this phase, we choose a company that will give us a solution. During talks with suppliers, we try to specify the requirements that should be met by the created software. Most often in this phase, the potential contractors we talk to ask questions that help them better understand the business problems you want to solve.


If at this stage we choose a company that does not have the appropriate competences, resources, know how and will not ask any difficult questions, the probability that the project will be successfully completed will decrease very much.

Give me fixed price

The most common requirement with which I met during my practice is to ask for the so-called final price for the implementation of an software solution - defined largely in the Ignitor and Research phases. This is obviously understandable from the perspective of the project sponsor, who wants to know how much should be invested in that the target solution is created.

The consequence of this request is the future course of action and interaction between you and the selected IT company.

Companies generally use two approaches. The first of these is the so-called reading tea leaves, when quoting from a hat is given (of course based on experience). This approach assumes that the terms of cooperation will be renegotiated during the project. The client placed in such a situation (if one can fish for such a bait) has limited possibilities of "protesting" because he knows that exchanging a supplier during the project is not an easy thing.

You should always (but always!) Avoid this kind of approach! Just how to do it? How do you know what factors affect the cost of software development? Is the price the most important? Or does something else matter? Who to trust, what questions to ask? A lot at this stage depends on how you define business requirements and whether you can enter details and also define functional and non-functional requirements. In general: the more defined requirements are, the more likely you are to avoid fortune-telling.

The second approach, in the case of trying to get a fixed price, is an approach that assumes a very deep entry into details. The company submitting the offer eliminates the risks related to the fact that the valuation will be inaccurate and important requirements will be omitted that affect the amount of work. At the moment we enter the details, we start the de facto project analysis. Often the question arises as to how much the analysis of the project is part of the work for which the IT company wishes to pay and, on the other hand, why would it work for free? This approach requires a lot of work - and above all knowledge and know how, how to do it? If you have an analyst in the team who can help you describe the requirements, you can be sure of the exact valuations, if you do not have such a person on board, the situation becomes a bigger challenge.

What should be done to ensure that both parties are satisfied with this stage of cooperation and how to find a win-win solution? In such a situation, it is worth to find a compromise between the accuracy of the valuation, allowing for a fairly precise project price (giving a sense of security to both parties), and the amount of work that needs to be put in to determine the details that will be sufficient for this level of valuation. Thanks to this, the supplier and recipient of the solution know what budget will be needed to perform the system, in which areas there are risks that can not or should not be estimated at this stage.

How to get a project to start without a failure?

There are a few basic rules that must be followed and which are very important from the very beginning of cooperation between the customer and the solution provider. Familiarize yourself with each of them - it will be much easier for you to talk to potential suppliers.

1. Determination of the business objective of the first version of the solution

Many times I met with the fact that the team that prepared the project's valuation did not understand the business goals that were ahead of them. What's more, I did not understand it myself. We should accept completely different assumptions when the client needs to make a prototype that will be tested and another when we are looking for a business model. Yet another strategy should be adopted when we create a high-availability solution that will be used by many thousands of users from the very beginning and which needs to be scaled up.

In each case, the valuation should be constructed differently. In a situation where we build a prototype, we do not have to pay so much attention to testing the solution, as in the case when we are building an enterprise class system.

2. Small scope - small budget

Do everything to make the first version of the solution as small as possible. As people, we are constructed in such a way that the most ideas, remarks and new solutions appear when we can see something tangible. There is no way to get 100% of the functionality for all the needs of the application's users the first time. Very, very interesting is the fact that when building a new car, fridge or smartphone, you create countless prototypes.

In the case of IT projects, we expect that we will determine the budget of something that is mainly in our heads and "feeling". Something that we actually need and in a magical way, without a few iterations, during which we will learn - whoever will be able to provide us with a great solution, acting without objections, as we imagined. This approach is wrong.

Achieving such a goal is practically impossible - unless we talk about the execution of the hundredth store selling shoes, and the team that works on it has so much experience and knows the business domain well that from the beginning you know what end users want. It's as if we were comparing the creation of a store with the production of a thousandth car on the production line. However, this is completely different than designing a car from the very beginning.

Thanks to the limited scope, and hence the budget, you will be able to learn, collect user opinions and work on new software versions. If you immediately set yourself up to the fact that the first version is only the beginning of the way to deliver high-quality services to the market, you will ultimately achieve a better final result

3. Allow the supplier to ask difficult questions

Software providers often have very large technical experience, but often business as well. Most importantly, they willingly share it - of course if you want to listen to them and let them talk. It's a matter of building the right relationship with the supplier. It is a time-consuming and difficult process. Especially when at first you do not know your software provider well. Remember that the sooner you allow to build a relationship and start listening to the provider, the (probably) the fewer mistakes you will make.

4. Building relationships and trust

Always look at the project as a long-term process. Remember that the application you are creating will have subsequent versions. If this is not the case - it means that after some time you have decided not to continue the project. You probably missed a niche and problems that were worth solving. However, if it is to be otherwise, you will need a strong partner who will be your companion during great moments connected with acquiring new goals, for example thousands of new users. Remember, however, that these goals are very close to the threats and failures that you may encounter in your path.

Is the system that you are building for sure will be able to handle such a growth of users? When to prepare for it? When should I test the application for this? Answers to these questions require excellent communication, relationships and trust. It is worth working on these things from the very beginning. Remember that just as much as you care about success, the same is true for every supplier for a stable project over a long period of time. The project, which will be not only a challenge, but also a source of great satisfaction for both sides.

What next?

We have started the project. The first win win-win. Cool! Now we have to focus on making it a happy end ... Remember that you are just at the beginning of a business road - many questions and decisions to be taken in order to maximize the success of running an application or service.

Download our Cook Book and check what you should look for at your IT partner and what you need to pay special attention to!

Need help with your IT project? Book free consultation with Tom: