If managed not to slumber through Part 1 on estimation, then you find yourself waiting with bated breath for the dramatic climax of our tale of estimation and fixed bid projects.
For the sake of this discussion, a fixed bid project is a project that has a fixed price based on a defined timeline. Of the fixed bid projects that I’ve seen, the timeline often has a 10%-15% leeway on the timeline. The cost almost never does – so you can be late, but you’re going to swallow the cost. Also common, just to twist the knife a little bit more, is the penalty clause. If you miss the date, not only are you going to pay for the additional time and resources, but you’re also going to have to pay the customer for the privilege.
Customers who are operating on fixed bid projects also tend to have a clear roadmap of what features they expect to be delivered, and, more importantly, they tend to have a clear idea of when they expect those features.
Why on earth would anyone get involved in a fixed bid project in the software world? I’ve pondered this question myself on more than one occasion, but outside the rarefied world of product companies and early to mid stage startups, fixed bid projects are far more prevalent than you might think.
We’ve concluded that estimation is hard but necessary, but how does this relate to a fixed bid project? Well, you really shouldn’t get involved in a fixed bid project unless you have a really strong handle on your estimation process. But there is a problem, even with excellent estimation.
Fixed bid projects are rooted on two perceptions, both of which are fundamentally flawed.
- The customer is 100% crystal clear on everything they are looking for. They have considered every eventuality and have documented a response in their requirements.
- From those 100% accurate requirements, the supplying company i.e. you, can produce an estimate that isn’t a guess but is in fact accurate to a clearly understood margin of error. Often this margin of error is contractually defined.
To put it another way, your customer has become a prophet and you’ve become a fortune teller.
Despite this, many business only operate with suppliers offering fixed bid agreements. If you want to play in this arena, then you need to develop the tools to make it work.
The Secret to Fixed Bid
It’s no coincidence that the first part of this post dealt with estimation, for a successful fixed bid project you need to be good at estimation. If you’re not, either your customer will not get their delivery in the timeframe they expected, which may lead to financial penalties for you, or you’re going to have to swallow the time and materials cost that it takes to get your customer their delivery. Sometimes both of these scenarios are true.
The second element is discipline in managing change. You need to deal with the perception that your customer has defined all of their requirements. By implication, anything that is not defined in the requirements is a change and needs to be dealt with as a change.
- In dealing with the change, you must:
- Notify the customer of the change
- Agree with the customer that this is a change
- Estimate the impact of the change, including its ripple effect
- Agree the cost and timeline of the change
- When will you take the change
- What does this do to timelines and penalty clauses (if any)
Every time you don’t follow this approach you’re working for your customer for free, or worse paying your customer for you to do the work.
The Agile Question
Fixed bid projects are naturally undertaken with a focus on minimising the deviation from the plan. Agile in contrast is founded on the principal of embracing change.
How can we reconcile these two seemingly contradictory positions?
The Agile Context
One of the more nuanced elements of Agile that is often skimmed over; completely ignored or perhaps just misunderstood is the context under which the agile process is operating. Specifically, the business context.
In Agile Project Management, Ken Schwaber briefly deals with context as a key success factor to the successful adoption of Agile (in this case scrum) in an organisation. Unfortunately, more often than not, the assumption pervades that the organisation should change to adopt agile rather than agile adjusting to match the organisation. Not surprisingly, the truth lies somewhere in between. The organisation must shift somewhat, but equally, the process must adapt also. If your business is largely dealing with fixed bid projects, why would anyone expect that to change because the organisation has adopted an agile approach?
Regardless of your preferred flavour of agile, I believe that the fundamental question being asked of self organising teams is:
How are you going to deliver this feature with the constraints that are established by the way the business operates?
In a fixed bid world, this means, given that I need these features delivered in this timeline, how is the team going to organise itself to deliver? My expectation would be that the team will come back with options on:
- ResourcingAdding more people to the project, or a different skill set or perhaps a different set of tools
- QualityPotentially adjusting the definition of done to accommodation a different approach to testing
- ProcessThe team might propose a different way of working, running two shifts for example, or weekend work.
Ultimately the challenge for an agile team is how will they adapt to the circumstances inherent in a fixed bid project.
Sprint planning, in theory becomes somewhat easier, as largely the sprint goal and the backlog prioritisation have been agreed well in advance. The sprint review on the other hand is an area of contention.
Agile approaches suggest that the sprint review is an opportunity for the customer to feed back on the delivery, identify gaps and re-prioritise the backlog on that basis. That approach is impossible in a fixed bid project. You can still run the demo, you can still gather the feedback but, most importantly, any change as a result of feedback from the sprint review needs to be managed as a change request. That process must include prioritisation and cost.
There are no free changes in a fixed bid project
Agile projects can operate in a fixed bid context. It’s somewhat unnatural by comparison with ‘normal’ agile projects, but most of the good practices that emerge in agile projects – face to face communication, individual commitment and so on are still good practices in a fixed bid project and shouldn’t be thrown out because of a different business context.
Fixed bid projects in many respects are an opportunity for the development teams, and by extension, for the business as a whole to demonstrate its genuine agility.