Fixed-price projects

Playing software development on Nightmare difficulty

Anyone who ever had a Project Management 101 course knows that famous image of the Iron Triangle. A project has fixed Scope, Resources, and Time. Stretching one leg of the triangle will impact the others. Want to add more scope? Be prepared to throw more Resources at it. Running out of Time? Cut some Scope.

The Iron Triangle (or Triple Constraints) is not an invention of software developers. It's a tried and tested way to keep any project on track.

Well, almost any…

Software development projects are notoriously difficult to scope right. We've learned over the decades that designing upfront is tough. New insights and wrong assumptions inflate the scope, stretching the other legs of the triangle.

Contemporary software development is largely based on the notion that while you can't always throw more people at it, you can always descope. Drop a few features. Implement the Aldi version of a solution. That works amazingly well in a product environment. Descoping is the ultimate tool to keep the budget under control.

Planning for those product teams is easier because there are so many levers we can play with. We can pick the scope and timing. The resources are usually the only real constraint.

But in many companies, the Triple Constraints are a harsh reality; And there is no harsher reality than the cast-iron triangle of a Fixed Price Project (FPP).

Fixed-price projects mean playing software development on Nightmare difficulty. They are tough and risky.

While it's easy to be cynical about these types of projects, cynics don't get shit done. I'm interested in what we can do when we're dealing with such a project.

Before we take a look at pragmatic planning tools in a fixed-price context, let's get a caveat out of the way: if you undersell an FPP, you'll lose money. There is nothing you can do to fix that afterward.

In a time-and-material approach, developers bill by the hour. That means the customer is responsible for allocating those hours well. The developer gets paid regardless of the outcome. That's why you'll typically see lower prices when billing by the hour: the customer assumes the risk.

In an FPP, the developer assumes the risk. They demand a fixed fee for a guaranteed outcome. If they have to do more work than estimated, it comes out of their own pockets. That is why fixed-price is typically more expensive: high-risk, high-reward for the developer, zero risk for the customer.

Margins

That brings us to our first tool: margins. If you've landed a fixed-price project after a race-to-the-bottom price war, there is nothing you can do to make this project succeed. Without healthy margins, the triangle is fixed, and there is zero leeway. You'll have to hope your estimates were spot on. Low-margin FPPs are the nightmare scenario.

So, add margins to the team's day rates or the overall project. While that's a tricky trade-off for salespeople, it's vital for project success.

Now, the key is to inform the project manager of these margins. Don't keep them a secret. A PM should know exactly how much each team member costs and how much their time has been sold for. By giving the PM control over the margins, they get some leeway with the Resources leg. That allows them to catch up by having developers work more than estimated. Cutting into your margin is to be expected in fixed-price projects. That's why they are there. That's why we want these comfy cushions.

Another healthy approach is to give a PM a financial budget as well. They can bring in a freelancer to inject niche knowledge or buy a tool to speed things up.

Buffers

While iterative buffer planning is harder with a fixed scope, we can set up a similar system. Projects typically have some kind of Work Breakdown Structure, a hierarchical list of all the work. Identify the high-level work items and add two weeks of Recovery after each one.  

These buffers give us leeway on both Time and Resources. They'll extend the project's lead time, allowing you to catch up when you're behind schedule. They'll also act as another margin: two weeks of extra development days. Again, you don't have that luxury if your project has been undersold.

The problem with a buffer is that you only know it was not big enough when you burn through it. That's why you don't just want to slap a big "contingency" buffer at the end of the project. Cutting into the buffer after a work item is totally fine. That's why it's there. Burning through it completely, however, is an early warning system. You don’t want to move that early warning system to the final weeks of the project.

Sprinkle buffers throughout the timeline rather than keeping one at the end.

Don't "do Agile"

Agile software development can be great for projects, but most "Agile" frameworks are not. Don't waste time with backlog grooming and prioritization sessions if everything is must-have. The cash spent on a Scrum Master should be spent on an IC. There's no point in estimating User Stories if we can't use those estimates to simplify and descope. Retrospectives will always result in "we need more time and resources". 

Spend more time analyzing the scope and writing that down. Developers have very little creative leeway in such an environment. Pretending otherwise is expensive and frustrating for all parties. 

Keep a Success Metrics Log

If fixed-price is your business model, you really need to keep a log with project success metrics. For each project, you want to see the original estimates, the day rates, commercial discounts, margins, and their final results. 

At the start of the project, write down the predictions in a log file. 

"It is gonna take 150 days, is sold for €600K, with a total of 5 developers, with a projected profit of €150K." 

And then plan a post-mortem meeting for the final day of the project. During that meeting, add the actual metrics to the log file. 

"It took us 176 days, resulting in an actual profit of €75K."

While there is little a PM can do to steer an undersold FPP, capturing the actuals will help the company make informed decisions on its next one. 

"Given our track record with this kind of project, we can't give more than a 7% commercial discount."

"Our Drupal projects consistently outperform our NodeJs ones."

Fixed-price projects are high-risk, high-reward. That means not all of them have to be within budget to be successful. Enough of them need to make a profit to compensate for the losses.

That's where a success metrics log can be invaluable.

---

I led my share of fixed-price projects in my younger years. I'm more of a product guy these days. It's a type of project that's easy to hate.

But there's an entire industry that relies on tight iron triangles. That means a lot of companies make this paradigm work. That makes it at least interesting to study.

One of the last fixed-price projects I ever did was a complete dumpster fire. It was a year behind schedule when I was brought on, and while I frantically tried to turn that around, the project never became a success. Over budget, over time, and underwhelming results. I gave it my all and still failed. 

I didn't get the "high-risk" part back then. Someone sold something that they thought they would make a lot of money on. That's a gamble.

FPPs are restrictive for managers. That doesn't mean there's nothing they can do. They can find creative ways to stretch the triangle's legs through margins and buffers. They have to get the team laser-focused on delivering rather than "Agile theatre" and record the success metrics to improve future projects.

That's a valuable job.