Drupal as a framework doesn’t lend itself well to detailed specifications — and many projects try very hard to do them to “contain risk” and get “a clear and exact” deliverable.

In my experience Drupal changes so quickly that the waterfall approach to project management often leads to things changing underneath the spec. In addition, this project approach often leads to highly bloated project plans, with everyone having input, and tends to include the kitchen sink. Lastly, containing risk is the opposite of “getting things done,” and tends to attract the kind of developer who’s looking to “have a job” rather than “build great things.” The “creativity in coding” (or what insiders call “hacking”) is one of the largest assets of a well run engineering company. When you don’t leverage it, you’ll rarely if ever end up with a better product than you could conceive of day one — a time when, if you’re honest, you have little insight into what you’re building — and you end up with, at best, your original idea. The learning that you get throughout the process of development is not typically well leveraged. And it’s some of the most important insight you can get as a product manager: how do you know if you’ve got what you want until you see what you have and see if you like it? The ability to change directions from a feature perspective, tweak specific ui elements that may work well on paper but not in real life, or take advantage of the skillets of new or improved skills in staff members during the project isn’t easily leveraged.

Now, there is a usecase for upfront planning, and that comes down to working with the entrepreneurial brain. If you think that “nailing someone down” on requirements is going to help — which is often the case with the kinds of mind that move at a million miles an hour — it can be a great idea. I’ve seen it backfire as well, because the scope tends to be everything. But if you’re trying to “do one thing, and do it well,” which is really the approach you need to manage this kind of personality, it can be extremely helpful to get the overall approach written down, and start from the end result. However, it all becomes a game of personality management when it comes to managing entrepreneurs: are they going to be too detail oriented, and manage by features; are they going to go so big that getting it down on paper is nigh impossible or very difficult; or are they going to work through it with you in a way that can get a clear, quantifiable deliverable that drives the project’s purpose and is aligned with the core strategy? You’re on your own there, but be aware it’s a possible exception — just to keep the entrepreneur from changing directions mid-stream (though that’s not warrantied with this process).

A second use case is when you’re working with organization dynamics. Some organizations require a carefully thought through specification in order to get budget or project approval, and getting it right can be the difference between success and failure, whether you’re working inside of outside of the organization. Sometimes clear deliverables that you can work within are necessary in order to support, or gain the support, or organizational initiatives.

However, even within those two exceptions (and I’m sure there are others: we’re all learning), the majority of time, it’s better to use an iterative, Agile approach with Drupal in order to gain the benefits I’ve laid out.

That requires something important: trust.

Drupal’s very nature is collaborative, open, community-centric, and re-contributive, and organizations that embrace those characteristics in their development projects tend to fare a better long-term result. The trust that inherent in the community is what built the platform to begin with, and it’s therefore advisable that relationships around the product embrace the principals that have made the product successful to begin with.

It’s just something I’ve been thinking about — I’d love to hear comments or reactions.