How should we quote differing sized contracts in a SCRUM environment

Question

I am trying to implement an agile-ish approach to our firm. Right now we have a very much waterfall like approach to designing, coding, testing, and releasing. One major issue we haven't found an answer for is the idea of quoting. We allow our customers to request small to large changes in the system and pay for those individual changes via a work order. For instance, one customer could request a field be moved over an inch in some report of theirs, while another customer requests a large, several hundred hour addition to the core software. The way we quote now is rather inefficient. Basically we, myself and my boss, look at the code and guess how many man hours it takes to finish. Sometimes we ask the dev who would work on it, sometimes we don't. Sometimes we have all of the requirements, sometimes we don't. It's very much an educated guess at best. We charge the customer the number of hours times some predetermined rate once we have an estimate. You can imagine how often we go over our estimates with actual work.

Since we allow changes and contracts of such varying scope, how could we go about quoting effectively in a SCRUM or Agile process? I like the idea of quoting by points instead of hours, and using SCRUM estimation practices to determine the points, but my boss isn't a fan as he thinks we need to have our quotes done and paid for before they enter any type of product backlog. His belief is that we cannot quote any other way because we need to lock the customer into a specific contract to avoid changes down the line.

Lately, we have run into many issues with customers changing specs last minute and getting mad at us for charging them for the changes or denying the changes out right. I like to look at the agile manifesto and think about collaboration over contracts, but no one else at my firm is sold quite yet.

Is there a way to effectively quote in a SCRUM process where we do not have regular, time intensive contracts but instead have a varying degree of change requests paid for by different customers?

If you need any more information let me know. I appreciate the insight.

Answer 1

'my boss's' belief is that we cannot quote any other way because we need to lock the customer into a specific contract to avoid changes down the line.

seems to be refuted by

Lately, we have run into many issues with customers changing specs last minute

This is a not a unique problem. Contract negotiation favours those with the more expensive lawyers. Otherwise it is better to work with clients who are flexible, understand what agile is about and actually want working software at the end of the project rather than someone external to blame when the project fails.

I understand that isn't very helpful for you right now, so I would suggest consulting hours. Bill them for a set number of hours up front and be honest with them that this is an initial estimate to get things started and that you can refine it with them later. If you then work closely with a customer representative to prioritise your backlog you can always be working on what the customer thinks is the most important. At some point they will decide they have dealt with all the high priority work and don't need to pay for any more hours, the stories left on the backlog were obviously not that important to them, whatever they said at the beginning. You need some predictability so I would suggest billing in chunks, 1 hour, 5 hours, 10 hours, 1 week, 1 month whatever is appropriate so you have some idea how much money is coming in next and can plan your payroll.

As for time estimates, you always need to involve the people who will actually be doing the work otherwise you are asking for trouble. And if you can track your estimates and then track how long it really takes, you should be able to build a model to better estimate in future.

Answer 2

If you work in an agile way this should also be reflected in your pricing.

Ie. Instead of estimating, quoting and fulfilling an order for a set price. You should quote per sprint.

Task and estimate as usual but be upfront with the client that if the sprint runs over, or they want to add more features, they will have to pay more.

Although it sounds off putting, its becoming a fairly common way of quoting. The sell is that that client doesnt have to take on the effort and risk of specing out the project up front.

You work with them in a collaborative way and they pay for the time/resource that they use during the course of the project.

Although there is the risk of the project running out of budget before completion in the aglie model. This is balanced by the avoided risk of mis, or under speccing the project in the waterfall model.

Additionally you could add that in fixed price contracts the seller will price in average overrun and 'keeping the customer happy' changes. So the pay by the sprint model can end up being cheaper if you dont overrun or make spec changes. (which no customer thinks that they will ever do)

Answer 3

There are 2 main ways to deal with this:

1. quote as before - its not the customer's responsibility to consider how your internal processes work, they pay, you deliver. Its part of doing business that you get your quotes high enough to make a profit, and low enough to get the work instead of your competitors.

2. quote on a "time and materials" basis. This is a 'rolling' contract where they pay for the time it takes, regardless of how long or what they want. They want more stuff, no problem, the meter keeps running.

Option 2 is the best for you, but not necessarily for the customer. If you suddenly start charging them much more for the same kind of changes they will notice, and you'll either lose the business or lose their goodwill. If your agile dev strategy works well though, and they get changes faster (and therefore cheaper), the opposite will happen.

If you cannot go for the 2nd option, and many businesses are simply not set up for such open-ended contracts as they cannot easily budget for them, then you'll have to estimate how long it should take, bill them accordingly and take the hit if you can't deliver (or take the money if you do!)

Answer 4

Well, one way or another this comes down to how accurate your estimation of the work involved actually is. And how you manage the risk.

I would suggest you have separate processes for minor modifications and major modifications. Minor mods, however you decide to define that, could be fixed price changes, (independent of hours worked).

Major mods would have a more complex charging structure, this could be negotiated with the client. Say you have a fixed price contract for the project, then the contract would be priced to accept the risk of a project overrun. Alternatively, if you charge by the hour, the client is carrying more of the risk.

You could try an estimated upfront cost (say a fixed number of hours) and then a reduced hourly rate. Alterations to specification would be charged on top of the original price.