Estimating Drupal Web Development

5941302441_0da6f04a28_z.jpg

The "Making Things Happen" Book Cover

Drupal web development estimates are necessary, but nobody likes doing them.

We need them as an agency and our clients need them also. The reason nobody likes doing them, as Scott Berkun says in his (great) book Making Things Happen, is the mismatch between imagination and precision. We are expected to know: 

How will this thing work given the very limited information we have?

vs

Exactly how many hours will this take to do?

This challenge creates a risk that we may be wrong, very wrong, embarrassingly wrong. Drupal web development estimates are difficult, but most anything that was built started with an estimate of some kind.  

Let me say (before Jason Fried and his agile disciples start flaming me), that if you can get your clients to give you some money and you do some work, and then you are able to convince them to give you more money, you should do that and then start writing a book on selling. I don't think it works like that for most of us. I would argue that even for agile projects with short, measurable, early cycles, a good client needs assurance they have enough money in the bank to finish a version of the project. 

So...here we are. We don’t want to be wrong. Our Drupal web development clients needs assurance this project can be done and that they aren’t paying too much for it. What do we do? Here are some ways to make the mismatch less of a miss and more of a match:

Have we done a Drupal web development project like this before? Can we start there as a basis of comparison? We track the hours for every project in Freshbooks and they are synced to our tasks in Basecamp. Detailing project hours really helps us generate estimates for future projects. 

Where are we in the process and what level of confidence is needed?  Mismatch and frustration that occurs when estimating is caused by a lack of understanding in the level of certainty required. Berkun suggests, clarifying this before starting an estimate. He breaks it out like this. 

  • A guess = 40% right 4 out of 10 times etc
  • A good estimate = 70%
  • A detailed and thorough analysis = 90% 

The Sustaina Website

Some additional context from our experience

  • A guess = 40% - This works as a reality check with a new idea or client.  Are we in the same ballpark and should we invest more time flushing out the details?
  • A good estimate = 70% - This is the level of certainty we typically have when completing a proposal. We will always take work with this level of certaintly.  
  • A detailed and thorough analysis = 90% - This is the level of certainty we get after going through a paid discovery process with our clients.  We recommend this for larger or custom projects.  The deliverable here is fully clickable Protoshare (above) wireframes and a functional specification. The blueprint of the site is documented in detail, seen in the screenshot above. In addition, it is clickable so you can also see how the pages realate to each other and how users will flow through the site and convert. 

If the account team can clarify the above for designers and developers, much of their frustration and resistance goes away.  

Sometimes, potential clients would like functionality that is just too vague to start to estimate.  I’ve seen bullets in RFP’s that say things like, “Social Networking Functionality” This could mean something as simple as Facebook connect which allows people to “like” the content on the site, or it could mean replicating the functionality of the Facebook site. There is a big difference in the two and it doesn’t make sense to estimate either without further clarification.  

It's ok to leave things to be determined.   

It's important to remember, that we want the same thing as our clients - a wildly, successful web project at a fair price. Good Drupal web development estimates and good communication are the basis of a successful client vendor relationship.