Why Stages is different

NOTATION FOR KNOWLEDGE WORK

Stages adopts what we consider general best practices from BPMN:

• Modeling process activities in swimlane diagrams with the lanes representing different responsibilities or systems
• Support for process hierarchies of arbitrary depth via subprocesses
• Data objects to represent process results
• Conditional process flows via decisions and gateways

Knowledge work extensions for BPMN have been proposed several times, but none of them was ever adopted.

Stages implements the following concepts we consider critical for knowledge work processes, but are missing from BPMN:

• Value streams to capture the high-level outcomes and work products during value creation
• Guidance (practices, work instructions, tool descriptions, etc.) to describe not only WHAT needs to be done, but HOW it should be done
• Mappings to reference models and standards describing WHY certain activities need to be executed
• Roles and teams plus their required skills that are responsible, accountable, supporting, to be informed, or to be consulted in activities of a process (RASIC or RACI)
• Metrics and work product quality levels to express and measure the progress of a process and determine if its outcomes were achieved
• SIPOC (supplier, inputs, process, outputs, customer) tables to describe the interfaces and dependencies between different processes
• Lifecycles modeled as phases and milestones to express execution timing and program progress across multiple functions, disciplines, and processes
• Entry and exit criteria describing the conditions for the start or conclusion of processes, which is especially important for agile and other highly iterative processes
• Templates, checklists, and examples to increase the quality of process outputs and work products

FEATURES FOR KNOWLEDGE WORK

With their inherent characteristic that “process diagrams are the process”, typical BPMN-based tools lack capabilities which truly model-based tools like Stages can offer.

Multiple perspectives: instead of just showing a static diagram, Stages can automatically visualize the process from different perspectives. For example, Stages can display all processes where a specific role is involved, or show all work products relevant for a specific milestone across multiple process disciplines. Different users need different levels of detail. Experienced users need less process details than newbies, but they need to get quickly to the information important for them.

Variance: every development program or project is different, so the execution teams should be able to derive their specific processes from a set of standard process templates and tailor them to their needs, ideally guided by rules and constraints. The resulting project-specific processes need to be version-controlled and further adjustable by detailed tailoring. Even if this level of specificity is not applicable, standard product development processes typically have several variants, e.g. if products are critical regarding functional safety and cybersecurity or not.

Compliance: almost all non-trivial products are subject to standards and regulations, not only for the resulting product, but also the process of how it was designed and developed. All requirements of a multitude of standards and regulations need to be traceable to activities, work products, and other elements of a process. This allows gap analyses on the project’s defined processes to make sure that all regulations are still being followed, even after tailoring the process.