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.

This is all excellent stuff.
Could it be moved from Chat to Work so it won't vanish after 90 days?

BossyBitch Thanks for this information. I have downloaded a PDF about Scrum and am now off to inwardly digest! All of the assumptions you made are correct by the way, other than the fact we haven't got a team. It is just my DH doing the Project, as a one-man band!

Okay, one-man-band is highly relevant. It changes a few crucial things about your approach and options:

1. You should probably be strictly prioritising tasks and, failing a nuclear war breaking out, stick to your priorities - even more so than in normal project management. IME, 90 percent of people are a lot more productive when able to focus on one task at a time. As it happens, I'm one of the remaining 10 percent myself, but I've had to learn the hard way that every team I've ever had delivers better results when I'm not operating on the assumption that they'll multi-task.

2. On the upside, you don't need to worry about all that fancy resource planning stuff you get taught in project management school. You have one single resource, whom you can load to about 90 to definitely no more than 95 percent (the rest is contingency).

3. You'll need to work out some kind of self-management for quality control as you lack the instrument of peer review - in the rare cases when I have to finalise deliverables on my own (which I try to avoid like the plague, to be honest) I like to work with my own DoD checklists and plan my work in such a way that I can have a night's sleep before I self-review.

Arguably the biggest quality risk associated with being on your own is not coding quality etc. but thinking error, e.g. overlooking a crucial factor during analysis or committing a logic error in your train of thought and having no-one to point it out. This happens to the very best of us on a regular basis. Try to get greater stakeholder involvement if you can so that your client can be your reviewer!

4. Your estimating issues just got a lot easier: since there is only one person estimating and the same person is the only delivery team member, you should be able to easily calculate your DH's average error. Use this as a factor on all of his estimates and then add another 15-20 percent contingency (contingency is basically the monetary counter-value of risk - in this case you'll need it because the one-person oversight issue described above makes it likely that you'll be more than the average error off in at least one crucial case) I'm willing to bet that you'll average out quite okay using a (ideally somewhat tailored to your actual circumstances) version of this.

5. Scope control is super extra important for you (it's always extra important)! While I'd quite like to strangle project managers who think that each and every problem can be solved by throwing more people at it (because that's not the case and they're idiots), in some situations this is actually sensible. This avenue is not open to you. Your scalability is precisely zero, which limits your ability to absorb change.

6. On the really bright side, if you manage to get profitable you can easily be insanely profitable, seeing as you have no unproductive management overhead (like myself ... ) to finance.

As it seems you have branched out into a bit of a sideline, have you checked your insurance cover is adequate?

Not a contractor and haven't read the whole thread but do you not have a project plan (of sorts) in place and Statement of work outlining what needs to be done.

Thank you BossyBitch. Most useful.

Truffle, yes we do have insurance cover.

Vivienne, we have a verbal agreement and not a Statement of work. Now I realise that this was our first mistake of many.

In that case get the statement of work in place ASAP and as detailed as possible.

By the way, one more point: the fact that your agreement is verbal only whereas you state in your OP that the client is a 'very large' company means you have to be extra careful (and must really try to get a contract in writing by all means).

Corporations are notorious for being sticklers for contracts. I should know - I work for one and legal is cramping my style big time.

A corporate client not insisting on ridiculous amounts of contractual documents would actually make me feel very suspicious. This is very, very unusual for large firms and I suspect not in a good sense.

Wrt estimating, based on what you've said, my guess is that he's estimating the coding stage and ignoring the rest. There's a number of different 'rules of thumb' but one is

1/3 Planning.
1/6 Coding.
1/4 Component test and early system test.
1/4 System test with all components done.

Have a look at some of the averages on line and see which most closely match your estimating and overruns.

Wrt the verbal agreements, you must put everything in writing, verbal is no use. When you create an estimate you base it on a number of assumptions. You need to document all assumptions (e.g. based on nn frames, x elements per frame etc). Agree your tolerances (can cover a 10% increase) and agree change control process up front. Anything which is likely to increase the cost must have change impact assessed and signed off by the client.

And remember, every client wants a rolls Royce for the price of a bus ticket. Get an idea of what they're likely to want to pay, and v clearly outline what they can get for that, based on the estimating model you choose, where coding is max 50% of total estimate. If they want 'bells and whistles' sell it to them by showing the value add

I doubt they will raise a purchase order without a signed contract...

I doubt they will raise a purchase order without a signed contract...

As far as I know, this is a requirement now in the UK under the anti money laundering legislation?

They have already raised two POs for the work that we are doing. We signed their general Terms and Conditions. We have now been paid for both POs. Trouble is that because we didn't build in any charges for the testing phase, we are still working on it even though as it stands, we won't be paid any more. I know in the light of this thread we have completely and royally f**d up.

We are considering just handing over the product to them as it stands. There is meant to be a phase 3 of the work when they plug our product into their systems. However, we don't know if we want to sign up for another piece of work with them. We have set up an expectation where we work for peanuts, so I suspect that they would be shocked if we presented them with the request to be paid at proper market value.

HidingfromDD You are so right in your guess of how we estimated the work required in developing the product. Just thought about the time needed to do the coding and nothing else! So many rookie mistakes!

We thought that even if we didn't make loads of money, at least a technical reference would be useful to allow DH to sign up with agencies to work as a Contractor. As our project has not been completed in the time the company we are working for hoped, the reference would probably not be a good one anyway.

As our project has not been completed in the time the company we are working for hoped, the reference would probably not be a good one anyway.

Congratulations! You've got yourself a bog standard IT project reference there.

Schedule and budget overruns are sadly the norm in the industry. I'm not saying this is a good thing, merely that nobody really expects anything else.

The worst case I've ever come across (not mine, luckily) was 7 years behind schedule and some 50 million over budget by the time we were contracted to perform an audit on it. They'd also only delivered about 40 percent of their scope by then.

We recommended to pull the plug on it. To nobody's surprise, they carried right on anyway. They're still not in production to this day, have caused mass resignations and must have wasted going on 100 million by now. Also, the guy responsible for it was promoted to senior god-mode executive somewhere along the line.

What You've got going there is by no means ideal, but it hardly clears even the minimum hurdle for inclusion in the tech project fuck-ups Hall of Fame.

Aah. Thank you BossyBitch..... That does make me fee a lot better! The guy who commissioned the work from us gave his bosses the idea that the work would be done by Christmas. We weren't actually told that they wanted it done in this time scale though. Now the guy who we deal with is getting pressure from his bosses. Although the product is finished, it is still being fine tuned to eradicate minor errors. Should be finished in days hopefully!

We recommended to pull the plug on it

Agree, it's very rare for a project to be pulled once up and running - too many egos in the way. Only once in many years of PMing did I get a project pulled, and that was before any detailed design or actual build had started.

I made an enemy that day who always made things difficult for me then on, to the point I recorded all conversations with him and sent out a transcript after every meeting. Luckily he was a shining star and was promoted out of my depth and then was head-hunted by a rival company where he spectacularly failed! The Curse of an angry PM knows no bounds!

I just remembered that this is so widespread that Wikipedia has a dedicated list of IT project disasters: en.m.wikipedia.org/wiki/List_of_failed_and_overbudget_custom_software_projects

Obviously this doesn't include the myriad smaller catastrophes that never made major headlines ...

:)

Apologies if already mentioned / but do not put your code on their IT system without a proper contract in place. That contract needs to specify clearly your liability and support arrangements.

Worst case your code breaks their it system and the lose millions , they can come after you for that? Also if it breaks at midnight - can they call you? Can they call you in 5 years time with problems? Who owns the IP? Could they sell your product on to other companies?

You need a contract defining all that and to protect yourself.

Eve is completely correct - I have a legal agreement with all of my suppliers (I have to) which covers all Eve talks about.

It also details the dev/QA/live process and how each stage is progressed.

Once you are an approved supplier then I am able to discuss initial scoping, statement of Work etc.

You may need a lawyer for the legal agreements.

It's about protecting yourself mainly.

Agree that Eve raises very valid points. I mentioned ensuring clarity regarding IP earlier, but understanding expectations around maintenance is also very important to avoid misunderstandings that can undermine your reputation (eg they expect you to fix something for free, you don’t realise this and they get upset). Liability is our lawyer’s favourite subject, though it concerns us when we feel a (very small) supplier agrees to everything without question as it might be that they don’t understand and that isn’t ideal if we ever needed to enforce a contract in some way.

I’ve just been (as a supplier) asked to push to my contractors unlimited liability contracts.

Unsurprisingly we and they all said no.

@snowyhill you need a contract making your liability clear and then insurance backing that up.

Eve oxoftoads Blueroses99

Thank you for all of this extremely valuable information. Can I ask how you went about drawing up such a contract? Did you get a solicitor to help?

I presume that we need to consult a contracts law solicitor?