Walter Street

Process Reform and Documentation Effort


My office has worked in flash for 10+ years. All of our legacy projects, apart from websites, were built in flash. Knowing Flash was also a requirement for getting hired.

I joined in 2013, and within a year of me joining my manager wanted us to get off of flash now that our internal browsers supported HTML5 and CSS3. We started the transition, got a couple of projects out the door with an ad hoc process. At the same time, some of the internal processes had also changed. Everything was very siloed and disjointed. Nothing was documented and all content was in the brains of individual people. This was very hard for new employees, and employees who had gone on rotation and had come back, to on-board to the new process.


After a few months of a process with no shared documentation, I proposed to my managers that we take the office “offline” for a period of time to review and document all our processes and business elements. My managers agreed to my proposal, and gave us 2 weeks to complete the task.


With the go-ahead, I developed our gameplan:

  • Each area of focus would be assigned a team of roughly 2 to 3 people.

  • Teams would be taken “offline” on a staggered timeline so that the entire office would not be off.

  • Each team would review their topic, document the current status/workflow, and create new documentation where needed.

  • When finished, the teams would swap their documentation with another team for review.

  • All final documentation would be posted to our Github, and eventually moved to our team handbook website.



The teams were split into each area of focus. Below are the deliverables of each team:

  • Interactives, for our office, are lightweight web apps that tell an analytic story on world topics and issues.

  • Outline full process for our interactive development process, include project generation, development tips, and final file creation.

  • Lay out the process checklist for all project types.

  • Provide tips for development process, Webpack/Gulp actions, how to install plugins, update boilerplates.

  • Provide guide for tablet development and testing for all tablets.   

  • Outline the timeline and checklist for publishing products on all platforms.

  • Provide email aliases and guides for individual product product review teams.

  • Establish and define tablet security standards.

  • Create tablet usage guide.

  • Define mission for iMac network. Establish which computers will be used for what.

  • Establish administrative team for network and their responsibilities.

  • Outline full process for our website development process and delivery.

  • Define post-launch support guidelines and rules.


Here is an example of one of the documentations teams results:

Old Publication Process

  • First users must determine what platform the product is being published on. If it is Platform A it needs to be finalized in a certain way, same is true for Platform B. If it is both then it needs to be finalized twice.

  • Send for review per platform and iterate based on feedback.

  • Complete scattered miscellaneous tasks required for publishing.   

  • Once finalized, the correct file must be upload in the correct folder. If not then the wrong file could be published.

  • Along with this the mobile version of the project must also be uploaded to the correct platform’s folder/location.

  • Once uploaded, an email needs to be sent to the publication teams for the corresponding platforms.

  • The email needs to have a certain set of people cc’d on it.

  • If all is done correctly, then the project should be published and work correctly.

New Publication Process

  • Send for review per platform and iterate based on feedback.

  • The project is finalized with one file needed to be created. That file is then used to create the mobile version of the product used on any tablet that need it.

  • Follow provided checklist to complete miscellaneous tasks required for publishing.

  • Upload finalized files.

    • No matter which platform the product is being published on the files will be uploaded to the same location.

  • Use checklist to auto-generate publishing email.

  • Once the email is sent the project will be published on the next day.


Our two-week documentation and process reform was a huge success. We were able to document all our business practices and processes. The strategic plan I developed allowed for everyone to be involved in a certain aspect. Even after we finished people continued to be involved on their teams; addressing any issues or changes that come up, or staying on as administrators for networks and tablets. We also now have a defined location for our documentation, our office handbook. The handbook is a wiki-like site with guides and tutorials on just about any topic that comes up in the office. It also serves as a resource for new team members to get on board with what they need to know to do their work. Due to security constraints I am unable to link to the Handbook, but am able to talk more about the process in person.