There's nothing that we enjoy more at Palantir than sharing our ideas with others. Out of sharing comes collaboration, and out of collaboration comes new ideas and sustainable practices, these are all things that Palantiri are passionate about.

At Palantir we are always looking at ways to improve. In 2008 it was about sustainability in theming, in 2009 we extended this practice into the engineering side, and in 2010 it's about applying transparency, sustainability, and standardization to our process.

The only way to standardize around a process is to take a long, hard, and honest look at what you've got already. We took some time evaluating our current tool set and began weeding out the old and inefficient tools and extended the strong ones.

We recognize that standardizing processes is not an easy thing to do, especially when you don't have the infrastructure to support the research or enough hands to discuss and document it correctly. Because of this we want to share our approach with you in hopes that you'll do the same in return.

We recently presented on this new process at DrupalCon San Francisco in our session The Magic of Teams: Communication & Collaboration.

The documents that we're sharing with you are intended to reach beyond just Drupal and Web development. They're meant to help set expectations with clients and in-house development teams as well as communicate our shared goals, and really can be used in many different ways on many different types of projects.

Our process is never set in stone, nor should it be. However, it should be documented and communicated to all the members of the team.

The documents provided below are only starting points. They are drafts with sample content that we hope inspire you to begin documenting and communicating your process to others. The documents are not meant to be literal representations of an ideal process, nor are they fixed in time. They should grow and change with each project.

Features List Draft

During the strategy and discovery phase of our projects we work with our clients to build a complete list of business requirements. We call this the "features" list. It is a very high-level listing of business requirements grouped by feature. It's intended to be a client-friendly document that we then design and architect from.

It's incredibly important that this document use language that can be understood by anyone, not just technical folks, or folks who know Drupal. It should capture all the key elements for a given feature.

• See the PDF version of the features list

After the features list is generated, we begin wireframing and design. This is our chance to hone in on the visual identity and tone for the site, while being informed by the features list. We don't finalize the business requirements until after the wireframes and designs have been reviewed and approved by the client. We anticipate addition and removal of changes during the wireframe and design period.

Task List Draft

Once the designs have been approved, we begin to dig deeper into the feature list. We build what we at Palantir call the "task" list. This list should be identical to the feature list, except that we move into greater detail, level of effort and build assumptions based on those requirements.

• See the PDF version of the task list

We also use the task list as an opportunity to educate the client on our architecting process. We try to include a glossary as well, to help people not familiar with our preferred tool (Drupal) be able to grok the context of the document.

Get All The Files

• Palantir's Process Docs in OmniOutliner format (.zip)
• Palantir's Process Docs in HTML format (.zip)

To use these files you'll need a copy of OmniOutliner.