I've been remiss in getting the last couple of bpmCamp updates out to the the blog,
In one of the sessions on the first day, I gave a summary of an approach to BPM projects that I like to call "Fixed Effort" - but clearly I didn't come up the ranks through marketing.
The whole point of the discussion was to give people a different way to think about a problem they face all the time with BPM projects: changing and evolving requirements.? As I pointed out in the discussion, the point wasn't to argue whether requirements should change or shouldn't change, the point was to discuss how to organize around principles that will protect you from the negative effects of requirements change.
I have found that sometimes a fresh set of analogies and thought models can help give business and IT leaders new arguments to support "doing the right thing" for their process projects.? I've previously discussed "Fixed Effort" in our blog, but this is an opportunity to really focus on it.
A quick review of the familiar approaches:
- Fixed price.? Typically you fix the scope as well before agreeing upon price.? The customer is paying for deliverables rather than hours of work.? Any changes go through change-order (and cost) process.? The problem: The biggest risk to any project is getting the requirements wrong - and because we're fixing requirements early, they are very likely to be wrong.? And because the bid is fixed based on the fixed scope, any change we make will likely increase our budget, reducing ROI. Fixed price projects also fail at a pretty high rate, and the Vendor takes on a lot of the financial risk.
- Time and Materials.? Scope may change, at additional cost.? The customer is paying for hours worked, not results.? Generally a light change-order process.? The problem: Timeline and budget risks are high (scope changes lead to longer delivery times and increased hourly charges). Customer takes primary financial risk.
So what is Fixed Effort?
Deliver variable scope on a fixed budget.
It sounds impossible, but it is, in my opinion, the most responsible way to deliver BPM projects.? The emphasis shifts to prioritizing scope based on importance of each item to the business (return) and based on cost to implement (investment).? The basic idea is: any new items get prioritized into the existing list, and the BPM team works on the highest priority items first, and the team makes sure to pull it together into a production release with completed items before the budget runs out.
Of course, there is more to it than just that - but philosophically, that's all there is to it!? One of my catchphrases at bp3 is "Respect the Budget" - don't assume you can go back to the well for additional funds - make sure you are production-ready before you run out of money.
What I really love about this approach is that I can treat a T&M project as though it is Fixed Effort, by emphasizing prioritizing, and making sure that we're always in a position to shift gears and go live with what we've got.? You can even get a Fixed Price project to behave more like a Fixed Effort project if you can convince your colleagues to treat the change-order process as a prioritize-and-replace process.
Of course, we got into a lot of discussion about specific cases and situations and how these techniques can be applied - but since I was speaking I didn't capture that in my notes!? Comments to add to this are welcome -