Some useful tips on estimating projects, your own value and project management for freelancers and agencies
One of the most important aspects of any operation is something that I refer to as self-value, important for all organizations, freelancers, no matter the size or even field of operation. Knowing self-value is imperative to estimate cost of services, and maintaining healthy self-value is helpful to ensure, well, healthy profit of all things.
Self-value is bruto-like-profit you want to earn to be able to comfortably maintain your operations for certain period of time. I usually recommend calculating self-value in scope of a year, that is, how much net-profit you need to maintain your operations comfortably for a year, the year being either calendar or accounting year. If there is a difference between the two in your particular case, you might want to calculate self-value relative to your accounting year as it will help you align accounting and net income cycles of your operation.
Self-value should include all projected expenses your operation has — be it company, or yourself, if you are a freelancer, and profit margin you want to earn on top of the expenses. In case of freelance, you should count together all of your known expenses as a freelancer and clearly, include your personal salary. However, you should treat your personal expenses separate from your operations self-value, as your personal income specifics has no bearing against your operations self-value. This is why I recommend you to establish your own salary or salary of your employees separately — determine the gross salary you are comfortable with, that is at least market value and proceed from there. Be realistic however — you can set your own salary and that of your employees to whatever you want, but if that ends up driving your self-value so high no customer is going to be willing to pay for it, your actual income will end up being nothing at all.
It is important to not include taxes directly related to income and alike in
your self-value, as you want to account for that at the moment when you are
applying self-value to any estimations.
This will help you maintain a healthy buffer between the expenses you can control, at least partially, like your salaries, versus the expenses you can not control — taxes, rent, utilities and other.
You should however account for taxes you already are aware of that are either fixed or easily estimated, like taxes related to the salaries you should already know at this point.
It is also important to evaluate self-value periodically, and adjust for any changes that might be necessary due to some external changes, like cost-of-living and similar.
So, to reiterate, self-value is total sum of:
- Expenses you can predict — rent, utilities, taxes not directly related to
- Profit margin.
For example, let’s assume you are a freelancer — one person, doing contracting work. Let’s also assume following (numbers invented, clearly):
- You need at least $3,000/month or $36,000/year to cover your personal expenses
- You need to rent a co-working space, because you can’t work from home for any reason ($150/month or $1,800/year)
- You need to purchase at least some office supplies ($100 year)
- You need to have accounting for your operation to handle your taxes ($200/year or $2,400/year)
- You need to pay social security or whatever applies from employer side (30% on top of net salaries sum, $900/month or $10,800/year)
- You want a profit margin of 60% on top of your expenses — e.g. clean, disposable profit you can invest in operations.
Your total expenses assuming these are the only expenses you have would be
$51,100/year or $4258.33/month.
The profit margin would be 60% and would amount to $30,660/year or $2,555/month.
Your self-value in this scenario would be $81,760/year or $6,813.33/month. That means, to run your business comfortably you must be able to bill at minimum $6,813.33 every single month on yearly average.
Going further, now that we know that your monthly self-value is $6,813.33, you can estimate your hourly rate, assuming 40 hour weeks, or 160 hour working months — $42.58, or $45 normalized. Just to note, never round down when you do estimations. That’s just bad in all kinds of ways.
In reality however, the expenses part might be slightly more tricky for you, for any number of reasons, so be sure to consult an accountant who is familiar with what kind of work you are doing.
For example, you might need to charge VAT on top of your hourly rate, and pay
income tax on your revenues, and all kinds of additional expenses I can not even
speculate about as it wildly differs between tax regimes, countries,
all kinds of things.
Now that your self-value is established, it is also a good idea to compare it
with market values in your speciality or field of work, to see if it is at least
competitive. If you overshot or undershot a lot, don’t be afraid to adjust -
you can increase your profit margin in case you undervalued something, which is a good thing in this scenario, or you might need to reduce some expenses if you overvalued a lot. However, do not try to underbid everyone and everything, this is neither healthy for you, nor the market, and majority of potential customers will be okay with slightly above than average price if the you can offer and deliver quality result.
It is also important to note, I often do rely on unquantifiable “gut-feel” when making self-value calculations. There is always something specific about each case, so there can’t be 100% clear cut formula for every case.
Also, remember that self-value is not exactly value you will bill your
customers. Self-value is your own cost and expenses + profit margin. You
billable value will need to include all taxes for the revenue itself (for
company income taxes in certain tax systems), VAT etc. expenses. You need to keep your billing value and your self-value separate, and calculate your billing value at the time when you are making a proposition or estimate for customer, project etc. This will help to ensure that your self-value needs to be adjusted only when your actual self-value changes, and that the expenses you have no control over like taxes on specific income are separate, and covered by what you bill, not from your profit margin.
Resource pool and tracking resource availability
Another important thing to keep a keen eye on is your resource pool. Resource pool is total sum of all assets you have available or occupied that you can utilize to deliver services or products. Resource pool includes all assets immediately available, for example — hours of work you can do in certain period of time, cash reserve,technical resources (like servers, etc), literally anything you can imagine that might be useful for operations. Itemize and track availability of each available resource as often as you can. This will help you maintain a healthy overview of your operation.
It is useful to arrange resource pool in tracking periods — time units that will allow you to scope resource utilization in time, so you are aware not only what resources are being used, but also schedule what resources will be used, and when. I usually use monthly, weekly and daily tracking periods, especially for scheduling. But this is specific to each individual case. If your projects are usually spanning months at a time, daily or weekly tracking might not be necessary.
Pay special attention to finite resources and avoid overbooking as much as possible — for example, if you are scheduled to work 120 hours out of your 160 hour monthly pool, and you estimate that your next project would require 60 hours, you have a resource shortage — you either need to increase the available resources (which you can not do without overworking yourself), reduce estimate (which you should not do, because you will miss goals) or negotiate longer deadlines that match your availability — the best option so far. But there is also another one…
In certain scenarios you might be able to “overbook” yourself by literally borrowing from future. Concept is easy to illustrate with analogy:
You have a project with deadline 60 days from now, and in your resource pool for current period (month) you have allocated 120 of 160 hours for this project.
There is another project that requires 80 hours, but has a deadline of 30 days (handsomely paid, of course).
What you can do in this scenario is overbook to the next resources tracking period — you can do 80 hours of work for the new project and 80 hours of work for the already scheduled project, postponing 80 hours to next month.
There are certain problems with this approach, especially if the resources, like in this case — time, can be tracked also by customer. It is good idea to communicate any pauses in work to customer as soon as possible. Not necessarily giving in reasons, but as long as deadlines are being met…
This is one two most complex and important parts of a project and estimating the project, the other being estimations itself. There are probably entire books, articles and research papers covering the process, so I suggest you do some research into the methodologies of requirements elicitation, as it is in fact, a really broad topic. There are cases where requirements are clear cut, but there are plenty of situations where it is quite a process.
A good starting point in getting the requirements together is to have requirements elicitation sessions, namely, just having a couple of sessions with the customer to gather ideas and needs the customer already has, itemizing and categorizing them in features and larger subjects.
I usually approach requirements elicitation by following certain steps till both myself and the customer is reasonably satisfied with whatever is defined. Also remember that customer might have more than one stakeholder, and stakeholders might have different priorities. Just keep that in mind when you prioritize things.
Generally, my process is split in two parts, the first being single time or when-needed, the second being iterative.
The first part:
- Identify players (single customer, single or multiple stakeholders, who is
responsible for what, if any);
2. Identify stakeholders — part of the players who actually holds interest in the project (the-need). Not all players are always stakeholders, some players might be in fact resources or oversight, or hold external dependencies,
for example someone from customer side providing something that you need to satisfy stakeholders;
The second part:
- Gather needs and requirements from stakeholders;
2. Prioritize stakeholders, prioritize needs and requirements;
3. Refine requirements, make proposals on concrete-ish solutions;
4. Collaboratively filter and reduce needs and requirements with stakeholders where possible;
5. Repeat till reasonably satisfied;
Important to remember: avoid what I refer to as “requirements hell” at all costs. Try to steer stakeholders away from over-designing the project in early stages of the project, especially if the project is not clearly stone clad fulfillment of a very familiar need. Always assume that even reasonably well defined requirements will change along the way. This however does not mean that you should skip obvious issues and postpone them till later — that is not in your best interest at all.
Always record all the requirements and keep them organized, track the changes over time and which stakeholder introduced what requirement, why and who made what changes.
It is good to always have at least two or three iterations of the part two if the project is complex, allowing some time to pass between the iterations. This helps to keep your and the stakeholders heads cool, and often helps with step 4 — filtering and reducing requirements that seemed like a good idea at first, but in practice would fade out, be superseded or duplicates other requirements.
When the requirements are reasonably finalized, ask for a sign-off on requirements, but only if applicable. This heavily depends on what management model you are using, customer preference etc. Some customers might require initial requirements documented and as part of a contract, especially large organizations and governments that usually deal with contracts based on set-requirements. In other cases where approach is more “Agile”, initial requirements serve as basis for cost estimations, initial time-line, tasks etc.
Estimate time and resource usage, and ultimately cost
This is actually really simple. Go over the list of your requirements, imagine a random number of hours and add it to the requirement, along with any resources you might use. Sum and here you go — estimations done! Right?
Well not really. There are two kinds of resources that usually constitutes parts of estimation — relatively easy to account for resources, like physical resources, software licenses, servers and what not, and “never-going-to-get-right” resource of time.
The most common way to determine how much time a certain requirement will
require to implement is to compare it to something similar done in past. Keyword
here is “similar” as it is almost impossible to recreate the exact conditions
that already were and to what time was already estimated for the new
requirement. In my experience it is near impossible to get time estimations
right — you will have to settle for “good-enough”.
There are numerous techniques for time estimation, I recommend you to do some research and develop an approach you are comfortable with using.
When doing time estimations it pays to be pessimistic — in my experience, time
is almost always underestimated.
Remember that delivering early is almost always better than delivering late. Keep a healthy buffer between your estimation and what you think the actual implementation will take.
Now that you have at least some estimation of time and resources you will need for the project, you can in fact count the cost of resources except time, plus add your self-value for given time. This will be your total estimate cost for the project.
Remind yourself and stakeholders that estimation is just that — estimation
Deadlines must not ever be regarded the same as estimations. Estimations are (often) wild guesses based on previous experiences and depends on level of detail your estimations have. Deadline should be regarded as “must-be-done-by” and estimate should be regarded as “probably-will-be-done-by-maybe-if-we-are-lucky”, and nothing more than that.
Delivery and acceptance cycles
It is very important to keep delivery cycles short, and acceptance cycles even shorter. The approach I almost always use is as follows:
- Do the requirements elicitation process;
2. Deliver estimate and offer;
3. Split requirements in cycles of 2–4 weeks (at most);
4. Deliver features continuously with customer review every cycle (2–4 weeks);
- Optionally: sign-off for each cycle and finalized features by the
6. Bill every month, or every cycle, or custom, but as often as possible.
This approach really helps to solve a couple of important problems — keeping customer in the loop and updated, ensuring correctly interpreted requirements and implementations by constant customer verification and communication in general. With short delivery cycles adjusting to sudden changes (and billing for these changes) will be infinitely easier than with delivery cycle of 6 months or something. Keep the customer in loop as much as possible, require customer sign-off (to ensure engagement more than ensuring legal protection). One thing you really want to avoid is long lists of change requests from the customer, so it is imperative that the customer always knows the current state of development and current up-to-date requirements, so customer could request changes often, in-time, and in small volumes.
Document and log everything, religiously
This is for the cases things do not work out. Meetings require meeting notes
that are shared with all participants later.
Changes require agreements, work requires contract, payment requires invoices. Keep your paperwork in check.
Changes should be agreed upon as efficiently as possible, but finalized in writing or something that can be traced and recalled later.