If you're working as a service provider for companies looking to outsource their product development, you may encounter customers who have a set of requirements from the beginning and are ready to negotiate a fixed price right from the start. When meeting such a customer, it's crucial to handle the situation so that the customer is fully satisfied and you can stay within the budget.

This blog post aims to serve as both an introduction and a set of suggestions to help you manage such projects and customers regardless of whether you are a Requirements Engineer, Business Analyst or a Project Manager. On the other side, it aims to support customers with a bit of insight into how fixed priced projects are best handled, so that they can collaborate more effectively.

Before we get into it, a quick introduction is needed of the subject matter.

What does Fixed Priced mean?

A fixed price software project is a type of contractual agreement where the client and the service provider agree on a set price for the entire project before any work begins. This price remains constant regardless of the actual time or resources expended to complete the project. The scope, deliverables, and timelines are clearly defined and agreed upon in advance.

Pros and cons

There are several benefits and risks when getting into such a project:

Pros

• Customer defines scope in advance and knows exactly what they will receive

• Customer knows the timing of the delivery, and can plan work around that delivery

• If the estimation is accurate, the service provider knows how many resources they need to allocate

• Simple, low complexity projects with a small time frame are a great option as it helps keep the focus and achieve the end goal

Cons

• Delivery and value of the software is fully dependent on the quality of the predefined requirements, deliverable descriptions

• Little room for including additional functionalities that are discovered during development

• Fixed Price projects are usually handled with a Waterfall approach which has proven to be extremely risky, especially for the customer

• Cost estimation is fully based upon an initial understanding of the customer needs. During development this understanding may evolve, thus requiring more effort

• Delays have a compounding effect. If the project plan assumes the acceptance of a deliverable by a specific point of time which is not met, then the whole project timeline may be shifted

• The fixed scope nature makes it difficult to adapt to changes in the business environment

• Large scale projects have too many risks associated

After looking at all these pros and cons, several steps can be taken to manage them well.

Project Lifecycle

Below you can find several suggestions on what you can do to support the Project setting in the Project Lifecycle

Estimations

As with all software projects, an accurate estimation means a successful delivery, happy customer and a project that has stuck to the planned budget.

Depending on the scope size though, the estimation accuracy may be reduced because of which buffers have to be introduced to support the increasing risk size.

In order to manage that, the following measures can be taken:

• Splitting of the scope into multiple smaller scopes that can be more easily handled, estimated and delivered

• Separating the requirements of the customer into risk categories, and either descoping or closely managing high-risk requirements

• In case the scope is too big, and separation is not possible, additional budget can be negotiated for design and/or in-depth analysis of requirements be. This should provide with an increased insight into the scope to be able to do a more accurate estimation

• If none of the above is possible, it should be communicated to the customer that a safety buffer has to be applied to manage all the unforeseen risks.

A successful estimation is one where you, as Requirements Engineer, feel confident in having an extremely good understanding of what the scope entails and both you and the customer are satisfied with the budget.

Additionally to understanding the scope, consider effort for the following tasks:

• Project Setup

• Testing

• Meetings

• Documentation

• Clarifications, negotiations, defect and requirement analysis

In our experience this usually is between 30-50% of additional time, depending on the customer.

Design Stage

Once the customer has agreed to the Cost Estimation of the work scope, the Design can start.

During the design phase, alongside the usual design process of clarification, backlog planning, and user story preparation, it is crucial for an RE to document and clearly communicate what the customer will not receive. It's also important to record their agreement to this. This will make life during delivery exponentially easier for both parties.

As the requirements received from the customer are the cornerstones of the design, a core part of the Design Stage is making sure that there is a common agreement on what those requirements mean, usually in a documented form to further reduce potential misunderstandings, and also to crystallize the scope and design.

Depending on the quality of the initially drafted requirements, a process of rewriting, nomenclature alignment, and acceptance criteria polishing is advised.

The customer may or may not have a product owner that can support during planning. The luxury of Fixed Price, Fixed Scope projects is that the order of implementation is usually not imposed by the customer. This way there is room for prioritization not by value (as all requirements are equally valuable in terms of the contract), but by logical, technical dependencies to make implementation as streamlined as possible.

During the design stage it can also be a good idea to already discuss the process of the customer requesting additional scope. The requests will inadvertently happen once the customer starts using different draft versions of the application and realizes that the requirements have not exactly reflected what they wanted due to human error, interpretation issues, language barriers, etc.

In these situations it is important to

• Reinforce the customer and the willingness to provide the best software product

• Highlight the limitations of the contract

• Discuss next steps in order to be able to deliver the requested feature i.e. in a different contract or by descoping something else

• Refer to the process you have agreed upon in the Design Stage

Further details about handling scope changes will be explained below.

Delivery

Waterfall vs Agile

An assumption that is usually made when discussing the delivery of fixed price, fixed scope projects is that the customer has communicated everything, you have all the requirements available, thus customer involvement is not necessary until the full scope has been implemented.

As proven thousands of times, this approach of waterfall does not work in software projects due to the sheer complexity these products usually have.

If the customer wants to have exactly what they want, the way they want it, they will need to involve themselves actively during development. Usually, a Product Owner can support the development process with in-depth knowledge, which can significantly speed up decision-making. Alternatively, a representative of the end users should be available to the development team to assist in making informed decisions that best serve the customer.

Delivery Process

In the process of delivery, the usual Agile approach shall be taken with a few additional pre-steps and post-steps.

The usual Agile approach with Scrum consists of the four agile ceremonies: Sprint Planning, Daily Standup, Sprint Review, Sprint Retrospective. These should be enough to facilitate a healthy iterative delivery to fully handle and develop the backlog items.

Next to this, the following auxiliary meetings are advised:

• Before the sprint planning, review the scope of the requirements and clarify both what they customer will receive and what they will not

• A weekly meeting with the customer to discuss any additional open topics, questions or defects

• A weekly meeting with the decision maker on the defects, potential additional scope, project health

It can also have a great benefit to provide the customer as early as possible with mockups or small PoC solutions so that they can decide whether the approach you would like to implement would actually work for them. Help the customer make the decision by also highlighting what the consequences could be, both positive and negative, so they can make informed choices.

Defects Handling

After each iteration of delivery, it is expected that the customer tests the delivered requirements. During this testing process, defects can and will appear, that can be of the following categories:

• Defects that clearly don’t satisfy one or more requirements

• Defects that don’t satisfy the spirit of a requirement

• Defects that are additional scope

Whoever analyzes these defects, their first task should be correctly assigning the defect into one of these buckets first, then providing an appropriate answer.

• In the case of clear defects, they should be planned for a further Sprint

• In the case of grey area defects, a discussion shall be had on the value vs cost. If the cost/value seems too high, the defect needs to be descoped

• Defects that are additional scope, or new feature requests should be assigned to a later contract.

Although, intuitively we want to deliver the best software we can for our customer, and solve all their problems, there simply is not enough budget to be able to do that.

Contract Closure

Hopefully, by following a rigorous delivery approach, the delivery of the full scope within the budget was possible. Depending on the timeframe of the interaction, several outputs and outcomes were achieved, upon which you should be able to build:

Outputs:

• Documentation

• Software Code and functionality

• Testing supporting the functionality (either history of testing or automated test plans)

• Backlog of unresolved defects / tasks that have been defined out of scope

Outcomes:

• A very well defined and oiled delivery process

• Great interaction and involvement from the customer

• Understanding of additional effort needed next to the requirements

You can use these as inputs to the following steps:

• The backlog of defects/tasks can be an opportunity for a new contract, polishing the application, applying improvements

• Building upon the already existing processes they can rest assured that delivery will be quicker than with other providers

• Future estimations will be more accurate with the same customer

Closing Thoughts

Whenever working in such a restricted context, it is important to always be reminded of the rules of the game. Although the natural human behavior is to support the customer and make their lives easy, this may be counteractive to the goals of finishing on scope and in budget.

Being able to provide affordable alternatives and handle difficult situations in Fixed Price projects is the bread and butter of a requirements engineer. The customer may request something completely outside the scope, and it is essential to stay open minded and try to support them with ideas that can still fit into the scope. As a last resort there is always the option of saying a well framed “no” with the goal of reminding the limitations of the contract setting.

Agreements on processes should be made early to avoid surprises and negative emotions on either side.

Handling such projects can be tough but extremely rewarding if you can stick to the initial planning.