fromAugust 2011

The Farmischt Freelancer


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.Random Arrows

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.


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.


"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.


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.


From our blog

Entity Storage, the Drupal 8 Way

In Drupal 7 the Field API introduced the concept of swappable field storage.

The Drupal 6 to 8 Upgrade Challenge - Part 2

Having concluded the readiness assessment, we turn next to migrating the content and configuration. In reality, there’s little chance that we would migrate anything but the blogs from our old site. For the sake of giving Migrate in Core a workout with real conditions, however, we’re going to upgrade with core’s Migrate Drupal module rather than rebuilding.

The Drupal 6 to 8 Upgrade Challenge - Part 1

Nathaniel Catchpole , the Drupal 8 release maintainer and Tag1 Senior Performance Engineer, suggested that Drupal shops everywhere could support the

DrupalCon Austin

The entertainment industry is not for the faint of heart.

Drupal Watchdog Joins the Linux New Media Family
Drupal Watchdog 6.01 is the first issue published by Linux New Media.

Drupal Watchdog 6.01 is the first issue published by Linux New Media. Come see the Drupal Watchdog team at DrupalCon 2016!

Drupal Watchdog was founded in 2011 by Tag1 Consulting as a resource for the Drupal community to share news and information. Now in its sixth year, Drupal Watchdog is ready to expand to meet the needs of this growing community.

Drupal Watchdog will now be published by Linux New Media, aptly described as the Pulse of Open Source.

Welcome to DrupalCon Barcelona - The Director's Cut

For all you schedule-challenged CEOs – and ADHD coders – this Abbreviated Official Director’s Cut is just what the doctor ordered.

Welcome to DrupalCon - The Barcelona Edition

Did we have fun in Barcelona?
OMG, yes!

Did we eat all the tapas on the menu and wash them down with pitchers of sangria?
Yes indeed!

Recursive Closures and How to Get Rid of Them

This came up while manipulating taxonomy children and their children recursively, so it’s as not far from Drupal as you’d think.