How to define fixed priced software projects and how to argue what is inside scope and what is outside scope? [closed]

Question

Closed. This question needs to be more focused. It is not currently accepting answers.

---

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 4 years ago.

Improve this question

So here is what happened

The customer gave me a list of things he wanted to have. It is a funding website. So to start a funding project he wanted to have certain fields in the "create/edit funding project" part. He gave me a document on what should get implemented. I estimated around 25 hours for it and made a price tag for that milestone, but am now at 66 hours, and according to him, it is not done yet.

An example: We changed an existing wordpress theme. He wanted a funding project initiator name for each project. So i estimated 0.5 hours for adding a field 'project initiator name'. For me, that was adding the field and adding it to the "create/edit funding project page" there was not mentioned to add it somewhere else in the document.

Now he added a "bug" that this new field does not change in the "My account" the display of the "my profile". He added other things that were not in the feature list as well.

How do you create contracts for milestones that don't give the customer a bad understanding of what is inside and me no need to explain what is not inside?

Answer 1

Software is never done. That's why it's soft.

If you sold this project as something that would be defect and maintenance free you're living in a hell of your own making.

A lack of defect tickets is not a milestone. It's a temporary anomaly (that may indicate something is wrong with the ticketing system).

You should be working towards the previously agreed milestones. Doing anything beyond that is not only hurting you it's hurting your customer who now thinks they have to hound you over every little thing when what they need is a working web site. You understand this better then your customer does. It's your responsibility to make it happen.

Your contract should have excluded maintenance and defect corrections. If the site can be made to work then you've got your milestones. You drive this point home by showing them what maintenance and defect corrections are going to cost. Don't underestimate this just to make work for yourself. This isn't real work. This isn't even charity. You're hurting your customer.

When you estimate the work make the scope clear and the price clear. Stick to the scope and the price. If there is any doubt be very conservative. Taking longer than estimated to get it "just right" is unprofessional.

Sometimes you get surprised. It happens. But as soon as it happens revise your estimate and seek new approval. Do not work without approval.

Do not "try harder". The very moment your estimate is in the slightest doubt revise it.

This is behaving professionally. Customers like predictability. So much they will pay you to take an hour to do a 5 minute job. Take 65 minutes to do it though and don't expect them to hire you again.

You say this is a fixed price contract. Doesn't matter. Time is money. Also, you are a very valuable resource to your customer so working yourself raw over trivia is also not doing them any favors. Take care of yourself. Take care of your customer.

If you understand this and behave like this then when problems crop up that you think will take "0.5 hours" to fix you can answer them with a confident, "That will require a new agreement. I'll allow a day for it and I'll need you to be available just to be sure it's resolved to your satisfaction."

Do that every time some little thing comes up and you'll see the little things become fewer and fewer and a bit more important.

Many programmers think of their customers as slave drivers cracking a whip demanding, "Faster! Faster!"

This is all wrong. Think of them as a little kid in the back seat of an airplane that you are piloting as they squeal, "Faster! Faster!"

It's your job to land them safely. You can laugh and dip your wings. But mind your air speed.

Answer 2

If I have learnt anything from freelance projects and especially with Agile development it is: for goodness sake - set done criteria. These are clear milestones that can be ticked off once something has been done. Naturally, these need to be crystal clear and set with your customer from the outset.

Now they may just want "a website", but even then it is worth taking the time to itemise everything so if either party are no longer happy with the association, then the work completed can be billed.

Something that can help (which freelancing sites use quite a lot) is escrow. It isn't a silver bullet but it at least helps to know that the development budget has been put aside and you're not over a barrel developing forevermore without seeing a dime.

Not everything should be billed. It greases the wheels if you can do the odd (quick) bit for free whilst you're in a certain section of the code doing something else. Make sure your client is aware of this goodwill development and it will help your position for any contentious features/bugs.