Archive for the 'contractors' tag

Setting your rates II

Posted on June 11, 2009

I Meant to post this yesterday and just plain forgot, so I’ll try to get two out today to make up for it.

I got some feed back on my post the other day about setting rates. It’s an interesting topic to a lot of people. One of the questions it did bring up was how to deal with negotiating on rates, or specifically dealing with a customer that doesn’t want to pay what you’re asking.

I for one set out my rate at the start in a quote, explain that it’s competitive and that’s what it costs.

I’m open to negotiation if for example you’re offering me a couple of days a week for a month, few months or a year. It costs less to develop and maintain one relationship like that than the equivalent in smaller customers – even if it is putting more eggs than I may like into one basket.

If on the other hand it’s a couple of days then I’m going to be much more firm about my rates.

One strategy for getting paid what you should, and giving a customer a price they want is to determine the budget from the outset then structure a proposal around that. Once you’ve got a number, make sure you can deliver what they want, or negotiate on a cut down version, which you can deliver within their budget. If it’s design work, cut some of the revisions, base the design on a template of their choosing. For coding work cut some of the scope, remove one or two of the lest important requirements.

A lot of times you may just find “you’re too expensive” really means, “we can’t afford it” and there are a lot of great companies out there that aren’t just being cheap, even if that’s the way it may seem on the surface and they’d be more than willing to compromise on the scope to get it done properly within their budget. Then who knows, revisit the rest in a few months time.

Other times you just can’t meet in the middle, you can’t do the work in the time allowed by the budget but don’t give up – there might still be a deal you can both cut. Maybe they offer a service you’re currently paying for, or have staff that aren’t being fully utilised you can borrow. Trading your services for theirs isn’t a bad thing, you still get a client, word of mouth referrals, case studies, testimonials and add to your portfolio and you still get something in return for it. I’ve done this in the past and it’s always worked out well for me, in fact it’s probably lead to more work from and through that client than we could otherwise expect.

If all else fails, my advice is to walk away. It’s hard but the brutal truth is that you’re risking getting stuck in a working relationship where the other side doesn’t value your skills. In my experience that attitude extends right through into how they value your opinions and the result of your labours. To them what you produce is a commodity and they’re probably going for the cheapest quote they can find. Everyone has worked with people like this, it’s not fun and it’s almost never worth the money. In fact, my advice is run – don’t walk.

Related articles by Zemanta
Reblog this post [with Zemanta]

What to charge

Posted on June 9, 2009

Lloyds TSB just announced they’re shutting down all C&G branches with loads of job losses. Though they said they were hoping to avoid compulsory redundancies with early retirement and by hiring less contractors.

So they’re not cutting jobs, except for contractors. Which is too bad for the contractors but brings up an important point if you are a contractor and you’re setting your rates.

You are responsible for your own job security and you have to charge for it. You don’t get holiday pay, you need to spend some of your time on the non billables that need to be done to operate, you won’t get a redundancy payment if through no fault of your own the company cuts your role in a cost savings exercise. You just don’t have a job.

There are various ways to mitigate the disaster and the best is probably to have as many customers as possible. The more you have the less the loss of one matters.

But you also need to be aware of the reality that you may lose customers when you set your rates. You need to bill for your desired salary + operating costs + expenses + some headroom for the time you aren’t doing billable work.

Here’s an example. Let’s say you want a £30,000 salary. You have operating costs for equipment, software, travel, expenses, taxes, accountants, rent, phones, internet etc; say £15,000/ year. Given 45 working weeks in a year, because you deserve holidays like everyone else and you’ll no doubt catch a cold or two at some point.

30,000 + 15,000 = £45,000/year MINIMUM turnover.
45,000/45 working weeks / 5 working days = £200/day

So if you want to earn a £30,000/year salary and you have enough work to keep you occupied every single day – you can afford to do it for about £200/day.

Let’s for a moment say you spend just one day a week on things you need to do, but you can’t bill a customer for directly - your accounts, taxes, your website, finding new customers, writing proposals, travelling to and from meetings, meetings, professional development.

That’s a rate £250/day and you still have absolutely no cushion. Lose a customer and even if it’s one day a month you’re not at capacity and you lose £3000 from your salary. If you lose a few or a big one and you’re idle a day a week – you’re out over £11,000!

Now if you want to build yourself in a cushion so that if you lose some work you’ve got money to eat while you spend time trying to get more customers, you need to up the rate. For the sake of argument let’s say you want to be able to eat working at 75% capacity if the times get lean and stay that way for a while. That means you need to be able to survive billing for 3 working days every week, so with the numbers above we get.

£45,000 / 45 working weeks / 3 working days = £333.33/day

Now in theory, working at capacity that would give you enough to pay yourself almost £45,000/year – but if you were smart and like the C&G contractors a major client suddenly pulled the rug out from under your feet, you’ve saved that and now have a good cushion going forward to find new customers. If they were 100% of your work, it could take sometime to build up that client base from scratch so the £15,000 really isn’t that much when you start to eat through it – literally.

Open Source for Business

Posted on June 8, 2009

I didn’t get this posted yesterday because the Internet crapped out in our area. Nothing but excuses, I know.

I’ve been working beyond the bleeding edge, using a version of the Nutch code that’s not even made it into the Apache SVN for the project yet. To celebrate the fact that my contributions will make it in I figure its a good time to get into open source and business.

To put it briefly, and as you can probably guess, I’m pro open source. I use it extensively and I push back as much as I can. When it comes to the most of the code I write there really isn’t much commercial benefit in keeping it hidden so it just makes sense to give back.

There are two types of business on the web, one where you provide a software service and that is the product and others where you provide access to data. It’s pretty easy to tell which camp you’re in.

37 Signals for example, they’re in the first and their software probably isn’t something they just want to let people download – unless they’re incredibly brave. Doing that would mean that they’d be competing on margins for the cheapest hosting, users would flock to the cheaper services, have a poor experience and blame the software.

Sproozi on the other hand is the second type, our data is what users mostly care about and we’re not planning to be precious about our code. I’ve already been pushing some of the changes I’ve made to Nutch back into the project and we’re planning open source projects of our own in the coming months.

One of our plans we have is to build iPhone, Andriod and other phone based applications for our service and release them as open source projects. We’re planning to write them (or have them written for us) and release ‘official’ versions. Then release that code as open source project to provide a framework for developers so that they can build great things from it and on our API.

If there are any experienced iPhone, Android, Blackberry, Symbian or Pre developers out there that want to get involved, drop me a line were a ways off yet but would love to chat about it and get some very early feedback.

Related articles by Zemanta
Reblog this post [with Zemanta]

Setting subversion up to work with contractors

Posted on July 28, 2008

In my last post I promised I’d write another about subversion and how to set things up to work with contractors. I was supposed to post this the next day, but I got caught up with other things.

Anyway, let’s just jump right in…

We run all our projects out of one big subversion repository, some people create a repository per project or group projects into a number repositories. In all honesty it really doesn’t matter how you group things, I think that one repository works better for us, I can move things around and I can allow people access to all or parts of the repository. You may feel differently, but for the time being I’m going to assume you’re working with a single repository like us.

getting started: installing apache, subversion and mod_dav_svn

I recently upgraded to Subversion 1.5, there wasn’t a package available for the version of Fedora we’re running on our server so I had to build it. It was a relatively painless process of simply making sure dependencies existed and following the instructions in the INSTALL file.

http://subversion.tigris.org/getting.html

Go do that now, get subversion and mod_dav_svn installed. There are more than enough resources out there on how to install subversion that I’m not going to go into too much detail about building from source or installing on any specific platform.

In fact since the steps and concepts I’m going over in this post don’t require a specific version I’ll just throw up some common defaults.

If you’re on a Red Hat based linux system try:

# yum install subversion
# yum install mod_dav_svn

If you’re on a Debian based system try:

# apt-get install subversion
# apt-get install libapache2-svn

In your apache configuration file, near the module declarations make sure you have the following lines.

LoadModule dav_module /usr/lib/apache2/modules/mod_dav.so
LoadModule dav_svn_module /usr/lib/apache2/modules/mod_dav_svn.so

setting up a repository

Again moving quite quickly here, there are tons of other better resources for getting started with Subversion on the web, better than I could hope to write. The basic command you need to run simply creates the directory structure that subversion needs.

$ svnadmin create /path/to/repo

It’s usually best to create this somewhere near, but not in the document tree for the webserver.

Open you’re apache config file, or the config file that stores the details for the virtual host you’re using and add the following lines:


DAV svn
SVNPath /path/to/your/repository
AuthType Basic
AuthName "Subversion repository"
AuthUserFile /path/to/your/passwdfile

Now create the htpasswd file and add a user or two using the following commands

# htpasswd -cm # htpasswd -cm /etc/svn-passwd andrew
New password:
Re-type new password:
Adding password for user andrew

# htpasswd /etc/svn-passwd -m simon
New password:
Re-type new password:
Adding password for user simon

Restart apache and that’s it all done. You should now have a running subversion repository with two users, andrew and simon, they should be able to view and commit anywhere. We’ll assume these are staff members who can view and commit on any project.

Setting up for an external contractor

Now you want to bring a contractor in on a project, so let’s create them a user:


# htpasswd /etc/svn-passwd -m john
New password:
Re-type new password:
Adding password for user john

The next thing you need to do is to setup svnauthz to control access to the repository. Back in your apache config file, add the following line into your svn config:

AuthzSVNAccessFile /home/goroam/dev.goroam.net/user/repos/svn-authz

So that it looks something like this:


DAV svn
SVNPath /path/to/your/repository
AuthType Basic
AuthName "Subversion repository"
AuthUserFile /path/to/your/passwdfile
AuthzSVNAccessFile /path/to/your/repository/svn-authz

I tend to keep my svn-authz file within my repository path, you may wish to place it elsewhere – whatever works best for you.

The next step is to create the svn-authz file. That’s as simple as this:

[groups]
staff = andrew, simon
contractors = john

[/]
@staff = rw
* = r

[/external-project]
@contractors = rw

The file is pretty simple and self explanatory but the first block starting with [groups] defines the groups. In this case we’ve got two one for staff with andrew and simon and one for contractors with john as the single member. The usernames to use here are the same as you set in your htpasswd file. Authentication is controlled by the standard basic authentication, subversion is only controlling access.

The next two blocks are paths within the repository. The first:


[/]
@staff = rw
* = r

Tells subversion to give all members of the staff group read and write access to everything under the / path – basically the whole repository. The next line * = r tells subversion to give everyone else, read access to everything.

Again this may not work for you, but we tend to allow read access to everything to everyone with a password. If we trust them enough to give them a password, we trust them. Also it allows contractors to build dependant libraries from the head, which is required at times and saves us the trouble of working out dependencies in our svn-authz file.


[/external-project]
@contractors = rw

In the next block, above, we’re giving everyone in the contractors group read and write access to everything in the /external-project path of our repository. This of course is the project they’re currently working, so your path will be different.

That’s it. Contractors hired, up and running in your subversion in minutes.

Slightly more complicated, but easy now that you know how

Let’s just complicate things a little bit by adding two external contractors from the first company and a third from second working on two different projects.

Let’s say that CompanyA Limited are working on project-x. They’ve asked us to create accounts for Dick and Jane. Then we hire Dave from CompanyB to add a feature called zing-bang to project-y. You could, of course just create two accounts, one for each company – but we tend to avoid that. We like to know WHO committed what code. Not just where they were from, we work closely with our contractors and it helps us when we’re communicating with them.

We know how to create the users, but just to recap here we go again:


# htpasswd /etc/svn-passwd -m dick
New password:
Re-type new password:
Adding password for user dick

# htpasswd /etc/svn-passwd -m jane
New password:
Re-type new password:
Adding password for user jane

# htpasswd /etc/svn-passwd -m dave
New password:
Re-type new password:
Adding password for user dave

Assuming, as above we have andrew and simon as staff users we should make our svn-authz file look something like this:


[groups]
staff = andrew, simon
companya = dick, jane
companyb = dave

[/]
@staff = rw
* = r

[/project-x]
@companya = rw

[/project-y/branches/zing-bang-feature]
@companyb = rw

We’re only building slighty on the previous file with the groups entries, and that should be clear. The entry here for project-x should also look familiar – Both dick and jane, members of the companya group have read and write access to the path.

For the next entry we’ve created a branch and we have company b working on the branch. I’m really just throwing that out there, mostly because I can, but also to show that you can go to any depth in the repository tree granting access as you see fit.

In this case it’s been determined that the work CompanyB in engaged to complete only needs to take place in this branch, so while they can read the whole repository they cannot write anywhere except here. This would allow you to continue internal development, or indeed external with some more entries on project-y making point releases while zing-bang feature is developed and CompanyB could merge the trunk in at will, since they have read access to it.

a lot of words

It was a lot of words, but the concepts are pretty simple. It doesn’t take long to set subversion up and even with basic auth and htpasswd files it’s not complicated to administer. So go on, get your contractors under control. I promise the dividends paid through increased accountability, visibility and communication will more than offset the time spent administrating the system.

Related articles by Zemanta
Reblog this post [with Zemanta]

Get your contractors under control

Posted on July 22, 2008

In a recently conversation I was told of a situation which I’ve experienced in the past and I’m sure others have as well.

While on holiday the code I’m responsible for has been modified by an external contractor. Before my holiday I pointed out that we should make sure version control is used by anyone making any change. It wasn’t. Now I’m frustrated and pissed off.

The problem isn’t that someone else was editing the code, or that I somehow lost control of a fiefdom or anything like that. It’s that I’ve just spent hours I could be using to do something else tracking down file modification dates and then diff’ing them against my versions out of version control. Time I shouldn’t have to had spent doing anything

The bigger issue is now I’m under pressure by my boss to deliver some changes at the same time as I have to deal with this, and no extra time has been allowed for it.

You pay contractors to do work for you, a large part of that should be to insist they do it in a way that is consistent with your working practices. You wouldn’t let them commit changes to a PHP website in ASP, Perl or Python and equally you should insist that changes are delivered consistently and in a manageable format.

Warning flags get raised if someone tells me they don’t use version control. Not knowing how and asking questions is one thing; I have no problem helping someone, a contractors included, learn our version control system and practices because I see our relationship as a long term one, so any investment in that relationship is worthwhile. If a contractor tells me they cannot or will not use our version control system though, we have a problem and usually we end the relationship then and there. It may sound like a hardline call based on a single criteria but it is a deal breaker for me.

For a contractor there could of course be some concern that they’ve submitted the work and may not be paid. Version control is not the cause of this – it’s dishonesty, plain and simple and if the person you’re working for is that dishonest submitting code via email before the cheque clears is equally risky.  

Some ground rules

Our most basic rule is commit at least once a day while you’re working on the project. This is especially the case if the work is being done on a day rate, but also if the project was quoted on a fixed rate basis. We use the data to judge if a project is on time, we’re completely upfront about why we want this: Knowing the current velocity for changes gives us a really good indication of where we are in the development cycle. With a current version committed to our repository we can just checkout, deploy and see. It removes the chances of miscommunication, misunderstandings and estimate errors.

Committing early and often by contractors is much like releasing early and often to users. It allows us to make regular builds and run QA on the project. The benefits of this are that we can start to run our testing regime long before we would otherwise be able to test. We try to encourage external developers to follow similar methodologies to those we use internally, the primary goal of any new project is to make a deployable release as quick as possible, then add features to it in a sensible manner. This coupled with regular commits allows us to test features as they’re added, not weeks down the line days or hours before the project is to go live.

Once bitten, twice shy

We’ve had a few projects in the past where we outside contractors for a variety of reasons failed to deliver on time. This has lead to our losing a follow up contract on at least one occasion we’re aware of. By getting code committed to our repository we can see where a project is, and if necessary step in early with concerns about the deadline.

Both daily commits and QA help immensely with this and all but eliminate estimate errors because we can have an honest objective conversation about how far we’re going to miss milestones very early in the process because a miss becomes obvious when you can see the velocity. The earlier you can do this, the better your chance delivering on time.

Rules for some, but not others

Sometimes it doesn’t make sense to go the whole forcing version control down someone’s throat route. For some projects and changes we’ll just bang a few files into an zip archive, email it and get the same back, then integrate it ourselves. It usually depends on the scope of the changes and how long they’re likely to be working on the project in question. We would only work with someone familiar or willing to learn version control though, even in the above scenario they’d would have to be willing to use it if we’d asked them to.

How have your experiences using version control with contractors gone? Post a comment and tell us about it!

I think tomorrow I’ll post a bit of more hands on article on setting up version control for contractors. I’ll try to focus a little more on how to build, install and implement subversion with access controls. See you then.

Saying no some more

Posted on July 16, 2008

Re-reading my post about saying no got me thinking about the other reasons we’ve turned down work. It’s hard getting work in the first place and doubly hard turning it down, but sometimes you just have to say no.

One big one that comes to mind is we quoted to do some work for a company we’ve had a long term working relationship with. A small company, they were unfortunately facing the loss of a key member of staff in the final few months of development of a key project already well overdue. A update to a project we’d worked with before, so we were familiar with the architecture, team and almost every aspect of the project.

We made quoted a day rate at the low end of the scale and offered to agree fixed times for each bit of development, insulating them from any estimate errors by delivering that iteration for the quoted price before undertaking the next. We agreed to put the work we were quoting on first, push our own development schedule back, not take on other work and offer any time the needed to get their project released.

I got the very distinct impression they wanted the work done cheap from a discussion with the technical lead for the project. I tried to mitigate any problems by sending an email detailing our costs and how they break down from developers salaries, equipment costs and the meagre profit margins. I also made it clear that we were uniquely qualified for the work, due to our extensive working history directly with the project.

The response was disappointing, they were willing to pay about half the rate we quoted. I had a brief discussion with the technical lead, who was as disappointed as us with the reaction, but it was clear there was going to be no middle ground. The offer was never even going to come up enough.

We gave up in the end – a shame really, like any small business we could have used the money. It was an issue of value. Despite all the positives, the experience, the fact that there was nobody else who could have hit the ground running like us and our prior working relationships they weren’t willing to pay what we consider a very reasonable price. They effectively wanted work done for less cost to them than it would have cost to hire a member of staff, with none of the security or benefits. A short term contract under terms worse that a job I’d been offered months prior.

In the end they had to give the member of staff who had planned to leave a significant pay rise to entice them to stay, hired another, less experienced developer who needed more managing and training and still haven’t delivered the project, months later.

For us, and for anyone else considering taking work at less than a market rate, it’s a tough choice. Though we could afford to survive without the work, it would have been nice to have the money in the bank. There is also always the potential that work can lead to more work, however do you want cut rate work leading to more of the same? It’s all too easy for it to set the tone of a working relationship and an expectation that you will continue to work for the low rate. Also the whole time you’re servicing the contract you’re not getting new clients or doing other more lucrative work. As a consultant if you’re not saving for a raining day you’re taking a huge risk, especially if things get a bit lean for a few weeks or months.