How do you bill for software development?

[gpuerrilla]

One of the challenges is freelance project managers have to get paid from somewhere and hence may not be completely neutral. In my experience I would say all else being equal (skills, experience etc) the ideal scenario is to have PMs that have worked with a given org for a decent period of time so understands the culture, ways of working, business and IT context, has wide-ranging relationships established etc. Realistically that means they will be closer to the customer than the supplier, but if they are a good PM, I don't think that is a problem.

Yes this it true, ideal but a bit sunny day (unrealistic for most setups). However as these things need doing it just means lots of adjustment, teeth pulling etc. From my experience it helps if the teams are keen to better their workflow and you can get them enthusiastic. People that are not keen tend to feet drag, appear resistive and do all their day job stuff leaving any tasks on the backburner which is why the integration/migration suffers.

 

[NickK]

Everyone follows the money.

The mindset the org needs to leave behind is that IT are overheads. In reality of the modern world, IT are enablers for the business model. Successful business units bring the two close together with one vision. The basic use of external contractors perpetuate this cultural issue. Instead the culture needs to be instilled from day one across the organisation.

 

[OspreyO]

Often IT isn't seem as an enabler but a blocker. Which is why some projects are outsourced to get around the imagined block. But when it goes pear shaped they come running back to internal IT to be rescued. But they've burnt their bridges at that point.

As for PMs it's rare to get a good one. A poor PM can poison a project.

This is why you need staged payments and never work past a missed payment. You get your money and be prepared to walk away.

 

[MikeTimbers]

If there isn't a fixed scope and requirements definition then there cannot be a fixed price. You have to try to make this argument to your potential customers. If they cannot fix the scope, you cannot fix the price. If they do fix the scope, and then want to change it, that's a change request while you continue to work on what was already agreed.

This is what the big SI do because they have the best contract lawyers to back it up. That may not be true for you but it's the balance you have to try to realise with the client that is there to protect you both.

If they want to work in a true agile manner, then the only way is to have an agreement for a set quantity of sprints with an agreed development velocity which defines the team structure that starts with a sprint zero where you are paid to setup for sprint one. Then extensions can be agreed but again based on a quantity of sprints. This too requires considerable overheard by your scrum master to prove burndown and velocity etc.

 

[NickK]

If there isn't a fixed scope and requirements definition then there cannot be a fixed price. You have to try to make this argument to your potential customers. If they cannot fix the scope, you cannot fix the price. If they do fix the scope, and then want to change it, that's a change request while you continue to work on what was already agreed.

This is what the big SI do because they have the best contract lawyers to back it up. That may not be true for you but it's the balance you have to try to realise with the client that is there to protect you both.

If they want to work in a true agile manner, then the only way is to have an agreement for a set quantity of sprints with an agreed development velocity which defines the team structure that starts with a sprint zero where you are paid to setup for sprint one. Then extensions can be agreed but again based on a quantity of sprints. This too requires considerable overheard by your scrum master to prove burndown and velocity etc.

The concept of precise and accurate requirement is really nonsense. It's all down to understanding and interpretation - this coming from someone that spent 4 years of a SE degree putting English into maths and then formally mathematically proving the requirements your adding don't destroy the existing integrality. If you look into Formal Specification, Z and set theory then you'll see what I mean.
Too precise and you'll end up coding it in requirements, to lax and you're unsure what is done - and that's why software requirements in a long list suck.

Fixed does work, but you have to stick to the documented definition and ensure that satisfaction of that definition disposes of the lock for payment. That's the key piece - the lock for payment. This is no different to 'agile' with a sprint. Once the agile sprint is done, then your requirement is disposed of and you can legally show it. If the customer wants something different then you should have a clause in the contract around change management that defines change is done with additional cost and does not hold the payment of the sprint payment.

You should also have a clause that specifies that basically limits the maximum time per preparation, sprint and also that your company will not be liable for any delays resulting from the customer.

I would prefer to have an internal programme manager. This prevents the timelines elongating into the distance to keep the contractor pay going.

 

[MikeTimbers]

The concept of precise and accurate requirement is really nonsense.

Totally agree. The days of waterfall software development are long gone as software complexity and business requirements have grown. I used to do it decades ago but I couldn't see how to even quote for it today. The only real way is to quote for a fixed price discovery followed by an agreed specification which is then quoted for. If secondary quote is unacceptable, walk away.