How to Budget a Drupal Project

…(silence)

This is what I hear most often when asking an organization what amount of money, or budget, they have set aside for their website project. Am I surprised? Not really. An enterprise website is a complex piece of technology - a software application. Ten years ago, the complexity of an enterprise website was far less than it is in 2015. If you have ever been involved in buying web development services over the last 2-3 years, you understand this. But, even a buyer who has procured these services once or twice often isn't adept at aligning their organization's digital needs with a reasonable cost for fulfilling them. Why? Web technology and digital marketing constantly evolve and unless you are involved in the procurement process for web services on a monthly basis, it's difficult to know what solutions and approaches are efficient, maintainable, and cost-effective.
 

RFP - The Best Starting Point?

There are two different approaches I typically see. I’ll start with the approach I observe in about half of our sales discussions and one that rarely works successfully. In an attempt to bracket or gauge what their budget should be, some buyers will issue a Request for Proposals (RFPs) that generally describes the business problems their website needs to resolve, goals for the project, and brief descriptions of functions and features at a high-level. They’ll receive quotes from multiple vendors and isolate how much they think they should spend based on the pricing proposed by each vendor. Seems like a widely adopted process that any average person shopping for a service would take, right?

Here’s the problem: if you cannot describe your vision in a way that’s detailed and representative of the entire website you want designed and built, down to the navigation, buttons, forms and information that will appear on each page, a vendor won’t be able to define an accurate price. Consequently, the final number you establish for your budget will be misinformed. There’s a high likelihood the quotes you receive will be all over the map, ranging widely from low to high. The inherent risk that lies in budgeting via an RFP is you and the vendor may seemingly be “on the same page” with regard to time, effort, and money required to execute the project described in your RFP when the project actually begins. But, after being multiple weeks or months into the project, both you and the vendor realize that the vision described in your RFP simply wasn’t detailed enough and misrepresented the true scope of the project. Consequently, your website may not launch with all the features you would like or your website launches with your desired features but the project goes over-budget.
 

A Detailed Plan Aligns Everything

A better, less risky approach to establishing a project budget is, as a first step, to plan your vision clearly. Research other websites and mobile apps to determine what features and functionality they use that would also help solve your digital marketing and communications problems. If there are departments in your organization that have a stake in parts of the website, get them involved early in the budget definition process and ask them to clearly articulate their business needs for the website so you can include those needs in your plan. When buying Drupal services specifically, it’s important to understand that Drupal’s true value proposition lies in thousands of modules that have already been programmed to manage content and demonstrate website features. Aligning your vision with popular Drupal modules and their features helps mitigate scope creep and keeps cost lower compared to heavily customizing Drupal.

Keep in mind that your website doesn’t stay the same indefinitely after launch. Content, features and navigation will likely need to evolve along with your organization’s industry vertical and business strategy. The post-launch period is the best time to create and install features that weren’t included in your website’s initial launch. Drupal’s modular architecture is ideal for this type of iterative deployment. Prioritize what’s most important for launch and what should be accomplished after launch. Taking time to clearly describe in written form how you need your website to look and function before establishing a budget will bridge the inevitable money gap that would have a high probability of occurring without a clear, detailed description. The best documentation includes an outline of navigation, descriptions of which audience(s) will use the website, a general explanation of each page’s purpose, and a sketch or wireframe of each type of page with explanations of how users should interact. Furthermore, prioritize the features that are most important.

Here’s an example of a poorly written requirement summarizing how a form feature should work compared to a well-written, detailed requirement:

After you’ve documented your vision in detail, ask vendors for a price range, and only a price range, as opposed to a single price and/or a proposal. Every website project Mediacurrent works on is a unique creation. Some are more similar than others, but in the end each has its own blueprint, like a custom built home. So, accurately estimating the price down to the dollar without detailed documentation for each page and feature of a website is extremely difficult. Once you’ve received price ranges from several vendors, you’ll have enough of a sampling to hone in on a budget number you’re comfortable with.

What if you know you need to change your website or need a new one but don’t know exactly what you want? Engage a Drupal vendor to do pure consulting - no development/programming work. We work with many organizations that do not have the time or the skill set on their team to research and document their vision for their website. A Drupal services vendor can facilitate the research and requirements definition process by educating and guiding an organization’s stakeholder group. It’s not a one-day, two-day or week-long process. In most cases, it takes anywhere from 60 to 200 hours for our team to collaborate with an organization to fully define requirements, digital strategy and the technical architecture that their website will be built on - a process we call Discovery.

To recap, the steps for defining an enterprise web project are:

1. Research other websites, document layout, features and functionality that are important.
2. Garner feedback from departmental stakeholders that have a vested interest in the website. Include them in the process early and seek budget from their departments.
3. Educate yourself on how the open source web development process works - leveraging modules’ out-of-the-box functionality as much as possible, limit custom development work.
4. Prioritize critical features - what are must-haves and nice-to-haves?
5. Establish a not-to-exceed number that’s been approved by the CFO and other departmental stakeholders. Include a smaller contingency budget within that number for any unknown requirements or expectations that could crop up during the project.

Tips:

• If you don’t have an approved budget, you’re not serious buyer. When you have an approved budget, quotes you receive from web agencies tend to be more accurate and inclusive of solutions that can realistically be delivered within that budget without the risk of the vendor’s billing exceeding the original quote.
• If you haven’t established a budget and you don’t have a clear vision for what you want, you aren’t equipping yourself to make the wisest decision on which vendor to select (you’ll end up in the RFP problem mentioned earlier).
• Ask others in your organization if they’ve hired an agency to build a website and what they paid. Be sure to find out the level of quality of services the agency delivered.
• The more complex your needs and vision are, the more time and money will be required.
• Just like anything else you buy, you’ll get what you pay for. Good talent isn’t cheap. Your budget should account for this.