Why is it so difficult to determine a fixed project budget?
As many as 27% of IT projects exceed their budget. Some projects are also delayed by up to 70%! Let us try to answer what causes this situation and how to counteract it.
In 1979, Daniel Kahneman and Amos Tversky published a paper in which they introduced the concept of the “planning fallacy”, which refers to our innate inability to correctly estimate the time needed to complete a given task.
One of the most famous experiments confirming this was conducted in 1994. Roger Buehler surveyed his students and asked them to estimate how long it would take them to write their master’s thesis. They calculated the average time to be 33.9 days. The study also examined how long the same task would take if everything went smoothly and how long it would take in the worst-case scenario. It turned out that the correct value was 55.5 days, which was 62% more than originally assumed. It was also 14.2% more than the students assumed even in the worst-case scenario. Only 30% of them finished the work within the original deadline.
Why does each of us estimate the time needed to complete the same task differently?
It’s simple. As a rule, we rely only on our own experience and do not take into account external factors that do not relate to the task but which may have a measurable impact on it. We also have a strong tendency to ignore risks because each of them has a low probability of occurring. In reality, however, they most often arise during the course of the task.
In IT projects, the issue is equally complex, as there are a multitude of factors and processes that can significantly affect both the budget and the project completion date, including:
- The problem of insufficiently detailed information about the project – when the client describes the objectives, functionalities or tasks in an overly simplified manner, which at a later stage may lead to misunderstandings due to the lack of detailed assumptions to which both parties could refer;
- The problem of changing scope of tasks and objectives to be achieved – often changing during the course of the project, when the client suddenly requires new objectives to be achieved or modifications to those previously set;
- The problem of combining the functioning of different elements of the system or parties – IT projects usually involve a combination of several or more different technologies, which means that adding new elements and modules creates new problems, e.g. with integration with existing functionalities.
- Problems with communication and interpretation – the lack of detailed project documentation often leads to misunderstandings or even conflicts, as it is common for people to perceive the same things in completely different ways. In the case of IT projects, a simple example would be a request to add an information banner to the client’s website, which we might understand simply as inserting it, but the client may also think that they will be able to easily edit the banner themselves, which is not so obvious and requires more work on the part of the programmer to implement such an option in the website management panel, and at the same time requires a larger budget on the part of the client;
- The problem of too many decision-makers influencing the implementation of the project, while at the same time wanting to give it a completely different shape;
- Technological changes – we have often encountered cases where, during the implementation of a project, the client wanted to change the initial assumptions regarding the technology used to implement the entire project.
Determining the project budget
We often encounter situations where the client does not want to disclose their budget for the project, as they are often afraid to trust the company or other people, playing their cards close to their chest and thinking, “I have 50,000, but I’d better say that I don’t know or that I have 20, because they will definitely send me an offer for the entire available budget right away, just to earn as much as possible.”
In this way, we condemn ourselves to the possibility of problems arising during the implementation of the project, and even reduce the capabilities of the company we want to commission, because it then has to blindly present us with potential variants of solutions in different budgets, ensuring a “better” or “worse” level of implementation, depending on how much time the project team will need to work to achieve the final result.
We ask our clients about their budget for the project in order to best match the proposed implementation options. To better illustrate why setting a budget is so important, let us use an example from another industry and consider whether, when we go to a property developer with the intention of building a beautiful villa with a garden, we assume in advance that we will limit ourselves to, say, £300,000, even if our actual budget is £1,000,000? By not giving the contractor the real budget, we are closing ourselves off to various possibilities for implementing the project in the form we need.
The core of every project should be the project documentation. Unfortunately, there are several reasons why clients often find this process unnecessary and would like to skip it and start working on the project as soon as possible. We have repeatedly observed the sad consequences of this approach based on clients who have gone through an unsuccessful project implementation process with another contractor and wanted to commission us to finalise it or introduce changes/corrections. Both parties should be aware that project documentation is a key stage of the project. If we devote sufficient time to thinking through the project and preparing the documentation, we can reduce or completely eliminate unnecessary costs and implementation time later on, and thus save ourselves a lot of stress. Project documentation should always be the starting point, and when it is missing, the best solution for both parties is to work on the project on an hourly basis.
What does the project budget consist of?
The project budget is influenced by factors such as:
- the chosen technology – e.g. React, WordPress, Jamstack, Gatsby, NextJs
- level of complexity – a simple information website vs. a portal with a customer panel, subscription system, integrations, etc.
- deadline – the shorter the deadline, the higher the hourly rates
- project coordination – a factor that is often overlooked, yet someone responsible and experienced on the contractor’s side must devote time to completing the project and keeping it on track
- RWD – optimisation of the project for display on mobile devices, which already account for the majority of web traffic
- level of experience of specialists – we can, of course, commission our project to a freelancer or junior specialists, and maybe if we find an outstanding person, everything will turn out well, but in most cases, everyone would certainly prefer to work with experienced specialists in the fields of UX/UI, design and programming, and higher quality always means higher rates, which in IT are simply dictated by market demand
Fixed price or hourly rate?
The main billing models for IT projects are fixed price and hourly (time & materials). Without a clear definition of all the functionalities, structure, and logic of the website or application, the only reasonable option is hourly billing. Otherwise, instead of doing something with due diligence, contractors usually focus on completing the project as quickly as possible and not closing it at a loss, so as to break even, or in the worst case, just to reduce potential losses.
We have taken over such projects from other contractors many times, where the cooperation between the client and the previous contractor ended in conflict. The reason for this is usually an underestimation of budgets or a divergent vision of what was created as the final result of the work, which was not written down in the form of closed project documentation that both parties could refer to. Very often, such projects have a technological debt, which makes working on them difficult and causes a lot of additional costs, and in some cases, it would actually be better to write the project from scratch instead of patching it up just to save money (sometimes patching it up ends up being more expensive than redoing it).This is why it is so important to create project documentation at the very beginning, which will allow the project to be closed within a rigid framework that can also be valued on a lump sum basis, to which the hourly work on further development of the project during its implementation will be accurate, depending on the client’s needs.
So how should you approach the budget and project valuation?
It is best to start with a preliminary briefing with the contractor and to think through and write down the results we expect. Then, discuss the whole thing in detail together. For larger projects, it is worth considering starting with workshops where you can work out all the arrangements for creating the project documentation together. This is particularly important because it is often the case that the client and the contractor have completely different ideas about the outcome of the work, which is a sure-fire recipe for conflict. The lack of detailed documentation makes it impossible to determine unequivocally whether the project objectives have been met or not.
If you would like to discuss a potential project with us, please fill in the brief.
