On estimations, cost and management

Some useful tips on estimating projects, your own value and project management for freelancers and agencies

Establishing self-value

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.

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
(net income)- 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
example,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…

Resource displacement

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…

Requirements elicitation

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;

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:

Optionally: sign-off for each cycle and finalized features by the
customer;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.