IT projects: Everything agile or still waterfall?

Lawyers are usually only confronted with the topic when instructed to create the appropriate contractual basis for such a project. And then it often proves complex to create the perfect contractual setting. It is essential that the lawyer understands how an agile project differs from a waterfall project.

The waterfall project management model is linear, so the project phases are not arranged in iterations. The typical phases in an IT project are: (i) planning, specification, draft project plan; (ii) creation of statement(s) of work; (iii) conversion; (iv) implementation and integration; and (v) approval tests.
As a classical project management method, the waterfall model often has its limits. Project phases may not be clearly definable in practice, setbacks due to incorrect planning and repeating project phases cost time and money, and above all it is impossible to specify all the requirements in detail at the beginning of a project. Especially with new developments, unclear or changing requirements are the rule rather than the exception. In practice, it is not uncommon to find at the end of the planning process that the previously defined requirements are no longer up to date, because the requirements have already changed. Change requests are of course necessary, but are often (with good reason) bound to formalisms and are time-consuming in the agreement.

For complex developments, companies are therefore increasingly relying on agile project management methods. The best-known agile method is called SCRUM. In contrast to the linear approach, SCRUM follows an iterative approach. The actual development work takes place in so-called sprints. A sprint is a defined period of time, usually two to three weeks, during which the team creates or changes a small part of the overall project based on a short and precise performance description. The project is therefore completed successively. Short daily meetings of about 15 minutes serve to exchange information about the current status of the process. The tasks of a sprint are listed in the so-called "Sprint Backlog". Within this backlog, the requirements may not be changed, which ensures a certain continuity for the team despite the actual dynamics of this method.

The Scrum Master mainly takes on coordination tasks, ensures that the SCRUM process is adhered to, resolves conflicts and moderates meetings. As a rule, he does not have the authority to give instructions to the team members.

The Product Owner is responsible for the product and maintains the important interfaces between the stakeholders.

The Scrum Team decides itself how to implement the requirements.

Among the frequently mentioned advantages of an agile project are: (i) more flexible adaptation to changing needs of the client or needs that are only determined in detail during the implementation of the project; (ii) closer involvement of the client; and (iii) greater transparency during implementation.

"Agility in project management has almost become mandatory, for better or worse."

An often (in our opinion wrongly) cited advantage is that the laborious and time-consuming phase of the specification of the actual object of performance at the beginning of the project is significantly shortened. Apart from this, there is also an undeniable disadvantage that is very difficult to handle: when signing the contract, it is impossible to precisely estimate the costs and duration of the project. This is a massive problem. Almost every client requires a certain degree of cost predictability when placing an order. For good reason, work contracts with lump sum prices are still the preferred form of contract when commissioning large IT projects. However, providers often argue (in our opinion incorrectly) that an agile project method cannot be applied to a contract for work, perhaps even one with a lump-sum price, because their contents cannot be combined. From their point of view, providers want to put themselves in the much better position of a service contract instead of a contract for work and services with a time and material settlement instead of a lump sum.

To achieve the best possible output from both models, a hybrid approach that combines the advantages of each is ideal. For example, an agile approach is agreed upon with a contract for work and services including a lump sum. This is especially possible if the parties have taken the trouble to write a sufficiently detailed description of services (usually called a SOW) before commissioning the project. This gives the team members a certain amount of leeway while meeting the requirements of the management. Interestingly, such models are especially conceivable for very large projects, which allow both sides to include enough buffers in the planned cost and time factors to absorb the deviations from the originally planned scope and schedule that inevitably occur during the iterative procedure.

Contracts for agile projects are typically characterised by the following:

• Payment in partial amounts each time a useful part of the work has been completed, as motivation to complete the project quickly. Motivation to work quickly can also be achieved through bonus payments when a sprint is reached quickly.
• Estimate of effort not time-based (and thus cost-based), but as relative effort by means of so-called "story points". Story points are a unit of measurement for the total effort of a "user story". Each task is assigned story points, which reflect the complexity and effort. A story, which is evaluated with one point, is therefore half as large as a task with two story points. The story points are awarded by the entire Scrum team. However, it is only about estimating the complexity of the implementation of the individual user stories to each other, not about a time estimate for the individual user story. Only once the estimate is confirmed or supported by the entire team is it converted into a financial evaluation. By using the so-called velocity factor, the experience of the team and thus the speed of implementation can also be included in the calculation.

The usefulness of these features for the contract is to be checked and assessed in each individual case. Nevertheless, it is imperative that contractors and project managers coordinate closely. A drifting apart of the actual procedure with the contractually agreed methods must be avoided at all costs.

authors: Wolfgang Tichy, Peter Ocko