home

How to get a supplier to give you a fixed price... tell him what you really really want

There are obvious advantages to receiving a fixed price quote over a time and materials estimate. It is possible to elicit a fixed price quotation from a supplier in response to an invitation to tender (ITT). It just isn’t easy.
If a supplier is prepared to submit a fixed price quotation, it should mean you can have a high degree of confidence in the business specification, implying the supplier understands exactly what you want. Where the requirments are not well understood the supplier will instead offer you a time and materials estimate, which is no guarantee whatsoever of time, cost or quality; a kind of blank cheque.
In a recent procurement exercise where the PrinceLite method was used to draft the specification included in the tender document, one supplier offered a fixed price quotation, and two others offered a time and materials estimate with a fixed price option that was priced as a 20% uplift on the time and materials price.
One way of interpreting this calculation is to equate it with a 20% uncertaintly (risk). This could be read as “we think we can do the job for x, but we are sure we can do it for x + 20%”. This implies there was a 20% ambiguity in the business specification. Rather than building in an uncertainty factor, the preferred response would be to seek clarification and then commit to fixed price. If the uplift was in the order of 100% or more, this would indicate there was something seriously wrong with the business specification, and perhaps no quesitoning was likely to result in sufficient clarification. This may indicate that the difference between the estimate and the quotation is a sign of the quality of the requirements. It is highly suspect that any project should go forward where no fixed price quotations are forthcoming due to the impossibility of assessing the risk. In the current example however, those companies who took the variable approach were the ones who had either posed no questions, or asked only superficial ones in the submission stage.
The winning bidder quoted £85K, the second bidder quoted £145K, and the third bidder £195K. Set in this context, the cost of producing the upfront specification for tender is easily justified. The decision to award in this case was simple, because the unequivacally fixed price quotation was also the least expensive by a wide margin, and it is no surprise this supplier asked all the difficult questions in the submissions stage.
How it is possible to produce an unambiguous business requirements specification to include in a tender document in a short period? The answer is in the application of UML for project management which is defined as part of the PrinceLite method. This includes:
• End to end activity modelling
• Actor identification
• Primary use case modelling (graphical only)
• Elaboration use case modelling (graphical and ‘mid level’)
• Business object modelling (grammatical and lexical modelling)
• State modeling (featuring the ‘transacted’ class to derive business rules)
A PrinceLite informed business requirements specification for tenders is typically 50 pages long. It is orientated around models that are produced at a level of accuracy sufficient to the task of allowing accurate quotation by an experienced software supplier.
The customer must be willing to represent the requirements upfront where they believe it is possible, can be done in a timely manner, and will result in tangible benefits. Some companies may not have the need to bring the modelling expertise inhouse and so the drafting of the specification for the tender can be contracted out. Conversely, the skills required can be taught to the inhouse project managers and business analysts. The training typically takes one week. The production of the business requirements specificaton for procurement typically takes 2 weeks to produce and a futher week of corrections with the business and ‘power users’ to ensure its correctness. Suppliers typically require 2 weeks to respond to the invitation to tender. Therefore, with a degree of experience the cycle from ‘go ahead’ to receipt of tenders can be reduced to 5 weeks. These figures are, by necessity, approximate but they are nonetheless typical. They are based on transactionally-oriented database applications for business and depend to a certain respect on the functional size of the ultimate system.
It must be remembered that the rationale for going through the process of learning how to produce these specificatons for tender is to allow for the organisation to move away from time and materials estimates to fixed price quotations. Ultimately, the purpose is to control software development products more closely, to drive down the cost of acquisition, and to shorten the delivery lead time.
Time and materials estimates favour the supplier. They are an open invitation for costs to escalate. They provide no recourse when the project deadline slips. They are open to accusations from the supplier that the reason for delays is down to the ‘customer changing the requirements’. This is a charge to which the customer is highly vunerable. Ultimately, is a time and materials estimate worth the paper it is written on? It is unclear how the cost is calculated and it cannot be relied upon. Therefore the decision to award based on such an estimate is a fraud. The lowest estimate will win, but it may well escalate far in excess of even the most expensive of the losing competitors estimates. This is a built-in contradiction within the process, that no right minded procurement professional should ever consider. Unambiguous upfront requirements representation for procurement is possible. It just takes a bit more work.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Please......

IMHO Your approach is only feasible for small projects in which everything is certain (maybe product selection projects, but most new-systems-development projects do not qualify).

What you describing is simply denying the fact that a project involves people:
- People probably working together for the first time, possibly getting to know each other, aligning their processes.
- Learning and discovery of new possibilities, business as well as IT.
- Developing a system is a joint effort between the customer and the supplier, other parties should not take over the role or responsibilities of customer, but just facilitate the cooperation.

A project always has certain uncertenties where good requirements description may help. Denying the fact that there are other things involved will simply endanger a lot of projects.

Fixed price, fixed functionality, fixed everything will just break a lot of things. Fixing one aspect and managing the others is a whole different story though.

Michael

Let's see

Well, as I'm doing the due diligence and will see the project through to delivery, we will see if your criticism is correct. I will report the experience one way or the other. Clearly, my assertion is that you're incorrect. I've heard the same criticism many times, but it still keeps working...

Peter

Wonderful Theory, Poor Practice

If you google "Fixed Price Unethical" you'll find an article that I wrote summarizing the evidence against this concept. Bottom line is that fixed iron triangle approaches reflect an abdication of responsibility. In practice they lead to cost overruns and schedule slippage if you strive to build something that people want, or lead to you building something to spec on time and budget (in the "best case" scenario) which people don't actually want.

Agile approaches to change management require significantly greater discipline on the part of developers, and greater accountability on the part of stakeholders, but in turn provide significantly greater opportunity for improved quality, greater ROI, and improved time to value. We're actually seeing this in practice, BTW -- agile teams are proving to be more successful in practice than traditional teams.

My experience is that when you educate stakeholders regarding the implications of the decisions that they make, and that when you give them a choice, that they quickly abandon the more traditional approaches that you're describing.

- Scott
Scott W. Ambler
Practice Leader Agile Development, IBM Rational

Due diligence

I did the due diligence exercise on this last week. It went well, there were a few clarifications. Computing magazine wants to run a series of 3 articles on the process to see if the idea of fixed price results in success. So, we'll see, and that's the spirit of science - right?

I had an interesting conversation with a colleague, who contributed some thought provoking stuff on the subject of FP. I'll get his permission, and pass them on if he's willing.

Peter
www.princelite.co.uk

Business requirements fixed-price option

I think this is an untapped option that a lot of clients are concerned with. However it does require assessment of the appropriate subject-matter experts, the primary audience - business stakeholders, ontological context and linguistics. We've done it with a number of large projects successfully.

Regards, Ron Chin

Agile still means requirements capture

I agree that ontological (great word) and linguistic analysis can uncover entities that imply requirements early in the lifecycle. It may be out of favour, but it reaches back to Abbot's early work on databases. It worked then and it still works.

LShift is a software development company in London. I interviewed one of their directors for a magazine article two days ago at the Agile Conference sponsored by the DSDM Atern consortium. Agile development suits their organisation which exists to deliver working systems, not to produce intermediate project artefacts. They follow the structure of DSDM Atern and pitch to customers to engage in a feasibility stage during which requirements are captured and evaluated. The customer may then choose to stay with LShift or to take the early work to a different supplier; either way they have used storyboards, scenarios and use cases to first flesh out the scope of the project. After the early engagement, LShift are happy to quote a fixed price to deliver the project, rather than the more common time and materials estimates that the big players enter into to do such work as the government projects that often go so spectacularly over budget. To win this kind of work LShift would have to bid unrealistically low, based on limited information and then hope to recoup their costs through change requests. In other words, the fact the customer is vague about their requirements is a weakness some suppliers exploit. They have no vested interest in helping the customer clarify their requirements in an open tender time and materials based estimate competition. Think about it, what value do these ‘estimates’ have? The winner is appointed based on a low pitch they know full well is not what the customer will pay. This is a process that is corrosive to the customer relationship, and simply not much fun. Personally I think it is cynical bordering on corrupt.

Peter
www.princelite.co.uk

Agile actually requires...

...that you work closely with your stakeholders to understand their intent and then produce a solution which fulfills that intent. You need to understand their "requirements", note the use of quotes seeing as it's really their intent as they currently understand that you're trying to explore, but that doesn't imply that you need to capture this information in documentation. Remember, documentation is the least effective means for communicating information between people.

It's very effective to capture requirements in the form of executable specifications, but that can require greater skill and discipline than what is typically found in traditional environments. Capturing requirements as tests cuts down on the work and increases quality. With a test-driven approach, instead of a documentation-driven approach, you can improve your overall productivity and effectiveness. But it isn't easy -- nothing comes free.

- Scott
Scott W. Ambler
Practice Leader Agile Development, IBM Rational

Design bias in requirements?

It is hard to argue against the merits of producing an executable specification that meets a set of business requirements. The challenge is the exploratory process – based on stakeholders intent – to achieve an executable specification requires a significant level of requirement elicitation/validation, design decisions, assumptions, constraints, etc – which in some cases may not have available facts to support a relatively-stable iterative specification. Agile, as a process to elicit and validate explicit requirements in a form of a design artifact, perhaps may inherently include some solution bias. This bias will have a negative or positive impact when requirements are open to multiple solution providers.

The interesting question is – does an executable specification meet the business requirements? The answer to that question, somewhat, has a self-serving bias.

Our fixed-priced requirements definition uses the tools available – such as simulation, prototyping, process maps and use cases – to elicit requirements subsequently filtering solution bias. Our requirements engineering practice considers ontology and sociology as key aspects to practical business requirements definition.

Regards, Ron

Different Experience Different Results

I work in consulting and would be happy to give you a fixed price estimate for a very exact requirements specification and deliver exactly what it asked for for the price. In my career I have never seen such a requirement specification, which if built to exactly would deliver to the business exactly what they want. I am willing to believe (am I really?) that such a thing can be done and if so fixed price would be fine. I have actually attempted to deliver on a fixed price to exactly what was asked for in what the procurement people thought was a very exact specification before. Strangely when it turned out the requirement was wrong, and easily proved to be so, the usual ‘whose fault’ arguments still ensued, it is truly amazing how a requirement can be interpreted when someone is trying to save their job.

I would take a little exception to your last paragraph which heavily suggests that companies who deliver time and materials estimates are all crooks and charlatans.

Basically even if the requirements were very tight and very exact and detailed there would still be the possibility of estimating incorrectly, so even if not specified in the quote it would be quite likely that a fixed price would have some uplift. Whereas if I have estimated correctly or even overestimated on a time and materials bid then the customer would actually get the benefit of saving not only the unrealized uplift but maybe also on the overestimation. If I bid $1m fixed price that’s what I get. If I bid $1m time and materials then maybe I do it quicker, only get $.9m, and save the customer some money.

I have done many time and materials projects on or before time or on or under budget (maybe my estimations skills will be questioned here) and delivered great benefits even as the requirements have changed along the way. I believe one obvious reason being that there is no conflict here when requirements change, no need for argument, no need for the implementation of some time consuming and expensive change management process and system. Time and materials lets the customer and implementer work co-operatively together, often allowing the customers personnel to be part of the team, something that would never happen in a fixed-price project.

Many of the statements in your final paragraph may be based on your direct experience but some of us have rather an opposite experience. I have never seen such an exact requirement as you talk about. I have given time and materials quotes complete with the calculation methods illustrated, and they have been accurate.

“There is no right-minded procurement professional”, may well be an accurate statement.

“Unambiguous upfront requirements representation for procurement is possible.” I can’t say I have ever seen it in an RFP but I can’t say it’s not possible either.

“It just takes a bit more work.” I would say it takes a lot more work than expressing requirements to a level required for a time and materials quote, interesting to see if the cost outweighs the benefits, and I would really doubt the ‘exact requirements’ would not change in the life cycle of a project of any size.

I have dealt with a lot of RFP’s etc., and a lot of procurement people. Systems development is not like supplying desks or building a house to a detailed specification (something that rarely works properly either).

If you have success doing what you say all power to you. Personally my company’s most successful projects have been time and materials, very often without even a contract and often delivered on or before time, and under the initial estimate. I don’t feel corrupt. I am prepared to explain my estimates. I don’t think my estimates are fraudulent. And many of my customers are extremely happy. And sometimes we deliver more than asked for for a lower cost because we have the leeway and are allowed adaptability to change.

Anything can work, I guess, different experiences.

'Corrupt' is a strong word

Hmmm, how to respond? Firstly I admit to using language that is somewhat calculated to invite a reaction. It is true that my experience has coloured my language. So, I've seen lots of instances where a time and materials estimate is bid low to win the business and the name of the game is to 'manage' the change requests to make a profit. Like it or not, that's what happens here (UK) in government tenders. I can't say for your market. I don't like it, because I've seen lots of consultants milling about who are supposed to be 'partners' who make absolutely no effort to help the customer (their erstwhile 'partner') represent their requirements in an unambiguous manner that is sufficient for the coders to get on and do their job with the minimum of questions. Not no questions, just the minimum of questions. 

 Personally, when I hear you talk about a result that is less than the time and materials estimate I'm amazed and impressed. You must be an honest man and I salute you. I mean it. I have been too cynical, and recently I have met software professionals of integrity, but in my career I haven't met many. Personally, I like to build systems that work and then move on. Too many people prefer to have a job, and to do what they can to ensure the job goes on for as long as possible. That's what I've experienced. It isn't pretty. I admit it's only in the public sector space. In the private sector it's been better. 

 I admit that what I'm describing is rare, unheard of. But interesting. It's my professional life's work. I'm not making it up. I'm not doing analysis paralysis. I'm doing requirements to a level that doesn't tell coders how to suck eggs. It just tells them what the system needs to do to satisfy the customer so he signs it off and hands over the money. Satisfied customer. Good experience for the coders. It's not analysis paralysis and it's not snake oil. It's about patterns and its about the navigation of abstraction. How long does it take? It takes less than a month. Honest. 

Thanks for writing. Thanks for your temperate tone. We're all strangers in cyberspace trying to communicate our experiences. But if it isn't a little edgy, a little new, and little out there, then interest wanes. I just believe successful repeatable project delivery needs unambiguous business requirements representation at the appropriate level of description. And I put my money where my mouth is.

 Peter

www.princelite.co.uk 

Post new comment

*
*
The content of this field is kept private and will not be shown publicly.

*

© 2007 Requirements Networking Group All rights reserved. contact | advertise | privacy
Requirements Networking Group