In our many years of helping clients, large and small, build and optimize their websites, Lullabot has seen a common pattern in digital projects: recurring cycles ranging from energy and enthusiasm to disillusionment and destruction.
This wave pattern is common, and you can see so many instances of it. There’s the Dunning-Kruger Curve, where you swing from the peak of Mount Stupid to the Valley of Despair when you learn a new skill. There’s the Economic Life Cycle of Boom, Bust, and Recovery that our economy grinds through over and over and over. There are the relentless cycles of high tide and low tide, and of course, the actual, endless waves of the ocean. The pattern is common because that’s the way nature and humans operate.
The Digital Destruction Wave
Let’s take a hypothetical, but pretty typical, example. Acme Corporation has a popular website that’s been in operation for nearly 10 years. They have hundreds of pages of content and thousands of images and a small editorial team that is increasingly frustrated with the work it takes to create new content. They’re using an old CMS, and they’ve seen others that appear to have nicer features. Their site looks tired anyway, and they’re ready for something new.
There’s enthusiasm for the idea of starting over. When comparing something they know intimately (with all its problems) to alternative solutions, Acme relies on demos and salespeople and marketing information that highlight the best features of the new solutions and mention little, if anything, about their limitations.
Acme stakeholders settle on a new solution. Everyone is optimistic and very ready to get rid of the current CMS. They tackle the months-long process of designing the new solution, building it out, and populating it with all the old content, and they finally launch it.
But after launch, cracks start to emerge. Editors find that some things are harder to do than they anticipated, and some things that used to work just fine now require compromises. Some things are easier to do, but others are harder. Editors want to be able to do “anything,” but the new implementation focused on the need for simplicity, consistency, and stability by limiting editorial options. Political realities within the organization rather than the site's actual needs drove other decisions that further complicated the solution.
The list of requested changes and improvements grows as users and stakeholders actually use the site and realize they need more features or a different experience. Every new requirement complicates the UX and UI, adds hundreds of lines of new code, and increases the frustration. Sooner or later, the new solution is weighed down with just as many problems as the original. And the next wave of digital destruction begins as everyone wonders whether there is some other, better solution out there.
Building for the Long Term
Lullabot primarily builds Drupal sites, sometimes monolithic stacks where Drupal delivers the entire digital experience, sometimes decoupled sites with a Drupal back end and React (or something similar) on the front end. And every year, we see this relentless wave pattern of clients reworking their digital properties in a quest for better digital experience and content management tools. Sometimes they’re coming from another CMS hoping that Drupal will finally solve their problems. Other times they have a Drupal site that has become bloated and inefficient, and they’re looking for a new solution.
Destroying everything and starting over every few years is enormously expensive and disruptive.
But is it inevitable?
Below are three reasons why organizations get disillusioned with Drupal, each with ways to combat the problem.
No Priorities - Everything for Everyone
One of the main reasons organizations get disillusioned with Drupal is not unique to Drupal. It has to do with a lack of clearly defined goals.
Either they cannot articulate those goals in a meaningful way, or there are so many competing goals that there is a resistance to prioritizing. Prioritizing means agreeing on precise definitions. It means being locked in on specific directions and making some tradeoffs.
It means giving up on some grand panacea of building something that is everything for everyone. Many organizations do not want to give up on this vision. But that vision is never realistic. Trying to reach for that vision will mean disappointing everyone. You cannot say “yes” to everything.
In our experience, defining and prioritizing goals is the big problem to solve when implementing a new CMS. Failing to solve this problem upfront results in failure. Period. Though you might not realize the failure until more cracks have started to appear. Like playing against a Chess grandmaster when you are a novice, you lost after the first move, even though the game wasn’t technically over for another 27 turns.
And this type of failure has nothing to do with Drupal.
For example, the marketing team’s goal might be to shrink the bounce rate and increase time on the website. That is what “success” is to them. But the sales team keeps hearing complaints from their prospective customers that spending so much time on the website before speaking to a human was frustrating.
This type of mismatch is a recipe for disillusionment, no matter what technology you choose to use.
How do you avoid this problem?
Solving this problem begins long before the project kickoff. In some cases, it starts before you even know you need the help of an outside vendor.
You must have the organizational governance to be able to make decisions and enforce those decisions. All stakeholders must feel as though they are heard. There must be clear and open communication and the ability to have difficult conversations.
Sometimes an outside party, like Lullabot, can help you have these conversations. An outside voice can cut through some of the noise and tease out information from shy stakeholders hesitant to speak up. The sooner you uncover potential mismatches and risks, the better off you will be when deciding priorities.
This can feel like an extended phase one. This is foundational work that sometimes has to do with your organization’s very identity. Why do you exist? Who are you serving? What does success look like overall? What does success look like for each department? Do they conflict? Why? What is most important?
Only after you can answer these questions should you move on to additional details. Presentation modeling workshops and other requirements gathering exercises will run so much smoother, and as a result, your new CMS has a higher chance of lasting for a long time.
Drupal is a Framework, Not a Product
Drupal is flexible, and that has been touted as one of its strengths. And it is a strength. You can do a lot with Drupal that you can’t do with other enterprise content management systems. It has a wide breadth, where it can be used for things beyond landing pages, such as blogs, event systems, listing pages, contact forms, CRMs, e-commerce, and more.
But do enterprise content management systems really need that type of breadth? In the age of micro-services, a CMS product can do a few things really, really well and then integrate with other services to fill in the gaps. Most modern enterprise CMSes are polished products geared toward solving a limited set of problems.
Drupal can also integrate with other services, but if you ask what problems Drupal is designed to solve, you will get different answers depending on who you ask and what day of the week you ask them.
A Lack of Polish
Drupal has no set of polished functionality that is highly targeted to solve a limited set of problems. It is not a product. It is a framework.
Drupal’s structured content capabilities are first class, rival many enterprise systems, and are better than any other free tool you will find on the market…but this advantage will not be visible to most stakeholders. A marketing team that wants to spin out beautiful-looking landing pages cares about certain success metrics, and the elegance of the underlying content model probably isn’t one of them.
To make up for this lack of initial focus, Drupal requires significant investment if you want to use it for a big project. This is offset a little by having no licensing fees to pay (which, for some enterprise CMSs, can run into the millions of dollars per year). This type of customization and investment comes with its own risks, like missed timelines and blown budgets.
The lack of constraints and limitations also means that other products will almost always have a more polished editorial experience. With Drupal, you often have to settle with “good enough,” and, outside of some core features, polished functionality is rare. Or at least, the cost of that final 10% of polish is both time and cost-prohibitive.
This can all contribute to disillusionment, especially if expectations have not been set correctly. The grass will look greener on the other side. The spit and polish of a product demo can be alluring, especially when that demo doesn’t have to contend with your organization's underlying complexities and competing priorities.
Flexibility: Strength and Weakness
Because it is a flexible framework, Drupal is also complex. It is a set of tools that can be used in many different ways. The problem is that a screwdriver is not opinionated in how you use it. It will totally let you swing it and use it as a hammer. Sometimes, it might even work as a hammer.
Many Drupal installations end up looking like they were built by using screwdrivers as hammers. They work. Barely. But the lack of craftsmanship shows, making the system fragile and difficult to work on. Any attempts to change certain parts can cause everything to collapse.
When customized for mission-critical functionality, serving hundreds of editors across different internal teams, Drupal implementations require deep expertise. If this expertise is not present, you run the risk of building a brittle codebase that is hard to maintain and hard to extend. An extensible, flexible framework that becomes rigid and fragile is a perfect recipe for disillusionment.
How do you avoid these problems?
You need to be unrelentingly honest. You need to be clear about your goals and priorities (as discussed above), and you need to measure any polished functionality against those goals and priorities. It can be tempting to fall for the siren song of slick interfaces and smooth aesthetics. But maintain clear eyes on what is important and impactful.
A new product may be what you need. A completely revamped editorial experience may be what you need.
But are you sure? Is the need more than skin deep?
Some other ways to ensure your Drupal implementation lasts for the long-term:
- Have deep expertise. If you are trying to implement Drupal at scale, where it is mission-critical to your business, you need true Drupal experts. Not just PHP experts or Symfony experts. Drupal experts. If you can’t have them on your staff, you need to hire one of the top Drupal agencies (like Lullabot). You also need an architect with Drupal expertise who has the ability to see the big picture and can help be a bridge between your organization’s domain expertise and its technical implementation in Drupal.
- Do not expect the slick editorial experience of a focused, polished product. Instead, you should manage expectations and keep the focus on what is actually important. Under the proper care, Drupal can provide you with an editorial experience that matches your business needs, but you need to reserve your budget for things that actually matter. Understand what makes for a good editorial experience, and Drupal will hold up very well when measured against that standard. Just don’t expect it to fly you to the moon. A pick-up truck doesn’t need the best stereo system in the world to do what it does best.
- Make sure you need the flexibility of Drupal. You need to ask if Drupal is really suitable for your organization. Drupal’s strength is in its flexibility. That means, to really get gains versus other systems, Drupal needs to be used for situations that have unique needs and require extensive customization. Do you have multiple audiences seeking out content in multiple formats? Are you a large organization with various departments, each with its own editorial team, and need to maintain both consistency and flexibility?
Growth, Maintenance, and Technical Debt
This spins out of the previous section on Drupal being a flexible framework. These problems are not unique to Drupal, but because of Drupal’s unique strengths, these problems can manifest in unique ways.
Each installation has its quirks. Each implementation will make different decisions that map better to an organization’s needs.
This can lead to frustration in the future. Even if Drupal has been deployed in an expert fashion, problems will start to sprout. Organizations are not static, and the software that serves them cannot remain static.
Teams roll off, and new teams roll on. Turnover can cause gaps in knowledge. As new features are added, the potential for performance problems increases. Forms get longer and longer and more cluttered. Technical debt attaches to projects like barnacles on a ship. Drupal, and the many dependencies it relies on, must be updated and maintained.
Since Drupal isn’t opinionated, similar functionality can be implemented in many different ways. Different teams have different styles, and these styles can start to clash if there is no proper continuity plan. This leads to less code reuse and a breakdown in the overall organization.
All of these things can start to cascade like a slow-moving avalanche, eventually ending the honeymoon period of a successful launch and leaving a wide swath of disillusionment in its wake.
How do you avoid these problems?
- Maintain continuity after team roll-offs. This can come in many forms. Good documentation is always encouraged, though that requires effort on its own, and it requires the next team to care about it. It is better to focus on people. You can have at least one developer overlap both teams, and they work to continue the same standards. Or you can have the same company pick up support and maintenance for the project. The concept of “office hours” can work. These are set times when members of the new team work with some members of the old team who helped launch the project.
- Be explicit when mapping business logic. Settling on a ubiquitous language and modeling that language with classes in your code can limit technical debt and make future maintenance smoother. Using something like Typed Entities to help keep your custom business logic separate can make it easier for new team members to jump in. These build fences around how developers extend Drupal, which leads to more explicit expectations and reigns in some of the disadvantages of Drupal’s radical flexibility.
- Maintain a clear view of your priorities. Managing your priorities doesn’t stop after the project launch. This takes us back to the very beginning. Your organizational governance must hold the line. New features must be filtered. New priorities and requirements must be surfaced in an organized manner. Unregulated growth is not good for any organism, and it remains true for your CMS implementation.
Conclusion: Noble Retirement
Your CMS investment can last a long time. And now, with Drupal’s new major releases not requiring migrations, your investment should last a long time. You don’t need to be subject to the waves of disillusionment and destruction.
Your investment won’t last forever. But it should last long enough for you to retire it on your own terms, long after you have seen an ROI. Send it off into the sunset with full honors, knowing that it did its duty and served you well.
Early destruction and re-creation are not inevitable. Manage your priorities, set reasonable expectations, ensure you have deep expertise at your disposal, and maintain continuity and consistency. These are easier said than done, but they can be done. Instead of being beaten down by the heavy waves of destruction, you can surf them with grace.
Contributed to by Karen Stevenson, Greg Dunlap, Mike Herchel, Mateu Aguiló Bosch, Chris Albrecht, Nate Lampton, Sean Lange, Marcos Cano, Monica Flores