Cheeky Monkey Streamlines Workflow by Standardizing Documents

A few months ago, Cheeky Monkey Media’s development team met to identify current inefficiencies in our development processes. Around the room, from monkey to monkey, we shared the components of our current methods that we felt needed the most attention.

After our meeting, we split into three teams, each committed to solving one of the three areas that we felt caused the highest level of confusion, time wasted, and overall monkey dissatisfaction.

These were:

• Documentation

• Consistent Environments

• Repeatable Processes

Improving the Documentation Process

Our team, which included Amy Fink, a Project Manager; Gabriel Comeau, a Drupal Developer; Ryan Smylski, a Senior Drupal Developer; and myself, a Senior WordPress Developer, decided to tackle our app-itis and lack of standard process for storing and tracking information.

What is app-itis?

App-itis occurs when one has too many apps, which causes pieces of information to be distributed across multiple technologies.

Our objective?

To create a framework that would consolidate, on a per client basis, all the things a monkey would need to know about any particular project or website.

Our Process: How We Got to a Standardized Document

Step 1: Brainstorming

We started by getting a sense of our project’s scope.

Lucky for us, we had one of Cheeky Monkey’s project managers on our team. Amy possesses a strong ‘big-picture’ perspective of a project’s typical life cycle, from its inception to deployment to expected ongoing maintenance.

A passionate doodler, Amy took to the whiteboard and began mapping out the overarching processes from project start to project finish, highlighting common information holes and areas that have a tendency to be inefficient along the way.

Basically, this let us make notes about where in the process our co-workers took different approaches. For example, one of our sales guys might reach out to a project manager before they go on a call, another may do so after. Similarly, while one developer used one technology, another may use another.

We also noticed that not everyone was getting information in the same way. We noticed that in a number of different places along the project life cycle, staff were asking for information that we already had recorded … somewhere.

Step 2: Narrowing the Scope

Our brainstorming session showed us that there were a number of things we could tackle.

For example, while the two other teams were working on creating a consistent development environments and repeatable processes for development work, we knew the entire office would benefit from a map (or detailed overview) of the process that occurs from the when we first get a lead to when to project is completed.

However, when we sketched this process out, we realized that if we wanted to tackle the one issue that would make the biggest difference for Cheeky Monkey Media, we needed to make it easier for everyone in the office to find the information they needed, when they needed it, regardless of where they were in the project life cycle. Defining and optimizing the process would need to wait until the next sprint.

Thus, we narrowed the scope of the project to: creating a framework that would consolidate, on a per client basis, all the things a monkey would need to know about any particular project or website.

Step 3: Determining What Information Needed to Be Included

Once we knew that we needed to forge the “one document to rule them all,” we went around the office and asked our other team members what information they needed to complete their daily tasks. (Edge case or unexpected scenarios were also accounted for.)

For example:

• Developers needed to know details about which modules and plugins were used in each project.

• Marketing staff needed to have a clear sense of the business objectives and which version of Drupal projects used so that they could write comprehensive and results driven case studies.

• Account managers needed to know at what phase their client’s project was at so that they could follow up with the right questions and recommendations.

We also did an inventory of the documentation we already had.  

Step 4: Constructing the Master Document

Our main goal for this document was to ensure that it would be used by all monkeys at the company.

As such, we knew it had to be:

• Intuitive

• Easy to locate

• Adaptable

In addition, and perhaps most importantly, the document had to be something that all the monkeys—from frontend developers, to backend developers, to project managers, to sales people, to marketers—could find and use. What good is a super comprehensive document no one knows exists?

Storing the Document

Since the master document would ultimately store everything a monkey could possibly want to know about a client (or link to that information) we decided to save each client-master-information document in the client folder. Simple, yet effective.

The Document Itself

Based on our preliminary research, we couldn’t find a pre-built solution for our needs. So, our strategy was to build our own solution, because we still needed something better than having information scattered across our multiple apps & products.

To keep things simple (see the trend?) we made the document using Google Sheets—check it out here. Each client gets a templated version of the document that is filled out with their information, and is split into three categories of information:

• Client Information

• Site Information

• Project Information

Organizing the Document Information Categories

Organizing and presenting information within the different categories was a bit trickier. We spent a lot of time brainstorming (read: politely bickering back and forth) about the best ways to name and present this information.

We wanted to ensure that:

• New users could quickly adapt to the document’s structure

• The document was specific enough, but not too specific, and

• We could add and change information without having to re-create the entire document

Step Five: Testing and Iterations

The greatest challenges we faced were constructing the most logical and effective hierarchy of information (that is to say, determining what the most-used data was, and making sure it was presented first), and finding appropriate wording for the sections of the document to make sure it was intuitive as possible.

In order to get it right, we shared this document around the office and asked everyone to comment on it. Was there any information they felt was missing, or didn’t feel intuitive to them?

The ‘Final’ Product

At the end of the two week project, we had an easy to find and use document that included the following components:

• All the key company/organization information for our clients (names, contract info, kick-off call info, etc.)

• A specific place for capturing a web project's developing & testing URLs

• Source control management information

• Server access instructions and credentials

• Employees who have worked on the project, and when

• Front-end compiling methods used

• Basic server configuration data

• Any unusual setup requirements or ‘gotchas’

• An in-depth list of site features (expected and realized)

• A detailed list of modules worth paying particular attention to if they are leveraged for custom work, or are sensitive to updates

Final Thoughts

Although it’s taken a bit of effort to get all the monkeys trained to fill out and look for this document first, everyone agrees that life is much simpler now that we have a standardized document that holds all the relevant client information. We’re also happy that we only have to go searching in one spot to find all the information we could possibly want to know about a particular client’s project or website.