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.

Doing a more tech project at the moment, although I am not tech myself

Collecting business requirements alone can be a project including what is not in scope - then once you have those captured, translate into a functional requirements spec (if you built a test plan to check it was done, you would check in ref to this list to make sure you built it all) and then that moves into the detail design docs, data loads etc

Also: write a change request process into the sow, even if you don't formally use it you can have it as the basis of your discussion (x can be done in scope, y would be too big a change to accommodate so is a change request with additional budget)

In my experience, whether the work gets done satisfactorily is generally much more important to everybody than the relatively small amounts of time you're talking about.

It's easy to mistake where the power balance lies, particularly when you're small fry dealing with a big company.

You're client's currently happy for you to work for buttons. You don't have to accept that. Taking 5 weeks versus 3 weeks is par for the course in IT. Just because you agreed to that timescale doesn't mean you have to just suck it up. If it were me, I would be prepared to pull out, not deliver the work and not get paid at all. I would tell them that's what I'm prepared to do, and mean it. It helps make everyone realise that they want you as much as you want them. For the client to take the work to an alternative supplier is expensive and they won't want to do that as they'll end up paying more.

From my perspective, day rates are fine when we are effectively ‘bodyshopping’, ie as the client we are responsible for managing the workload and deliverables and the contractor is just providing the resource. If we are buying in expertise however, and want the contractor to take more responsibility, we would not agree to day rates at the risk of the project cost becoming a blank cheque. Project budgets need to be controlled somehow.

The next stage of our project will be putting the product we have developed on the Company in question's IT System. I think that this is going to be particularly hard to judge how long it will take as there will likely be unforseen snags. Charging for the scoping stage and drawing up a statement of work should help alot though.

Do you already have some kind of framework agreement in place with your Client? The may already have a Statement of Work template that can be tied back to it and which could be used.

Always build a certain % contingency time into your plans. I'd suggest 20% is sensible. Even if you charge on fixed price you could calculate the reduction in cost based on equivalent day rate and invoice the client at the lower amount at the end. Shit happens, and never more than when working in projects! You definitely need some extra time to deal with the surprises.

Totally agree with the comments on charging for scoping - you'd be mad not to!

Agree with pretty well everything others have said, but would also add that presumably you are expecting the client to deliver things to you (Requirements, sign-offs, attend meetings etc) at certain mile-stones. Make sure you make these clear and that you will charge them for any delays incurred if they fail to meet deadlines, or their inputs are incomplete.
I suggest you hire a competent PM for any future work, until you develop the skills yourself.

I'm a manager within a global tech consulting firm and I estimate projects and write offers as part of my job:

Some really good advice on this thread already, but let me briefly summarise my POV:

First and foremost, not having written contracts is a no-no. You need to have a formal agreement on a whole range of issues, most of which have already been mentioned. Scope, compensation, change processes, liability, client's obligations towards your firm (and some definition of what happens when they're not met), assumptions (and what happens of they're not met) ...

Secondly, your compensation model needs to fit the type of work you do. If your scope is fuzzy (or, worse, entirely unclear) you stand roughly a snowball's chance in hell of not making losses if you're going with a fixed price. In this case, you're a lot safer with a time & materials approach. Understandably, clients tend not to prefer these unless you have an established relationship and they trust you not to waste their money, though. There are some very interesting mixed models, too, though. Google agile contracts - I've recently delivered a project on a model that set prices on a performance basis. The client lives it and it incentivised the team to do better.

Thirdly, your estimating seems way off the mark. That's a very common problem in a lot of IT projects, but there are ways and means of improving the situation. I suspect that your most pressing issue may again be that you're unclear on scope. You can't possibly know how much effort something requires if you can't properly define what is and isn't part of said something. Also, as PP have stated, developers always underestimate. Personally, I use a method based on back data of actuals from years worth of projects to apply factors to any estimates. I learned this from my ex-boss and it works miracles. To be frank, there's a good deal of art rather than science involved in estimating - in that you have to somehow approximate relevant context in addition to simply being able to forecast the raw amount of work that goes into a given task.

Then, forecasting and project controlling: you shouldn't find yourself in a situation where you're surprised by unexpected extra efforts or delays. If you set up good controlling and reporting you should be able to anticipate these and pro-actively work to limit impact.

And, finally, none of this is going to make a difference if you can't assert yourself. You have to protect your scope and your T&C as though it meant your life. Yes, doing something or other 'extra' is a good relationship builder - but you've got to be in a position to pick a something that won't break your back.

I could go on forever (and I do, at times, in that I teach internal project management courses). This is all very high level stuff right here. My best advice, OP, is to take thee to a bookshop and buy some PM educational books. Don't limit yourself to just one methodology either but read what each of them has to say so that you can assess what fits your client projects' circumstances.

I would suggest you go on some kind of Project Management training. In the meantime to cover you I suggest you draw up a services for assistance time and materials contract

"The next stage of our project will be putting the product we have developed on the Company in question's IT System. I think that this is going to be particularly hard to judge how long it will take as there will likely be unforseen snags"

Haven't you done the testing yet? If you have done a comprehensive test and have a good test plan it should not happen as much. It can be controlled. Do you not have a test manager in your team? It is almost always the testing phase that delays almost every project

And @pitterpatterrain is right. Any CR, that is a lot of work should be charged separately.

Thanks again to all who have taken time and trouble to post advice. I was just wondering how many days is reasonable to charge a client for scoping? I know it is a case of how long is a piece of string. I was thinking along the lines of maybe three days. One day for discussing with the company concerned what's required, one day for coming up with statement of work and a final day for discussing statement of work with client. Does this sound like too much?

Bluebells. Sorry to miss your question. WE are testing the product now. One of our many mistakes is we didn't allow time for testing.

If you seek to produce the best product you can

OP this is a classic hole to fall down - you produce the product that is necessary to do the job and the one you are paid to do... not an all singing/ dancing system.

Day rate for scoping...then when you get a confirmed design you can give a fixed rate for that!

Eve and PetraDelphiki That is useful advice. Thank you.

I was just wondering how many days is reasonable to charge a client for scoping?

This is when it’s useful to plan at a more granular level eg think in hours rather than days. How many meetings will you require with the client to gather requirements? How long will each meeting be and when will they scheduled, is everyone available immediately? How long will it take to write the findings and how long will it take to share with the client? What additional steps might be needed? Is there documentation to read etc? Then once you’ve planned it, convert it back into days.

Regarding @Eve's point, read up on 'goldplating' - this is the standard term for when unreasonable efforts are made in order to perfect minor details. It's also a pandemic disease among very good engineers and therefore keeping it in check is any delivery manager's bread and butter.

As for how much time is reasonable for scoping: this depends entirely on the high-level scope as is already known, i.e. how large your project is. I'm currently running an entire self-contained project with the explicit goal of scoping a number of follow-ons, and we need 3 months for it. But this is for a large-scale, multi-component enterprise with >50k users and a complex legacy landscape.

Even for a small, self-contained project, though, I'd want a week: three days roughly about for what you say and another two to negotiate the tough cases.

Please bear in mind, though, that I specialise in large scale delivery, so my understanding of 'small' might be a few orders of magnitude off. To me this is

Right. Off to buy a book on Project Management. Agile or Scrum; which do you think is best?

Ex analyst here for large in-house projects. Some very good advice here. If your role is to do everything - i.e scoping, defining, bullding,.testing implementing. Then scoping and defining should definitely be day rate. As others have pointed out, it takes as long as it takes. Relies on key personnel being available to give you information, give you access to systems, and can take a long time to work out requirements definitions, nuances with the current and historical data etc..and as others have said, meetings (often back to back) and travel to other offices sucks up loads of your time. Once requirements are specified (on pseudo code if necessary) then you can probably afford to set a time frame and cost to the development, testing and implementation. And allow for someone in business to also do testing and be available before implementation.

Blueroses99 BossyBitch venys

Thank you for the valuable points that you have just made. They are much apprectiated. I have learnt a lot.

I would suggest learning about more traditional project management first (PRINCE2 maybe?), then Agile.

I was also going to add to my previous post that you need to separate effort from timescales. Eg the scoping might take 3 days actual work but it will take 5 days to finish. This takes into account that you might not be able to work back to back every day and there might be some downtime. You should be aware of both numbers.

Do a PRINCE course then Agile. A book won't be enough. How are you getting work with no experience? Surely you have something tangible to base your timescales on?

KenAdams We quite often get offered projects as result of our training work. We are not experienced as Project Workers. We thought that it would be lucrative and stimulating to take on a Development Project. Turns out that there is a lot more to it than meets the eye.

The Project work we have taken on is very bespoke, so it isn't easy to say that it will definitely take x hours to deliver the project. We have massively underestimated how long the minor tweaks take. I appreciate from the client's point of view they can't just give us a blank cheque and for the thing to drag on forever. Safe to say, that we are somewhat out of our depth.

The advice we have got from everyone will really help approach the next stage of the Project more realistically though.

@SnowyHill, I could be wrong here (going on the understandably limited amount of info you've provided), but I read roughly the following:

• Your scope isn't clearly defined
• You're not worried about the technical abilities of your team (or haven't said so, at least)
• You are facing uncertainty rather than risk in terms of the technical challenges that will come with integrating the product into the client systems landscape
• You've not been paying quite enough attention to testing so far
• Your requirements are hardly fixed
• You have a gold plating problem

Given all that, if this were my project I'd be looking at implementing Scrum (well, probably a scaled agile approch based on it in my case, but you don't seem to be operating with multiple large teams) - mainly for its powerful capabilities in terms of integrating stakeholders, controlling scope in a value-driven manner while accommodating change and the fact that its insistence on a Definition of Done - if properly practised and understood - takes care of issues such as a lack of testing and over-delivery.

Having said that, Scrum projects are not the easiest to project manage - and the fact that half my clients seem to think 'agile' means 'no management needed' doesn't help. I couldn't in good conscience recommend that a beginner project delivery team try to pull off an agile transformation effort while already struggling.

You might still benefit from some of Scrum's easier to implement features, though, so should definitely read www.scrumguides.org

PS: having said that I agree that it's a good idea to start formal PM education with a more classical approach. It's the best basis you can have to go in any direction.