When we refer to “mission-critical processes,” we typically describe the essential services required to go about your day-to-day operations. If a particular operation cannot be interrupted without affecting production, it is considered mission-critical.
About 30 years ago, the technology that supported mission-critical processes was a lot simpler than it is today. Data centers have grown from a few mainframes supporting minimal software applications to servers occupying over 100,000 feet.
As more processing power is required to sustain a business, the systems supporting the business become increasingly complex. That is why it is so essential to explicitly draw out your mission-critical processes with a living document that provides the level of specification necessary to keep fires at arm’s length.
This living document needs to remain up-to-date each time a project or goal is reached. The benefit of this document is immeasurable. The greater the investment in its creation and maintenance, the more stability your organization will have. You lose employees, you hire new employees, and systems break or decline—all of this should be explicitly outlined so that you’re saving time, money and headaches.
You might think, OK I understand that I need this but where do I start? I’ve outlined a few specific documents that every business should be sure to document.
1. Decision documentation
Every critical decision in regards to design and architecture that the team has made throughout development of the company should be summarized and updated to explain why the team reached such a decision. This will be the most helpful for developers.
2. Vision statement
Senior management will find this most helpful, as it defines the vision of the organization and should include a summary of the current cost estimates, staffing estimates and scheduled milestones.
3. Operations documentation
This will contain everything from the requirements of your system, troubleshooting guidelines, references to backup processes and how to navigate through potential technical or operations problems.
4. Requirements document
This document will almost come out as a manual for developers, users and managers. It will define what the system does and its requirements such as user stories or terms and definitions.
5. Support document
A support document will provide training materials that could serve as a handbook to support staff as well as user documentation to be used as a reference when troubleshooting and solving problems. It should also provide an updated list of contact info for the maintenance team.
6. User documentation
Even the most technically savvy users might still need to reference a manual, usage guide or training materials. These different documents would all fall into this category to help new employees get acclimated with your system.
While I’d love to say that these are the only documents that you should keep on record, this is only surface level. The more complex a system, the more documentation will be needed. It’s best to start with the vision, the why, and then get into the specifics.
If you’re still unsure of where to start, let All Systems Grow’s passion for processes organize your data. We have years of experience on how to develop effective systems and policies for those systems. Contact us today to learn more.
