Business requirements and a fixed price contract



  • 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?



  • 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.



Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2