I work in the public-procurement department in a software-development company. That means that in at least 90% of the projects I work on I have a public institution as a client. Contracts are normally defined by a document with specific administrative specifications and another one with technical features. These contain all the services that are being hired, the characteristics of the product to be developed and the maximum price of the tender. They include even the technical features of the software and the profile of the projects’ participants. It is all very narrowly defined. It is the price that the public administration must pay to avoid arbitrariness.

If our company has been lucky enough to win the tender, then both of us, provider and client, have to face the harsh day-to-day reality of projects. Circumstances change. New legislation comes up that affects the project. Things that were deemed correct a few months ago are no longer valid, because needs have changed. What should we do? If we adapt the project to every change that the client needs, then we providers have to bear the brunt of additional cost. If we refuse to change anything for the client, always waving the contract and its specifications in their face, we risk delivering something that might be perfect for last year’s decree, but—for that very reason (or for any other reason)—is no longer of any use.

The way to avoid this, or at least the way that has worked best for me so far, arises from the way of working in Scrum projects. At the beginning of the project I make a list with the features to be developed, and give them a score that the client knows right from the beginning.

I normally give the example of a large jar full of ping-pong balls. Each ball is a feature that must be developed. The jar is full. If the Product Owner wants to include two new features, I ask that person to tell me which other features—or ping-pong balls of a similar size—should we take out of the jar. Normally this vision solves the predicament and the Product Owner does not resist giving up other features, now recognizing that they aren’t important. If it all gets recorded in the meeting’s minutes and, most important of all, if the Product Owner understands what is being given up and what will be gained instead, it is normally a comfortable solution for both sides.

You can find texts like this and many other about how to manage agile projects in my book Agile 101: Practical Project Management (available on Amazon).

Translation by Begoña Martínez. You can also find her on her LinkedIn profile. Proofreading by David Nesbitt.