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 -

One of the sessions at Forrester’s Business Technology Forum 2009 was a lunch session sponsored by Appian on the subject of Iterative or Agile development and BPM.

Sandy Kemsley quotes Tom Higgins of Territory Insurance Office in Australia as saying “Waterfall contracts and iterative development don’t mix.” Apparently he spent quite a bit of time talking about the contractual aspects of the project they took on with Appian, and Sandy took the opportunity to comment as follows:

The contract needs to focus on risk management, and you can’t let your lawyers force you into a fixed-price contract that has pre-defined waterfall-type milestones in it if you don’t know exactly what you want; in my experience, no BPM project has ever started with the business knowing exactly what they want ahead of time, and I don’t imagine that many do, so don’t mistake a contract for a project plan. If you plan on doing iterative or Agile development, where the requirements are defined gradually as you go along, then a fixed-price contract just won’t work, and will be a higher risk even though many (misinformed) executives believe that fixed price is always lower risk.

It is certainly true that waterfall contracts (often milestone or deliverable contracts are really waterfall contracts, so beware) are not an optimal fit for iterative development.

Having said that, you may find yourself in a situation not of your own making – where a Waterfall contract has been put into effect, and you have the responsibility of delivering the project.  At such times, it is still in your interest to convince the project team to go down an iterative path and get the contract revised to reflect it.

At BP3 we have been brought into just such situations when major outsourcing shops bring our firm in to help lead a customer BPM deployment.  We articulate the value to both parties to help them see the light that although the Waterfall contract would allow a lot of choke-the-vendor opportunities, and a lot of change-order opportunities – it would also bury the team in change-order requests, and it would likely fail to meet the business objectives and time-lines.  We do this by making a simple commitment to both parties:

1. The business will prioritize the work in each iteration (In other words, the business MUST prioritize).
2. The delivery team will deliver the highest priority work in a quality, repeatable fashion (in other words, technical team will honor the business’ prioritization decisions)
3. The iteration will be accepted if the business accepts it as having substantially delivered their top priorities and as having prepared the team for moving to the next iteration.

The difference in productivity, and in the tenor of the relationship is dramatic.  Of course we have to follow up words with deeds – delivering value, and delivering on the priorities the business has set for the team.  We have to take commitments seriously.  After establishing a pattern and habit of success with this new paradigm, we’re much more likely to achieve success.

A more common scenario is to get into a waterfall-methodology-oriented environment, where the contract may be more generally structured (perhaps even T&M).  In such cases, we have had a lot of success in applying iterative and/or agile techniques within the overall waterfall framework – including characterizing early development work as prototyping or design work, in order to pull some of the riskier technical or requirements issues to an earlier point in the deployment.

Regardless of the situation you find yourself in, you’re going to be better off if you can apply iterative techniques to your BPM deployments.  Once you apply those techniques, success will reinforce the approach.

Sandy makes another point in her post about working with people you trust – I couldn’t agree more.  If you don’t have that trust in your customer relationship, you have to work hard to earn it. If you don’t trust your vendor, find someone you do trust.

As a proposal, challenge yourself to think about your project as “Fixed Effort” rather than “Fixed Price” or “Time and Materials”.  What is Fixed Effort?

1. Honor the budget by deploying the process within the allotted budget.
2. Use iterations to always stay close to a production-worthy deployment.
3. Always work on the highest priority elements that meet the business objectives, and get you as fast as possible to a “minimally viable process” (For more information on this subject, look for Minimum Viable Product or MVP).

This approach honors the realities of the world that are often ignored at the peril of the project and its team members:

1. The Budget is LIMITED.  Fixed effort honors that by delivering a production ready process with real ROI within that budget.  Let’s say that again:  a Fixed Effort project honors the budget by delivering a production-ready process with real ROI within the budget.
   
2. Wrong requirements are among the most expensive mistakes a project can make, if they make it to production.  Iterations and Agile methods will expose these missed/mistaken/wrong requirements earlier in the process.
3. By always staying close to a production-ready release, at any time the Business should be able to say “this is good enough” (translation: we have a minimum valuable process), and you should be within just a couple weeks of going “Live” by doing a little cleanup and final QA before go-live.
4. By focusing on the business priorities, we’re focusing on the parts that add the most value / ROI – rather than the check-boxes that might meet IT requirements or might make us feel better about the project.
5. If pieces are left off in the end – they are likely less valuable and provide less return than the parts we’ve already implemented.

I realize “Fixed Effort” may not catch on in popular lexicon, but it keeps you focused on realistic budget in BPM projects.  The requirements aren’t fixed, as they are in a typical “Fixed Price” contract, so the vendor can’t easily commit to delivering static requirements.  A Fixed Effort approach is the way to address that requirements risk, while still addressing the budget risk.  Its a balanced approach, and managed properly, it works really well.