Agility within a client environment - tackling fixed bids
12 September 2012
I recently gave a talk on Agility within a Client Environment at Agile Evangelists’ 15th meetup. Rather than prepare a talk, I thought I’d ‘ask the audience’ so adapted a retrospective technique for the purpose. I asked the group to write down any questions that they have relating to the talk topic on a post-it and then put them all up on a whiteboard, went through the questions and grouped similar topics. We voted on the topics that we wanted to discuss - I have to say I was somewhat impressed by the blatant attempts at vote rigging that I witnessed during this part of the exercise - you know who you are!!
The selected top topic was about how to deal with a fixed bid scenario with an Agile delivery.
Fixed bids are all about managing risk. In a time and materials project, the client shoulders all the risks - if something takes longer than expected, they have to pay more for it, if you lose team members and have to ramp up new people, they have to pay for the learning curve. In a fixed bid, the risks are taken on by the vendor - they will have to foot the bill if there are any issues. So, in order to protect yourself and your company, you need to ensure you are protected from this exposure - avoid the trap of optimism.
What are the key risks for a fixed-bid Agile project:
How well do you know your team?
Do they have an established velocity?
Are they optimists or pessimists?
Have they worked together before or do we have to allow time for storming?
Do they have experience of longer-term planning games to help with this estimation?
How well do you know your Client?
How well do you know the Client and their environment?
Do you have a trusting relationship?
Do you know about their processes - these can add a lot of time to a project.
How good are the requirements?
If they are not clear, ensure that you are covered by listing assumptions that will avoid small-seeming items from mushrooming.
Do they look likely to change? Do you want to add in some points to accomodate change?
Are there any integration points?
How large is the project? The larger it is, the harder it will be to have an accurate bid.
Assess these areas of the project, and ensure your bid reflects these items. No-one will benefit from over-optimism - not yourself or the Client - so be realistic. Also, ensure that you are open with the client and the team that you’re working with - both parties should have their expectations set and you will need their buy-in for the venture.
One question that arose was - why enter into a fixed-bid situation with a client? - It’s hard work and in many ways goes against the general Agile principles. There are both benefits and drawbacks to this way of delivering projects. Consider it to be a risk/reward relationship - in fixed-bid, you stand to get a higher reward on the project if it goes well. Now there is also an element of caution to be taken when looking at a fixed-bid - why is the Client wanting this model? Maybe they just want it for security or piece of mind, but if it’s a way of protecting themselves from previous bad experiences, it would be worth discovering more about those experiences - it may be that there are hidden risks around the client that has led to previous projects failing.
One thing that I didn’t mention in the talk, but is a key benefit with fixed-bid is that it allows you as a vendor to have more control over the project practices. For anyone who has had to explain to a Client why pairing is good and to try to justify that it will save costs in the end, this is a real benefit. In this way, you may be able to get buy-in on Agile practices with the Client, without having to justify everything up front.
Post by Kim Lennard.
Kim is a Project Manager and Agile Trainer, with a passion for transforming and improving delivery and working environments.