Contracting in IT - Am I missing something?

daigo75

Hi all, I have a question to people who have experience in IT Contracting. I noticed a common trend, in companies looking for contractors, which is indicating the value of the contract in terms of months/days, together with a daily rate. The way I understand this is that they'd expect a contractor to be in their offices full time for the specified amount of months; this, in turn, means that a contractor would not have time to follow more than one customer at a time, for a period of several months. I've been self employed in the past, and I would never have taken the risk of having only one customer at any given time; my idea of contracting is to define projects, agree on a price and a deadline and meet with customers on a regular basis, but, for sure, I never spent 40 or more hours a week in their offices.

What I mean is, the main advantage I had when I was self employed was that I could manage my days any way I liked, as long as I met the agreed deadlines. In short, I was paid for a result, not for the amount of hours/days I spent in an office, while it seems to be a common trend now. So, back to my question: is it really like this, or am I missing something?

fret_wimp2

depends on the contract. If you are contracted to produce something by a deadline in 6 months time, then its up to you if you work 18 hour days for a month, or standard 8 hour days for 3 months. In this case if you feel you can do it, and you dont have to be on the client site, then i dont see why you cant take on other contracts.

But if its a service contract, where you are contracted to provide a service, then yes, you are contracted for a specific duration. Most often you will have to work set hours and so wont have time for other contracts.

There are lots of variations but those would be two main contract types as i understand it.

daigo75

Thanks fret. From what I see, the majority of contracts I see seem to be service contracts, then. At least now I know how to call them.

Mrs OBumble

fret_wimp2 wrote: »

depends on the contract. If you are contracted to produce something by a deadline in 6 months time, then its up to you if you work 18 hour days for a month, or standard 8 hour days for 3 months. In this case if you feel you can do it, and you dont have to be on the client site, then i dont see why you cant take on other contracts.

True, but it's pretty rare in IT to produce something that needs the efforts of one person only. At very least, you need to consult with company architects / standards folk, to make sure that what you're producing not only meets the spec, but also fits within the overall IT plan for the company.

And more than likely if you're producing anything substantial, the project will need the input of multiple people who you need to work co-operatively with. And if the companies projects are at all well managed, there will be a PM who wants concrete evidence that you are on track: they won't be impressed by the extra risk involved in having you working 18 hour days.

So I'd say that the model you've experienced in the past was more unusual, even back then.

I do agree with our about spreading your risk, though this applies more if you're into management consulting rather than "making something" type contracts.

jimmycrackcorm

In the last ten years all my experience with working with contractors was on-site on a daily rate for a fixed duration. What the op is referring to is outsourcing.

Alexander Supertramp

IT contractors would come on to our site for the duration of the contract.

I've worked on a project recently with a contract developer. He arrived on site when the requirements had been gathered. He then carried out the development work for x amount of weeks, provided support for testing when it was been carried out then left the site when the project was complete. I'd say he was here for a month in total.

daigo75

JustMary wrote: »

True, but it's pretty rare in IT to produce something that needs the efforts of one person only. At very least, you need to consult with company architects / standards folk, to make sure that what you're producing not only meets the spec, but also fits within the overall IT plan for the company.

And more than likely if you're producing anything substantial, the project will need the input of multiple people who you need to work co-operatively with. And if the companies projects are at all well managed, there will be a PM who wants concrete evidence that you are on track: they won't be impressed by the extra risk involved in having you working 18 hour days.

@JustMary: That's true, but I don't see how all the above requires a person's physical presence on customer's site the whole day. If planning is done properly, people don't need to talk to each other every other hour, and, often, not even every other day. Else, I wonder how distributed teams could ever achieve anything.

Thanks to all for the replies, they clarified the situation. This raises one further question: service contracts seem to be the norm, what's the advantage compared to having the very same position as a permanent/temporary employee?

jimmycrackcorm

daigo75 wrote: »

@JustMary: That's true, but I don't see how all the above requires a person's physical presence on customer's site the whole day. If planning is done properly, people don't need to talk to each other every other hour, and, often, not even every other day. Else, I wonder how distributed teams could ever achieve anything.

Thanks to all for the replies, they clarified the situation. This raises one further question: service contracts seem to be the norm, what's the advantage compared to having the very same position as a permanent/temporary employee?

Distributed teams are largely only effective when the work can be sufficiently partitioned into segregated blocks. A single person in isolation is unlikely to be as effective as working as part of a team which in turn relies on good communication to be as productive as possible.

The advantage is that you are adding a temporary resource required for a fixed length of time. Also the contractor may bring some specific technical expertise to the project.

daigo75

jimmycrackcorm wrote: »

Distributed teams are largely only effective when the work can be sufficiently partitioned into segregated blocks. A single person in isolation is unlikely to be as effective as working as part of a team which in turn relies on good communication to be as productive as possible.

The advantage is that you are adding a temporary resource required for a fixed length of time. Also the contractor may bring some specific technical expertise to the project.

Thanks Jimmy. I agree with you, but I still don't see how someone's physical presence could make any difference. In the specific case of Software Development, when I'm in the office people think it's ok to ask me things here and there, or even call me for a meeting with 10 minutes notice. My policy is instead the opposite, i.e. I'm not available unless specifically stated. By enforcing this method I obtained a huge increase in productivity for the whole team, as questions, tasks and meetings had to be planned properly. As a result, my presence on site could have been optional.

Regarding my question of "why contractor?", I apologize because I haven't been clear: I wonder why someone should become a contractor, when the only "bonus", compared to the same position as a full time employee, would be a modest increase in the gross annual income.

BostonB

I've had contracts where I could work from home and was only required onsite a few specified days a week. Once the deadlines were met and meeting attended it doesn't matter. Depends on the job. Some can't be done except from a specific location. Patching a server room, or upgrading machines, or running training.

TBH many of the jobs I've had permanent or contacting, I could have worked offsite for a large part of the time no problem. However usually its some manager that thinks time spent at a desk in their office is the only time that counts. TBH theres often vastly more distractions and interruptions in an office, than at home.