10 minutes into any fixed bid project initiation meeting, a PM can quickly get a wisp of things to come…Hard end date…planning backwards..a not very specific software requirement “specifications” document.
Here are 10 ways to mitigate fixed bid disasters….(fingers crossed!!)
Point 1 : Break the project into small projects. Not phases, but small projects. Something that you can manage, something that will give you overall grip..and remain in your line of sight . I see project of not more than 3 months working for me. These sub projects should amount to the cost on the SOW and of course the timeline….
Point 2 : Negotiate for 1 week of workshop with the customer before start of each project. Work out Iteration 0 for each of the small projects, where the team can sit with the Product Owner and understand ALL the work-flows that the Product Owner wants starting from the most crucial. Iteration 0 also enables environment set up and deciding on Technology choices and modeling a high level design for the entire project. By end of week 0,we will :
a) Revisit estimates on high level requirements and gauge what we can deliver by end of sub project 1
b) Understanding of scope, purpose and priorities of the customer.
c) Gives the management perspective if we are heading for disaster 🙂
d) We can’t go back on cost or time..if our estimates were wrong in the SOW ….the best we can make out of it is to give serious business value for buck in the given timeline. The outcome is not only business value but trust, relationship, confidence on promise vs. delivery and more business if the customer can value all these….!!!
Point 3 : Educate the Product Owner to be available and engaged with the team throughout the project. Explain to him that demos are not UAT and project pace cannot be judged with the first iteration. Have the Product Owner present for Iteration planning meetings, occasional scrums, weekly progress meeting etc.
Point 4: Keep the iteration 1 week long. 2 weeks, I found, is too late to recover.
Point 5 : Size does matter. Sizing stories enable us to exchange story for story while involving the customer in the process. The customer will have to think extra hard to judge which previously prioritized story has to go out and this will probably even reduce the number of times he tries to juggle stories. Sizing also ensures we measure our velocity which will become the basis for future project estimates.
Point 6: Iteration planning should end up having a goal for the iteration which is basically the workflow the Product Owner would like to see. The demo should basically go over that workflow. The software should be available at the customer’s premises a day after the demo for them to play around with.
Point 7 : The product backlog ( if you are using an excel), should contain your workflows as probably the Goal of the iteration and stories indented to it which is needed to achieve this goal. The workflow should be mapped back to the Specifications for Requirements traceabilty purposes. And the stories linked to your acceptance criteria which by all means have to be written with the stories and in accordance with the customer. All in one sheet in one place.
Point 8: If there are 10 stories against the workflow, the stories should be prioritised 1- 10 so as to enable the developers to understand dependency and of course the priority.
Point 9: For the team, no sticks and no carrots.A friend of mine says “Hawthorne effect” works.. I am going to try that!!
Point 10: If stories slips, be transparent about it and communicate the. Anyway the risk of slippage is with every team in any methodology.. Agile just makes it visible faster…
Well , the above tips are meant to mitigate knee jerk reactions when disaster actually strikes..
hmm….I can’t help recalling one of Calvin’s quotes…
Calvin : You can’t just turn on creativity like a faucet. You have to be in the right mood.
Hobbes : What mood is that?
Calvin : Last-minute panic.
.
Author
Co-founder of People10, a 'total agile' software development and consulting company.