Business requirements and a fixed price contract

Question

A new customer asks us to develop a complex software product (in time and on budget). They provided us with business requirements. These business requirements is a text logically devided into (un-numbered) chapetrs and sub-chapters. There's no identifiers for requirements ofcourse.

They also provided us with basic software architecture diagram, which shows the breakdown of the whole system into software modules and what functionality those modules should provide.

In general the business requirements and architecture diagram looks good. But there are many open technical questions, for example:

• many architectural details
• technical details (how excactly the modules should be implemented, what third party software is gonna be used, exact APIs, etc)
• non-functional requirements

We could ofcourse elaborate all these questions with the customer but this requires weeks of time which we don't have.

So we made a brief WBS for each module and estimated the amount of work (based on basic architectural and technical assumptions). Not everything seems to fit in time we have for development, so the customer is going to have only some part of all the features.

Now I'm thinking of the way to make a contract. How should I make a contract if I don't have a clear set of defined requirements - all requirements are scattered allover the text describing the product from the business point of view.

What feature should I promise to deliver if there are no clearcly defined features?

Answer 1

A FFP is not appropriate for your customer or you. If you pursue that you have to load it with a ton of contingency in both money and time that it would make it unfeasible for a normal customer. And it would ruin your reputation.

A T&M is perfectly appropriate for this scenario. Insist on it or walk away.

Answer 2

Without detailed and fully agreed requirements, you have a load of assumptions. I suggest you document the assumptions as fully as possible, then structure a contract on a time and materials basis with the assumptions clearly stated. Then you can test the assumptions and document them as risks or issues as necessary.

As an alternative to this you may prefer to set a fixed price for a very limited (agreed) basic scope consisting of the top priority deliverables, and build an agreed process for charging for further scope that will be prioritised later. This additional scope may be easier to estimate as you will have more clarity as to the approach and a better understanding of the application / business needs.

Neither of these approaches is perfect but in this situation you need to ensure that you don't carry all of the risk for changes to scope or flawed assumptions. Equally, your client won't want to carry all of the risk either so there may need to be some level of compromise and protection on both sides.

Answer 3

One of the factors to consider is whether the client is sufficiently experienced at this kind of engagement. It only makes sense to take this kind of thing on if both parties are prepared to negotiate scope later, otherwise one or both of you is likely to come away dissatisfied. The customer should understand that "fixed" price means they pay a premium for the contractor to assume some of the risk and they pay extra for things determined to be out of the scope. Given the unknowns, the "non-fixed" part of the project is probably just as important as the fixed part and the contract ought to make that explicit.

When you are negotiating the fixed price you can also quote a (cheaper) T&M estimate for comparison. Assuming you are delivering in iterations and billing them regularly throughout then you can grant the customer the option to convert to a T&M price at any time, i.e. if/when it turns out that the undefined scope makes that desirable.