Fixed Price Unified Process (UP) Projects
Summary
Fixed price contracts for software projects have become popular particularly for large projects where project sponsors have experienced the pain of project overruns or cancellation.
Fixed pricing is viewed as a means of mitigating risk by imposing an absolute on project cost and therefore delivery. However, this technique fails to take account of a fundamental principle that software development unpredictable and therefore will not minimise risk.
This article considers how fixed pricing can be applied to adaptive software development processes such as the Unified Process (UP).
Introduction
There have been many well documented cases of project overruns and failures within the IT industry. On eof the results of this has been a greater understanding of the nature of software development a considerable improvement in development processes. However, another side effect is that many sponsors of IT projects are wary of similar outcomes occurring on their projects.
Regardless of improvements in technology and methodology, software development is still dogged by these same problems to the point where fixed price contracts are commonly negotiated on large IT projects in order to control cost and hopefully project delivery.
With fixed price contracts, the key stakeholder (the sponsor) is (initially) happy, as risk in terms of project cost has apparently been mitigated by imposing an absolute limit on the project funding. But has any risk really been mitigated?
Software development is very different when compared to other more predictable engineering disciplines such as civil or mechanical engineering, and yet analogies with these are still common place.
- ‘Building software is like building a house or a bridge’
The fact is that this mentality of being able to predict and therefore control software development accurately is fundamentally flawed. Software development cannot be accurately predicted, yet by imposing fixed cost constraints inevitably forces project managers to adopt this predictive approach to planning and controlling development.
Traditional (predictive) waterfall process has been shown to be no more effective and in many cases far less suited to software development than more recent adaptive software development processes, such as UP, extreme programming (XP), DSDM, SCRUM etc…
What these adaptive processes recognise is that software development requires continual feedback throughout the entire lifecycle from many different stakeholders to validate and verify that development is progressing in the ‘right’ direction – i.e. that the deliverable will be a system fit for purpose. This feedback forces adaptation in the development. This means that it is impossible to plan (and therefore predict) accurately a project from the outset.
However, there is still a strong desire to use fixed priced contracts for large IT projects.
A major problem of fixed priced policy is that it implicitly forces the supplier to fix resource requirement prematurely. Often the project scope will also be fixed, therefore the only variable will be software quality.
So how can adaptive software development processes, such as UP, and fixed price contracts work together without compromising deliverables?
To answer this requires a brief overview UP.
UP breaks a project into 4 distinct phases (UP is an extendable framework, more phases could be present):
- Inception
- Elaboration
- Construction
- Transition
Moving between phases changes focus of the project as follows:
Inception Focus
- Understand the scope of a project (Use Case analysis – and other techniques)
- Produce a course grained estimate of the project duration and resource requirement (very course possibly > +/-40%)
- Produce a high level development plan (number of phase iterations)
- Identify a candidate architecture
Elaboration Focus
- Achieve stability in requirements (no new architectural significant requirements occurring)
- Develop a stable executable architecture
- Mitigate all high risks (business and technical)
- Produce a finer grained estimation for the rest of the project (about +/-10%)
Construction Focus
- Complete system implementation
- Complete system test
- Deliver a software release ready for user testing
Transition Focus
- User testing complete
- Software release available
- Prepare user base – training, documentation...
- All deployment information available
Maybe fixed prices could be applied for each phase?
This is a possible approach, but a price could not be fixed for say construction
while still in inception, this is falling back to a predictive ‘waterfall’ style.
Also a fixed price for a relatively short inception and/or transition phases
could well incur unnecessary overhead relating to planning, estimation and
contractual negotiations.
A refinement is to fix a price for a combined inception and elaboration phases and when the elaboration phase is completed a greater accuracy plan for the remainder of the project is produced based upon knowledge gained during these 2 phases (team productivity, domain knowledge, remaining scope…).
However, there is still a problem that will arise, particularly for large
projects, with this refined approach. This relates to maintaining project
continuity. It is highly undesirable to stop a team that intimately understands
the project domain at the end of elaboration in order to wait for contractual
negotiations to conclude before resuming the project. The break could
be the equivalent of up to 2 project iterations during the construction
phase.
Therefore a final enhancement is to include an additional fix price period,
depending on project size, for 1 or 2 construction phase iterations in order
to allow for submission and approval of a final project plan in parallel with
ongoing project development. Note however, that parallel development productivity
will be lowered as the best people to assist in the estimation process will
be the project team.
Conclusion
Software development is unpredictable in nature. Therefore a predictive approach to planning, estimation and management is fundamentally flawed due the mentality that deviations from the plan are errors rather than giving a true indication of the software development in progress.
Fixed pricing for software development is a risky approach to take for funding the complete lifecycle of software projects. It will not mitigate risks, and often results in poor quality deliverables as development teams work with restricted resources based upon inaccurate initial predictive plans. Using UP (or other adaptive processes) allows continual feedback to refine plans and improve accuracy of estimation.
In order to use fixed pricing on UP projects, an understanding and appreciation of the unpredictable nature of software development is necessary in order realise that one fixed price for a complete project is wrong and is aligned with outdated predictive software development processes. Instead fixed pricing should be applied to UP phases, such as a combined inception and elaboration and a combined construction and transition phases. Additionally a fixed price period to the initial iterations should be included to provide development continuity while final estimation for the project completion is submitted and accepted. construction and transition phase estimation and plan can only be relatively accurately produced when the architecture (and therefore requirements) is stable - i.e. at the end of elaboration.
