Skip to content Skip to navigation

Tips for selecting a Drupal vendor

I provide web project strategy and guidance for Stanford departments looking to hire a vendor for custom web development. My clients receive a full-service experience that includes business analysis, technical review, needs assessment, research and writing, agency recruitment, proposal evaluation, reference checks, forecasting, and is tailored to their specific needs. My clients are very happy.

However, this model does not scale. A comprehensive selection process can take 6 weeks, and I can’t work with everyone who needs help. Therefore, I intend to use this blog to share information  and experiences with the community about some of the basics of vendor selection that could help lots of people at once.

Because of the importance of Drupal in Stanford’s web environment —and the inherent dangers of handing a tool with such flexibility (and thereby margin for error) to a non-specialist— I choose to focus specifically on Drupal for this article, but I should probably write another one for general considerations when sourcing web design and development talent.  For today, I will keep it mainly on the Drupal channel, occasionally flipping over to the PM channel.

When selecting a vendor for Drupal work, these are among the things that I look for. Please read these tips before searching for a vendor or signing a contract.

tl;dr summary

  • Make sure your developer knows the Drupal API

  • Standing in the Drupal community matters

  • Examine portfolio and filter on the specialty suited to your particular needs

  • Require secure code

  • Check references

  • Seek competitive bids

  • Project Management and communication matter

Knowledge of the Drupal API

Drupal has a hook system that allows for any given component of how Drupal works to be overridden. It is fundamental that your developer understand this system. Masters of this practice can do amazing things. Those who ignore it break stuff.

A common mistake is hiring an expert PHP developer to build something in Drupal. They will have a solid understanding of the underlying technologies, and will be naturally inclined to seek expediencies (a.k.a. “hack core”). That’s bad. An expert PHP programmer could easily become a Drupal developer, but they will need a guided tour before they dig in. The value of this approach may not be apparent or convincing to a developer at the outset.

Standing in the Drupal community

Your preferred agency may seem skilled and professional, but who are their developers exactly? All Drupal developers have profiles on drupal.org. Ask who the lead developer on a project will be, and ask for his or her drupal.org username. You can then look him or her up and discover what contributions they have made to to the Drupal project.

Is your agency a member of the Drupal Association? Do they participate at DrupalCon and Drupal Camps? Do they sponsor these events? Do they contribute code back to the open source community? These are all things that matter.

Experience shows that standing in the community can have a direct effect on project outcomes. Drupal is not one project, it is thousands of separate projects (called “contrib” for “contributed modules”), a constellation that orbits one central body that is Drupal Core. This is one of the big reasons that Drupal is so flexible and so powerful. If your custom project pushes the boundaries of what is possible in Drupal, and new functionality is needed to succeed, a dev that is well-established in the contrib space will be more successful in getting patches accepted by  module maintainers.

I should acknowledge that not every agency broadcasts their contributions, and plenty of expert implementers don’t have have numerous commits to the Drupal project. I know some stellar developers that have light-looking d.o profiles. It’s not a litmus test, but if the lead dev for an agency doesn’t even have an account, that’s a red flag.

Portfolio and sub-specialty

Not all web projects are the same, and often no two Drupal projects are exactly the same. Some projects require sub-specialties. How strong is your agency of choice at theming? devops? features? installation profiles? custom module development? evaluating available contrib options? commerce? CRM? SEO? An agency that is excellent overall might not be top-of-list if their skills don’t align with your project requirements and priorities.

Caveat Emptor: do NOT hire a pure marketing/advertising agency without a qualified Drupal development team, and if you hire a print designer with no web experience whatsoever, I guarantee that you will be the owner of a hot mess in about six months..

Secure Code

Drupal is a very secure system that is used widely by such entities as the Department of Defense and the White House. The core project is very secure when kept up-to-date and implemented correctly. Drupal also has its own Security Team that responds to exploits discovered by the community and keeps us busy applying code updates. However, as soon as we introduce a custom module—as large projects almost always do—we must be certain that the vendor we engage is well versed in best practices for writing secure code. Simply asking your prospective vendor what they do to ensure that their developers are up to speed on web application security is a step in the right direction.

References

Has your preferred agency worked at Stanford before? If so, which projects, and what was that experience like for the Stanford client? Some of the best agencies in the business (to my chagrin) still have not worked with Stanford, so this shouldn’t really be a barrier to entry; however, you should check with colleagues in order to benefit from institutional memory.

Competitive Bids

The Procurement Office requires competitive bids for development web development work. Stanford faculty and staff have a fiduciary responsibility to follow Procurement guidelines, and should not abuse the sole source justification. Sole source certainly has its place, but we should be rigorous. If you are tempted to select a vendor based mainly on a prior relationship, slow down, evaluate the project requirements, and take stock of whether you are asking them to operate outside their area of expertise

Client Communication and Project Management

In the early days of my vendor relations career, I prized technical chops over pretty much everything else. That was a mistake. Projects can fail for a variety of reasons, technology being only the most obvious. Successful projects are built on three pillars:

  1. Technical proficiency of the designer, developer, or agency
  2. Project Management (PM)
  3. Client communication

I used to put all of my eggs in basket #1, but have since learned that this stool needs all three legs. Project Management is a highly technical skillset, and the people who are very good at it are rockstars. Not everyone can do it well. A technical PM is an invaluable asset, especially if they can provide deft pushback when needed (and it will be needed at least once on every single project).

I have also learned that PM and client relations are separate proficiencies, and we need both. PMs can be extremely efficient communicators, but may not be best suited for the client relations role, and having an additional point of contact separate from the PM workflow is ideal. If it is an especially huge or complex project with a large stakeholder group on the Stanford side, it is recommended that you have a dedicated PM on the client side to work with the PM on the vendor side. I realize this sounds like overkill, but experience shows that staffing at this level can really pay off and take a great deal of stress off the Stanford project lead (a.k.a. “you”) and save money in the long run.

Inconvenient Truth Time

It is a stark fact that doesn’t get talked about much, but for projects that experience difficulty, clients are in fact the problem at least half the time (this is an industry-wide phenomenon and is not unique to Stanford). Technical and creative projects tend naturally toward entropy and confusion, which has to be mitigated on purpose. An agency that possesses a distinct client communication proficiency will succeed more often. Clients are not obtuse luddites, they may be brilliant minds at the top of their chosen field; it’s just that they don’t do web-related work every day, and sometimes need a congenial expert guide to keep the ship on course. If your agency has one of those people —in addition to a skilled development/design and strong PM— then you are in good shape.

Conclusion

These days many units at Stanford are opting for Drupal at project outset because of the great amount of resources and expertise that we have accumulated as a University in this technology, and, I wager, the inherent power of the Drupal framework. Drupal is complex, and hard to do well especially if you don't want to forward that complexity to the user. Because Drupal is complex, it is important to engage a bona fide Drupal agency if your project calls for custom solutions.

Lastly, if any Stanford unit has a bad experience with an agency, please let me know. If your unit has a good experience with an agency, also let me know. We want to learn from mistakes and successes alike, and pass that information on to the community.

Good luck with your project!

Comments

Great article, Zach! These are some really important issues that all vendors and clients should keep in mind. 

Thanks Caryl, but I'm not so sure that "wisdom" and I belong in the same sentence.
I think I might hit the bar for "common sense" on a good day. :)

Well said. I hope this reaches people who can benefit from these insights.

One thing that's hard to quantify (and possibly to believe) is that Drupal community standing would have any relevance in these decisions. You've listed a few concrete reasons but I think one over-arching principle might be that of good-citizenship. People or organizations who are concerned about the community and ecosystem they work in (be that Drupal, their local community, education, etc.) are much more likely to do good work for a project they believe in and to see that project through to success. Organizations who've managed to do that for many years and with many different clients are, almost by definition, organizations that have figured out how to do so in a sustainable, repeatable way.

So, any firm with a good Drupal community reputation and a longstanding involvement is much more likely to be an organization that not only knows how to code something, but also how to deliver a successful result.

Thanks Drew, and I take your point. You are spot on. We at Stanford, and other institutions that care about Drupal and open source, are very swayed by this line of thinking. We benefit greatly from the labor of others, and are increasingly looking for ways to contribute back. One way to do that is to support the ecosystem by choosing vendors that contribute to Drupal. However, I think that this logic might be lost on someone new to open source, which is why I appealed to self-interest instead.

Certainly. I might have gotten too long-winded there. I think community standing/reputation is a reasonable indicator of whether a firm can deliver a successful project. As I see the chain of questions:
A. Can this project make us more effective as an organization? (If "yes", continue)
B. Will [insert firm name here] be able to realize or exceed our expectations and deliver this successfully?

I think question B has a highly-corollary answer:
B1. Does this firm have a good community reputation for doing similar work?

If you can answer B1 with "Yes!", you most likely also have a "Yes!" for B.

... with your rationale. That is pretty much how we do vendor selection around here (at least how we come up with short lists), though I try to always do homework on what is being done elsewhere, and learn from the community in the broadest possible sense. I think your Question A probably doesn't get asked often enough!

(via Julienne Van Der Ziel, with permission) Good stuff... I'd add:

Understands accessibility requirements and builds them in from start - get it in contract For higher ed - HIPPA and FERPA; general public sector rules as well for us public institutions

References - I'd broaden topic: Taking it from 'best/most direct' to generic, I'd go down list as:

- direct experience with my organization
- specific and similar experiences with institutions in my industry at my size of organization
- general experience in my industry - strong references, but not in industry

(and if I was forced to split farther, I'd go with breaking out functional vs. technical experience)

I'd add a 'first question' of 'are you looking for a partner or just a body shop of specific skills?' - approach, pricing, risk/reward are very different between these approaches

Really like the portfolio and subspecialty comments - so true! I'd add "assess your own skills and gaps and make sure your vendor is skilled in areas you know you are weaker"

Security - I'd add - put requirements in the contract/SOW

Client communication/PM: I like, I'd add a fourth - "understanding and focus of the business problem and knowledge of the business space you are operating in - i.e. the functional and business expertise needed to not only have the right technical solution, but also meets the real business need"