Process documentation: way to innovations or a relic of the past?
I work for an IT start-up which is really fast-growing and fast-changing. We reinvent the processes really often and I always try to document it to keep everyone in a team on the same page: even if you are not a part of the process you still can understand how the things go on in a team, moreover it helps everyone to control the things they do and always know what should be done next. Also, it seems that formalized processes make organization less flexible (or agile if you want). What do you think: should you document the innovations you bring to the workflow and if yes then how it should be done?
Welcome to the ever changing startup world!
After doing 6 startups and in the process of co-founding my 7th, I understand about changing processes.
For customer facing processes, they need to be written, locked and everyone on the same page. That being stated, customer facing processes need to change to meet customer neeeds, especially just starting out. But any process touching a customer needs to be documented and communicated to all customer facing team members.
On the development side ( I have been CTO many times in companies large and small) processes need to be conistent and when they change communicated to all. Maybe not even written down, but being able to communicate to all team members affected by the process. Agile is key and communication drives agile.
If you are driving process, put into the tool, not a word document. By tool I mean, Slack, Jira, Pivotal Tracker, GitHub etc. they all have ways of building in process. Don't just put it on a piece of paper, may it part of interacting with the tool. Make it natural.
I think it starts with documenting and maintaining the Business Model (proces), because it clarifies to everyone what and how the business is run. The Business Model Canvas template is perfect for that. The next documentation layer would be the principles for every business area. For the crucial processes (like the customer facing James mentioned), do it more detailed.
There are two pieces of documentation that I often recommend: Design for Privacy in which is described how privacy data is collected and how it is managed and design for security in which the security principles are described.
I ran the corporate PMO for Disney technology for many years. While we weren't a startup, we would have in excess of 100 active projects at any time.
Instead of detailed process documents (we had agile, non-agile, and maintenance only projects) we decided to create a project framework that could apply to all projects. For example, the framework described how to on-board a project, the standard project phases and phase gates, and the mandatory deliverables required for all projects. Each specific project had some flexbility to customize their project details, but only to the extent that it didn't violate the principles of the framework. If the framework was violated, we would have lost our ability to manage that many projects.
The key to success, however, wasn't the framewok per se. The real success came from forming a cross functional framework design team that religiously monitored and managed the framework. It truly was a living organism that was owned by the whole organization.
There's a real art form to process design. How much process is enough is almost impossible for a single individual to accurately answer. To me as a the owner of the PMO, the only given was that "no process" was a bad answer. If you form a cross functional design team based on the important stakeholder organizations, that group will answer that question for you.