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?

  • 1
    You probably shouldn't promise anything based on assumptions that might turn out as invalid. Instead, you need to communicate to the customer that their requirements likely won't fit into the time and budget constraints. Find ways of managing this project that both you and the customer can agree on, it seems like an agile approach might be workable, but you will need cooperation by the customer to define and maintain a product backlog, and to define an initial MVP. If they aren't willing or able to cooperate then chances of a successful project are slim. Commented Feb 23, 2020 at 12:58
  • 1
    Do not accept a fixed price contract without clearly defined requirements, that's a recipe for disaster. also make sure to have it clearly specified in the contract what happens if the requirements change during development, in that event it's going to take extra time, and the price must be re-negotiated...
    – hanshenrik
    Commented Feb 24, 2020 at 7:31

3 Answers 3


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.

  • Thank you, but the customer doesn't want T&M Commented Feb 23, 2020 at 19:04
  • 2
    @ChrisBrettini, you are party to the agreement. Your desired contract matters, too. Negotiate with them. The alternative is an extremely expensive FFP in order for you to cover your risks, or a competitive FFP where you are extremely likely to lose your house. We don't work for free; we don't subsidize our customers. You MUST have that mindset when you negotiate for business. Commented Feb 23, 2020 at 19:30
  • 2
    You are also hinting of fixed time. You have fixed scope, fixed price, and fixed time. That's an impossibility for you. Commented Feb 23, 2020 at 19:40
  • Agree - take a look at this: softwareengineering.stackexchange.com/a/6079/201384
    – sonstabo
    Commented Mar 6, 2020 at 9:00

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.

  • Thank you! I'm thinking about the Scope Statement Specification. Who is responsible for composing this document? A customer? Or are we supposed to propose such a document to them? Commented Feb 23, 2020 at 15:53
  • The t&m approach is perfect for this type of scenario. +1! Commented Feb 23, 2020 at 18:25
  • 1
    Everything is negotiable! Either you can develop the Scope Statement, or the client can. But as David Espina has stated elsewhere, you don't work for free so I would be looking for an up-front piece of paid pre-development work to define the scope and agree the parameters. You don't want to do this for free then have the client say "Thank You" and use it to go out to tender with (or offer the work to) other suppliers! This activity should also help to give you a better understanding so that your estimate ends up being more complete and accurate.
    – Iain9688
    Commented Feb 24, 2020 at 9:29

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.