Drupal has become one of the most preeminent open source web CMS in the governmental and public sector spaces, and its track record makes it an easy sell during platform selection. Even so, you have to do your due-diligence - Drupal may be strong, secure, and scalable, but it is important to determine whether Drupal is a good fit for your project. Start with "can we build it with Drupal?" and then ask "should we build it with Drupal?"
If you answer yes to both questions, congratulations! Time to get to work - the hard part is just starting. Simply using Drupal is no guarantee of success. You'll need to plan your project to work with Drupal's strengths and around its weaknesses.
Lay the groundwork
What can you do before you contact a vendor to ensure that you're going to get the product you need?
Work proactively with your stakeholders to understand what their goals and objectives actually are. The vendor might not always have access to these folks, so if you can, help them zero in on what really is essential to their jobs. This will make it easier to create requirements that lead to a more Drupal-appropriate approach.
Educating your stakeholders in what they can expect with a Drupal product helps as well. This makes it easier down the road when you have to negotiate with them about requirements that might not make into scope. Think about what Drupal is good at and help your stakeholders align their goals and expectations appropriately.
Get to know your internal technical team
There is no team more important to getting your site launched than the internal technology team.
Make sure to get them involved in the project early - and if technology approvals are required for any aspect of the site before launch, find out what these processes involve early. They may have questions about what is needed to support Drupal, and putting them in touch with the eventual development team early will pay dividends later (the same goes for the security team). If Drupal is new to your organization, this becomes even more vital. For example, you may need to bring in external security consultants versed in Drupal to validate the product.
Don't assume that approval of the underlying stack is enough (PHP, MySQL, etc.). Drupal as the platform may need additional approval.
Get to know the larger hierarchy and org chart as well, and learn what you can about their internal workings. There can be friction at certain points, so knowing what to expect is key. If the infrastructure team works on the same floor as the security team, the handoff of your approvals from one team to the next may go more smoothly than if the two teams are in different cities and are embedded in subcontracted vendors.
In addition, internal IT departments at large organizations tend to be organized around the platforms that support the primary business goals. If 90% of their job is setting up Sharepoint installations on Microsoft IIS servers, then getting a LAMP stack provisioned for a Drupal site might be a challenge, even if it’s approved software.
Good news! We already support it! It’s been approved!
Drupal is mature and has a track record, so if you're lucky you may get to skip the technology approval process. Anyone who has gone through a new technology approval process knows that this can be the single biggest reason to select one technology over another.
If it’s not approved? You will need a strong internal champion to shepherd the approvals, sell the project internally, and make sure there's sufficient ongoing support after launch.
Primes, subs, and contractors, oh my!
The nature of government contracting means that there are usually multiple vendors and complex layers of contractors. How can you ensure that your Drupal project isn’t affected by the structure of other vendor relationships?
Don’t assume that everyone knows about Drupal. You may have a top-notch development team with deep knowledge about Drupal development, but you may also have separate contracts out for designers, information architects, systems administrators, and security consultants. The degree to which they are familiar with Drupal impacts the efficiency of their relationships.
An example: We worked on a project for a government client with a partner firm that provided design, content strategy, and IA services, while we architected and built the Drupal platform used to build out departmental and agency sites. Our counterparts were all smart and really good at what they do, but they were not a Drupal shop. They made certain assumptions in their designs and IA work that didn’t initially match up with our architecture, and there was a learning process we all went through to adjust our respective assumptions.
Your role is the product owner. You can’t throw requirements over a wall and expect that the vendor team will build what you actually need without active involvement. There will be instances where you need to make decisions about aspects of your Drupal site and make sure that everyone is comfortable with it.
Without a budget there is no work, and in the government space there are always complications.
Does the contracting situation support a Drupal-centric approach?
We’ve talked a bit about how, in a perfect world, the developers and the client work together to find the best solutions to the challenges that they’re going to face. But if your prime doesn’t fully understand Drupal and limits the interactions between you and the implementation shop that does, you may get stuck with bad requirements and a Drupal site that doesn't work for your needs.
Do the budget and scope have a good working relationship?
Your vendors may find themselves needing to extend Drupal to meet requirements it’s not suited for. If they're working on a fixed-scope-fixed-cost contract, then they're either going to take a loss or cut quality. They may not always have a say in how the contract is structured, but if you can make sure your scope is focused on goals and objectives (as opposed to requirements), you can mitigate this risk.
Another way to limit risk on Drupal projects is to break risky work out into time and materials contracts if possible. This is something we try to do for migration tasks, where page count invariably inflates and content and data inevitably require cleaning up.
Do you have a roadmap?
Drupal is an excellent platform for iterative development. One thing I tell my clients is that they shouldn’t consider the site launch to be the end of development. Your needs will be different in six months, in a year, in five years, so your software shouldn’t be static: it should be an evolutionary tool that grows with you. It is never too early to talk about what features you’ll need in a year, even if you don’t have budget for it yet.
The flip side, of course, is that you should be open to moving features to later releases. This helps keep the functional profile clean and tight, and can provide an internal safety valve for managing pressure from stakeholders. You may not be able to satisfy everyone's needs, but if they understand that when their features are planned, they might work with you to get additional budget.
Finally, if you are able, it’s never a bad idea to schedule a separate "discovery" engagement where you sit down with strategists, introduce engineers to your technical team, and get to work on figuring out what exactly needs to be built. This doesn’t have to be long and expensive (and in fact shouldn’t be). The key thing to do is to identify the unknowns that introduce risk and get enough defined and understood so that everyone on both sides is comfortable getting started.
Manage your requirements - Don’t let them manage you
Fair or not, the stereotype of governmental projects is that they are waterfall in nature, come with vast lists of highly granular requirements, and have little leeway for discussing or revising the scope. As the commissioner of a Drupal project, how can you work with your internal stakeholders to manage requirements?
- Get your vendors involved early - they'll be the ones ultimately holding the bag if requirements are bad, so it's in their interests to help you wrangle your requirements.
- Establish goals, objectives, and success criteria with your internal clients so that you all understand what the real big goals are, and what "success" means internally.
- Collaborate on priority - if you can all agree on goals, it's a lot easier to push features out of scope that don't really get them value in these areas.
- Take advantage of Drupal’s flexibility and discuss alternative approaches, both online and offline.
We hope that this short guide (get started with part one "Can I build it with Drupal?" and part two "Should I build it with Drupal?") helps you understand how to plan a Drupal site. Above all just remember that Drupal got to where it is through the efforts of a huge community that loves to see Drupal sites succeed. We've helped dozens of government clients plan and execute on complex enterprise-grade Drupal projects, and we're not the only ones. So be confident - good luck!