Any IT contractors out there who might be able to help?

[SnowyHill]

We have ventured into IT Development work for a very large company. We are having difficulties managing invoicing. When we undertake work for them, we have no idea how long the piece of work will take. On the first occasion, we estimated that the work would take a week and it ended up taking three weeks. Effectively we worked free of charge for two weeks.

The second piece of work, we gave an estimate that the work would take three weeks and we would charge for any additional days on a per day basis. The piece of work ended up taking five weeks. The company concerned are not happy as they feel that it is more than they had anticipated paying. They only want to pay for the three weeks already invoiced for.

Clearly we are over-optimistic with trying to guess how long an IT project will take. It is virtually impossible to know really how difficult something will be. Unforseen snags arise and also clients want changes which seem trivial but take time to get sorted.

How do other IT Contractors manage re knowing how much to invoice? We are really struggling with this and are ending up doing lots of unpaid work in effect.

[PoppyCherry]

I’m not a contractor but work with them a lot.

Why are you doing fixed price rather than day rate?

When you don’t know in intricacies of a company/their environments/operating models etc. It must be nigh on impossible to judge how long something will take?

[PoppyCherry]

Just read again.

So, not fixed price?

But you’re providing an estimate of how long it will take, is that right?

[Eve]

DO you have a contact with them?

That should define exactly what you are going to do , when you are going to do it and the dependencies and deliverables, and then you either do it as a day rate or you do it as a fixed price rate depending on where you want to carry the risk?

Why are you going over so much? is it poor estimating or are requirements changing?

[SnowyHill]

Sorry for delay in reply. We are going over so much as we have no idea how long the job will take. IT projects can be so fiddly. We don't have a signed contract in terms of what we are going to deliver. It's down to a verbal understanding of what is to be achieved. Of course we do get some changes in requirements as we go along because these projects kind of evolve.

I'm not sure how to go about charging a daily rate. The company concerned raises a Purchase Order for chunks of work. If we were to charge on a daily basis, I wonder if raising multiple Purchase Orders would be tricky?

The company we work with also takes 90 days to pay invoices, so it's a long time before we are paid as well. Nothing we can do about that however.

[EggysMom]

No offence, but you don't sound as though you are running the company very professionally - you have no estimate of how long the work will take, no formal contract, and as a result no way of rejecting changes/additional work or increasing your fee appropriately.

The cost estimate should be on the basis of a works order that describes and details the work to be done, for an negotiated fee, by a certain date. If it takes longer for the agreed work, that's your problem. If they want to change the agreed work, you re-negotiate.

[ShoutyMcShoutFace]

Yes to order of work or detailed project plan, anything outside of scope you deal with as a (chargeable) change request, plan in extra time to each stage to allow for things slipping. Are you splitting it down into coding, QA, user acceptance etc?

[DrDreReturns]

I'm not an it contractor but I'm a software engineer. Estimating how long something will take is notoriously difficult. I always double my initial estimate when my boss asks me how long something will take!

[PoppyCherry]

Ok, so if it’s a chunk of work you need:

Detailed defined scope
Plan (development, test phase, implementation)
Assumptions you’re making (together with a clause that says if they turn out to be incorrect it may affect time/cost
Dependencies
Risks
Change request process (they change requirements, you impact assess it, then quote additionally)

Companies are going to LOVE you if you quote fixed price. No risk to them, no matter how long it takes.

You MUST get something in writing. You have no come back if not.

[SnowyHill]

Thank you all for each of your comnents. They are all very useful and have given alot of food for thought. Sorry it is taking me a while to reply . Juggling family stuff as well as posting this evening! I realise that we are not really going about things in a very professional manner. How do you go about drawing up a contract? Is this a job you would need a solicitor to do?

[PoppyCherry]

Google “Statement of Works Template”

That will give you a good starter for ten.

[WeAllHaveWings]

The IS partners we work with charge us for a functional assessment, timescales and costing before we decide to go ahead. Any changes to the original request are reassessed and chargeable. Then it takes as long as it takes, but they are usually pretty close.

[SnowyHill]

Thank you for this advice both of you. I am just off to Google Statement of Works template.

[Yetanotherposter]

Tricky one this. You've set up expectations that will be hard to back out of.

Software development estimation can be really hard because it's abstract rather than concrete. You hire builders to build a 10m long wall, then a 20m long one, we all know what a wall is and you have a fairly intuitive feel of how much the second one will cost you*. Two bits of software that do task A and need to be extended to do task A+B could be hugely different amounts of effort - and that's before we discover task B has loads of fiddly nuance that makes it ten times as big as expected.

Sorry if any of the following is old hat to you, but: there only seem to be two ways out:

• untrendy waterfall, where you charge separately for requirements discovery/design/planning and then for delivery of the agreed scope - and ruthlessly charge extra when customers change the scope, OR...
  
• trendy agile, where you supply a team that has some analytical as well as development ability and charge per small iteration ("sprint") at the end of each of which you demonstrate progress. Usually the charge is based on a "blended day rate" averaging your charges for the different roles involved.
  

(Nb - only waterfall development has successfully landed on the moon, but nobody will hire someone who doesn't pay lip service to agile)

If you're really just a 1 or 2 person band you could probably just be charging individual day rates like freelancers, though in my experience that just shifts all pressure to demonstrate progress into your ability to win people over, which can be stressful.

Discovering what the client's problems are and how to match them to fairly straightforward (but just-right) bits of technology is often more important than making super-fancy technology - so you need to charge properly for it. In my experience (as contractor, consultant, and hirer) you have to be a bit expensive for customers' decisionmakers to listen to what you're saying.

And finally, never forget the iron law of IT estimation:
Ask your developer to think of a time (2 hours)
Double it (4 hours)
Change to the next unit up (4 days)
...and add one (5 days)

And that's how long it will take!

Good luck...

*apologies to any builders whose clients disprove this - I'm sure they're out there!

**a bit more than twice as much; it's more than twice as likely to hit a hidden obstacle.

[PoppyCherry]

Nb - only waterfall development has successfully landed on the moon, but nobody will hire someone who doesn't pay lip service to agile

Ain’t that the truth 🙄🙄🙄

[SnowyHill]

Yetanotherposter That is is all really useful information. You are absolutely right about the abstract nature of software development. The product produced seems to evolve into a life form of it's own as it is so bespoke to the client's requirements. If you seek to produce the best product you can, then you almost create a rod for your own back by generating hours of extra work. Love the iron law of IT estimation. Can so relate to that!

We will have a good think on how to use all of the information you and previous posters have supplied to try and get to grips with a more sensible working model. The way we are going, we are earning significantly less than the training work we were doing previously, so seem to have taken a backward step.We started out on this development malarky thinking it would be both lucrative and interesting!

[boxoftoads]

You need a cast iron statement of Work, I'm used to being charged for a few days initially for scoping too then full work. I'm happy to do this as it benefits both sides.

A PO can usually be amended in value or due date. Just depends and good to ask this at the start of each negotiation.

I bloody hate agile. It just seems like a constant exercise to get something/anything out and claim to fix all faults next time. Repeat for ever more.

I can't stand the terminology and how fashionable it is. It also does not work in a regulated environment where validation and compliance is key. But who am I to question such a brilliant thing

[kalapattar]

For you

[SnowyHill]

[Blueroses99]

I do the contracts for IT services for my firm.

Development is typically split into 2 phases: ‘elaboration’ and ‘construction’. The first phase is going through the requirements in detail and obtaining all the info needed to confidently plan and price the second phase. A deliverable of the elaboration phase is the completed statement of work (SoW) for the construction phase. Any changes to the SoW that impact cost or timescales must go through a change control procedure so we the client do not incur any additional costs without having agreed in advance and in writing. We would not expect the contractor to change the scope or carry out any additional work unless it had been agreed this way. This approach applies to agile as well.

We would raise one purchase order for each phase and each subsequent change order. It is extra work to generate the purchase orders but it means that there is full transparency.

In terms of the contract, you might find that you’ve entered into some default T&Cs eg attached to the purchase order. You could probably search online and find a decent template, or could ask the client for a copy of their standard T&Cs (although chances are these will be in the clients favour rather than yours so it might be too onerous on you). With software development the major issue is around intellectual property, including who owns the IP created, can you use any of the IP in other client projects, can the client share the source code with other contractors (your competitors) eg to enhance or maintain the software. This may be included in a SoW or in separate T&Cs. As a buyer I would be looking for an IPR indemnity which means my firm is not liable should it turn out that a contractor has copied from an unauthorised source!

Probably lots to think about but if you could the framework in place, I’m sure you can handle this more professionally and hopefully also enjoy it!

[SnowyHill]

Blueroses That is really useful information. I hadn't realised until reading the input from you and previous posters that you can actually charge for the stage when you are finding out what the client wants. It can often take several days of meetings to get to the bottom of their requirements.

You are right that there is a set of preset terms and conditions. It is a very large company we are doing work for so they are well organised. I will dig them out and read them as I am sure that this will be very relevant. Thanks again as your information really helped.

[NoFanJoe]

I always do a daily rate. Aim to do frequent code drops so they can see progress. Aim to wok with people you trust and who trust you.

Estimating isn't precise enough ... so you get burned when you under-estimate ... so you massively over-estimate to prevent that ... so the client complains about how much you're saying it'll cost ... so you end up guessing what they'll be willing to live with and estimate that irrespective of what the work is.

Agreeing requirements beforehand ... wastes effort producing that spec ... which is then continually haggled over because it's always changing or misunderstood ... which just wastes everyone's time.

[PoppyCherry]

that you can actually charge for the stage when you are finding out what the client wants.

Yup, we do this too for bigger/less clearly defined scopes.

[chewiecat]

Yikes this all sounds like quite rookie PM errors, sorry op
It may be worth you taking a basic project management course eg Prince or PMP, really helpful to understand the relationship between scope, time and resources

1. Your estimation is too ambitious

I always overestimate to my clients especially when scope is unclear. Also I add in a buffer when I know the client can be tricky. This gives me some wriggle room in case shit hits the fan and I can chuck resources at it

1. Scope needs to be clearly defined

Every job I start, we draft a statement of work (sow). Work doesn't start until the sow is signed by both parties. In the sow, I detail everything that I will do, with what resources and how long. I go through this sow with a fine tooth comb and ideally get someone else to review because this document is the fallback when things go awry.
Once the project starts and there are any deviation from the sow, you need to raise a change request and ask for more resources or time

[SnowyHill]

NoFanJo We did try to charge a daily rate. I gave a price for 3 week's work at the start of the project which we said was an estimate of what would be needed. I said that any extra days required would be charged at a daily rate. However the company we are doing work for took this to mean that the Project should be finished in 3 weeks. In retrospect I now realise that we didn't build in enough time for scoping and testing and refining into the estimate of 3 weeks. We are learning the hard way.

[SnowyHill]

Chewiecat No offence taken as you are quite right. Our errors on this occasion mean that we are literally doing highly skilled and specialised work for peanuts.