Quoting and Estimating Drupal Projects

How do you quote for a Drupal based project? How do you come up with a quote that is both fair and it does not end you up working for free? It has been usual for me to come up close to estimation for some years now, to the point where a few margin hours no longer matter for the larger projects. There are some steps and methods that I have been using, all taken from other freelancers and project managers, in Drupal field of application and outside. In this article, I will present this process, as I view it, and hopefully you find it helpful. So here are those quote steps.

1. Discovery. Understand the Requirements.

Without additional help, non-technical people are usually unable to tell what they really need in terms of a web site, and translate it into a working requirement. Frequently, non-technical businesses can have a specific goal in mind, without being able to understand how it translates into actual solutions. You need to talk their needs through with them, and write down the requirements in clear terms. For example, when some clients say they want a blog, where they can organize groups and discuss things, you really want to clarify, if you need to make two separate things - a blog and a forum.

The goal is for you to have a clear picture of what the client really needs. This is also a good opportunity for you to educate the client and arrive to a point, where you both know you are talking of the same thing.

For existing web sites and migrations, discovery is also important to get a picture of what the ‘given’ is. The goal here is to have a picture of what the client already has, what needs to be salvaged or carried over to a new site, and what are some obstacles that will arise.

Discovery stage is a real work, resulting in a specific result - the evaluation of current status and understanding of the needs and obstacles. It should be a part of the quote, if it is to have some depth and result in commercially valuable suggestions and estimates that the client will receive.

2. Feature-specific Technical Task.

You don’t have clients write technical tasks for you. You write them. Once you have a clear picture of what your client needs, and once that picture or vision is confirmed with the client, you need to write the technical task.

The idea of the technical task is this: the vision is translated into specific Drupal related functionality.

Each aspect of functionality needs to be viewed as a more or less separate item. These items are usually called ‘features’ by the name of the Drupal module that is frequently used to pack such solutions together. Thus, you can break your whole work into a set of specific solutions, or features. “I need a blog and a forum.” translates into “2 features: a blog and a forum”.

You must also have a clear picture of how each feature will be implemented. A white spot, where you are not sure how to build a certain feature, may result in a black hole for the budget. Write down a set of modules, libraries, and assets you are going to use for each functionality.

Technical tasks can be lengthy. For an estimate, you don’t need to write a lot. Just the features and the technologies and libraries you are to use for each.

3. Estimate each Feature.

If you had estimates in the past that were too small, erroneously thinking, that “This project looks like nothing hard or lengthy”, then is they step that will correct that.

Each step can have different stages - usually, these are building, coding, theming, testing.

Building: you build node types, taxonomies, views, etc. using the available contrib modules, and pack the functionality into a feature.

Coding: you write code to complement for missing or varying functionality, you create modules.

Theming: you apply styling, icons and images, edit templates, write preprocess functions in the theming layer.

Testing: you need some time and a few people to test the complete feature.

When you remember, that a certain feature will need to not only be built in the UI, but also themed, coded for, and tested, then you escape the pit of seemingly easy feature, that later takes more time than you expected.

4. Estimate Base Featureless Site.

Apart from the features, the base site itself needs to be installed, configured, modules installed and pre-configured, and then the site needs to be base-themed. The base theme is a theme that has all the basic styling of the web site apart from the styling of the specific features. With the base theme, the site will look right even if the features never progress. Logos, colors, layouts, some basic blocks, generic headers and footers.

A generic featureless site would be a simple ‘business card’ website with nothing but simple pages. But even so simple, it takes time. For me personally, it can take somewhere between 10 and 24 hours to reach this stage of a ‘base site’, depending mostly on the complexity of the base design.

5. Estimate the Migration Costs.

Migration is perhaps the hardest thing to evaluate. Much in it depends on the data and assets that the client provides. It is very frequent, that when you are handed the export xml or csv, that you may find wrongly exported or missing fields in it, and some images from the provided zip archives missing. You will end up discovering those inconsistencies, asking the client for correct data and missing files, and it is also very possible, that you may end up doing this more than once. All this takes time and effort.

When planning and estimating this step, you should make a considerable margin for the possible additional work related to missing assets and corrupt source data.

6. Coming up with the Base Estimate.

The base estimate is the calculated pure man/hours. When you know all the steps, andthe required features, and each stage of a feature, and the approximate cost of a base web site construction and theming apart from the features, then you can add them up into the total amount of hours, and multiply by your hourly rate.

What you will have is the pure time, or the ideal time, that you will never fit into, really. The larger the project and the more variables are in it, the farther from that time you will end up landing time and cost-wise. But you still need this pure base estimate, because it will be the bulk of the work and the base for the actual estimate / quote that you will send to the client.

Now, we will need to project additional costs and margins.

7. Estimate the Margins and the PM Costs.

One thing that I myself learned about the margins over time, is that these are not some arbitrary numbers that you add to your calculations out of sheer greed. No. When you take up a project and bid a nice amount, to only discover, that you have not taken into account a lot of really predictable factors - then you realize the need to account for these things.

We have waited with the PM work estimate component till the end of the article, simply because it is usually a margin projected off the ideal project time.

In larger companies, there is sometimes a set margin percentage for PM work. Project manager will need to spend 2 - 3 hours of his or her time for each 10 of your hours. The PM time is mostly spent on relating to the client and the developers (coordination), and the paperwork / documentation / correspondence. If a freelancer, you will still need to spend 1-2 hours out of 10 corresponding, skyping, and writing documentation.

In different organizations, margins can be different. Larger companies statistically determine the optimal margins that they add to the pure estimate. Let’s list some of the margins / percentages that you may want to apply to the Base Estimate. I will list the numbers that I usually use in parenthesis, but you need to be aware, that these are the percentages that work for me personally and can be different in your case.

  1. Project management margin. (10% works for me, education of client excluded).
  2. Variables margin. This margin is taking to account the fact that the ideal time is never reached. There are always complications and problems to solve that you could not have anticipated. (10% usual, about 20% for migration projects.
  3. Uncertainty margin. You can not always build an ideal solution in mind before bidding. In some harder cases, you end up having 2 or 3 viable options of how a certain feature can be built. Of course, the more exotic the feature is, the more uncertainty you can expect in achieving it. You may end up trying a few approaches before choosing the best one, a few libraries before you find the right one for your need. In this case, you may want to add a margin to the time planned for that solution. (10% to 20%).

There may be some other margins. In my case, my total margin ends up being about 10% - 15% of the ideal for the smaller projects, and about towards 20% for the larger projects, smaller projects being more predictable.