Avoiding Big Problems With Big Drupal Projects

At CommonPlaces, nothing is better than the day we finally launch a big project and hand over the keys to our clients. After a long period of planning, designing, developing, and tweaking, it is very rewarding to finally see a project come to fruition.

We recently launched a large-scale Drupal project for a well known organization. In the end, the organization was ecstatic about the finished product. As a developer, I like to go back and evaluate the things that went off-track or could have been avoided during the production of this project. While this is not a crystal ball that will preview the problems you may encounter in your own project, it is entirely possible that these issues may sound familiar to you.

1. Does the client’s business model and workflow translate to their Drupal project?

We were instructed by the client to follow the pre-established plans, which we had inherited from another developer, for this project. However, it wasn’t long before we noticed that most of the planning did not mirror the expectations and needs of the client. Several workflows were not well defined on the business model of our client, which brought and even more unexpected factor into the game. We ended up spending several hours trying to define ways to replicate or improve real-life problems to Drupal. In trying to rectify this, we were taken away from actually developing the site

• Lesson Learned: This may sound clichí©, but no matter who is pressuring you, (project managers, bosses, clients, etc.), do not enter the development phase if the client does not have a well-defined business model that is currently working in real life. In other words, it is hard to build the ‘unknown.’ Do your homework and start developing only after well-established planning has been completed.

2. Evaluate time that will be spent trying to fix bugs and problems on contributed code.

Sure, spending time trying to fix somebody’s code is a noble and appreciated attitude, especially in the rich community that Drupal has, but not when you’re under heavy time and budgetary constraints. The success of your project can be jeopardized if you spend too much time contributing back with solutions and bug fixes.

• Lesson Learned: If a problem arises with a contributed module, go to the module’s issue queue page and investigate whether a patch with a fix is either available or in the works. If there is no patch, evaluate how much time will be required to get the module working properly. Communicate this with your project managers and clients, and if time/budget allows, make the fix and contribute it back to the community.

We hope this will highlight some things to look out for so you can stay on track, on time, and under budget with your Drupal project. Of course, if you have any questions about using Drupal or anything else, feel free to contact the CommonPlaces team.