Risk & Benefits of an open approach to Drupal Project Management

A common theme you'll encounter with the Drupal community is openness. Sure, a lot of companies just use the great free software and don't put much if anything back. But active community members are passionate evangelists. The community takes the ideas of sharing, contribution and co-operation very seriously indeed. Community members tend to stick together and in some ways this reminds me of the mediaeval guilds, where a shared skill set and common interest bound groups of tradespeople tightly together. Of course, the guilds generally acted in their own interests to protect their members.

But Drupalistas don't just use the technology for their own ends - they use it to make the products and services they provide to their clients as good as they can possibly be. That means deliverables based on a high-quality code-base, developed as economically as possible. In point of fact, this actually gives rise to challenges for Drupal companies and their clients. When embarking on new work it's typical for a client to want to know exactly how much something is going to cost. But you'll often hear Drupal people saying - I don't know, let's wait and see! Not surprisingly, this can be disconcerting for many clients.

But in point of fact, it's often a very good indicator that your development company has your best interests at heart. Drupal is an enormous technology with thousands of modules. It's extremely unlikely that any development company will know all (or even most) of the modules available. So R&D is generally the first step in any Drupal project. Good developers will typically ask - has this been done before? how much of someone else's code can I reuse? what features are essential and what are nice to have? what hasn't yet been thought of that could make this product even better? what can we drop to keep budgets low? 

To work together like this, trust is essential. Any development company worth their salt should be aiming to get their clients the best possible spend for their money. They know that their clients success is their success.

And if code is available, they'll adapt it and pass on those savings to their clients. If you are thinking about using a Drupal company, you'll find much of what I'm saying is commonly recognised. Watch the videos from Drupal conferences, check out the articles and discussions on drupal.org.

Companies don't like to work to fixed budgets because it's almost certainly the case that once a project has begun, all participants will recognise many assumptions that were incorrect, must-haves that turn out to be less important than originally supposed, and nice to haves that are actually essential and may cost a lot less than was originally thought. As such, fixing costs at the beginning of a project can be extremely risky - agreeing to work together openly and honestly to a common cause reduces this risk considerably. Of course, often budgets are fixed or driven by competitive tender. It's not always possible to commission a project without absolute clarity.

At Sereno, we often find ourselves working to fixed budgets and we're proud to deliver to them. But when developers and clients establish trust, Drupal provides the ideal platform for flexible, high-quality and cost-effective development.