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.
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
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..
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.
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.
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:
- Technical proficiency of the designer, developer, or agency
- Project Management (PM)
- 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.
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!