9 Principles for Drupal Support Projects that Drive Results

Support projects aren’t the most flashy, but we love providing ongoing support for our clients. For us, the length of time we support clients is a long-term indicator of how well we drive value.

A successful support practice has four crucial components:

1. Proactivity - Much of support is tactical work supporting clients as they execute their business strategy. That is appropriate. But it shouldn’t be a one-way street where the client directs the agency team. You should have the feeling that your support team brings new ideas and suggestions to you as well.

2. Reliability - A successful support practice has a long history of stable releases, thoughtful planning, and few surprises.

3. Velocity - The backlog for ongoing support never ends, but you should still feel—and be able to measure—that steady progress is being made on bite-sized refinements.

4. Personality - To gain the long-term efficiency benefits of familiarity, you want an assigned team working on your site. When the interaction with the support team is a ticket system, there will always be a disconnect and a frustrating lack of ownership.

In some cases, we take over a dumpster fire of a project and spend time sorting out the problems before we can smooth it out into a well-oiled support project. These nine principles turn an average support project into one that works and drive results.

Principle #1: Strategy informs support, continuously

We are big believers that making small, continuous improvements over time is how you lap any competitor—no matter how much better funded or more talented they might be. The discipline to focus every day on small improvements is the secret to long-term success.

A digital strategist from the support team should be regularly analyzing your Google Analytics data and overall engagement flows to recommend improvements to information architecture, UI, and UX. The cadence is less critical (and more dependent on your support investment) than the commitment to stick to a schedule and experiment, experiment, experiment.

If you are struggling to find the time to incorporate testing into a busy schedule, consider two important lessons. First, do what is most important in the morning, because as the day progresses, new requests tend to shift to afternoon priorities. Second, put a block of time on your calendar for testing—not a meeting about testing, but for actual work time. That will ensure that you don’t get booked for another meeting and will make you feel obligated to actually spend that time doing that task.

Principle #2: Your agency should be leading you, not the other way around

It’s easy to get stuck in a tactical relationship on a support project where you are bringing all the ideas to the table. Your support team should be bringing new ideas to you, challenging your assumptions, and pushing you forward.

Think about it: Can you remember the last time your agency spotted the best way forward—before you asked? If you can't, you have a problem.

Principle #3: A real person takes your email

A corporate IT ticketing system is not unlike a black hole: lots of information goes in, but nothing comes out. The challenge with a ticketing system is a lack of familiarity. The team that addresses one issue one day might be different than the team that addresses other issues another day. And issues often relate to past issues, so if the team is different every time, you may end up paying for someone to relearn what someone else had already learned.

You should have a single point of contact for ongoing support, and that contact should be a friendly human. They have context for the tickets you put in, and they can proactively reach out to you with questions or ideas about how to move forward.

Principle #4: There’s a visible, trackable, understandable process

Process is sort of like martinis: A moderate amount is better than none, but too many has terrible results. Your support partner should have a clear process in place for several crucial components of support:

• Backlog - Everyone should understand how things are added to the backlog, when they are groomed, how they get estimates, and how regularly they are reviewed with stakeholders. Without this process, stakeholders may miss changes to the backlog, items will grow stale without grooming, and prioritization of tasks will lack a cohesive strategy.

• Planning for the next month - There should be a clear process for when and how to plan for the month ahead. It is also important to manage expectations about how late new tasks can be added to the queue. Of course, support should absolutely offer flexibility for quick help with unexpected needs—you are a business after all—but some constraints are necessary to protect against a reactive support model where “everything is priority 1.”

• Quality assurance (QA) and user acceptance testing (UAT) - As with any investment in technology, you need to balance the competing interests of developer velocity and QA testing. Without a clear process for how refinements get tested, you may not have the time blocked off to invest properly in UAT.

• Releases - A release involves many stakeholders on both the client and agency sides. A standard release schedule provides a framework for prioritization decisions to get made. Without it, you will find that the needs of the one often outweigh the needs of the few.

As a system of deliberately-applied constraints, any technology effort is at risk of failure because of fragility. Process helps reduce that fragility by clearly defining how people interact with that technology, ensuring those interactions are productive.

Principle #5: Drupal updates should just happen

Drupal regularly needs security and functionality patches to stay current and secure. Your support team should have a standard, automatic process for evaluating security vulnerabilities as soon as they are discovered, and deploy emergency or standard patch installation as needed.

Principle #6: Support starts with an audit

When you engage a support team, it should thoroughly examine your Drupal for best practices, performance issues, SEO optimizations, and security vulnerabilities. If you don’t look, you will never know if there are serious issues that will inevitably cause problems.

Principle #7: Checklists are valued, not skipped

If you have ever flown on a commercial airline flight, you are likely still alive because of checklists. Checklists offer two distinct advantages: they dramatically reduce the error rates of repetitive processes and they provide a system in which improvements can be captured and applied consistently in the future.

We’ve found checklists are absolutely essential for things like audits, dealing with a malicious attack, and production releases.

Principle #8: Measurement is taken seriously

It is a simple but very true rule: You only make progress toward a goal if you have a way to measure it. You should have clearly defined goals for improving the performance of your site, and your support team should help you track them

Consider this: Would your agency partner be able to state, without referencing notes, the two or three KPIs that you most care about?

Principle #9: No compromises on Quality Assurance

Any support operation should have tickets that track acceptance criteria, quality assurance (QA) testing, smoke testing for hotfixes, regression testing for larger releases, and an overall QA process.

As with any development work, it is important that QA ensure acceptance criteria is met, and that the feature, fix or update meets our quality standards. Equally important is the task of regression testing: QA needs to assess the impact and risk associated with each code change, and ultimately safeguard against unintended consequences or regressions that the change may have caused elsewhere on the site.