pan·de·mo·ni·um /ˌpændəˈmoʊniəm/ noun 1. Wild uproar or unrestrained disorder, tumult or chaos.[1] 2. The initial phase of a Drupal project that is not self-contained[2]
Project Management
Project management is the use of techniques, policies and procedures to optimize the likelihood of completing a project with the agreed scope, on-time, and within budget. Though it is, to some, akin to the Tax Code (too much overhead with little gain), 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 you)
- Time - the time available to perform the work, measured in person-hours when defining effort (two people working eight hours is 16 person-hours), or elapsed time for calendar time (working eight hours and then waiting two days is 56 hours of elapsed time)
- Quality - objective, but can mean more than ‘really great,’ such as needing to reach a level of certification
- Budget - the bottom line for any freelancer not doing pro bono work
These factors are linked: changing one affects the others. If the time needs to be shortened, more resources will be used, resulting in a higher cost. So, at least one of the factors needs to be variable.
The project manager is responsible for the project plan, showing the tasks required to be completed, the resources and time necessary for each, and their dependencies, which are very important for keeping the project on track. Task 2 might not be able to begin until task 1 completes, or perhaps can begin so long as task 1 has already begun. If there is only one person available for configuration and there are 20 hours-worth of configuration tasks, each will likely have to occur serially. Once laid out, a path through the tasks that cannot slip without causing the entire project to slip can be identified: the critical path.
Then the project manager needs to assess risk; the ‘red flags.’ Some examples of risk are the project sponsor not having the authority to obtain resources, manipulate their priorities, or make decisions regarding scope, the project manager not having authority over the project resources, and a project that has a hard end date but not the assured availability of key resources. A risk assessment can result in factors needing adjustment (scope, budget, etc.), and sometimes the project being scrubbed.
A Drupal project can often be a red flag akin to pandemonium. Here’s an example:
A company has historically run a Java shop. Somehow, into the mix has come a Drupal site created by a third party, no longer available. The company wants a similar site for another brand, and wants both sites constructed same way to reduce maintenance costs. To a Drupaler 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 any Drupal site) will be nigh on 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 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 know.
Development
“You want to use which 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, but in a project where resources like IT, QA, network folks, and SME’s (subject-matter experts) will need to be plugged in, “We do a bunch of coding and see where we are at a certain point, and then do it again,” or your best correct-speak version, will likely produce a ring around the conference room of dropped jaws sans a warm and fuzzy feeling.
Deployment
How are you going to take 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. These things, 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 a long, long way away from being something that can be documented as a process.
I don’t dislike Drupal, really. Cut me and I drip blue droplets in search of botsnacks. I’m simply pragmatic…some call it curmudgeonly. You cannot take an organization used to the conventional way with measures and methods that better their chances of doing them profitably, and say, “Excuse me guys, can you move over and let us do our thing?” So, what’s the answer? I have two proposals:
I call for a Drupal standard for a site blueprint. I should be able to look at the blueprint and know that this field comes from that view, while the other field comes from a hook_node_view implementation with some template hijinks.
Second, I offer up the Whitewater method. 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 the conventional project controls. Rapids represent the critical path; the fastest route to completion (hopefully with you still afloat), and eddies are the spirals of agile development sprints occurring between waterfalls.
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.
