Time&Materials? Definitely!

At the end of 2014, we made the decision, that we will not implement new IT projects with fixed model. We decided to work only with time & materials model, using agile methodologies (SCRUM model mainly).

I wanted to write about  reasons for choosing time & materials model.

Understanding

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.

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)…

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).

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

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.