At the end of 2014, Tom and I made the decision, that we will not implement new IT projects with fixed model (fixed price, fixed term, waterfall implementation model, where, after several months of work the customer receives a finished product, within the budget specified at the beginning). We decided to work only with time & materials model, using agile methodologies (SCRUM model mainly).

We believe that this important decision will be followed by far-reaching, positive consequences for our partners and the entire company. We have had a lot of experience in conducting e-commerce implementations in both models and sales talks.

Therefore, we were slightly afraid of the reaction of some of our partners to definite refusal of approaching projects in a fixed budget. Experience has shown that customers in the trade sector, in which we often operate, persistently seek to “close the budget” of a new project (“I need to know how much it will cost”). Sometimes they are very suspicious (“you have to take full responsibility for it”).

The last four months I spent mostly on discussions and “converting” the projects, in which talks have already started – from fixed price to time & materials model. No customer has resigned. What’s more, even the biggest skeptics managed to come back and thank us. Their projects were finished earlier and in better quality than was assumed.

Tom has already written about why you should build your IT department along with the implementation company.  I wanted to write about a few additional reasons for choosing time & materials model that emerged in the discussions I mentioned before.

Understanding

Working in time & materials model requires understanding of the model by both parties. Proper understanding from the customer’s side is especially important. Working in agile methodology includes creating and work of a team consisting of representatives of both sides of the project.

In Divante, a SCRUM team always includes a Product Owner – a representative of the customer, who makes business decisions about the shape of the system. In addition, the project consists of specialists (mainly from our side, but they can also come from the client’s team – programmers, project manager, analysts etc.).

Such division of force means that the commissioning side has full control over the shape of the resulting application. We engage our customer in planning the scope of work. Before the start of each work iteration (usually sprints last two weeks), there is a meeting, during which the team plans the scope of the next sprint (planning) and summarizes the previous one (retrospective). Tasks are estimated through function points or “ideal time” (how many hours can the task take if the programmer is not distracted by anything else). After each sprint both sides know how much has been done with respect to what was planned (the speed of the team can be determined). It is very valuable information for planning the next sprint.

After each sprint a demo takes place where the team presents completed functions ready for testing by the client. The assumption is, that after each sprint, publication and usage of the newly created function should be possible. Our customers also participate in dailies (15 minute meeting, often on Google Hangouts – when the customer is out of our headquarters) where they can react to all the informations about project and know exactly what it is/was/will be done.

Customer participation in the project means, that at any moment, the scope of work may be further clarified – add or delete tasks from the next sprints (the current sprint should not be modified) and determine whether the quality of a particular function is sufficient or not.

An argument, that is often raised against the model without a specific volume of work, is the concern that the customer will not be able to control the project budget and an implementation company can perform a variety of tasks freely and profit at the cost of an unaware client :)

Certainly, there are companies that do it, but it is very short-sighted because sooner or later they end up with a lack of trust and efficiency. A first joint project becomes the final one. Hardly anyone can afford it, given that IT companies live mostly off the sale of services. Selection of an implementation company is important – it is especially worth looking at references and portfolio. I am convinced that, just like our company, other major companies do not deceive their customers.

If we assume that every implementation company aims to establish the best and fastest team – customer participation means that the project can be implemented faster, if we agree to simplify it, it may be decided to implement a simplified MVP version, which be expanded later on. We can do a lot of things.

Clarity

In contrast to the above – in the fixed model, after the analytical phase of a project, a curtain is lowered and the team starts working. It is not beneficial for an implementation company to inquire the client or present anything, as it may cause expansion of the scope of work. There are no ideal pre-implementation analyses. Work is often commenced, when the results of the analysis are “good enough”. This means that, for example, they describe the exact effect of a frontend application, not taking into account an administration panel.

IT project is not a project of a wooden cabinet, where everything can be discussed and drawn before the work begins, and then only require the quality of it. This is a project for several months – often without a clear picture of the final result. During these months, the requirements also change.

Any lack in specifications is a great opportunity for an implementation company to save money through the implementation of a function in the simplest way possible. Most companies have provisions in contracts saying that in the absence of a precise specification the functions will not be realized, or realized in the easiest way. This is exploited especially when other parts of the project have cost the company too much (because they were badly priced)…

Ongoing demos are not presented – there is no reason for doing that. There are stages – usually 2-5 months. After that, the customer receives the product and the fight for acceptance begins. Often the product differs from ideas and sometimes it does not fulfill its function at all. But you can prove that it is consistent with the specification and force acceptance :)

It is just not right. Poor quality intensifies customer dissatisfaction, long discussions on the acceptance protocol ruin relationships. As a customer – we were glad that we have the budget under control but in practice, once the work began we have lost control over the shape of the project. Such situations are not possible in the agile approach. In addition, the customer has up to date insight into the ticket system where the progress is updated (in our case it is JIRA or Redmine) and insight into the source code (through Gitlab) where code & review may be led if it is required.

Deadlines

When it comes to deadlines – transparency is crucial here, too. Usually implementation companies working in agile models allocate the entire team full-time to the project. This team is not occupied with other projects and works as fast as possible. The customer participates in dailies so it can be observed (even by the number of performed tasks).

In fixed price model, companies exploit the fact that they have a fixed deadline. It is most often established with a buffer. The buffer is sometimes used for… other projects or putting out fires. In the agile approach it is the customer who decides when to run the project – and it will be done as soon as possible – in the fixed approach, the project will not be started before a certain date in the contract. Exactly then, or as practice shows, later (due to erroneous estimates at the start).

Estimates are realistic

In fixed model there are always buffers added to price evaluation. In practice, the buffers are at the level of 40-100% per function. The worst thing the customer can do is to require price evaluation without analysis. Surprisingly, this does happen quite often (always refuse to start a project with these assumptions, it is suicide).

In time & materials model it does not make sense to add buffers to price evaluation – an implementation company is not afraid that it will have to pay extra for the project because the client actually pays for all the hours of work. Unconvinced customers are welcome to participate in a workshop with an implementation team where features are estimated and discussed. In such arrangement, the customer is 100% sure as to what has been evaluated (Or maybe some assumptions have been missed? Maybe some are exaggerated?). Projects done in time & materials model are simply cheaper. The only exceptions are situations where the project is really very complicated – R&D. In these projects, there is nothing to compare lead times with. Fixed price model will then create the impression that it would be cheaper. But it would appear so only because the project would be sponsored by an implementation company.

An implementation company sponsoring a project is not a good partner. Sooner or later (usually in the maintenance phase of the project) we will pay extra exactly the same amount of money we got from the customer during the implementation.

Is it for everyone?

IT implementations are not for everyone. If your partner is not ready there are usually a lot of objections against settling in time & materials. For example, there is no IT department that could evaluate the work and… build trust (“Yes, they are doing it well, it takes that much time, I’ve seen the code”). There is no project manager with technical knowledge that could be the product owner. (S)he does not know what (s)he wants to achieve and the company does not support the project (usually an implementation requires the involvement of many departments).

Summary

All the major implementations we have done were realized or ultimately came to realization in Time & Materials model. In this way, we work for TIM S.A. (a shop that sells for > million PLN per day). That is how we work for CDP.pl. That is how we worked for Reserved.comThat is how we work for all foreign customers.

If your project is important to you, you care about content and quality – you should choose agile model. It gives the best results, as fast as possible and with minimum costs.

Piotr Karwatka

CTO at Divante eCommerce Technology Company. Open-source enthusiast and life-long builder. Co-founder of Vue Storefront and Open Loyalty. Now gathering engaged communities around new technologies. | LinkedIn | Twitter

Share your comment