July 2012 Archives

Freelance software developers: How do you charge for your work? It can be difficult to structure your billing so that you get paid on time in a way that makes economic sense for you and your customer. How can you do it?

Time-based billing by the hour or the day is one way, but it has its downsides. If you're really good at what you do, then you put yourself at a disadvantage, because you'll be highly productive on the job while earning a set amount. The more productive you are, the less profitable your work is for you. The other problem with an hourly or daily rate is your scalability. Time-based invoices come with a ceiling. There are only so many hours in the day, and days in the week. You limit what you can earn, unless you keep increasingly your hourly rate.

Project-based costs are another option. Charging a set fee for the whole project enables you to capitalise on your productivity. Getting it done quickly while hitting the project requirements enables you to increase your earning potential. But this carries two dangers: scope creep, and cashflow issues. The bigger a project is, the more difficult it becomes to accurately scope the requirements and the harder it is to get clients to stick to them. And while some clients may be prepared to lay down a significant advance up front, many won't be, meaning that you don't eat until you're done.

One other way to charge stems from agile development processes that break programming jobs down into more manageable chunks. It involves partitioning the project into user stories. A contractor friend of mine who works remotely and for multiple clients does this on a regular basis. User stories break down the functionality of a program into small tasks that correlate to tasks that the users of the system would understand and identify with. 

A user story for an online library system could be "As a user, I want to renew a book so that I can read it for longer". Another could be: "As a user, I want to reserve a book so that I borrow it when it becomes available". 

These stories are understandable enough that the client will feel comfortable about what they are paying for, and small enough that they can be coded in a couple of days and billed for in a granular way. They also provide freelance programmers with a way to more easily reuse code, as many user stories may use the same underlying functionality.

There are doubtless some projects that this won't work very well for. It might be inefficient in terms of time to break down very small projects that only involve a week of work into different user stories. And projects that users never see (perhaps certain embedded systems, or complex back-end financial algorithms) might not be a good fit. But for straightforward projects such as web applications, this could be a good way to charge the client equitably and clearly - while also providing a structure for yourself to tackle the project in the process.
We never have enough personal power or authority to perform our work. If you're an individual contributor, you can always see problems that require you to work across the organization--which means you need to use influence. If you are a technical lead, project manager, or a manager of some variety, you know you need to influence people. But how?

Relying on your title is a weak form of power. Having someone like your boss vouch for you is a better form of power. A recommendation or a reference is even better. Recommendations that live on forever, such as those on LinkedIn are great.

But the best form of personal power is when you have a reputation as someone who gets things done around the organization. You deliver and deliver and deliver. Now, you don't have to be agile to do this. You can use the idea of inch-pebbles to do this.

But, you can't just get things done. You also have to tell people you accomplish work. Yes, you have to blow your own horn. Not too loudly, but loudly enough.

Now, you've started to accumulate personal power.

I learned this from Jeffrey Pfeffer's Power: Why Some People Have It and Others Don't. There is a lot more in this book. Some I agree with, some I don't. But I thought this part, the delivering and delivering part, to build your personal power was great.

So, to start building your personal power to be more influential, you have to deliver something. And keep delivering. I recommend something a few times a week. Can you do that? That's why inch-pebbles are so great. Or, agile works so well.

In the next part, I'll discuss how you use your personal power to influence others.
Enhanced by Zemanta

Current Vacancies from CWJobs

(* Required field)










Preferred format