This past week at DrupalCon Denver, I attended a wonderful BoF on project management. The session started as a conversation about the complexities of Drupal project management. As we collected a bulleted list, one item in particular from our list stuck with me:
In Drupal development, fixed budget projects exist in an instantaneous sense, but in reality evolve constantly.
One can never account for every unknown on any given project, even when given an infinite amount of time. This idea captures the typical project process exceptionally well as Drupal (and its community) rapidly changes and improves, but we often stumble on the "two steps forward, one step back" phenomenon as a part of this. How can we account for these external risks and explain this phenomenon to our collaborators in the project process? Without firm understanding of this concept, the frustration is likely to mount for all parties.The illusion of moving forward by several paces only to jump back detracts (sometimes entirely) from the fact that progress has been made. This often leaves development teams discouraged and clients, stakeholders and collaborators neglected. As project managers, we're posed with bridging the gap. But how?
Because sometimes modules become abandoned, patches never get merged, and other dominant features crop up, it's best not to guarantee the use of any one particular module, installation profile, distribution or any other kind of feature, but rather an encompassing functionality. For example, instead of specifying the use of the ShareThis module, specify the functionality for users to share pages with members of their social networks. Not only does this get at the meat of the problem we're trying to solve, it explains it in language that our stakeholders will understand, and it won't lock the development team into a dead-end in terms of solutions architecture.
At this point, I can hear site builders and business developers alike saying to themselves, "You expect us to account for building this feature from scratch when there's already something out there that does what I want? That will multiply the size our estimate!" The answer is: not necessarily. Obviously, the Views module is not going to be abandoned any time soon (and if it somehow is, there better well be an jaw-droppingly awesome successor). It really depends on the strength and the state of the feature the developers wish to incorporate, and how cutting edge the stakeholder wants to be. The most cutting edge stakeholder will likely be understanding of the two-steps-one-step phenomenon, so it's a moot point. Those who aren't looking for the shiniest tool in the toolshed should be happy to settle with something that is tried and true. As for those who fall in between, consulting on a feature-by-feature basis will likely get you what you need to accomplish the project: "We could go wtih module X which is currently the standard, or we can try module Y which seems to be up and coming for such and such reasons, but may have risks involved as it's still in its early stages."
Another great resource to determine where a particular feature is, and where it is going is by consulting the good old technology product cycle diagram (More about the product life cycle on Wikipedia). The development team should be able to place where the feature falls in the product cycle. If they can't, then it's probably not a safe bet. Anywhere at the tail end of a growth phase or in the maturity phase is ideal. This diagram will speak to many clients, stakeholders and collaborators in a way that they will understand. If they see that the module they're interested in is in a decline or an early growth phase, they should be able to understand the consequences with little explanation.
A cry I hear coming from the coding side of my psyche is: "Modules and other functionality can't be swapped out so simply-- they aren't interchangeable. What if the module we intended to use is one I'm familiar with, but the one we end up going with is completely foreign to me?" This begins to get into internal risk mitigation and recognizing the skill set of your team. Skipping over the complexities of that (enormous) topic, before selecting a module and getting gung-ho about it, give your developers time during the design phase to familiarize themselves with the options, and gain confidence in their ability to manipulate them to suit the needs of the project. If they're not confident in this before the design is solidified, they may as well be building the feature themselves. How this affects budget, especially with regard to an increase, will need to be discussed with the client, and the budget balanced accordingly.
In the end, by avoiding specifics and focusing on goals (while still emphasizing the feasibility of the target) in the sales process gives the design and development team the freedom to accomplish the goals in the best way possible in the moment. If uncertainties arise out of product life cycle changes, the path forward should be determined by the stakeholders, so long as they understand the consequences and the available options fit within budget (which could encompass an entire blog post on its own).
All in all, my mind is still churning the ideas exchanged during the brief 15 minutes in this one hour BoF in the three day conference and I can't wait to contribute again to the DrupalCon experience (next time, at home base!) in Portland in 2013. Looking forward to seeing you all next May!
Image: A graph of Everett Rogers Technology Adoption Lifecycle model. Drawn in OmniGraffle and then trimmed in Apple Preview. http://en.wikipedia.org/wiki/File:DiffusionOfInnovation.png