The freelancing business part 2: budgeting your projects

By R Blank

Introduction

Welcome to the second in the series of dev.opera.com articles covering making money as a developer. In the last article, we discussed issues related to pricing—how to price your work, and how to maneuver your career into higher rates. Now that you know how to price your work, you need to manage that money. So in this article, I’ll address budgeting.

There is significant overlap between pricing and budgeting, and of course scheduling and contracts as well. I don’t care if you’re the coolest, most in-demand talent in the world—successful execution of projects requires a sufficient grasp and intelligent use of these disciplines—or working with others who have those skills.

The contents of this article are

What is Budgeting?

Broadly speaking, budgeting is the process of estimating the effort and resources required to execute a given task. When people speak of ‘budgeting’, they almost always refer to financial budgeting—budgeting money, and that’s what this article focuses on.

Once you work on larger teams, or for an employer, budgeting is usually handled by a resource separate from the production talent—such as a project manager or account manager. But, when you work for yourself, you do the budgeting. And if you don’t, then no one does! Unless you are an employee, or you are working on a pure time and materials contract, budgeting should be a part of your standard workflow.

The budget is the financial plan for a project and to ensure profitability, you must author your budget comprehensively, and maintain it diligently throughout the project. Failing to establish, manage, update, enforce and utilize your budgets mean that, odds are, your project will not be profitable.

Thus, the difference between taking this process seriously and not is the difference between a profitable and unprofitable project—making money!

Where do budgets come from?

Budgets come from two places: they are either established by the client, or they are estimated by you after a client explains what he wants built. So, for example, a client will say ‘I have $10,000 to spend on a website—tell me what I can get’, or a client will say ‘I want a website that does X, Y and Z,’ in response to which you estimate a budget.

In both cases, the challenge is making sure the budget matches the project specification (or ‘spec’, the requirements of what is to be produced). For this to be possible, the spec must actually exist, be correct, and be thorough. While that may seem obvious, it is all too easy to do this incorrectly—to skip the specification process, to leave parts out, or to be just wrong (after all, we work with interactive computing technology, which is not the most predictable medium).

It may not be possible at the start to specify and define the work accurately and comprehensively. In such cases, it is very important to manage your client expectations up-front, so they understand the cost uncertainties involved, and to ensure you update the budget as you receive more clarity and information about the project.

My agency most frequently encounters this issue when a project has inherited code—code completed by other developers, who may or may not still be available. Indeed, my agency no longer accepts inherited code on fixed fee—we will only work on time and materials when inherited code is part of the equation. And in many of those cases, over time, clients will attempt to alter the definition of the project such that it becomes budgeted fixed-fee—and it is very important that you not let that happen.

But, a completed spec is not the whole story! A good spec is a pre-requisite for a good budget, but it is not the direct source. You need to analyze the spec, define the actual tasks (for yourself and/or your fellow team-members), and then properly estimate the time required to execute those tasks.

So, budgets come from time estimates that are derived from specs. This means it is really important to learn how to estimate. Generating accurate time estimates is not easy—indeed, it can be remarkably difficult, and often comes from years of painful experience. To do this properly, you should also need to have a grasp of the actual skills and technologies involved. For example, I’m primarily an interface-level developer; I would be a poor choice to estimate the time and effort required to install Apache and MySQL on a web server, and set up a customer records database.

So, on top of a good spec, and task list, generating good budgets requires two sets of skills:

understanding the specific technologies involved
maturity/experience providing estimates

If you can do both yourself, that’s fantastic! But, if you can’t, the odds are that for a given project, you are better at one, so find some help for the other.

What Factors Influence Complexity and Risk of Budgeting?

Complexity and risk are two different, though related, concepts. Both, however, can directly impact your budgets.

Moving Parts

There are some obvious factors, and some that are less obvious. On the obvious side, budgets are harder to manage when there are more moving parts and more money. For example, managing the budget for a $10,000 website that you can build yourself will be far easier than managing the development budget for, say..., Windows Vista. In part this is because the budget for the website is approximately 0.00001% of Vista’s dev budget, and in part it is because you can build the website yourself, but Vista will take the coordinated efforts of tens of thousands of resources. This is, of course, an extreme instance, but it illustrates the point—the larger the project and the more moving parts, the harder it will be to plan and stick to a budget.

Project Definition

Uncertainty means precisely that—lack of specific and fixed knowledge. The more uncertainty in a project, the less comfortable you should be representing a budget for that work. Hence all that time spent reinforcing the need for a good spec!

Defining a budget without a good spec is like trying to decide how much it should cost to build a car when you haven’t even defined what a wheel is or what the car will use as a propulsion mechanism—you can’t! The more uncertainty in a project, the more likely that your budget estimates will be wrong.

So, to start, if the spec is missing, wrong or incomplete, it will be extraordinarily challenging to generate an accurate budget (sometimes an inaccurate budget can be far worse than no budget at all—when there’s no budget you know it; when the budget is wrong, you can be lulled into incorrect and dangerous ambivalence, as you operate under the incorrect assumption that the work has been budgeted properly).

Technology Risk

Many of us love finding projects that allow us to work with new technologies—it’s how we keep our skills fresh and our portfolios sexy (recall the tips on increasing your rates from the last article). But, working with new technologies is directly akin to being a test pilot—odds are you’ll survive, but you never know!

Often new technologies will present problems—bugs and undocumented limitations that force work-arounds and re-coding. Even when the new technologies present no issues at all, there will always be a learning curve—the first project will always take longer than the rest.

This lesson applies even when working with established technologies—there is always a significant technology risk in our work. We’ve had projects go way beyond hours from a variety of technology-related factors, including:

Computers (including servers) going down—hopefully this will not happen often, but even one crash of the wrong computer at the wrong time can be a complete nightmare
SVN-generated tragedies, such as code overwrites and rampant conflict-generation; of course, SVN servers can crash too
No way to test locally (for example, because of server software requirements), which always significantly increases development and debugging time
No direct access to a development, testing and/or staging environment, which makes development and debugging a complete mess
Restrictions in access to required environments such as VPN, which causes delays and increased time getting resources configured to work
Server cron jobs for testing, which require you to wait for automated scripts to execute prior to testing
There is new release of, for example, the Flash Player or a popular browser, which starts causing more bugs to rear their ugly heads
and plenty more…

So, whether or not you realize it, there is always a technology risk inherent in the work we do, and when these risks manifest into problems, the budgets suffer.

Cash Flow

Another important consideration in budgeting is cash flow management. Let’s say you have a project that you believe will take you about 12 months to finish, and you’ve estimated the budget for the project at $50,000. And what’s even better is that your budget is accurate! (Woo hoo!)

Even though the budget was accurate, you could still end up in trouble. How? Well, to keep this example simple, let’s say the client must pay you half now, and half upon delivery. That means you’ll get $25,000 up-front and another $25,000 in 12 months. But that first $25,000 will only cover your expenses for 9 months. That means you will have a significant (and likely painful) 3-month cash flow gap at the end of the project. In other words, getting the payment timing right can be as important as estimating the budget properly! (I will have more to say on this in the next articles on scheduling and contracts).

It’s not enough to be cash-flow positive at the end of the project—you must be cash-flow positive at all points during the project, or your project will ‘run in the red’ causing you financial pressure.

Other People

As I mentioned above, budgets are always easier to manage when you are the only resource on a project. There are however issues beyond just the size of the team that can increase or decrease the budget risk. For example, have the multiple resources on the team worked together previously? If not, then work will inevitably flow more slowly than if everyone on the team were already familiar with the others. And, with new resources there is always the risk that the resource will flake out or fail—in which case you will have to find another resource for the work (with no guarantees what that new resource will cost), or, if you are capable and have no alternatives, you will end up doing the work yourself.

The same uncertainty applies to clients. If the client is new, you often have a gut sense of what it will be like to work with them—but it’s not always right, so there is risk from the uncertainty of the relationship. Once you have worked with a client, you have a better sense of how to estimate the time and effort required to work with them.

The more familiar you are with the other people involved in the project, the more comfortably you can formulate your budget estimates.

How to Mitigate Your Risk

Be Specific and Detailed in Everything You Do

As you can see from the description of risks, most of them stem directly from uncertainty. Some uncertainty—such as working with new people or technologies—can’t be resolved up-front and must be worked through. But others, such as project definition and cash-flow, can be reduced, and even eliminated completely.

This requires being detailed about everything. As I explained above, no budget can be accurate without a detailed project definition, so make sure that the project definition leaves no room for questions. Define all the functional requirements, the technologies that will be used, the server environments on which the project will be deployed and your access to them—everything that you can think of. You’ll never get this right the first time—the point is to never make the same mistake twice. As soon as a mistake bites you in the ass once, learn from it and ensure you institute a process to prevent it from recurring.

Buffer

Even those uncertainties completely out of our control can be somewhat counter-balanced through the easiest, most basic and most important risk mitigation technique—buffering the budget. A buffer is padding—some extra cushion in your budget to account for complexities and risks.

In other words, it’s easier not to exceed a budget when the budget is larger than required. For those new to the joys of client management, this may strike you as unethical—why should I charge more than I need to?

You must realize that when you represent a budget, you are assuming risk—the risk that costs will exceed the budget. That risk has value—otherwise, the client would put you on time and materials (after all, theoretically, the same project should cost the same whether it is fixed-fee or charged on time and materials). So, your budgets must reflect the value of that risk—you must include a cost component to compensate you for the risk you bear by representing a fixed budget.

This is also in your client’s interest, whether or not they know this. If you have budgeted precisely, with no buffer, unless things go better than projected, you will always running right up against the budget. This means that you are more stressed, and far less flexible to reasonable client requests—and that’s with nothing going wrong.

There is no standard buffer. Recall that the buffer is a way to assign a value to the risk associated with a project, and not all projects carry the same amount of risk. Generally, Almer/Blank applies a buffer of 20%-35%, depending on the client and the project. In terms of the project, refer to the sources of risk above; the more risks that are present, the greater the buffer you should apply.

Similarly, demanding, difficult clients incur larger buffers than reasonable, accommodating clients. Although you may derive some subconscious pleasure from charging more on projects with unpleasant clients, it is important to remember this is not punishment—this is business and as a business owner, it is your responsibility to look out for the interests of you, your firm, and your contractors and employees.

Prevent Scope Creep

To increase the chances that you can successfully maintain the budget on a project, it is vital to maintain vigilance for scope creep (the addition of new requirements to the project, without recognition of that fact, and corresponding adjustments to schedules and budgets). When a client attempts to add or change project requirements, it is important that you consider this a change request. You must not let change requests occur silently—that is a death-knell.

Remember that you need not charge for all change requests—one reason to apply a buffer is so that you may accommodate certain reasonable change requests without upcharging. You can make that call on a case-by-case basis. Even if you don’t charge for the request however, the client must understand that it represents a change (so that, for example, if you have to charge for a separate change request later in the project, the client will be more accommodating, because you accommodated the client’s request at this point).

Distribute the Risk

Risk is like a hot potato—if you have to carry it, you should get paid to carry it. But, sometimes it’s better just to pass it on to the next guy. Of course, it isn’t possible to distribute all risk away, but there are some key things you can do to pass on bits of the potato.

For example, if you are on a fixed-fee budget, and you pay your team on time and materials, you are facing some considerable financial risks—if the budget is blown, you will eat it—not the client and not your subcontractors! So, if you are on fixed-fee and need to hire additional resources, ensure they are on fixed-fee as well.

Getting talent on fixed-fee helps mitigate overall budget risk, but that still leaves cash flow risk—at any individual point in the project, you might still owe your contractors more than you’ve been paid. So, ideally, you will get your contractors on a ‘pay-when-paid’ clause. A pay-when-paid clause means that you tie the payments to your subcontractors, to receipt of a corresponding payment from the client. If a payment is late (either because the client is delaying, or because the team is late on delivering a milestone) your positive cash flow is still ensured.

Of course, you must also strictly define your warranty. A warranty for your work is just like the one you expect on your muffler when your mechanic works on it—some guarantee that the product actually functions. On fixed-fee work, it is perfectly reasonable for a client to expect a warranty—but not an unlimited one! You must limit the warranty in terms of scope and time. For instance, if you built an application to run on a server, and the server goes down, you want to ensure the client does not expect you to fix that for free. Similarly, if six months later the client reports a previously undiscovered bug, it is not necessarily reasonable that you fix it, so you will want to restrict the warranty period to something like 45, 60 or 90 days. Sometimes, however, it is best to provide no warranty at all—such as when you are paid to update an existing code-base.

The terms of your warranty would be contained in your contract. Just like a spec is the binding definition of the project, the contract is the binding definition of the relationship and business context of the project. Your contracts and warranties must be as comprehensively detailed as are your specification documents—a well written and considered contract can be all that separates a profitable from an unprofitable project. I’ll have much more to say on that, and many other important points that will impact your budgets, when I address contracts later in this series.

Maintain Constant Vigilance

A budget should be considered a living document—it is not written once and then locked-down, only to be reviewed at the end to see how profitable the project was. Instead, the budget (like the schedule, as we will see in the next article) should be maintained and updated throughout the project. In this way you will be able to see, and hopefully address, minor issues before they become significant cost drains. You will learn to see budget problems in advance and avoid costly problems.

Tools to Help

A final word to the wise: Learn to use a spreadsheet program fluently. At Almer/Blank, we use Numbers for day-to-day spreadsheet work, and when we need to bust out the VBA, we boot into Windows and use Excel—by far the most powerful spreadsheet program in the world. And if you don’t want to pay, there’s always OpenOffice.

Summary

In this article, we explored several important considerations in the process of establishing and managing project budgets, with a particular focus on recognizing and addressing the core risks of budgeting. We didn’t actually formulate a budget—and that’s because budgets really derive directly from the project schedule. So, in the next article, we will explore the creation and maintenance of project schedules—and their relationship to budgets.

R Blank

R Blank is an entrepreneur, author, community leader and teacher. R has specialized in the development of rich interactive applications for over 13 years and has focused on Flash Platform technologies for the past 8 years.

R is currently CTO of Almer/Blank (almerblank.com), an Adobe Solution Partner based in Venice, California that specializes in video and application development in Flex, Flash, AIR and open source technologies, for clients including E! Entertainment Television, Microsoft, Apple and IKEA. R is also the Director of Training at the Rich Media Institute (richmediainstitute.com), which offers workshop training for digital professionals from industry leading talent.

R founded and manages LA Flash (laflash.org), a community of over 2,800 Flash industry professionals, and home to three Adobe Users Groups for Flash, and also teaches Flash and interactive technologies on the Information Technology Faculty at the University of Southern California Viterbi School of Engineering.

R is the author of the DMTS Flash CS3 Jumpstart online training, AdvancED Flex Applications from Friends of Ed, and the DMTS Inside Flash 8 instructional DVD. Previously, R co-founded Wildform, where he co-created Flix, the first video encoder for Flash.

This article is licensed under a Creative Commons Attribution, Non Commercial - Share Alike 2.5 license.