Why other solution fail as Team Operating Systems (like QMS)

All organizations and teams seek solutions to manage their knowledge and their work. But surprisingly nothing on the market actually works.

We have analyzed various systems for organizing knowledge, work, processes and quality. Here's a summary of our findings.  

Standard Solutions and their Shortcomings

1. Quality Systems
   QMSs are cumbersome and result in instructions, which are not part of the real work - which is similar to trainings
2. Project Management Systems
   PMSs attempt to split large work into its parts, to allow planning and also monitoring progress. Yet they contain no know-how as to how things get done. Administering these tools is also very time consuming, especially when teams work on vary diverse kinds of projects.
3. Task Systems
   Task systems help you remember what you should do and allow you to spread the tasks across various persons. But they also don't contain any knowledge and therefor only solve 1% of the real problem.
4. Wikis
   These are great tools to collect knowledge. Unfortunately, nobody looks at the wikis while working.
5. Checklists
   Checklists are very practical for simple procedures, but people tend to ignore them while working. They also don't scale when processes grow and need sub-processes.
6. Business Process Management Systems
   BPMs solutions and digital forms are often used for critical business processes. Yet they are some cumbersome to configure and maintain, that organizations only use them for very few processes - if at all. 

After a lot of research and testing we had to bite the bullet and start creating an own solution. But what was this solution going to be?

Team-Operating System: Requirements

When we started it became clear, that our solution would only become relevant, if it solves all of these aspects:

1. Knowledge Management
   ...especially expert knowledge, but also process knowledge.
2. Quality Management
   ...especially to ensure that intermediate work/products are always the same, which is critical for follow-up work which needs the initial state to be consistent.
3. Work Specification
   ...to ensure that the delegating person like a project manager will collect all necessary information before passing on the task to the team for execution.
4. Work Documentation
   ...to ensure that it's transparent who did what and when, and also what comments were added when problems appeared.
5. Process Management
   ...to ensure that things that depend on other things actually work, and that work-step-sequences are respected.
6. Task and State Management
   ...to ensure it's clear who does what, and that work can be passed around from specialist to specialist. To do this, the state of the task must always be preserved and clear. 

We believed that all this complexity must be super-simple - even trivial. Otherwise people tend to circumvent the system.

I'm sure you've seen that before: A "great" system is introduced - and a few months later it's not being used, and nobody noticed. 

So the tool had to be so good, that employees can only get their work done together with the tool, it had to become indispensable.

The parts of a real Team-OS

1. Simple checklists which preserve their state
   ...which list all steps to be done. We call these recipes.
2. A wiki-fashioned editing system
   ...so that all employees can manage the recipes themselves, and can take full responsibility as to their contents.
3. A chaining system
   ...which links recipes together. This is a requirement, so that partial processes can be their own recipes - which again is a requirement to ensure that instructions are not duplicated and start to vary.
4. A recipe catalog
   ...which stores all recipes, and allows simple search and maintenance.
5. A task system
   ...which copies recipe-templates and lets people actually work with the recipes, ticking off the steps as they go and preserving the state.
6. A digital forms system
   ...with form fields which are part of the recipes, so that task specs or results can easily be stored in the task in a structured way.  

Time to Build

So we decided, that it's time to build this Team-OS. You'll find the full story in our blog.

With love from Switzerland,
Daniel