2

I am working at a custom software development company. The number of incoming custom projects has increased over the last few years.

The first problem is that not all customers are willing to pay us for the development of the requirements specification. Thus, we are losing money due to the estimation of some projects, which we reject. The second problem is that projects are complex and do not have a lot of standard tasks.

Are there any tools helping to estimate a project with sketchy requirements? It would be perfect to have automatic estimation, but speeding up the process for a human would be enough.

I will be glad to hear any tips and ideas on this subject.

P.S. I don’t like the idea of rejecting every other project by default :)

UPD: When I can affect the type of contract - T&M is simplest solution, of course. But this is rare case. Also, sometimes I have to take on "difficult" projects, to ensure that sufficient cash flow for paying bills, as well as for investment projects.

Usually requirements occupy a hundred pages, but are still sketchy and unclear. So I'm looking for ways to accelerate at least a primary estimation of the requirements.

5

You're solving the wrong problem. If the scope is ambiguous and uncertain, then you need to pursue a type of contract consistent with that situation. Do not enter into a contract when no one knows the scope where you share or take fully the cost risk. Simply say no. Enter into a T&M contract, where you can never lose money due to uncertain scope. If your customer objects, walk away and let some other contractor lose money.

For some reason, getting into a firm fixed price contract or cost plus contract is highly prevalent in the IT space where requirements seem always unknown. You will never see this in other industries, such as construction. Can you imagine hiring a builder to build you a home and all you tell them is it's going to be a home. "Where, how big, the style of it and materials will be decided later but please provide a fixed price now!" It'll never happen.

  • 1
    ++ but an alternative to saying "No" is to come up with an at will, per delivery, fixed price contract. Treat it like a partnership where they continue paying so long as they find it valuable enough to keep paying for the product you're supplying (a new increment of working code every 2-4 weeks). Won't fit every customer or situation, but it's a payment model worth exploring. – RubberDuck Jun 10 '16 at 16:11
  • Thanks for your reply. I almost can't affect the type of contract. In my situation, the best thing I can do - quickly distinguish a potentially profitable contract from knowingly unprofitable one. Then I make a reasonable estimate for a good contract. Then it turns like a casino - I might get lucky and the project will be very profitable. Also, often it turns out to negotiate with the customer about controversial issues. But sometimes it just unprofitable project. Fortunately, we already have a good experience and on the average profit still there. – OlegAxenow Jun 10 '16 at 19:00
  • ++ for mentioning risk. The type of contract determines who bears the risk. If the risk is on your side, you need to price accordingly. – Mark C. Wallace Oct 28 '16 at 11:48
2

We have worked with four different models

  • Fixed price
  • Time and Materials
  • Time and Materials within a number of days worked range
  • Small chargeable scoping exercise, followed by a fixed price

The problem with Fixed Price, especially in your situation, is that you need to understand the problem well, otherwise you will have to add lots of contingency. Then you become uncompetitive. With fixed price, one of the other party is the loser and we have rarely had a good experience with it, unless it is for very small pieces of work.

Time and Materials on the other hand, from a customer perspective is like writing an blank cheque.

Time and Materials within a number of days worked range is similar to fixed price, but the benefit to the supplier is that you can build some contingency into the price, but not necessarily make it uncompetitive and the customer has the benefit of knowing a range of days, so it is gives them the benefit of that safety net. The basis of the range of days, is still upon experience of similar projects.

Small chargeable scoping exercise, followed by a fixed price works the best, especially if the result of the scoping exercise is a document that can be given to the client, that they can choose to go to other companies for quote. Then giving a fixed price quote on the back of that is much lower risk for you and gives the client the flexibility of having worked with you a little for scoping so they will know if they like you and your work.

In our experience options 3 and 4 are the overall best for both parties, and in practice option 3 is the one most clients would prefer.

There are some projects that because they are so ill defined (this we find especially with tenders), that we cannot quote sensibly and so give a very high quote that includes a safety margin, expecting not to win.

Remember you don't want to win all projects.

  • Thanks for your reply. We use the fourth model for writing technical requirements if we can arrange it with customer. Unfortunately, most of the projects is tenders in which we can do nothing to change. Can you share more information about the third model? Do you mean the restriction in the agreement, or something else? – OlegAxenow Jun 14 '16 at 5:55
  • I have edited following your comment to expand on option 3 – Marcus D Jun 16 '16 at 9:05
1

I worked with one consultancy that did some estimates based on risk.

They used a formula that would evaluate the following:

  • Type of customer (e.g. how collaborative they were, had we worked with them before, etc.)
  • Size of project (small, medium, large)
  • Technical complexity (low, medium, high)

and create an estimate based on that.

The estimates were not very accurate, but they were quick and cheap. The price charged to the customer was increased to account for the added uncertainty of using this approach.

An example:

A customer makes contact requesting some work to be done. The requirements are not well defined, so the technical team looks them over and estimates that it is a 'medium' sized project. They typically think of 'small' as under one month, 'medium' as 1-2 months and 'large' as over 2 months.

The project involves no new technologies and is a repeat of similar work the agency has done before. They rate it as 'low' for technical complexity.

After talking with the customer they find them to be quite defensive and very contractual (i.e. they insist on a deadline and full scope delivered). They rate the customer as 'challenging'.

They apply this information to a spreadsheet using a simple weighted formula. This results in a project estimate of 40-60k. As the customer is 'challenging' they decide to go with the upper end of the range and quote 60k.

  • Thanks for your reply. I use almost exactly the same approach as the first "filter" for incoming projects (see my comment on the David's answer). Also I takes into account schedule of the project. The bad news is that often requirements occupy a hundred pages, but are still sketchy and unclear. – OlegAxenow Jun 10 '16 at 19:15
  • 2
    Another approach I have seen when the requirements are vague is to sign an initial contract to produce a prototype. Say 5-10 days work at a discounted rate. Then use that time to reduce the unknowns and come up with a much more confident project estimate. This can often help to inspire confidence in the customer as well. – Barnaby Golden Jun 10 '16 at 20:36
  • @BarnabyGolden Very interesting idea. Could you provide more details about this formula approach? – Ruslan Doronichev Jun 14 '16 at 10:32
  • 1
    I've added an example to the answer. Hope that helps! – Barnaby Golden Jun 14 '16 at 10:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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