Some useful tips on estimating projects, your 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 the cost of services, and maintaining healthy self-value is helpful to ensure, well, healthy profit of all things.
Self-value is gross-like-profit you want to earn to be able to comfortably maintain your operations for a certain period. I usually recommend calculating self-value in the 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 the profit margin you want to earn on top of the expenses. In the case of freelance, you should count together all of your known expenses as a freelancer and clearly, include your salary. However, you should treat your expenses separate from your operations self-value, as your income specifics has no bearing against your operations self-value. This is why I recommend you to establish your 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 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 others.
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 the total sum of:
Expenses you can predict — rent, utilities, taxes not directly related to company income;
Salary/Salaries;
Profit margin.
For example, let’s assume you are a freelancer — one person, doing contracting work. Let’s also assume the following (numbers invented, clearly):
You need at least $3,000/month or $36,000/year to cover your 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 to handle your taxes ($200/year or $2,400/year)
You need to pay social security or whatever applies from the employer side (30% on top of the 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 a minimum $6,813.33 every single month on a 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 specialty 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 you can offer and deliver a 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 the value you will bill to your customers. Self-value is your own cost and expenses + profit margin. Your billable value will need to include all taxes for the revenue itself (for example,
company income taxes in certain tax systems), VAT, and similar 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. A resource pool is the 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 a certain time, cash reserve, technical resources (like servers, etc), literally anything you can imagine that might be useful for operations. Itemize and track the 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 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 the 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 the future. The concept is easy to illustrate with an 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 a good idea to communicate any pauses in work to the customer as soon as possible. Not necessarily giving in reasons, but as long as deadlines are being met…
Requirements elicitation
This is one of 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 until both myself and the customer is reasonably satisfied with whatever is defined. Also, remember that the 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 into 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);
Identify stakeholders — part of the players who hold an 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 the customer side providing something that you need to satisfy stakeholders;
The second part:
Gather needs and requirements from stakeholders;
Prioritize stakeholders, prioritize needs and requirements;
Refine requirements, make proposals on concrete-ish solutions;
Collaboratively filter and reduce needs and requirements with stakeholders where possible;
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 the early stages of the project, especially if the project is not 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 — that is not in your best interest at all.
Always record all the requirements and keep them organized, track the changes over some 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 second step if the project is complex, allowing some time to pass between the iterations. This helps to keep your and the stakeholders head 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 the approach is more “Agile”, initial requirements serve as a basis for cost estimations, initial time-line, tasks, etc.
Estimate time and resource usage, and ultimately cost
This is 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 are done! Right?
Well not really. There are two kinds of resources compromising parts of estimation — relatively easy to account for resources, like physical resources, software licenses, servers, and whatnot, 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 the past. The 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 count the cost of resources except time, plus add your self-value for the given time. This will be your total estimated cost for the project.
Remind yourself and stakeholders that estimation is just that — estimation
Deadlines must not ever be regarded as the same as estimations. Estimations are (often) wild guesses based on previous experiences and depends on the level of detail your estimations have. A 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;
Deliver estimate and offer;
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 customer;
Bill every month, or every cycle, or custom, but as often as possible.
This approach 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 want to avoid is long lists of change requests from the customer, so the customer must always know the current state of development and current up-to-date requirements, so the 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 a 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.
Good luck!