7 rules: why you should NOT start a Drupal enterprise project

In last 7+ years, our team has repeatedly been asked to take over a development of Drupal enterprise projects. That has made the Drupal related consultancy & programming a cornerstone of our business model. And while every single project has its own quirks, there is a pattern that emerges, and I would like to discuss the don't-do-it-list, rather than things that can be done properly. The reason is simple: there are always several different ways to make a Drupal project a success, but ways of doing it bad are almost infinite in number.

So, here is a list to expand according to your needs:

1) Client do not understand properly the enterprise scope of a Drupal project

Interestingly, it seems that this applies more to medium-size companies than to startups or big enterprises. Typically, a client lands a project where Drupal expertise is required, but due to lack of experience or internal staff changes the knowledge that Drupal is not just another CMS, but an application framework disappears. So, how to recognize the scope of a project? Unfortunately, no silver bullet is available for Drupal management to do it, but if anything sounds familiar in the following list, the chances are good that you have an enterprise project at hands:

• 1M+ clicks/month expected
• Newspaper-like procedure applied on publishing content (reporters/editors etc.)
• 20+ Views, or 5+ Drupal content types with 10+ Fields
• 3rd party integration points: Storage providers like Brightcove or Amazon, CRM systems like SugarCRM or Salsa, complex payment system integration (insurance/social security systems, or specific telecom provider API integration)... the list is endless, but remember: this is oft the main cause of your potential headaches.
• Integration of specific business logic: 10+ simple IF-THEN-ELSE (or more complex) rules not already integrated as a possibility in Drupal core
• There is a part of the project (outside of the theming) that requires custom programming, and 50% of that specific functionality can not be covered with existing contrib modules.

2) "There is a Drupal module that solves X"

We hear this sentence so oft that we have stopped counting. But remember - it is your job to understand the enterprise web, not the job of your client. In this specific situation, you have to decide if you want to engage the client in learning Drupal. If client actually starts to understand what does it actually means to apply more than 2 contrib Drupal modules at the same time, you have won an ally.

3) "The budget for Drupal project is fixed"

The prospects of this sentence are not really optimal for you as a Drupal service provider, but it is interesting that very oft this actually means "We have some money to spend, and then we will see if it works". So it is your job to make it work (usually by slashing the scope of the core project biz model), but it is also your job to present your work in a measurable way for the client.

There is also a variation called "The budget equals zero, but you'll get a percentage of profit".  Sincere advice would be either to walk away gracefully, of help client to find an investor - enterprise Drupal projects can not survive without a budget. Period.

4) "No experience with feature X of a Drupal project"

Drupal is huge. If you need to explain difference between Drupal and another open-source CMS (for instance, WordPress), and you need to explain it to your counterpart that has some IT experience, you can try it with telling that WordPress to Drupal is something like Java SE to Java EE. So you are not obliged to know everything, although a good advice is to walk away from an enterprise Drupal project if you are not familiar with 50+ most popular Drupal modules.

5) "Take over of existing Drupal project"

This is where the fun starts. Usually, you will land as instant help into a project that is already late, and has a team that lacks the expertise to proceed.
Although you can start your engagement by cursing your predecessors, being polite is always a good advice, since most of the programmers can accept that they have made an error if you explain it properly. And you would need some key information from those same people, sometimes in the future, perhaps in another project - this is a small world.

Usually, architectural concepts of a Drupal application are not set optimally, so a good advice is to go to the square one and scrutinize the data model. Whatever the strategy is, never accept any fixed model contract in this case (fixed budget, fixed functionality). Chances are good that you will need to patch existing functionality in a hurry (just to provide that the end-client see some progress), and after a month or two bump on some serious deep inside the project (and it was not just once when we landed into a big project with hacked Drupal core or contrib modules; some static code analysis is an absolutely must-do on the start).

Except that you need to grow spine to withstand the pressure from several different directions (your development team, direct client, as well as end-client), two things are necessary:

1. Explain openly all your counterparts that the project has inherent risks, and that you are most probably not aware of all the problems at the start
2. Build that knowledge into the contract: make it short-term, warrant (as far as it goes) only for the code that you deliver, and price it accordingly.

Be ready to walk away from the project if you get a feeling that it will go south - nobody needs bad press, and this goes especially for Drupal centered companies.

6) "Do your Sprint/Agile properly or don't do it at all"

It is your responsibility to organize your work in measurable chunks (and contract & charge accordingly, btw). Interestingly, almost all organizations are using an issue tracking system nowadays. In theory, that will facilitate doing the agile properly - and in real life, there are very few cases that this actually works.

If this is an issue of human nature, or the way how humans are socialized... well, that is beyond the scope of this debate. The practical consequence is, however, that if you do not organize your work in small, measurable issues that apply for sprinting, your client will certainly not do that for you. Remember that you are engaged very oft not only as a Drupal programming capacity, but as a consultancy source to technology AND the business model. A nice side effect is, that if you use Git and issue tracking system properly, your invoicing while be indisputable as long as you can deliver sprint after sprint as agreed with the stakeholders.

7) "Enterprise means dealing people, and I am not comfortable with that"

Welcome to the real life. Drupal is an enterprise tool, and that means that you will most probably start dealing with enterprise organizations and their hierarchy.

So... you come into a situation that... eager new management from department A wants to apply Drupal on part(s) of the internal procedures, and you are the one who will get the "friendly fire" from other departments... or, critical information are withheld (by all you can tell) on purpose, no access is given to internal servers or APIs for months... or, someone in the accounting delays the payment of your invoices for no obvious reason... or, someone somewhere simply wants the project to die, since (for whatever reason) they want to bring company X and technology Y in the game, and not Drupal... or, despite all the good intentions, you will get hit by a sudden change in client’s internal policy that affects the budget priorities - and your project as well... or, department X engages you, and then department Y takes your prototype (without telling anyone) from the test servers, starts experimenting with it - and put it online to everyone's joy and excitement (btw, don't think the list is a movie script - all the listed cases are real life examples that we experienced or heard about experiences of other Drupal centered companies).

So... you end up in a fight that is not your own. Therefore, do not make it your fight:

• Take time to do your contracting properly
• Always meticulously document every communication (chats, telcos etc. ) and request review of those communication notes from your counterparts
• Don’t take sides in internal dog fights, take the side of the project: when dealing with confronting information or requests, ask politely "How is this helping our Drupal project?"
• Create and nurture your own "Drupal fun club" across different organizational departments - this will increase the chances that the information you have about the future of your project is up-to-date and accurate
• Always document every single feature that you deliver, deliver on regular base and communicate those deliveries with all stakeholder
• Always configure your Drupal logging to track every action of (at least) "power-users" and backup the logs on regular base
• Be aware of all communication overhead and charge accordingly
• If you decide to lose your confidence or patience, do it on purpose and with precisely defined intentions (for instance, create some pressure to start things moving a bit faster)

Those are just some of the rules that we get familiar with (in one or another way) in the past. However, although dealing with enterprise Drupal projects can be challenging from time to time, a success of a project gives you very oft the sense of accomplishment, pride and confidence that is a great deal of help when you want to start a new one.

I would be very interested in the experiences of other Drupal providers and their own "don’t-do-it" lists, so feel free to engage :-)

original posted on montenasoft.com