Oil and Water(fall) #BTF09 #BPM
- October 14, 2009
- 3 Comments
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:
- The business will prioritize the work in each iteration (In other words, the business MUST prioritize).
- 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)
- 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?
- Honor the budget by deploying the process within the allotted budget.
- Use iterations to always stay close to a production-worthy deployment.
- 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:
- 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.
- 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.
- 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.
- 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.
- 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.