Estimating time in Drupal project

Estimating time is indeed difficult. We've had success with applying a
strict method of using fixed amounts of time and breaking tasks down. We
estimate in man hours, and use a fixed scale of units: 1, 2, 5, 10, 20,
50, 100. The rule of thumb is to pick the higher of the two if your
estimate lies between two. If unsure, divide and conquer - break down
the task and estimate each subtask.

It's better with a mix of 10's, 20's and 50's than multiple 100 hour
blocks as the risk of error stands in proportion to the size of the
estimate. This way, you can better control potentially inaccurate
estimates. By assigning a complexity and risk rating to each estimated
item you can also take risk and complexity in account when doing project
planning. We've had good success and produced eerily accurate estimates
this way.

As many of you have observed, making accurate estimates is
time-consuming, especially with Drupal where many features can be
implemented by combining existing modules and code. You can usually
spend half an hour to an hour to make a rough estimate based on your
experience with an accuracy of a few hundred hours. That's what we do
as part of a quote for a client, and we can also see roughly what
competence is needed where and include that as well.

If the client wants more precision, what we offer them is a pilot study
that lays the foundation for the development process. Many people can
build Drupal sites but not all can do it well, The Drupal Way, as we
say. Most programmers can use Drupal to implement anything
monolithically and not reuse existing modules and combine them. However
if you want to work efficiently with Drupal you need to know the
terrain, know how to use existing modules to build what the client
needs. This task is what we refer to as Drupal architecture, and it
takes an experienced Drupal developer to tell where a custom module is
needed and where an existing one can do the job. More importantly,
sometimes a client can relax some requirements and thereby get 95% of
the functionality at 50% of the time it would take to implement
something exactly to spec by going with an existing solution.

In our dreams we get to take care of everything from design to
implementation and have a concise unambiguous specification to work
with. In reality you often get a complete design mockup in your hand and
you're told to implement it. The time estimates for mockup designs tend
to get high as there are a lot of details that need customized
solutions. When we talk to them about The Drupal Way, clients get
excited when they hear how much time they can save by doing things a
little bit differently than their designer envisioned.

As part of a pilot study we include suggested implementation guidelines
(a "recipe") with time estimates and complexity rating. It explains how
to build the site on Drupal exactly to spec and how a similar solution
that depends on existing functionality (The Drupal Way) can cut
implementation time considerably and what effects it has. Such
guidelines can then be used by the client to make informed decisions
before the actual development work starts. Since the pilot study is a
service we offer we can dedicate time to building small test sites and
evaluate the solutions we suggest. That enables us to make time
estimates that are based on actual hands-on experience rather than
extrapolated numbers and projections based on experience.

Being honest and telling your client you can't give an estimate, that
the information provided is insufficient and that you'd rather focus on
producing a pilot study for them is often a good idea. Clients that are
familiar with software development understand your reasons and will
consider you a more serious partner than a company that gives a fixed
even price (say 200 000). After all, a successful project is something
both you and your client will benefit from. Showing that you do not want
to compromise your relationship by running the risk of selling something
you cannot deliver on time and with the quality required strengthens
that relationship.



Jakob Persson
Co-founder and Consultant at NodeOne
"Empower the user"
Kåkbrinken 11A Vita gavelns väg 10
SE11127 Stockholm SE42671 Västra Frölunda
Phone: +46 31 780 02 23