Budgeting a project: agile SCRUM methodology with a fixed price?

It is a quite common scenario when a client approaches us with their idea and asks for an exact project costs evaluation. As a requirement, he wants the project to be developed in line with Agile software development methodologies because he was told it is the best way to go. Faced with two contradictory requirements, one can’t help but wonder: Can you combine a fixed price approach with the agile SCRUM methodology?

TL;DR:

1. To evaluate a project within a fixed price model, it is necessary to own the whole specification and you have to account for risk.
2. Agile software development imposes a flexible approach to requirements and a willingness to accept changes.
3. Combining Agile product management with a fixed price model requires planning tasks in advance and relying on Change Management (which, like all things dealing with future predictions, isn’t very reliable itself).
4. Even if you make a budget estimate based on a very precise specification, there’s still no guarantee that the cost won’t change. This is caused by SCRUM’s flexible nature and the fact, that every app operates within a changing environment (devices, operating systems, 3rd party services, infrastructure, laws, etc.).
5. The fixed price model is adjusted to optimize finances at the expense of good practices which can only result in lowering the quality of the end product.

What is Agile SCRUM methodology?

New projects, we all love them. We love accepting challenges and we love the excitement that comes along with all the possibilities. From my experience, the Agile SCRUM methodology is great when it comes to managing projects with different levels of complexity and scale. SCRUM proved to be the best solution especially when we were developing small projects in the MVP phase. Why is that?

Because SCRUM gives us loads of possibilities to make changes while realizing and testing the concept before it will be shown to the end user. This made it the perfect methodology to be extended outside of the IT and implemented, with success, in other fields. Which industries? Well, the list is long by just to give you an example SCRUM is often used in manufactures, military, laboratories, universities etc.

Agile Project Lifecycle Management

What is the “fixed price” model?

The fixed price model assumes that the assessment of the finance costs, needed to complete a project, must be made by the contractor in advance. To set the price, it is necessary to determine the functional scope (required by the client) and also the time that is needed to finish a particular project in a given price range.

Attempts in doing so very often face one very big limitation: the lack of full requirements. Frequently, at the beginning of a project, it is very hard for a Product Owner to extract all the important details from a broader idea. This is completely understandable, although it makes it impossible to evaluate exact costs.

This is one of the reasons why lean methodologies (e.g. Agile SCRUM methodology) were invented in the first place so that it would be possible to work on a project without having to determine the whole scope and supplying the development team with a full documentation.

Why assessment is so important

Cost evaluation is a very important element when you start a business relation. It helps the contractor to become more aware of the project feasibility within the resources that he has available. At the same time, the Product Owner has the possibility to familiarize with the team and the way they think.

Basically, the better we get to know each at the beginning, the easier it will be to work together later. But the most important part of making a cost estimate is so that the client can find out if he can afford it.

One project, different prices

Usually, the Product Owner will send dozens of e-mails, to lots of different companies asking for their costs estimates. Furthermore, it is not a secret that he is also asking for an evaluation of a project he has already done. Entrepreneurs do it to find out what the capability of a particular contractor is.

Is it worth the effort? It is hard to say because all projects are different, as well as the people behind them. Every programming team has its own experiences and various problem-solving approaches (connected with project-specific issues).

Agile PLM and possible risks

If the Product Owner is interested in Agile software development, which will allow him to make changes while working on the project, he should keep it mind two things:

• Estimates must account for risks connected with change requests. It all should be taken into consideration while making evaluation within a fixed price model.
• The price that is given at the beginning should be treated as a pointer of how long a project should take. Final estimations will never be equal to numbers given at the starting point.

The truth about projects with a fixed price and the Agile software methodology is that no matter how hard the client and the development team try, it is really difficult to stay within the budget. At this point, the SCRUM team is faced with a challenge: to find an optimal way to tackle with the change requests it is given.

The fear of changes

Even though we are familiar with the term Change Management, very often what works, in theory, doesn’t apply in practice. Mostly it comes down to counteract the effects of making changes. As a result, we are making an excessive effort to prepare for changes that may never come.

All the actions we undertake to avoid possible changes mean that more time will be needed to prepare complicated, preventive tools. This renders Agile methodologies impaired because dealing with change is what they were made for.

Transparency helps

To sum up, the initial assessment should mostly help with:

• dividing project fields,
• presenting initial development concepts,
• assessing a plan of action, while keeping risk levels at 20-50%.

While making the assessment, the team preparing the estimates must take into consideration the possibility of potential problems that can occur a few weeks or months after beginning. In this situation, the Product Owner agrees with increasing additional costs, which can be used in any other way.

Watch out for welters of changes

On the other hand, there is always a risk that the Product Owner, encouraged by the ease of requesting changes, will start to enforce them even though they’re not a ‘must have’. That may lead to fixing that isn’t broken or over-analyzing details of low importance.

Planning to the rescue!

In order to make an initial cost estimation, the analyst must first collect all functional requirements. Then, while planning the project, the Product Owner, with the help of the rest of the SCRUM team, should work out the backlog and which tasks should be done in the upcoming sprints (according to the Agile SCRUM methodology).

Even if the client and the contractor have the same final vision, we should always remember about managing current tasks and controlling the total progress of the project.

Planning by The Simpsons. Source: giphy.com

One of the big advantages that come from planning tasks in accordance to the Agile SCRUM methodology is that the longer we work on a certain project, the more precise the assessment. This is possible thanks to the constant communication between the development team, the Product Owner and the stakeholders and thanks to the work rhythm that’s implemented in agile projects. Because of that, we can predict the costs much better than if we were using the fixed price estimation model. The better we know the specification of a particular project, the easier it is to predict how long it will take to make a functionality.

The spec isn’t everything

The project and the team’s social dynamics is another factor that makes it more difficult to evaluate the project time. The speed with which new technologies are emerging is consistently amazing. These solutions are arising, evolving and disappearing unstoppably.

For developers, it is not a surprise that the solutions taken into consideration at the beginning are changed on behalf of something new and more effective- even if while making the project. This doesn’t mean that the situation like this happens quite often, but it is important to be aware of it.

The dynamic of current technologies makes old software development methodologies obsolete (with highly specialized exceptions). Their outdated and stiff structure makes it almost impossible to optimize costs.

The Agile SCRUM methodology allows us to practice all the new components that are used to solve any difficulties. Today’s software is mostly the blend of ready-made elements and a specific business logic that defines the uniqueness of a project.

Is fixed price + Agile PLM pointless?

This is a complicated question with no clear and objective answer. From my personal experience, I would say that combining a fixed price model with lean methodologies will cause more harm than good when you are not aware of potential consequences. Especially within a dynamic framework, a huge market competition and a will to keep adapting a project if necessary. Instead, Product Owner should always consider using the time & materials model: in which the client pays for the time in which the project was realized. However, it’s quite obvious, that the client would prefer to know the total cost of each of the project phases.

The fixed price model imposes the costs optimization and not the optimization of achieving an effect. Such a financing model creates a very guarded attitude on both sides and leads to over-analyzing operation effects.

Check out other agile methodology related articles on our blog.

Sources:
www.scrumalliance.org
www.timecockpit.com
www.drdobbs.com 
www.nearshoreexecutives.com