pan•de•mo•ni•um /ˌpændəˈmoʊniəm/ noun 1. Wild uproar or unrestrained disorder, tumult or chaos. 2. The initial phase of a Drupal project that is not self-contained.

Project management

Project management is the use of techniques, policies and procedures to optimize the likelihood of completing a project within the agreed scope, time, and budget. Though it often resembles the Tax Code (complexity without clarity), done properly it can be an indispensable component of a project.

To better understand, let's look at the lowest common-denominators of most projects:

• Scope - the collective term for the project deliverables.
• Resources - the people, equipment, facilities and services needed to achieve the deliverables (including the project manager)
• Time - the time available to perform the work, measured in person-hours when defining effort (two people working eight hours = 16 person-hours), or elapsed time for calendar time (working eight hours and then waiting two days = 56 hours of elapsed time)
• Quality - while subjective, this attribute can run from, at the minimum, "job done" (i.e., the deliverable meets a defined acceptance criteria such as a specific level of certification) all the way up to "awesome, guys!"
• Budget - the bottom line for any freelancer not doing pro bono work

These factors are linked: changing one affects at least one of the others. For example, if the time is shortened, increased resources may be required—with a consequent increase in the project cost, which could then exceed the budget—or the quality of the deliverable may decline. So at least one of the factors needs to be variable.

The project manager is responsible for the project plan, which shows the tasks required for completion of the project, the resources and time necessary for each task, and any dependencies between tasks, which are all very important for keeping the project on track. Task 2 might not be startable until Task 1 completes, or perhaps Task 2 can begin as long as Task 1 has already begun. Similarly, if there is only one person available for configuration and there are 20 hours-worth of configuration tasks, each task will likely have to occur sequentially. Once laid out, a critical path can be identified: that path through the tasks which cannot slip without causing the entire project to slip.

A project manager also needs to assess risk; the "red flags." Typical project risks are situations where the project manager has insufficient authority over the assigned project resources, or the project sponsor lacks the authority to increase resources or change project priorities—particularly if a project has a non-negotiable end date.A risk assessment can highlight the factors needing adjustment (scope, budget, etc.), and may sometimes result in the project being scrapped.

A large Drupal project can easily lead to pandemonium in a field of red flags. Here's a hypothetical example:

A company has historically run a Java shop and now a Drupal site created by a third party who is no longer available comes into the project/asset portfolio. The company wants a similar site for another brand and wants both sites constructed the same way to reduce maintenance costs. To a Drupal developer it doesn't sound so bad, but let's look at it from a project management perspective.

Planning

In most cases, defining the tasks necessary to produce this site (as opposed to building a new Drupal site from scratch) will be nearly impossible. It's a rare day that a Drupal site comes with documentation that traces each visible element or non-UI critical function back through all the events (or Drupal layers) necessary to produce it. For example, does the item on the node page come from a view, a view template, a node template, content type field settings, a custom module, a panel, Javascript, or one or more of the dozens of contributed modules? Not only will you not know, you will not be able to accurately define the time needed to find out. Planning becomes an infinite loop of Discovery.

Development

"You want to use which development approach?" It might be of little matter using the Agile approach to develop in a purely Drupal environment--or in a project where you are a subcontractor delivering a remotely-developed product--because our hypothetical (but all too typical) project requires resources like IT, QA, networking folks, and other subject-matter experts to be plugged in without the benefit of knowing how far in advance you will need them. Agile methods imply an iterative approach to development where "we do a bunch of coding and see where we are at a certain point, and then do it again." Even your best text-book description of the Agile approach will likely produce a ring around the conference room of dropped jaws and raised eyebrows: hardly a vote of confidence for project managers or technical leads who need to express themselves with a high degree of certainty but are likely to be constrained by budget, time, scope, resources or quality.

Deployment

How are you going to push the finished site live? If you've been around enough Drupal deployments you know the drill, but have you ever explained the process to a non-Drupal person? "Well, we can export these as a feature, and probably those with Strongarm. However, there's really no easy way to move, and when we do, the paths will need to be edited and recreated." I won't say it's a mess, but it's definitely more Art than Science; a process that defies being documented in a meaningful way.

I don't dislike Drupal, really. Cut me and I drip blue droplets in search of botsnacks. I am simply pragmatic--some call it curmudgeonly. You cannot take an organization used to conventional measures and methods and ask them to take a leap of faith with statements like "Excuse me guys, can you move over and let us do our thing?"

So, what's the answer? I have two proposals:

First, I call for a Drupal standard for a site blueprint that illustrates that this field comes from that view, while the other field comes from a hook_node_view implementation with some template hijinks. Whatever the format, a developer or themer should be able to start with any screen element and use the blueprint to understand what created it: Panels? Views? Context? A block? A template?

Second, I offer up the Whitewater Method of project management. If you've ever been whitewater rafting, you know there are waterfalls, rapids and eddies (areas of spiraling water). In this context, waterfalls are the portions of the project that need to have conventional project controls: the tasks or phases of a project that represent the greatest risk, are dependent on limited resources, contain a fixed scope, or are constrained by tight, specific timeframes. Rapids represent the critical path; the fastest route to completion (hopefully with you still afloat). Eddies are the spirals of agile development sprints occurring between waterfalls; iterative development cycles where features and functionality may not be well-defined and that require few resources other than the developers, their platform and QA folks.

Laying out the project plan will be as complex as predicting the flow of a whitewater river, but hey, that's what project managers do!

Happy Drupaling.

The Farmisht Freelancer is a column for the (oft irreverent) discussion of all things related to being in the business of developing, building and theming Drupal sites. Farmisht is a Yiddish word with a nuanced meaning. Picture yourself waking after not enough sleep and stumbling around in search of coffee to help your eyes focus.