Why is it worth planning and devoting sufficient time to developing project documentation if we want a fixed price for the order?

Project documentation should be at the core of every project. Unfortunately, there are several reasons why customers often consider 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.  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.

The benefits of developing project documentation:

• Faster project implementation time
• Cost reduction
• Detailed scope of implementation
• No ambiguities or room for different interpretations of the project assumptions – both on the part of the client and the contractor
• Easy verification of the Contractor’s fulfilment of all commissioned work
• Allows you to archive a description of the entire system/website/shop and its functionality in a single document
• Makes it easier for another Contractor to familiarise themselves with the completed project if necessary, should we wish to commission them to work on it

What is the most common reason for project failure?

For many years, we have been working on projects as “Fuck-up Managers”, where we have to rescue projects that, for various reasons, have stalled at a certain stage, often generating costs or being on the verge of a lawsuit by one of the parties. What do most of them have in common? Most often, it is poorly prepared project documentation, which was prepared in a hurry or, worse, unreliably. Projects based on such flawed documentation usually end in a legal dispute between the client and the contractor, because both parties had different ideas about the appearance or operation of the individual functionalities that were coded.

Discussion on cooperation models in IT sector projects and project documentation

The following account is an excerpt from a conversation between Łukasz Pach, Managing Director and Co-founder of ADream Agency, and Paweł Sawicki, Legal Advisor and Partner at Sawicki & Sawicki Law Firm in Krakow. The conversation concerns cooperation between parties on IT projects, cooperation models, project documentation and settlements. We invite you to read on.

Łukasz:
Hello Paweł, it is a pleasure to meet you and discuss different perspectives on IT projects.

Paweł:
Thanks for the invitation. I am also pleased to discuss IT projects, bearing in mind your circumstances. I hope that together we will be able to compare our experiences and draw positive conclusions from them. Łukasz, how does it look from your perspective?

Łukasz:
Paweł, when we get involved in projects and try to straighten them out – and we are asked to do so by both friendly agencies and irritated clients – we see that clients often want to operate within their own, undocumented standards and what they understand as standard, and something like that does not exist in IT. For example, a client reports that they want to have registration and thinks that logging in via Facebook is already standard. I often point out to clients that certain issues are not obvious.

Paweł:
I understand. So you see the sources of misunderstandings, doubts and potential disputes mainly in the difficulty of agreeing on what you as an agency are to do, i.e. the scope of the work entrusted to you and the manner of its implementation.

Łukasz:
Let’s assume a situation where a customer says he would like to buy a FIAT Panda. He goes to several agencies and checks where and how much a Fiat Panda costs. He finds an agency that offers him a favourable price and orders it. The agency sells him a FIAT Panda, and the customer then says that he wanted a 2000 FIAT Panda, but got a 1995 model. The engine should be a 2.0, not a 1.6. The dealership responds: “But we only sell cars from 1995.” If the customer wants a 2000 Fiat Panda and did not specify this, why should the agency not give him a 1995 car with a 1.6 engine? The customer must specify all his expectations if he wants to operate in the Fixed Price model. If they are unable to do so and need to clarify certain things on an ongoing basis and adjust certain elements of the project during its implementation, it is best to work on an hourly basis for the work performed, e.g. with weekly or biweekly billing reports.  We often give clients a link to a system with the option to view project time in real time. Paweł, in your opinion, whose responsibility is it to develop the project documentation?

Paweł:
First of all, there are no legal provisions that directly regulate the form and elements of IT contracts. I am omitting the copyright aspect here, as we are not discussing it. The mutual relations between the parties to such a contract (the ordering party and the contractor) are based on fairly general provisions regulating the so-called contract for specific work. With this in mind, we must assume that it is primarily the parties who must determine how and what they want to implement. In the case of fixed price (lump sum) settlements, the subject matter of the IT contract should be precisely defined at the time of its conclusion – so, on the one hand, I am talking about the scope of work and, on the other hand, of course, about the remuneration due. Precise regulation of the mutual obligations of the parties will be primarily in the interest of the client, as it is mainly the client who should care about the project being carried out efficiently and without complications. If precise specification is not possible at the start of the project, then the fixed price model will also not be possible.

Łukasz:
You see, the problem is that, for example, clients expect that within the assumed 80 hours resulting from the initial estimate of the time needed to complete the work – everything will be done to their complete satisfaction. However, they do not take into account that the initial estimate was based on the requirements and expectations of the client reported to the contractor before the “start of the project”. Often, however, during the project and after signing the contract, they require the functionality and service to be expanded with new ideas that were not originally included in the project. This results in an obvious increase in the amount of work and, consequently, in the costs that the contractor must bear. At the same time, they often want to burden the contractor with the lack of their own specific requirements at the start. According to some clients, it is always the Agency that should know what the client expected, even though they did not express it in any way. We would rather have to talk about mind reading here, and despite our sincere intentions, we are not ready for that when developing a project. In our agency world, there is talk of something called “Polish Agile” – meaning “I commission everything, flexibly, to my satisfaction, but the price must remain unchanged” :). This cannot work, and in a mature work culture, especially with Western clients, no one would even think of such problems.

Paweł:
The billing system can, of course, be shaped freely – through a fixed price or a time and materials estimate. Remuneration can be determined in a mixed manner, and there are also different financing options and models. Two issues are important here. First of all, the client should determine the acceptable budgetary framework. When jointly setting the assumptions and objectives of the project, and subsequently during the implementation of the project, the parties should keep the budget in mind at all times. Secondly, the financing rules and the resulting remuneration of the contractor should be tailored to the way in which the project is implemented. A pure fixed price usually works well for simple projects where there is no risk of changes or system expansion, and the client has provided a detailed specification of their requirements or detailed project documentation. If the project is being expanded on an ongoing basis or is being implemented without strict specifications, especially in a flexible “agile” approach, it is impossible to determine the remuneration as fixed and lump sum. In this case, the appropriate measure is mainly the amount of time (hours) spent by the team of specialists working on the project. It is also possible to agree that the basic version of a given project will cost a specific lump sum, and any additional elements added during the project will be priced or billed at an hourly rate. The contract must clearly specify the method of determining the remuneration, and in particular, if it is not a pure lump sum, what the base rate for each hour of work will be.

Łukasz: From the customer’s point of view, which billing method is therefore worth using? Is the method of billing according to actual expenditure (cost estimate, time and material) easy to control? Which is more cost-effective?

Paweł: First of all, we need to clearly answer whether, as the contracting authority, we prefer to implement the project flexibly and save on the preparation of costly project documentation (what if the project assumptions change during the process and the documentation cannot be easily corrected?). Or do we implement the project in stages or flexibly (saving on detailed analytical and design activities) and settle the project according to actual activities and expenditure? I would like to emphasise that a flexible approach does not mean a lack of control over the budget. This is always necessary and, especially in large organisations, is often subject to strict expenditure and control procedures. It should also be noted that a project implemented on a cost estimate basis based on an hourly rate does not mean that we are deprived of control – or, to put it figuratively, that we are sailing on the ocean without knowing its boundaries and limits. Firstly, we have a budget – so all activities should be adjusted to it. Secondly, a professionally prepared team is able to prepare so-called estimates, e.g. determine in advance the expected time needed to complete specific tasks or elements of the project. On the other hand, the client, adding further elements to the project that were not initially required, must take into account the need for additional settlement. In such a case, it is better to have a certain margin within the budget (assume a higher budget) – taking into account that new and unforeseen elements requiring settlement will appear. Alternatively, recognising that the additional work is a priority, it is possible to abandon or budget other, less urgent work for the next period. I might add that Time and Materials billing can be significantly cheaper than fixed price billing. First of all, you can save on complex pre-design and design documentation. In most cases, the contractor will also offer a higher amount for a fixed price, as they usually assume a considerable margin for unforeseen circumstances. Every project is different and each one carries different risks. That is why it is a good idea to consider the terms of cooperation and billing. All these conditions must then be clearly specified in the contract.

Łukasz: What do you think are the special features of IT projects?

Paweł: Usually, unless we are talking about purchasing a licence for a ready-made simple product (e.g. office software), we are dealing with a complex, time-consuming implementation process, or, from the customer’s point of view, an investment process. In addition, this process concerns goods that are not as obvious and tangible as material goods (e.g. vehicles and buildings). I am even talking about activities such as the purchase of ready-made ERP software from global manufacturers. Such software usually requires complex implementation (adapting the base software to the needs of a specific company). I would say that full awareness of this, mutual understanding and precision in agreements are particularly important in the IT industry. For example, in the construction industry – due to the very tangible results of the work, strict rules for designing and erecting structures – a construction expert will appear who will say exactly what work has been done, what materials have been used and what the price lists are (using standardised cost estimates). In the IT industry and IT projects, these standards are difficult to define. We need to consider several issues here. It is difficult to say unequivocally why people in the same positions and with the same experience, such as back-end or front-end developers, work faster or slower and what the exact reason for this is. In addition, the same results can be achieved in different ways with varying degrees of efficiency. Faster does not always mean better. Let me give you an example. Two programmes may appear to work the same way. However, a programme made with greater precision (with more effort or by a better specialist) may be better optimised, which in the case of commercial activities, for example, can be extremely important and translate into real money. Not to mention data security and process validation, the effects of which are not visible at first glance, but any problems associated with them can be extremely costly. Another issue is the fact that IT activities and projects are undoubtedly the result of creative work. It is not without reason that computer code and programming work are regulated by the Copyright and Related Rights Act.

Łukasz:
I would like us to devote a moment of this conversation to the precision of agreements. What happens when such precision is lacking?

Paweł:
The answer here is quite simple, but the solutions to such situations are not. If there are different opinions on both sides, there is a risk of dispute (conflict). If the parties cannot reach an agreement themselves, the natural consequence is the need to rely on a court ruling (common court or arbitration). This obviously increases costs and, more importantly, does not bring the parties closer to achieving the goal for which they entered into cooperation. The customer is in a particularly difficult situation, as they are waiting for the order to be completed – a dispute usually creates uncertainty about the fate of the project.

Łukasz:
What if the provisions, despite their precision, are controversial? Or, for example, one party wants to understand them differently than the other?

Paweł:
It often happens that despite the precision of the contract, a dispute arises. Of course, such a situation will occur when the contractor fails to perform the contract (undertakes to perform the contract and, despite proper financing, fails to perform it or fails to perform it in full). Another issue is that settlements often cause disputes, especially when the parties base their calculations on hourly rates. Of course, in terms of the proceedings, the so-called mutual intention of the parties must be established. There is only one contract and there can be no question of there being two versions of it. If the parties understand the provisions of the contract differently, the court will determine the mutual intention and the correct content, understanding and meaning of the contract.

Essentially, this brings us to all the issues we discussed above. Due to its nature, the lack of a tangible material effect, the assessment of the results of the work may vary. Therefore, I would like to emphasise what I said above, that in IT projects, one should be aware of the conditions for a given project, be guided by mutual understanding and be as precise as possible within the framework of a given cooperation model. Returning to hourly billing, it is a good measure – which is why it is widely used (no better or simpler measure of workload has been invented so far – and I am not only talking about IT activities here). To facilitate hourly billing, dedicated programmes have been developed for counting and reporting hours. In this context, the role of the project manager is also important, as by applying the right management model for the organisation, they also have an impact on work efficiency (and thus the workload reported to the client). Nevertheless, it happens that settlements are questioned. The client asks themselves whether such work cannot simply be done faster. Of course, it is possible that there is a company or specialist somewhere who would be able to do the work faster under certain conditions. There will always be someone faster – after all, there can only be one master. Nevertheless, we must rely on common sense here and take into account the fact that each of us works at a different speed. This does not mean that only the fastest deserve remuneration. I can give an example of a ruling where the court determined that a given specialist had worked a certain number of hours, while the other party insisted that this was impossible and that the time in which the work should have been completed had been significantly exceeded. However, the court ruled that some people work slower and others faster, and that this is natural. I am simplifying this a little – deliberately – but that was simply the implication of the court’s ruling.

Łukasz:
I can give an example where a client had a contract with a contractor for the implementation of a dedicated synchroniser. It was completed in less than 100 hours, exactly as initially outlined . Then the client began to expand the project documentation, and the further we got into the project, the more additional work he commissioned, until he was completely satisfied. I will not hide the fact that the agency we worked for signed a rather frivolous contract with its client. We worked for an agency that became a hostage to its client. The agency received successive lists of claims, which kept growing, and in this way, 50 hours of additional work suddenly turned into 300. Resetting expectations constantly resulted in new expectations and further work. Unfortunately, our client agreed to meet them every time, but we informed them each time that all subsequent work was additional work and would be billed hourly for each additional hour worked. The case of Pendolino and WI-FI, which was not available for several years, is a perfect example here – it seems obvious to everyone that it should be there, but it was not in the design specification and therefore it was not there in the end. The same is true for IT.

Paweł:
It is difficult for me to comment on a specific case without reviewing the documentation and familiarising myself with the matter – nevertheless, I can say that if the work in question was not provided for in the contract (the parties did not agree on its performance), then of course there is no reason why the contractor should not be entitled to additional remuneration for its performance. That is why it is so important to define the terms of cooperation, including the subject of the contract, the model of cooperation and the rules of settlement. It seems that your client did not make the proper arrangements with the contracting authority or misinterpreted the contract (intentionally or unintentionally). Perhaps they were entitled to additional remuneration, which they simply waived. However, when it comes to the Pendolino train you mentioned and the lack of Wi-Fi, the situation is slightly different, as we are talking about a public procurement contract under a tender procedure. The nature of the subject of the delivery is also different. Undoubtedly, however (apart from the specific purchase of Pendolino trains), the specification of essential conditions for this type of contract is extremely extensive. In such contracts, it is usually the contracting authority that dictates the conditions and specifies what it needs. If, for example, Wi-Fi is not included in the tender documentation, it is of course possible that the offer will not include Wi-Fi. This is a price-determining factor, and since the contracting authority does not require it, there is no reason to offer it. But as I mentioned, the purchase was made through a public tender, which also changes the rules of the game. Returning to IT contracts, if they are between two private companies, it is possible to forego the preparation of detailed contract documentation and choose a flexible model of cooperation. The documentation can run to hundreds of pages, and it is obvious that its preparation is costly (whether it is prepared by the contracting authority or the contractor, its preparation is costly and someone has to bear the cost). Therefore, it is possible to take a flexible approach to the order by creating less precise documentation (this is a typical case). If a dispute arises in this context, in particular as to whether the scope of work was within the original contract or not, unfortunately, the provisions of the Civil Code do not provide any ready-made simple solutions. The obligation should be performed in accordance with its content, socio-economic purpose, principles of social coexistence and customs. In procedural terms, the party that goes to court and brings an action must prove that it is right. For example, it is the dissatisfied customer who must prove to the contractor that a given element was supposed to be there but is not. Without detailed documentation, this may be impossible or difficult. It should be assumed, however, that all elements that are not necessary to fulfil the terms of the contract and were not specified in the contract will be a new contract or additional work. Therefore, it is worth ensuring that the contract contains appropriate provisions – even if the project is being implemented flexibly without detailed design documentation.

Łukasz:
So, if you want to work efficiently and flexibly, using an open model of cooperation, how do you balance the interests of both parties?

Paweł:
When it comes to remuneration, as we mentioned, in an open cooperation model without detailed documentation, it will usually not be possible to determine a fixed price, unless we are talking about simple tasks or largely ready-made solutions (the sale of prepared products or those based on proven templates or models). In any case, the contractor must be sure that they are selling a proven product and that they are able to implement it for the customer at a given price. Otherwise, it does not make sense. In the case of time and material work, the client must accept that the remuneration is based on variables. Of course, it is possible to introduce safeguards, reporting methods, commitments not to exceed monthly budgets, etc.

As for the scope of work, there is no major problem with a model based entirely on hourly rates. The client pays for the time it took to complete the work. If the client requires a fixed price, they should not be surprised if the contractor questions the scope of the expected work if it was not originally clearly specified and is not a defined necessary standard. There is no room for speculation here. The customer should demonstrate that they have ordered a given element and that it should be included in the performance. This is done by means of documentation (the minimum requirement is, for example, the customer’s requirements, mock-ups or analyses). If the contractor is to assist the contracting authority with the preparation of documentation, this will usually be a preparatory element requiring separate settlement. The parties have a great deal of flexibility, but it is essential that they are precise and do not treat the contract as a meaningless formality.

Łukasz:
That’s right, in the case I mentioned with the synchroniser, the documentation that was initially prepared took into account the client’s assumptions and requirements, but in no way specified the subsequent expectations that arose during the implementation of the entire project. The client signed the documentation and then wanted to expand the project with functionalities that were not covered by the documentation at all.

Paweł:
To prevent this, a thorough discussion of the terms of cooperation and settlement is certainly necessary. Both parties need to know what they are signing up for. However, if the client requires a fixed price, they must seriously consider the clause in the contract that states: “Technical conditions, requirements or functionalities that are not included in the order, offer or project documentation are not part of the order and will be carried out as additional work.” This brings us back to the issue of proper preparation of the order and project documentation.

Łukasz:
Exactly, please tell me, in your experience, does the court only look at whether the completed project has a registration function via a specific, strictly defined button or system element, or does it look at it only in general terms from the perspective of the functionality itself – is there registration? There is, so the Contractor has fulfilled its obligations.

Paweł:
First of all, the court is not an expert in assessing technical and technological solutions. In such cases, a court expert, i.e. a person with competence in the field, always gives their opinion. The correctness of the performance of the contract should also be assessed from a broader perspective than the literal wording. It would be difficult to expect an expert to accept the performance of a contract carried out in accordance with the requirements of the contracting authority, but using technology from 15 years ago that is not supported by today’s servers, even if for some reason the technology was not explicitly included in the contract. However, if the order has been functionally completed, meets today’s standards and takes into account the guidelines indicated by the contracting authority, there is no reason to refuse the contractor the correct performance of the contract. If, due to the contracting authority’s individual preferences that are not justified by the reasons indicated above, the contracting authority demands that the system be rebuilt (the same, but different) or demands the addition of unforeseen elements, functionalities or interactions, then such a demand is not justified and does not fall within the scope of the contractor’s obligations (i.e. it will not be covered by the contract).

Łukasz:
What can be expected from a customer if, after the contract has been performed, they claim that they simply do not like the work and will not accept it or pay for it?

Paweł:
It doesn’t really matter. Acceptance of the work is not necessary as long as the project has actually been properly completed by the contractor. The obligation to pay arises from the mere fact that the contractor has fulfilled their obligations. Of course, the rules of settlement may be strictly regulated by the parties, in particular the rules for financing the project in progress. If the agreed payment schedule is not followed, the customer should expect the work to be suspended through their fault, and even be liable for damages to the contractor.

Łukasz:
And what does the law say about how something should be done? What if the customer says they want something to work differently, even though, looking at it in black and white, it has been done?

Paweł:
As I mentioned above, if the order is functional, meets today’s standards and complies with the guidelines indicated by the contracting authority, there is no reason to refuse the contractor’s correct performance of the contract. Thus, they are not obliged to perform the work again, but in a different way. If anything, they are then entitled to additional remuneration.

Browser-based projects, especially those aimed at our client’s customers, often require careful consideration of the graphic design, ergonomics of use, etc. Here we enter the area of work whose evaluation may depend on individual taste and preferences. Our client may have a completely different opinion on this than we do. That is why it is important for the parties to cooperate with each other during the project. The client should take an active part in the subsequent stages. They should approve graphic designs, site maps, etc. In principle, this should be sufficient protection and should minimise the risk that the final result will not satisfy the client in this respect. Nevertheless, tastes are difficult to argue with, and the court will not argue with them either. If the client simply does not like something, and it meets the above-mentioned conditions, there will be no grounds to question the correctness of the work performed. The law does not go that far. If we have two painters, one better and one worse, this does not mean that we should not pay for the painting painted by the weaker one. Here, only market mechanisms and the reputation of companies play a role. A company whose customers are satisfied certainly has a better chance of market success than its competitors.

Łukasz:
Paweł, thank you very much for meeting with us and sharing your perspective.

Paweł:
Thank you, Łukasz, it was a pleasure to meet you.

The above conversation shows how important precise project documentation is in the implementation of projects if we want to receive a specific lump sum offer for the execution of an order. However, if we are unable to develop such documentation and want to maintain full flexibility in the project assumptions, the answer is Time & Materials billing. At ADream, we consider project documentation to be the basis for successful cooperation on IT projects. If you are planning to commission a website or online shop, write to us or fill in one of our briefs, and we will help you choose the right type of billing for your project.