Wellstone Action: A Drupal Process Case Study

Wellstone Action! is a national center for training and leadership development for the progressive movement. Founded in January 2003, Wellstone Action trains, educates, mobilizes and organizes a large network of progressive individuals and organizations.

The original Wellstone.org website was built using a proprietary CMS system. As the site aged and communications needs evolved, staff had to increasingly work around that system and its constraints. As such, part of the motivation for a new website was to not only present information clearly, but to do so in a way that was open to evolution and improvement over time, making Drupal an ideal fit for their needs.

Wellstone Action's Drupal-powered website launched in the Spring of 2008. With roughly a year of operating perspective, we can begin to assess the overall effectiveness of the project. Accordingly, this case-study is intended to:

1. Document the process used to manage this project and make decisions
2. Discuss the overall success of the project (and thereby evaluate the process)
3. Spark more conversation in the Drupal community about the best ways to produce the best possible results for all of our clients and their Drupal projects

Our Process - Some Background

Gorton Studios has been building websites since 2001 and some of us have been working on the web since 1995. Our first Drupal project was built in version 4.4 and Drupal became our definitive go-to CMS/Framework starting with version 4.7. In that time, we've seen a lot of projects, good, bad and otherwise, and we've had the opportunity to learn some things along the way.

Hopefully, therefore, we have some insights that can help others. And, just like the continuous improvement of Drupal is an incredible asset for the community, we can all probably benefit by improving the ways in which we employ Drupal so that our efforts generate the best possible results. In that spirit, we're sharing our process in the hopes that doing so might make us all just a bit better.

Judging 'Success'

The web remains a revolutionary, we've-just-scratched-the-surface medium with an incredible power that spans communications, commerce, community, processes, automation and much more. And, it can do that all with a speed and size-of-audience that surpasses anything yet experienced in human history.

All this power is a double-edged sword, however; with so much possible, it can be hard to focus on what's appropriate.

Simply stated, we believe a successful website ought to be one that accomplishes the goals of the organization it represents. A successful website ought to make communications, commerce, etc. as impactful and easy-to-manage as possible. Additionally, as organizations, technologies and circumstances continuously evolve, another key element of long-term success ought to be the ability of a website to grow and evolve in ways that aren't necessarily expected the day the site launches.

Enter Drupal

Happily, Drupal lives at that precise technological intersection - making it possible to do things quickly and effectively, and doing it in an incredibly modular, flexible manner that presumes continuous change and long-term improvement.

This is what we perceive to be one of the greatest underlying strengths of Drupal - the ability to turn over a vendor-neutral, standards-based system that can be extended far beyond it's initial vision with minimal time/hassle/costs.

A Drupal Process

We've developed the following basic process to help us create successful Drupal websites. This process can have additional steps depending on complexity of needs (e.g. the development of major custom functionality), but this process has served us well in the creation of 'standard' Drupal websites that use a mix of established core and contributed modules for a broad range of functionality.

Phase 1: Planning

If the success of a website is defined by it's ability to accomplish the goals of an organization, the first and foremost task of any web project must be understanding the client's short- and long-term needs and vision. Even (especially?) if you're building a website for yourself or your own organization, this phase is incredibly important.

For us, the planning phase is all about asking the right questions at the right time and building momentum. It starts by assessing big-picture goals and ends with the creation of wireframes. Those wireframes are then used in Phase 2: Design/Build - where the separate design and build teams, now well-grounded in the purpose of the organization, create an attractive, functional, effective website.

Step 1: Strategic Brief

Created By: Account Executive
Approved By: Client Account Contact

The first thing we do when starting a new project is to create a Strategic Brief, a short document that summarizes the reason for the project. It gives an overview of the client and answers the fundamental questions of what is motivating them to undertake this project.

This document helps keep everyone grounded. Over the course of every project there are new ideas and corresponding judgments to make. Referring back to the Strategic Brief is a good way to make sure we're paying attention to the things that the client has identified as important.

This step didn't exist as a formal written document at the point at which we started Wellstone Action, but if it had, the Strategic Brief would have looked something like:

Wellstone Action is a national center for training and leadership development for the progressive movement. Founded in January 2003, Wellstone Action’s mission is to honor the legacy of Paul and Sheila Wellstone by continuing their work through training, educating, mobilizing and organizing a network of progressive individuals and organizations. It's audiences include members, program alumni, people trained by the organization, donors and potential donors, individuals seeking training on grassroots organizing, advocates for specific causes and people who identify with the Progressive Movement and its causes.

Wellstone Action would like a new website to convey their vibrancy and energy and do so in an easily-navigated, easy-to-manage system. A new website must showcase Wellstone Action's content (e.g. events, trainings and news) and get visitors to critical content quickly. Because their audiences can be fragmented by particular causes and issues, the site must also try to cross-connect these audiences by exposing similar content and attempting to make connections between different groups. Moreover, the new site must be built in a manner that facilitates long-term flexibility and change, and may specifically include community and mapping features over the long-term.

Step 2: Kick-Off Meeting

Led By: Project Manager
Attended By: Client Stakeholders, Client Project Manager, Account Exec, Wireframe Lead (UX person)
Optionally Attended By: Prototype Lead (Developer/Configurer), Creative Lead (Designer/UX person)

Introducing the entire team to each other and generating a sense of anticipation/excitement is an important part of starting a project. This meeting recaps the project goals and briefly reviews the Strategic Brief. It's main function, however is to encourage client stakeholders to talk about their likes/dislikes with the current site, their hopes and fears for this project as well as what things are important to the different people/roles they represent. It is not unusual for this to be the first time that all client stakeholders are in the same meeting discussing these things in a focused way, and, as such, it can be very informative for everyone present.

In this meeting the Project Team should talk no more than 20 - 25% of the time. A successful Kick-Off Meeting will encourage dialogue among the key client stakeholders, get some agreement on priorities, discover new wrinkles in the project as well as to give everyone a chance to have input.

Another goal for this meeting should be to clearly establish the power of the respective Project Managers. The more complete and thorough this meeting is, the more stakeholders will be willing to trust (and appreciate) their respective Project Managers in their roles of organizing and synthesizing all feedback. This trust, if affirmed in the below Planning Phase deliverables, sets up a smooth overall project in which the Project Team is not asked to backtrack or defend decisions once momentum is built and the site is under active design and development.

Step 3: Competitive Analysis

Created By: Client Stakeholders, Client Project Manager
Reviewed By: Project Manager

Competitive Analysis is a well-established best practice in many types of projects, including building websites. This step asks Client Stakeholders look at similar sites and give structured feedback on the design, content, functionality and effectiveness of those sites. The purpose of this step is to learn from others who've attempted similar things as well as to give further insights into the needs and values of the client.

Step 4: Content Types

Created By: Project Manager
Reviewed By: Client Project Manager, Client Stakeholders

Establishing Content Types early is a Drupal-specific task that we've identified as an important part of our planning phase. Because we know that our site will be built around a core of CCK and Views, we start to catalog the different kinds of content that the site will consist of. This document serves as an ingredient list for for the wireframes that are the final product of the planning phase and a map to use when building the prototype site.

The following is an excerpt from the Content Types document created for Wellstone Action:

Program
A parent page for any training event.
Title, Header image (optional), Additional images (display in gallery form), Body, Related Audiences, Org (Action vs. Action Fund, optional), Related Content (audience, toolkit), Featured Alumni, Keyword tagging

Training Event
Appropriate for all training events and any other events you may have. Time will appear on single-day events, but not on multi-day.
Title, Location (not required / mapped if available), Date, Time, Featured Trainer(s), Org (Action vs. Action Fund, optional), Related Content (audience, program, blogs), Sign-Up URL (multiple)

Alum Profile
A way to highlight specific alumni. They will be random on refresh for each program.
Associated program, Picture, Pull quote (appears on teaser view), Story (appears when Read more is clicked)

Audience
A way to view content by “self-identifying” audiences, including:
Alumni, Campaign Workers, Candidates, Citizen Activists, Domestic and Sexual Violence Advocates, Fellows, Labor Organizers, Native American Leaders, Non-Profit Leaders, and Students.
Title, Body

Partners
This content type is used for partner organizations and partner features.
Organization Name, Organization Image (logo or pic), URL (link to org), Teaser, Body, Contact information, Address (for eventual mapping), Related Content (audience, program, toolkit), Keyword tagging

....

In addition to specifying all the different content types, this document also describes the types of content that will be shown on the homepage as well as the types of vocabularies (taxonomies) that will be used to describe, tag and sort content.

Step 5: Site Map

Created By: Project Manager, Wireframe Lead (UX person)
Approved By: Client Project Manager in consultation with Client Stakeholders

Site Maps are another tried-and-true part of planning websites and an important part of our process as well. The Site Maps we create are less graphical than many other examples. In particular, we deliberately don't draw page-boxes joined by lines as a good website will facilitate movement in many directions. Instead, the focus of this step is to finalize the hierarchical organization of the website, finalize the terminology to be used as well as to identify any other categorizing principles to be used.

In our experience, communicating linkages between content is best handled in Step 6: Wireframes:

Step 6: Wireframes

Created By: Wireframe Lead
Approved By: Client Project Manager in consultation with Client Stakeholders, Project Manager, Prototype Lead, Creative Lead

Wireframes are likewise a very well established practice in building websites. As the culmination of our planning phase, they are an especially critical part of our process. Wireframes are the foundation used by by both design and build teams as they simultaneously develop the look and functionality for the site.

In a very real sense, Wireframes define the website that will be built. They are deliberately presented without color and are only suggestive of layout. Good wireframes will present enough specificity to allow the build team (Developers) to start implementing the functionality necessary to support the website, as well as enough context to let the creative team (Designers) start to working on visuals.

Our wireframe documents typically include one wireframe for each distinct type of page layout that will exist. Depending on the needs of the client and complexity of the project, however, that rule-of-thumb can vary. For Wellstone Action, there were 21 different wireframe documents presented. And, even though many of these variations will become blocks, nodes and views controlled by site admins, we've found that presenting those variations helps both client and project team understand and account for all the different parameters that the site will include.

Phase 2: Design / Build

A central feature of our process is that both the Design and Build teams get to work simultaneously on their portions of the project. Both teams are asked to work towards the site that has been visualized in the wireframes and, when better ideas happen, to bring those back to the larger team for discussion.

Design and Build Simultaneously?

This is rather different than a process which does planning and design first, followed later by implementation. It's also quite different than the reverse - taking a site that's already been built but 'just' needs a new theme.

The biggest danger we've seen with either of those other variations (design-then-build or build-then-design) is that they can easily loose focus and start a downward spiral when changes are needed - and changes are always needed - especially when the site hasn't been visualized and explored first in a thoughtful process.

Those changes have the power to stop both design and build teams in their tracks while everyone tries to assess impact and implications. That, in turn, can effect budgets and schedules, which, in turn, can poison the overall success of a project very quickly.

Avoiding Trouble

Our solution is an emphasis on the big-picture goals that our initial Planning Phase provides. In a situation where we've been asked to 'just' design or 'just' build a site, we still like to start from the beginning. In our experience, it's important for both the teams designing and building the website (and making thousands of decisions along the way) to understand the big picture. If the client has done a good job in their planning, we may be able to zip right through the Planning Phase (e.g. by reviewing documents and holding a Kick-Off Meeting for clarifications). If, however, something is missing from the planning phase, going through the steps will identify and fix problems before they arise. Put another way - every time we've ever skipped a planning step, we've rediscovered why we thought it was important in the first place!

The Benefits of Working Together

Regardless of the negatives of design-then-build or build-then-design, we've found that there are great benefits to running a simultaneous design-and-build process. The design team can put together a great look without feeling boxed-in by a system (which often happens in build-then-design). At the same time as the design team is imagining visually, the build team is implementing the site. As such, they're the first people to actually experience it - and can give feedback on that experience as well as bubble up great ideas in time for the design team to react and propose elegant solutions.

This back-and-forth interplay allows something wonderful to happen - smart people who understand both systems and visuals are allowed to use their respective strengths to further the goals of the project. Having both groups anchored in the outcome of a thoughtful planning process keeps everyone on target, and the trust established in Phase 1 builds momentum in a great way.

And, perhaps best of all, we've found that running design and build can simultaneously decrease overall costs and timelines while improving overall results.

Design Track: Creative Brief

Created By: Creative Lead
Approved By: Client Project Manager in consultation with Client Stakeholders, Project Manager

The start of the design track is the production of the Creative Brief. This document is to the design what the Strategic Brief is to the entire project; a document used to set priorities and bring focus future discussions and decisions.

In particular, this document helps to align the upcoming review and critique of soon-to-be-created homepage design concepts. In that important meeting, there may be feedback which is very personal in nature ("I don't like X" or "I prefer Y"). Sometimes, that feedback can be very relevant, but sometimes it can also be difficult to deal with. With a Creative Brief to refer to, however, that conversation can become something like:

• Client: "I don't like X"
• Creative Lead or Project Manager: "That's interesting. What about X makes you feel that we're not meeting Key Objective Y?".
• Client: "Well, Key Objective Y is all about openness, and X just feels too crowded for me"
• [valuable conversation ensues]

We find these kinds of discussions are common in design meetings, and they're extremely valuable conversations to have. Being able to refer to a Creative Brief keeps everyone's focus on results, and, at the same time, can help clients articulate their ideas in a way that a Design Team can react to in a positive manner.

Design Track: Homepage Designs Concepts through Final Designs

Created By: Creative Lead
Approved By: Client Project Manager in consultation with Client Stakeholders, Project Manager

The design track follows what we believe to be relatively standard best practices in that it offers several options and then iteratively improves one of them until the client gives final approval. We present multiple designs concepts to the client, each of which is based on a different interpretation of the Wireframes and Creative Brief. In the case of Wellstone Action, three design concepts were presented.

Our initial design meeting is generally done in-person and feedback is gathered in the discussion of the different design concepts. If necessary, we occasionally include deliberately contrasting concepts in order to tease out a particular issue and/or determine the relative importance specific items.

The conversations in the initial design concept review meeting can be extremely valuable and should not be short-changed. We typically ask that clients allow for a 2 hour meeting, and parts of that meeting invariably involve a discussion like the one alluded to above. This meeting should also conclude with a decision on the direction to be taken (which design concept will we be iterating with in the next round) as well as a recap of the applicable feedback to be addressed in that next round.

The Design Team then takes that information and makes adjustments. The next design presentation we do also includes concepts for how internal pages will look. It is not uncommon for this second round of design to also be the final design iteration, but this depends almost entirely on how well the initial design review went and was conducted. Almost all of our projects have their designs finished by a third iteration; it's extremely unusual to have four (or more) rounds of design in this process.

Once finalized, the design source files are cleaned up and handed to the Build Team, who have by now finished the build of what we call the "Prototype" site.

Build Track: Prototype Build

Created By: Build Lead
Approved By: Project Manager (internal approval only)

The Build Track of the Design/Build phase starts immediately once the Wireframe Step of the Planning Phase is complete and final wireframes have been approved. In 'normal' Drupal sites which consist of a mix of core and contrib modules with 'normal' Drupal functionality like CMS, E-Commerce, Blogging, Communities, RSS, Voting, etc, the Build Team will have enough to immediately start on the site build.

The first step of our Build Process is to install a new instance of our base Drupal installation. That installation is kept in our subversion repository and includes:

• Drupal core
• The contributed modules we favor and use across most of our sites (e.g. biggies like CCK and Views as well as things we find ourselves using in almost every project, such as Pathauto, Webform, Devel, Backup and Migrate, etc.)
• A minimalist theme which implements a Yahoo YUI Reset and then reinstates basic Drupal layouts (e.g. tab styling) and adds simple black borders to blocks and regions.
• A Database snapshot containing our default configuration for core and contributed modules. In that snapshot, we have turned on common modules and configured things per our preferences.

Once we've checked out this core package, we import the base database using either the command line or a tool like phpMyAdmin. We then update the sites/default/settings.php file with appropriate database authentication information, and our base Drupal installation (which we call the 'Site Skeleton') is up and running. This whole process takes no more than 5 minutes and, as such, is relatively quick and painless. More importantly, however, is that by sharing a core set of modules across our clients' sites, we can update and apply patches once to that core and then easily deploy those improvements to client sites that reside on servers all over the internet.

We first created our Site Skeleton for Drupal 4.7.x and then recreated it for Drupal 5.x. In many ways, however, it is similar to what Acquia Drupal provides starting with Drupal 6. Likewise, our base theme predates the existence of the actual sub-theming provided in Drupal 6 and even such popular base themes as the Zen theme. Anyone considering adopting a setup like ours for Drupal 6 and beyond would do well to look at these and other existing options.

Once the Site Skeleton is installed, the build team starts rolling with what we call our Prototype Build. The Prototype Build starts with the creation of the content types mapped out in the planning phase. Once content types are in, we configure navigation and menus and add sample content for development and testing purposes. We also turn on and start to configure additional modules that the site will be using.

Another important part of the site Prototype is to start building the views necessary to support the site. That process starts with a careful review of the wireframe documents which are now a master set of annotated documents shared by both design and build teams. In our environment these are paper documents as we all work in the same physical space.

As part of our wireframe approval process is a thorough review with both design and build teams (done before wireframes are presented to the client), this isn't the first time our developers have seen these wireframes. There will have already been some discussion, for example, of the different kinds of content, teasers and views being called for and some discussion about those particulars. Those conversations also generally include some eye-rolling and fussing (at least they do around here) - some of which will have been forceful enough to have had an effect on the wireframes that were finalized and presented to the client in Step 6, Wireframes.

The build continues and different areas of the site have their supporting pieces built and configured. At some point the site will be functionally complete (or close to it). Once upon a time we would present this functional-but-not-pretty site to clients, but we've learned that exposing clients to an un-themed site - no matter how functional - is generally a scary experience for them - which is also why we describe this as our "Prototype" build - even though it is the actual site.

Build Track: Content Input

An important part of our Prototype build is adding actual content (as opposed to simplistic placeholder or Lorem Ipsum text). We like to hand-enter a representative sample of content, in realistically proportional amounts (e.g. at least five-to-ten items of each content-type, with more of the types of content that will be used heavily). Working with this actual content helps us verify our work, make improvements to workflows and get started on our training manuals.

• Verifying Design: A realistic mix of titles, words and images will often expose some weakness in the design of the site. It may, for example, become clear that the titles of events will need to be quite long in order to be intelligible - and that may effect the way events are styled when presented in teasers or lists.
• Verifying Build: Entering data the same way the the Site Admins will eventually do is a great way to make sure that our content types are supporting the right kinds of information
• Checking Workflows: Using a variety of roles and their differing workflows (if any) is an excellent way to work out any flaws in what has been built as well as to verify that any workflows that exist are both sensible and useful.
• Prepping User Manuals: This data entry process is also a great opportunity to get a start on the training manuals that are finalized later for our Training sessions. Doing actual user and admin tasks allows us to start taking screen shots and record the actual steps taken for particular tasks.

At some point, however, Content Migration becomes a real pain. Sometimes content comes from flat HTML files, sometimes from a database and, frequently, from a mix of several things. And, often times, a disjointed website will consist of disjointed and out-of-date communications which may need to be edited and/or deleted.

Every project is unique, but complete content/data migration can be a real pain and something you definitely need to plan for with any larger site. Options for data migration run the gamut from having actual human editors hand-manage the transfer to creating your own import/export tools to hiring data migration specialists like Cyrve to do it for you. Or, you could take a look at their newly-released (as of this writing) Migrate module.

In the case of Wellstone Action, we started down the path of custom import/export but discovered so much of the data needed editing that the client pared down the amount of content to be ported to only about 25% of what we had initially planned. In the end we had editors move about 500 - 1,000 pieces of content over to the new site and edit along the way as that was judged to be the least of all possible evils. (But it was still a bear. Yuck.)

Build Track: Custom Code

Depending on the needs of the project, there may be additional coding required. With such a vast array to choose from, writing a new module ought to be a very rare task; we generally feel that writing a patch against an existing module is a much more valuable way to spend your time/budget than creating yet another module. This being said, there are occasions where a project could benefit from some additional functionality that doesn't yet exist which can also be generalized and shared.

In the case of Wellstone Action, we knew that we were going to present videos in a Thickbox format and wanted to share those videos across multiple pages. The abstracted version of that idea was to grab snippets of HTML from a particular node and present them in a Thickbox compatible way - so ronan wrote a module called AHAH Fragment to do so.

Build Track: Theming

Theming is a well-discussed step in the building of any Drupal site, and there is a lot of wisdom out there on how to be better at it. The Drupal.org Theme Guide is a great universal resource, as are many of the Drupal books and blogs. There are a lot of exciting things happening in theming space right now, especially after some of the recent Drupalcon DC conversations (and blog posts) and it looks like that discussion is continuing in the Design for Drupal group.

On top of all those great resources, we also identify with Colleen Carroll's comments on the theming of one of Palantir's projects. In her post, she lists three main goals for theming:

1. Avoid using tpl.php files where ever possible.
2. Create default CSS styling and reuse as much as possible, "Theme" don't "Skin"
3. Leverage the Drupal admin everywhere [possible].

For goal #1, Drupal 6 implements theme preprocessing - an extremely valuable tool. As Wellstone.org was built in Drupal 5, it followed the techniques described by Matt Westgate of Lullabot for doing this kind of preprocessing in Drupal 5 (now a historical anecdote as the drop keeps moving).

In the case of Wellstone Action, these techniques allowed us to stay relatively clean and use only the standard 5 *.tpl.php files: block, box, comment, node and page.

On goal #2, we are of the opinion that markup ought to describe content, CSS ought to control presentation - and to the extent that Drupal already provides lots of descriptive consistent markup, smart CSS work can go a long, long ways. We also try to solve presentation-layer issues using CSS before using PHP to adjust the markup of your site. As a general principle, we first try to solve presentation issues with CSS and second via phptemplate_* functions.

Which brings us to goal #3. Absolutely everything that is a setting within a Drupal administrator's control ought to be used, respected and anticipated by your theme. You're site will be more effective if a site admin can update everything from labels to date formats and beyond. Drupal is powerful because it doesn't make unalterable assumptions - don't mess that up with your theme.

Shifting Definitions

Throughout the design/build phase, the wireframes gradually loose their importance as defining documents. In some ways, our wireframes can be thought of as Paper Prototypes (see also A List Apart's great article). As such, they are eventually superceded by the experience and definitions provided by the actual site. Although we often refer back to the wireframes and consider them to be important documents throughout this process, it's essential to allow good ideas to be implemented as the client, design and build teams move through the project in ever-increasing detail. In this way, the wireframes slowly recede in importance and are replaced by the actual site in a very organic manner.

Phase 3: Alpha to Launch

Once theming is largely complete, we're ready to show the site to the client. We call this themed, functional site the 'Alpha' deliverable, and all that should separate an Alpha site from the website that is eventually launched is the fact that we haven't spotted and fixed all the bugs problems issues opportunities yet.

The rest of these steps are really just about giving the client and ourselves the time to find and address any remaining issues, and, as such, are relatively straightforward and standard best practices in any web project.

Alpha User Acceptance Testing (UAT) and Feedback

The Alpha deliverable actually tends to be the highest-stress, highest-focus deliverable in our process. This will be the first time the client has unfettered access to all areas of the site, and therefore we place a lot of importance on getting things right. We always anticipate changes from Alpha, be we do want them to be as few and minimal as possible and work hard to make this deliverable a solid platform and experience. We also generally conduct our first user training sessions during Alpha as the publishing and editing experiences are essential components of effective website.

Beta Feedback and Launch

Once we've had a chance to address all Alpha feedback, we submit our Beta candidate for review and for the client to verify that everything has been done correctly. We also ask that no new pre-launch requests be added to the project at this time and handle any new requests by offering to address them in the days/weeks/months after launch (it is a modular, extensible Drupal website, after all).

Low Stress Launches

Our site launches are typically very low-stress days because of all the work and effort that goes into the previous deliverables (especially the Alpha deliverable). Aside from the other benefits mentioned above for combining design and development (better, faster results with greater longevity), another nice benefit is a relatively relaxed launch schedule. (In fact, it just so happens that today is a launch day for us, which is why I finally have the time to finish this case study.)

A different visualization of our process shows this energy curve:

While deadlines always add a certain amount of pressure, tension and excitement to our lives, we've found that our biggest internal freak-outs tend to surround the Alpha deliverable, not site launch. And, needless to say, everyone involved with a project likes a calm launch day.

Phase 4: Training and Support

Any useful website must change; the long-term success of a web project relies tremendously on the ability of the client organization to take effective control of their website.

Accordingly, another major emphasis of our process is structured training covering the details of site and content administration. We expect to empower our clients, and detailed training and training manuals are absolutely critical to making that happen. Depending on the roles and workflows involved in the site, we may hold several different kinds of training sessions and/or produce several different manuals. We have found that this not only helps our clients to succeed, it also reduces their long-term reliance on us and reduces associated support costs and needs.

After a site launches, we typically see a client contact us a few times in the weeks after after launch to ask how-to questions and clarifications. It's wonderful to be able to refer to a page in their training manual and then walk them through the steps they need to take to answer their question. It's not uncommon for that conversation to go something like the following:

• Client: "Hi, this is Mary with Organization X"
• Us: "Hi Mary! How are things?"
• Client: "Good, but I'm trying to do Y and I don't know how"
• Us: "No problem. Let me grab your training manual. Do you have yours already in hand? ... No? Ok - well, go ahead and get yours while I go over to the shelf and get our copy...
• [pause while we all grab manuals]
• Us: "Ok, it looks like that's on page 64. Let's go ahead and run through the steps together while I'm on the phone and make sure this works like it's supposed to."
• [task completed successfully, client confidence gained]

These interactions leave us all happy; the client is off and running and is less dependent on us, which leaves us with more time to do what we enjoy most - building great websites for great organizations!

But What About Success?

The success of any particular project isn't about the design spec, the technology stack or the process used to build it. All of those things ought to make success more probable, but true success is about facilitating the goals of the organization. We can talk all we want about process, but if process doesn't achieve great results, it's pointless.

That judgment is really in the hands of the client, and it isn't just about how a site works the day it launches (how could it be?). Accordingly, I asked the Communications Director for Wellstone Action to give her judgment on this project roughly one year after launch. Although we always strive to do great work, I was deeply honored by her response:

When Wellstone Action embarked on overhauling our website, we were a bit overwhelmed. We knew what our goals were, but we had no idea how to get there with web design. Gorton Studios stepped in and led us through an ideal process to determine our organizational needs, asking all the right questions so that they could get to know our goals for our organization, and for the website specifically - what audiences we wanted to reach, what stories we wanted to tell, and what was and wasn't working about our current site.

Gorton Studios went above and beyond the call of vendor duty to get to know our work and steep themselves in our organizational/brand identity. The result of this process was a top-notch site that gets consistently high praise from our Board, constituents, and peers in the field. Our Drupal-based site has helped immeasurably in reaching our goals -- raising our profile and gaining exposure through providing compelling, interesting content that is exposed on the site and easily shared. Gorton Studios as a firm has that rare quality of excelling at both aesthetic and data design -- both the look and feel of the site, as well as the database-driven infrastructure, have opened doors we didn't even know were possible in helping to position Wellstone Action as a national leader in our field and a source of best practices and valuable information. Since the launch of the site, Wellstone Action's profile has grown significantly, with media inquiries citing our blog as a source of information, peers referring to the site often, and excellent search engine rankings.

When I recommend Gorton Studios (which I do often!) I say that not only did the final product exceed our high expectations, but the process was an ideal vendor/partner relationship. The best part - I knew that Gorton Studios wanted to see us succeed, which made all the difference in navigating a process that can be overwhelming for many organizations.
__________________________________
Elana Wolowitz
Communications Director, Wellstone Action!

Success = Pass

If we measure success as how well we facilitate the goals of the client organization, we clearly did some things right in this process.

Continuing the Process Conversation

As a community, we have an incredible wealth of talent and an amazing willingness to work together and share our best ideas and efforts. In my own personal experience, however, I think we may have been slower to share the strategies and tactics we all use to ensure great project outcomes (than, say, the modules used to build a site).

I recently gave session on managing a Drupal process at Lullabot's Do It With Drupal conference (slides/video) as well as at Drupalcon DC (slides/video). Based on those experiences, I know there are a lot of other very talented, very experienced people with a lot of insights to share. I hope this case study helps us all share our insights and thereby makes us all just a bit better at what we do.

At the end of the Drupalcon DC presentation, the following venues for that conversation were discussed as good starting points:

• Share your comments here
• Blog your own process & insights
• Use groups.drupal.org/projectManagement for in-depth discussions
• Announce it all using #drupalprocess on twitter and the g.d.o. Project Management group

Thanks for reading - we welcome your insights, comments and questions!