Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Channels ▼


Surviving Fixed-Everything IT Projects

Lately, I've been involved in discussions about funding strategies for software development projects. Typically, someone is trying to take a "fixed-everything" approach — defining/fixing the price up front, defining the scope in detail up front, and defining/fixing the release date — of or their project. Considering the overwhelming evidence against such an approach, and the easily observable (and negative) experiences that organizations have used it, I'm not only firmly against fixed-everything strategies I'm deeply concerned that people still adhere to this line of thought. In fact, as I've written here in Dr. Dobb's over the years (see links section at the end), I consider fixed-everything strategies to be unethical for IT professionals to engage in and grossly incompetent for business people to insist on. Not surprisingly, some people have an issue with this position.

The challenge in many organizations is that their IT governance processes insist upon a fixed everything, often mistakenly referred to as fixed-price, approach. This is particularly true for the procurement of IT solutions from external service providers; but it is also a common restriction on internally developed solutions. Organizations do this in a misguided belief that they will reduce their project risk with a fixed-everything approach — not understanding that what they're really doing is dramatically increasing their risk. The IT project management community has preached for years that at least one of your project's scope, schedule, or cost must vary and that initial estimates should be given in large ranges that are tightened up as the project progresses. Without flexibility, you run the risk of:

  • cost overruns on your project,
  • missed project deadlines,
  • a solution that fulfills the specification but doesn't really meet the needs of the stakeholders.

Worse yet, the overhead of governing a fixed-everything project can often be substantial, with management desperately trying to show progress via techniques such as Earned Value Management (EVM), function point tracking, and onerous change-prevention processes. Although the people making the decision to take a fixed-everything approach do so with the best of intentions — namely, risk mitigation — they don't understand the implications of the decision and often don't understand that they have significantly better options available to them.

Whenever I work with an organization that insists on a fixed-everything approach I try to dissuade them from doing so. First, I have a discussion with the IT staff around how well the strategy has actually been working for them. Sometimes there's a bit of denial. For example, I recently ran into a senior IT manager who claimed they provided estimates with an initial range of +/-20% and always delivered within that range only to discover later that a majority of projects needed to "reallocate" costs to other financial buckets to do so. Once I get people talking about actual projects, it becomes very clear very quickly that fixed-everything strategies aren't working well and never have.

Second, I ask to have an open and honest discussion with the senior executive stakeholders, this often includes the chief financial officer (CFO), and senior IT representatives in the same room together. One goal of this discussion is to explore the challenges around the fixed-everything approach and the bad behaviors that it promotes within IT project teams (my April 2011 article, Survey Shows Unethical Behavior Rampant Inside IT Development Teams, explored this bad behavior in detail). The interesting thing about such discussions is that the business stakeholders rarely put much faith in the promises made by their IT staff, while, at the same time, the IT staff are frustrated with the situation. Worse yet, because they never openly discussed the problem as a group, they didn't recognize the need to change. Third, I then ask to work through the various options of funding and governing IT projects in an attempt to come to agreement around a better approach than fixed everything. With a bit of education, and often with a lot of effort motivating all the key players to work through the issues, I can help organizations recognize the need to change the way that they fund and procure IT projects.

When I share this strategy, I'm often accused of not living in the real world. Take it from me, my world is just as real as yours. Granted, the above strategy seems to work for me only about one-third of the time. Clearly, there's room for improvement, but this success rate is infinitely better than that of the "real worlders" who do not even try to move away from fixed everything.

Having said that, what can you do if your "real world" doesn't allow you to move away from a fixed-everything strategy? Let's work through a scenario. A customer has approached its usual IT service providers with a detailed request for proposal (RFP) and has received five bids. One bid is very low, one bid is noticeably higher, and three bids are close to one another. Let's work through the likely implications.

Chances are pretty good that if you work with the low bidder that bad things will happen on this project. Granted, there is a small chance that the low bidder has exceptional staff who are experienced at building what you've asked for, have reusable frameworks that they can leverage, and are using some agile/lean/ubercool methodology that enables them to get the job done. But chances are exceptionally good that they've underbid because they intend to put you through a tight change management process in which you pay extra for every little change that you request. According to the December 2010 survey, 29% of development teams adopt such change-prevention practices. Worse yet, towards the end of the project when it's clear that they're in trouble they may try other strategies such as de-scoping (22%), compromising quality (15%), or extorting/requesting more money (10%). I suspect this isn't news to anyone who's been on the receiving end of a fixed-everything project, although it's shocking sometimes how some organizations forget these nasty lessons.

The middle bidders are likely in the right ballpark. The primary decision here is to choose one with the cultural fit for your organization, which is something you can judge based on your previous dealings with them (if any) or through a round of interviews.

Then, there's the highest bidder, who may in fact still be the best option for you. The high bidder might know something that you don't based on their deep experience building similar solutions or with previous experiences working with you. Smart customers have a conversation with the high bidders to explore why their bid was so much higher than everyone else's, and thereby reduce the overall risk of the project. Furthermore, if you've had positive dealings with them in the past, you may want to give them the opportunity to rework their bid.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.