In This Issue
- The Dire Consequences of Fixed-Price IT Projects
- Book Review: Ethics for the Information Age, Second Edition
- Links
The Dire Consequences of Fixed-Price IT Projects
"Fixed-price" projects are a common practice in IT, either as the result of a fixed-cost competitive bid or as the result of budgeting pressures on internal software development projects. I put quotes around the term "fixed price" because the projects often go over budget, but for the sake of argument let's choose to ignore this nasty little bit of reality. Organizations often prefer fixed-price projects in an attempt to decrease their financial risk. Unfortunately, the exact opposite seems to happen in practice. Everyone seems to know this, but we somehow can't find a way to get out of this rut. This month I discuss the problems surrounding fixed-priced IT projects to hopefully motivate you to move away from this questionable practice.
The fundamental problem with fixed-price projects is that they motivate you to perform very questionable things which invariably result in wastage. To develop an accurate estimate you need to understand the requirements which you are supposed to implement and the architecture which you are going to build to. The greater the need for accuracy in your estimate, the greater the need for more detailed information. As a result of the pressure to develop an accurate initial estimate you are typically motivated to adopt:
- A big requirements up front (BRUF) approach where you create a detailed requirements specification early in the lifecycle.
- A change management process which strives to avoid "scope creep" throughout the project.
- A big design up front (BDUF) approach where you attempt to specify your architecture in detail before coding begins.
- A software development lifecycle that is mostly serial in nature.
Let's examine the inherent problems with each of these practices. First, the challenge with BRUF is that you can't accurately determine up front what people want because they fundamentally don't know themselves. People are good at indicating their intent and then once they're shown something such as a UI prototype or actual working code they can indicate what they don't like and what might work for them instead. By iterating, we can home in on what they actually need, but that means that we'll evolve away from the initial requirement upon which the estimate was based. These "requirements changes", what is really changing is our understanding of the requirements, in turn puts the project team at risk of going over budget. The implication is that you can have an accurate estimate of something people likely don't want, or an inaccurate estimate of something people do want.
Second, many "change management" processes are designed to make it difficult for stakeholders to change their minds, reducing the chance of requirements changes forcing you to go over budget. Change really isn't being managed, it's being prevented. These change prevention processes increase the chance that the system will be built according to the specification but decrease the chance that the system actually reflects the true needs of its stakeholders. As a result a lot of money appears to be wasted building functionality that stakeholders don't really want and not on what they actually do want.
Third, BDUF also proves questionable in practice. By designing in detail early in a project you are effectively making serious decisions when you know the least amount of information -- during the first month of a project you know far less than on the 10th month of a project, for example. Once these decisions have been made you're motivated to stick to them because of all the hard work you've invested. Worse yet, if you didn't get the requirements right to begin with, which is often the case, then no matter how good of a design job that you do it's still wrong because the requirements on which it is based is wrong.
Fourth, BRUF and BDUF are two aspects of a serial lifecycle; serial lifecycles seem to offer few control points for stakeholders, thereby increasing overall project risk. Although stakeholders are usually actively involved up front with the BRUF effort their role is often greatly diminished until user-acceptance testing at the end of the project (assuming time permits). There may be the occasional milestone review where they go over status reports and technical documents which are presented as representing so form of earned value, but for the most part the majority of the software development process appears to be a black box to stakeholders: They won't know until close to the end of the project if they're going to receive anything of value in return for their IT investment.
Sadly, many of the so-called accurate estimates aren't all that accurate in practice anyway. No matter how detailed the requirements and design specifications there is always some uncertainty. For development teams to reduce their risk they'll pad their estimate to the point where it is still acceptable to the stakeholders yet still gives them some buffer room for any mis-estimation. In effect, the development team is putting as much of the project's financial risk onto the business stakeholder's anyway, effectively defeating the primary purpose of having a fixed-price project.
In reality projects often go over budget, and more often than not the business stakeholders pay for part or all of the overage to get the desired system from the IT provider. Sadly, mistakes like this motivate people to insist even harder the next time for an accurate up-front estimate, and thus we never seem to get off the fixed-price treadmill.
The alternative to fixed-price projects is of course variable-priced projects. In practice it is much easier to reduce financial risk on variable-priced projects with gated investment based on interim deliverables (ideally working software). This approach requires a good relationship between business stakeholders and IT as well as active stakeholder participation in the project. If you want to ensure value from your IT investment then you're going to have to manage your IT investment closely.
Fixed-price IT projects aren't good for the developers working on the project because it motivates questionable behaviors which put your job at risk in the long term. Nor are fixed-priced projects good for business stakeholders because they seem to increase risk instead of decrease it as promised. It's time to rethink our approach to funding IT projects.
Book Review: Ethics for the Information Age, Second Edition
One of the most important things about being a professional -- any kind of professional -- is to act in an ethical manner. This is as true for IT professionals as it is for doctors, accountants, and lawyers. An understanding of ethics is important whether you're a traditional IT professional or an agile one, yet ethics is rarely discussed in practice. Considering some of the questionable activity which we've seen when it comes to agile certification, I suspect it's high time that the agile community starts thinking about ethics a bit more than we do.
A good resource is the second edition of Michael J. Quinn's Ethics for the Information Age. This is a very approachable book which covers a formidably complex topic. It begins with a general overview of ethics and major ethical theories throughout the ages. The book includes chapters on the ethical issues surrounding networking, intellectual property, privacy, computer and network security, reliability, and wealth. The most valuable chapter, in my opinion, is the last one on professional ethics. Most of the chapter is a review of the ACM/IEEE-CS Software Engineering Code of Ethics, something all IT professionals should be aware of, and a discussion of why it appears to be a very good code. In the end, ethics boils down to a judgment about the choices that you make. My recommendation is that you choose to read this book.
Ethics for the Information Age, Second Edition
Michael J. Quinn
Addison Wesley, 2005
400 pps., $63.80
ISBN-10: 0321375262
--SWA
Hot Links
The article examining the "Big Requirements Up Front (BRUF) Approach" overviews and discusses evidence as to why comprehensive modeling up front puts your project at risk.
The Big Modeling Up Front (BMUF) anti-pattern described in detail.
The Change Prevention Anti-Pattern.
A comparison of estimating and scheduling strategies.
The Broken Iron Triangle Software Development Anti-Pattern describes how at least one factor of scope, schedule, or resources needs to vary otherwise quality will suffer.
The Agile Alliance homepage is the best starting point for anyone interested in learning more about agile software development.
The Agile Models Distilled page provides links to overviews of a wide variety of models.
The principles of Agile Modeling v2.
The practices of Agile Modeling v2.
Check out the the Agile Modeling mailing list.
