Oil and Water(fall) #BTF09 #BPM
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:One of the sessions at Forrester’s Business Technology Forum 2009 was a lunch session sponsored by
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.
- 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).
- 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.