Home > Project Management > Fixed Price IT Project – The avaricious pays twice? – Part I: Preparation

Fixed Price IT Project – The avaricious pays twice? – Part I: Preparation

Fixed Price IT Project – The avaricious pays twice? – Part I: Preparation

How fixed is a fixed price project and what is really happening behind the curtain

By Vitaly Dubravin

CIOs and Business Managers are under the constant pressure to cut costs of doing business. Though, innovative IT development projects have become a major enabling factor to a competitive advantage on the market. Such advantage often comes with a heavy price tag attached.  Cost-driven businesses had found a way to limit IT appetite and put development budgets under control – Fixed Price Projects.  Is this a real cost saver or a financial black hole for the company? Let’ look at some essential project steps to answer this question.

1. Requirements definition

Businesses, usually, have a decent understanding of the ideal system to be delivered. This understanding is driven by needs (often called pains). Such needs have a wide variety of forms and contributing factors, but can always be defined. Needs trigger requirements gathering, conducted by an internal project team or is outsourced to a trusted advisory company. Final result may be presented on a single sheet of paper or in a thick book, but I have never seen a document that will cover more than a half of what a project team will really need during the execution. Most documents will contain between 10 to 30% of vital information for vendors to scope a project.  This has nothing to do with the experience and professionalism of the team collecting requirements. The problem is much deeper. Literally no one on either customer or vendor side knows what will really be necessary a few months ahead when the project should be delivered. And no one can even guess every flavor of the future business need behind the project. Final requirements document describes, at best, the system as seen today, but not the system to be and is not very helpful because of that.

2. Request For a Proposal (RFP).

RFP is drafted and Vendor Management Office will send it to a few known vendors to solicit the favorable price and a solution.  Vendors have a very limited interaction with the actual project stakeholders. Process rules permit formal question submissions and absolutely exclude live interactive communications. Bidder’s Conference is the only chance to get a first-hand project details and a feel for the unwritten expectations from the customer. This is the last time in the process when business needs are the primary goal for all parties. The rest of the process will focus on cost controls.

3. Response to an RFP.

This is the most uncharted territory. There are good formal processes on how to prepare a solid and professional response, but none of them can address the root cause of the uncertainty – under defined business requirements. Each vendor will propose a solution based on the prior expertise of a similar project implementation and the best (though educated) guess of the ambiguous business requirements interpretation. (Remember: RFP process did everything to isolate vendors from the project initiators). Never the less, every vendor should submit a proposal with a price attached – a Fixed Price.

Vendors are not a suicidal business and they load proposals with buffers and backdoors. Buffer is a risk bucket attached to the project activities / deliverables. Buffer money will be used to cover the loss when an unexpected in-scope work pops up (for any reason). If no “surprise” work was conducted during the project, then this is an extra profit for the vendor. Almost every project has a certain amount of unexpected work and risk buffers rarely remain untouched. All delivery teams are trying to plan risk buffers as large as possible, while competition pressure with other bidders and, sometimes, internal politics may force them to cut buffers “to the bones” and even beyond.

What’s left? Assumptions, out-of-scope work and acceptance criteria. This is the most common way to open the backdoors in the contract to adjust project price during execution.  Every good proposal has at least first two elements and the more experienced project teams will include an acceptance process and criteria as well.

Assumptions are driven by the requirements uncertainty. We’ve talked before that those business requirements are never defined well enough to have a complete picture of the project. Assumptions serve two purposes: suggests most favorable (for the vendor) implementation path and a guess for unspoken business needs.  This is a polite way to introduce new scope boundaries, limiting future “pro bono” work for the delivery team due to requirements misinterpretation. Both purposes served the same goal – help to avoid expensive and painful work item that the vendor is not comfortable with. The only difference between them is that assumptions limit scope indirectly, by suggesting new requirements while out-of-scope items simply state what not to be performed. This is the second time when the project scope is explicitly separated from the needs of the buyer’s businesses.

An acceptance criteria, when included in the proposal, is the most powerful tool to ensure successful project delivery without strong correlation with business needs.  Every project should have one since project success has to be formally measured and formal acceptance criteria is the way to go. But, when defined in the proposal, it strictly works in favor of a delivery team and not ultimate system users / buyers. (Just another remember – business requirements are under-defined at this stage).

Vendor proposals are carefully reviewed by a bidding committee and the final decision is very much influenced by the price tag of the proposal. Of course, it’s a long list of different metrics, but cost was and will remain the decisive factor. The way it affects future system users is perfectly described by John Glenn (NASA) – “I wasn’t scared, but I was up there looking around, and suddenly I realized I was sitting on top of a rocket built by the lowest bidder.”

Keep in mind that the lowest bid does not mean that this will be the final cost of the executed project. Different independent research teams came to a conclusion that 60 to 90% of fixed price projects exceed original cost estimates and it is not uncommon when original cost doubles, triples and goes even higher than that.

Bidding process forces project teams to consider cheaper resources to win, but these folks are not necessarily best for the job. This also limits team ability to find a good solution for every challenge to face during project execution.  This seems to be a potential risk that may or may not materialize, but have to be watched.

So far all the preparation activities described, have contributed to a wider gap between business needs and project team deliverables. I’ll explain what happens next in “Fixed Price IT Project –The avaricious pays twice? – Part II: Execution”

(originally posted on CIO.com)

Advertisements
  1. February 16, 2011 at 16:02

    I simply want to say I’m all new to blogging and actually savored you’re web-site. Most likely I’m likely to bookmark your site . You surely have wonderful articles. Thank you for revealing your web page.

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: