In the two years or so since Mediacurrent started a web agency predicated around Drupal we have fought a recurring battle. We did not feel like our challenge was exclusive to just us in the Drupalworld. More specifically, we struggled with properly estimating and qualifying Drupal projects – a lot of variables, too many unknowns, hard to anticipate problems, different approaches to solving the same issue, etc. For these reasons among others, most open-source firms particularly, have abandoned the once popular Waterfall development methodology in favor of a more Agile approach. One of my favorite phrases from prospects is that this should be an "easy job" for an experienced Drupal developer – the sirens really go off when I hear that.

Furthermore, many Drupal shops squawk at doing fixed bids – those two dreaded words "scope creep" seem to inevitably raise their ugly head. To complicate matters worse, Drupal pricing and hourly rates from service providers seem to run a wide gamut. Customers are left pondering why they get quotes ranging from $5000 to 5 million dollars – that’s right, "m"illion, for the exact same project. While this is an extreme example, this huge discrepancy really did happen to someone I talked to last year.

We found ourselves having lots of conversations like this:

Caller: Hi, I saw your website and portfolio, like your work, and would like to discuss a Drupal project we are contemplating.

Me: OK, tell me more – where are you in the process? Do you have a budget range? What is your timeline? What are the goals/objectives? Most importantly, do you have any technical specifications you can send me that further describe your project?

Caller: What do you mean by technical specifications – what kind of information do you need from me?

Me: Well, I am ideally looking for a requirements list or features you would like on the site, design files, a site map, wireframes, user/system interaction explanations, roles, content types etc. in order to give you an estimate with confidence.

Caller: (pause) – OK, I see, but I really do not have the time, resources, or know how to pull this together. Can you just give me a ballpark quote and timeline of what something that I verbally described to you will cost?

Now, here’s where the disconnect really begins – simply put, we should not be upset at the Caller. Rather, they need to be educated as to what the level of effort is into a building out a Drupal site. The analogy I often hear is would you start building a house without a blueprint? A custom builder usually asks lots of questions like how many bed and bathrooms do you envision, positioning of closets, granite or corrian tops, finished basement, etc – you get the picture. Similarly, a good Drupal team will ask the same type of probing questions to pinpoint mission critical information architecture. Drupal is a complex platform full of "secret handshakes" as one of my associates correctly pointed out. Others have said that Drupal is the type of framework that has a never-ending learning curve.

Hence, this was the motivation behind us wanting to engage and collaborate with writer and Drupal trainer Tom Geller, whose name you may recognize from the Lynda.com Essential Drupal Training series he produced. We found quite a few end-user type manuals, plenty of tutorials, books, seminars, and videos existed. However, there seemed to be a void for a guide that goes into granularity about how an organization can pro-actively position and scope their Drupal initiative for long-term success. In short, the Callers need to have realistic expectations set, direction, and guidance. They need to adequately understand what goes into engineering a Drupal site, and recognize the value or specialty expertise that Drupal firms are offering. Therefore, we sought to create "Building an Enterprise-Class Web site with Drupal and Mediacurrent". Should everything in this guide be considered the holy grail – heck no. We are simply trying to provide tools and resources (questionnaires, checklists, examples, etc.) that we’ve been utilizing that may help others get started off on solid footing.

What do you think? Are there any forms, tips, or nuggets of advise that you would like to share that would help those who are in the pre-planning stages of a Drupal project?