The FFF Utopia
Why I find Gorbunov Bureau’s approach useful for business but question whether it works everywhere. On flexible scope, fixed commitments and the authority PMs actually have.
FFF (Fix Time, Fix Budget, Flex Scope) is Gorbunov Bureau’s approach to project management. They preach it like gospel. Fix the deadline and budget, protect quality and flex the scope when necessary.
At first glance, it’s a bloody brilliant model. The business gets predictable costs and a launch date. The client gets a working product. The team knows the constraints. Businesses love FFF, and I can see why. When it works, it helps you avoid missed deadlines and features of questionable value. But I have a few questions about how this works in practice. Especially in client-funded software development, where the delivery team doesn’t get to set the terms.
Not everything is flexible
FFF rests on one key assumption: you can change the scope without losing the product’s core purpose. For a new service or an MVP, that makes sense. Drop the secondary features, ship the first version and test your assumptions with users. It gets harder with enterprise systems, mandatory integrations and features carved into a contract. A system might need to submit data to a government service, meet security requirements or support a specific business process. Remove the essential part and the remaining product is useless. Even if it technically launches without a hitch.
Which raises a fairly basic question: who decides what can be sacrificed? If a decision means changing an approved spec, procurement budget or acceptance criteria, the PM can’t just drop a feature. A client who happily flexed the scope on one project may refuse to do it on the next.
The conditions we conveniently forget
Gorbunov Bureau openly says it works directly with the decision-maker and won’t take on projects with several independent centres of authority. That does make getting changes approved rather easier. In software delivery for clients, you may not have that option. The client has a product owner, an IT director, security, procurement and a few other stakeholders for good measure. Something one person is ready to approve in five minutes can take everyone else several weeks.
The Bureau uses FFF within a particular model of client relationships. PMs elsewhere are sometimes expected to deliver the same result without the same authority. They usually don’t get to choose the clients, rewrite the contract terms or turn down the project. At that point, I’d question whether the method fits the situation, rather than whether the individual PM is any good.
A fixed budget
Financially, FFF is genuinely appealing. A fixed deadline limits how long the work runs. Flexible scope helps protect the project economics. Managed well, it can work for both sides. But the option to reduce functionality needs to be built into the agreement from the start. Ideally, you also establish who makes those decisions, how acceptance criteria change and what happens to the work you cut.
Picture a fixed-price project with a thin margin. The estimate turned out to be optimistic. Part of the budget is gone, and the client still wants the original scope. Meanwhile, changing the contract requires a new procurement process. No matter how lovely the method is, it won’t create extra capacity. You’re left negotiating the constraints, revising the plan or escalating the decision to senior management on both sides.
The Bureau itself acknowledges that agreeing to FFF upfront doesn’t mean a client will happily accept a particular scope cut. Its published discussion of a dispute over a removed button shows just how painful that can be. So even if you follow the principles, negotiations can still end in a no. That’s a normal commercial risk. It shouldn’t automatically go down as a PM’s professional failure.
Where the PM’s responsibility ends
This is where I particularly dislike the idea of using FFF as a universal test of good project management.
A PM should track constraints, flag risks, suggest ways to reduce scope and explain the trade-offs. They can’t guarantee the client’s approval when that client is bound by a contract, internal procedures or genuine product requirements. Failing to get a scope cut approved doesn’t automatically mean the PM is doing a bad job. Sometimes it means the delivery model was wrong for that contract in the first place.
I like the principles behind FFF. Fixed constraints encourage discipline. Short iterations produce results sooner. Having to choose what matters helps prevent pointless scope creep. But applying those principles requires the right business conditions, contract terms and decision-making authority. Without those conditions, expecting a PM to make every part of FFF work is a bit odd.
This is my personal take
Gorbunov Bureau and Nikolai Toverovsky offer project management training that I haven’t taken. I’m not claiming to know every detail of how they work. Their published principles do give us enough to discuss where the method may run into limits in client-funded development. If Artem Gorbunov, Nikolai Toverovsky or anyone at the Bureau reads this and wants to change my mind, I’m easy to find by name. You can also get in touch through the blog. I’d be happy to talk specifics. And obviously, I wouldn’t turn down some free training either.
Flexible scope is a great idea. Ideally, it shouldn’t require flexible contractual obligations.
Let's Compare Notes
I shared this article with experienced IT professionals from other agencies. They've all been working in custom software development for years. Below are anonymous opinions from specialists who regularly have to make similar decisions on their own projects. I'll keep adding to the list.
In all the years I've been working, I've seen this approach used everywhere. But honestly, I've never once managed to see it through to the end, because I don't have control over all the variables that come up along the way.
I've always thought this was a pretty strange way to manage project finances. Here's an everyday example: you walk into a shop and say, "I want this, that, and a whole bunch of other things." The shop assistant says, "That'll be a thousand rubles." She takes your money and disappears behind the counter. Then it turns out she doesn't have this at all, there's only half of that left, the fifth thing isn't quite what you wanted, but the tenth one is perfect. And your thousand rubles are already gone.
FFF requires clearly defined responsibilities and costs for specific deliverables. Basically, it should look like this: Stage 1 — mandatory. Stage 2 — mandatory. Stage 3 — we need this specific part. The first 35% is mandatory; the rest is optional. Stage 4 — optional.
That way, the contractor can honestly say, "You pay us X, and we guarantee Stages 1 and 2, plus 35% of Stage 3. But if we happen to have any time, energy, or budget left (assuming Claude hasn't eaten through all our limits), we'll build the remaining 65%, throw in Stage 4, and even put a nice little bow on it."
Just make sure you agree on a Testing Program and Methodology (TPM) upfront, one that doesn't include anything we're not firmly committing to deliver. Then you can sign the contract and get to work.
Another problem with the economics of this approach is that you can't change absolutely everything, the way you can with T&M. Say someone orders a bicycle and then asks you to turn it into a moped, except you've already built the bicycle frame in a way that makes it impossible to attach a fuel tank.
My favourite setup is fixed budget, fixed scope. Any deviation from what's been agreed goes through a contract addendum — or it's a firing squad. If I've estimated and agreed on 10 developer hours for a button, and the developer finishes it in 8, we're probably not going to spend those extra two hours tying a pretty bow on it. Most likely, some other work will eat them up, or I'll eventually buy myself a beer with that money.
I’m a project manager. About working with russian clients and teams, sharing experience and things I’ve noticed.