In This Issue
- Reducing the Risk of Fixed-Price Projects
- Hot Links
Reducing the Risk of Fixed-Price Projects
In Is Fixed-Price Software Development Unethical? I questioned the ethics of fixed-price IT projects. When I use the term "fixed-price project" what I really mean is something closer to "fixed iron triangle project" where the price, schedule, and scope are all defined up front which is what "fixed price projects" invariably devolve into. The column summarized the reasons why people choose to work this way and the deleterious implications of doing so. This newsletter expands on my column, providing advice for what to do when your stakeholders still insist on having a "precise estimate" at the beginning of the project.
The first strategy is to recognize that you need to give a ranged estimate, not a precise one. As Walker Royce likes to say, you're trying to do 5 nines decision making with only one nine of information -- the implication is that your estimates must reflect the actual quality of the information that you have at hand, including the "shifting nature" of the data going into your estimates. It's reasonable at the beginning of a project to indicate that you believe the price will be between $800,000 and $1,300,000 but it would be inadvisable to say that the price will be exactly $975,000 because of the uncertainty of the requirements at that point. As John von Neumann said "There is no sense in being precise when you don't even know what you are talking about."
Second, recognize that you'll need to do a little bit of up-front agile modeling to obtain sufficient information to give a reasonable guess. That reasonable guess is best developed by people with experience building something similar in the past, ideally by the people who are committed to doing the actual work (thereby increasing their motivation to get the estimate right). The required information can be generated as the result of some initial requirements and architecture envisioning, you don't need to take on the risk of created detailed specifications early in the project.
Third, if your customer isn't willing to accept a ranged estimate from you then you still need to calculate the range and then give a "precise" estimate as far up in that range that you believe the customer will accept. In other words "pad" your estimate as much as possible to counteract the risks that your stakeholders are trying to put on you. This strategy offers the potential for higher margins if you're able to work efficiently.
Fourth, take a "reasonably agile" approach to change management where the price remains fixed but the scope varies. With this approach requirements are treated like a prioritized stack and you work down that stack in priority order. If stakeholders want to change a requirement, or add a new one, without changing the price that they will pay then they need to drop a requirement of equal or greater value from the scope of the project. By being flexible with the requirements this strategy reduces the problem of your team implementing functionality that your stakeholders don't want. Furthermore you increase the ROI of the project by working in priority order.
Fifth, adopt a stage-gate approach to funding where the project is funded a phase or period at a time. This doesn't imply that you need to take a waterfall approach to development, for example Rational Unified Process (RUP) and Open Unified Process (OpenUP) both have a risk-driven lifecycle where in each phase you address a specific category at risk, and then at the end of that phase you decide whether it makes sense to continue with the project and to what extent. Staged-gate funding is often used in combination with variable scope approaches.
As IT professionals we need to start pushing back when the business asks us to do fixed-price development. The ethical approach is to educate them in the options they have available to them, to the trade-offs involved, then give them a choice. Regardless of the choice as professionals we need to respect the decisions of our stakeholders even if they still choose to go with fixed-price. However, my experience is that when stakeholders understand that they have choices, and the implications of those choices, then they often choose to abandon fixed-price approaches. Many people claim that it isn't possible for their organizations to work this way, but I've been successful in turning business people away from fixed price even when I was told it couldn't be done. This is a battle worth fighting.
My August 2008 Dr. Dobb's Journal column is Is Fixed-Price Software Development Unethical? questioned the ethics of fixed-price IT projects.
My September 2007 Dr. Dobb's Journalcolumn Agile on a Fixed Budget describes strategies for running agile projects for all combinations of fixing, or not fixing, the schedule, scope, and budget.
My March 2007 Dr. Dobb's Agile Newsletter Counteracting the False Arguments for Big Modeling Up Front (BMUF) describes the risks associated with detailed modeling early in a software development project.
Architecture Envisioning: An Agile Best Practice describes how to go about initial architecture modeling on an agile project in a streamlined manner.
An Agile Best Practice describes how to go about initial requirements modeling on an agile project in a streamlined manner.
I've summarized a collection of Agile project planning tips here.
Stop by my Agile@Scale blog.