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.
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.
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.
The Definitive Guide to Agency Optimization
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.)
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:
Easy to locate
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:
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
The first iterations looked kind of like this:
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.
Wheewf! It feels good to streamline.
You may also like:
[MICROSITE] The Definitive Guide to Agency Optimization