Is estimating a project without basic requirements or user stories a good idea for a fixed cost proposal?

Question

I am currently trying to create an estimate for a software proposal.

In this context, we are requesting a fixed cost amount of funds.

I personally lean toward Agile development practices. I, however, can not find a way to negotiate a "not fixed cost" contract.

I have received some recommendations to not estimate the project using user stories and "done conditions." (BDD style)

My gut tells me that not having all requirements in advance creates too much risk. I personally want to know what "done" looks like.

Do I collaborate with my customer to document user stories to help define the project scope? Or should we just bid the project based on very vague feature requests.

Thank you in advance.

Answer 1

Let's start with obvious observation: the moment that we know least about a project is at its very beginning. Unfortunately, for fixed-priced projects it is also a moment when we usually requested to say how much it's going to cost, thus to estimate.

In such situation I would focus more on improving estimate quality than on choosing this or that estimation technique. In other words I don't see why you shouldn't estimate BDD-style (if that worked for you that is).

Talking about improving estimate quality:

• Use multiple-point estimates (as Zbigniew points; +1). This approach is used in many methods, e.g. PERT, even if at the end we get a single-point estimate. There's one trap related to multiple-point estimate. If you work on fixed-price contract you don't have multiple-point pricing, so eventually you need to translate multiple-point estimate into single-point price. Either way it is still better to be aware of range of possible estimates than just a single one.

• Probability. Alternatively, instead of choosing a range, e.g. from 80 to 120 man days, you can use probability, e.g. we are 60% certain that it will take 100 man days. See how Monte Carlo analysis is used in Evidence Based Scheduling to learn more how you can apply this technique.

• Use historical data. Probably the biggest game changer in terms of estimation. The best we can do to improve our estimates is to verify how we did against our estimates in the past. What you need to apply this technique is you need to gather data how you estimated and how it eventually went. Then you can learn how much wrong you typically are and use this knowledge to adjust your current estimates. After all, if you consistently underestimate your tasks by half why suddenly you expect to be exactly on target this time?

• Avoid estimation at all. This is radical, I know, but it isn't that far from what I proposed above. If you can split your project to roughly similarly-sized pieces (e.g. see: Standard-Sized Features) and you have reliable historical data you can use to learn your delivery rate, i.e. how frequently you can deliver such feature, you can base on these values to estimate the amount of work needed to complete the project. See this example to learn how you can do that.

And most of all read Steve McConnell's Software Estimation book.

In terms of estimation there is no silver bullet so basically knowing different techniques you can improve the quality of estimates in a way that is feasible in your case. For example your team can be organized ad-hoc for a project and it may not be possible for you to have reliable historical data, etc. The trick, as always, is to use right tool to the right problem.

Answer 2

Fixed price contracts and ambiguous scope do not belong together ...ever. You cannot go down the path of even saying clearly what you will do because no one knows what needs to be done. You cannot plan to handle it with change requests because a CR is a change to scope...and you don't have any scope.

This is a time and materials contract. This is not debatable. A FP contract under these circumstances is unfair to both the seller and buyer of services. For the seller, you are taking on a degree of risk that is unacceptable and unmitagable. You would have no choice but to load the price with a ton of contingency, which in turn makes it unfair for the buyer by cause the price to be two, three, or four times what it could have been under another arrangement.

Answer 3

If you have to estimate without requirements, you need to be very clear in stating precisely what you will do for the fixed cost payment you will request. So rather than accepting "the job" (which is some loosey-goosey handwaving specification), you will list specific deliverables that you can accomplish. Make it very clear that the deliverables will only include what is written, and additional work will come at additional cost.

Answer 4

welcome to PMSE!

Let's split your question into sub questions...

Is estimating a project without basic requirements or user stories a good idea?

No, it's not a good idea at all, but sometimes we have to dance to the music.

My gut tells me that not having all requirements in advance creates too much risk. I personally want to know what "done" looks like.

Your guts are correct, I'm afraid. Project risk is directly proportional to the lack of clear requirements... which means in your case the risk is huge.

So, what can I do?

As there are no clear requirements but clear budget (and deadlines, I'd assume) I believe you'll need to discuss a lot with the client in order to break down the project as much as you can. Having a first PBS, define rough estimates for each piece of work to be accomplished, their dependencies and also clearly define priorities between each piece.

The estimates will be updated as the project goes by, their dependencies will help you defining the project path on the future and the priorities will be used in case things get out of track and you need to cut things off. Sorry, when dealing with projects we always need to be ready for worst case scenarios.

So, in short:

• Be honest with your client, explaining that as clear the project gets, the less risk you both will have (here I'd suggest to avoid saying "the unclear the project gets, the more risk we'll have", as it can leave a bad impression);
• Draft with the client a rough PBS;
• Agree piece's priorities with the client before you provide your estimates (just to avoid bias on the client's decision);
• Formally agree (by mail, contract, you name it) all the above, taking special care to the details about what's going to be delivered and what's not.

Success!

Answer 5

Please don't try to specify everything using BDD. You'll end up with a horribly fine-grained backlog that takes ages to maintain and which will still bear no resemblance to the real project that emerges.

Something I've done - and which works very well with BDD later on - is to look at the high-level capabilities which the system needs to provide. A capability is something that a user will be able to do, or which the system can do. This obviously means business capabilities, but it can include technical capabilities, such as performance, integration with 3rd party systems, etc. As a guideline, we had about 30 cards for a 2-year enterprise project.

Next, put a big red dot on anything which is new or unknown. These are your most risky areas.

If you want to, you can roughly estimate the relative size of the capabilities in points, the same way you would estimate stories, but bigger (use multiples of 10 at least). I started with the smallest at 20, then the biggest at 400, then found one in the middle and went from there.

When you're done, double everything with a red dot unless you can think of why the risk isn't that bad.

This will give you a really good idea of how complex and risky the project is compared to similar projects you've done, and you'll be able to estimate the approximate cost much more easily. It will also let you spend your money and the customer's on producing software instead of arguing about scope. If you have trouble estimating it, find some people who've done similar projects. You can also use the capabilities to define a minimum release, which will be easier to estimate and also represent less risk and faster return to the customer.

My last piece of advice is to work with reasonable customers who would rather produce useful stuff and address the real risk together than argue about who is responsible for defining the nebulous future.

For further reading, this is an article I wrote a while back on this technique (we were referring to capabilities as themes or feature sets then). Please also read Dan North's posts on the Perils of Estimation and Deliberate Discovery.

Answer 6

If you want to estimate the projects based on what you have so far you can do it by providing a range of dates instead of a fixed date. This is called "The Cone Of Uncertainty". The basic idea is that the less you know the less accurate your estimates are, so you should include that error in your dates. However, I understand that the client always want to have the fixed date, so you should explain to him where the ranges came from.

Plus add a buffer to include changes and another buffer to include risks.

Answer 7

I agree with the other answers that it is impossible to estimate without knowing what the requirements are.

What you could do, based on the information you have now, is to offer a Fixed Price Contract for a requirements analysis study only. You could include a rough or detailed functional and even technical spec if you are familiar with this type of project. Add some important screen prototypes so the customer can get a feel of what he is going to get.

When this is done, and it doesn't have to take that long, you can add your best price for the remainder of the project as well.

Ensure you have a qualified customer representative working with you the whole time. Not only to make sure your analysis is to the point, but als to build relationship with this client.

Requirements do change over time, so make sure this is clear to your customer as well and add appropriate process for changes in the remainder of the project.

You can sell this to the customer with the idea that what DONE looks like is clear for both parties, but that they can use it to go shopping elsewhere. This is where the relationship thing is important.

Answer 8

It can be a risky decision to accept project. it is advisable to go thru customer requirements, and most risky part is if customer explained project in one line.

fixed cost project can be acceptable in following conditions - if solution/project is clearly defined from developer side - if you have strong feeling that customer will definitely satisfy wiht your solution/work - if customer is very know to you.prior work experience with him

Answer 9

I assume this is during a bidding phase, where the client is determining what partner to work with. They have a problem and they want it fixed, as well as possible for a fixed amount of money.

You wrongly assume that you should estimate what it costs to provide a certain scope. It is often the other way around: they have a budget available and want the supplier who will offer the most value.

• Suggest a (billed) analysis phase, where you will work with the client to better define the scope. Sales arguments:
  • Without this, we will just add a huge amount of contingency to our contract. All (serious) vendors will.
  • By paying us to do this, you will end up with a high-quality requirements document. This will enable all vendors to lower their contingency, allowing you to get better prices.
  • Vendors will (minimally) do this analysis for free to reduce their own risk / pricing point. However, you will have to talk with 5 vendors instead of just 1.
• Make up the scope, as precisely defined as possible. They will be happy that you did the proactive effort and will clearly see you know their business.
  • Disadvantage: they could just use your analysis and incorporate it in the next RFP. Make sure they can't, by making your offer confidential.
• Suggest a scope-to-budget project. Provide a very clearly defined proof-of-concept to show them what you're worth. Once trust is established, they will realize you are value-for-money and will not care about the budget anymore.
• Simply make their scope for them, based on a simple conversation on business goals + available budget. Of course, this takes more sales effort, while you still might not win the project.

Answer 10

We are very often in this situation in our company. But that's just how we work.

Our strength is not requiring details from customers, but to create proposal ourselves -- what we will provide for the customer by his money. Using Agile approach -- even on Fixed Price contracts.

What we essentially do is following:

1. Figure out customer's main problem business goals.
2. Create PERT estimate for all project goals (split on high-level deliverables).
3. Make sure there is some solution that meets customer's budget. Simplify any deliverable you need to meet the budget -- for example, downloading CSV instead of comprehensive reporting. Be sure it can still satisfy your customer -- if it still solves his business-problem.
4. Provide as much assumptions together with deliverables as you can -- i.e. describe what you are going to deliver. It will help you to negotiate scope change during course of the project.
5. Create schedule which will have approximate dates for delivery of the deliverables. Specify detailed requirements only for a couple of first ones.
6. Important thing: when you come close to starting of the next deliverable -- start specifying its details and negotiate them with customer. If you discover that customer wants something bigger than you budgeted, then tell him: you considered less budget for it, so now there are two options:
   1. To stick to original version of the deliverable, or
   2. Make it bigger, but to simplify further deliverables even more -- to meet the same total cost in the end of the project.

There are some other tricks you use, but these are essentials to both avoid making expensive upfront planning, but still be able to solve customer's problem in Fixed Price manner.