Ralf BürgerTidbits TOCPaR
 
 

Processes as Requirements (PaR)

 
 

Did your processes become a heavyweight backpack to be carried by the projects, instead of a lightweight intrinsic approach that really helps the projects? It gets better when processes are designed as requirements that are reused in the projects. And this automatically also suggests establishing process platforms for product platforms.

 
 
 
 

Abstract

Standards and processes should be an exoskeleton that helps the teams to move safely and efficiently through the storms of the projects. Instead, often the processes grow excessively over time, e.g. because they are designed by central departments that are acting far away from the projects, only looking at the standards. Then the exoskeleton rather becomes a heavy backpack that the projects have to carry in addition to the customers' load. When your teams start considering processes being rather extra effort than help, it is time again to >listen to the projects' voice<.

Actually, standards and processes are just requirements saying "how" to do the "what" in a way of proven best practices. The latter ("what") often is given by a customer as product requirements. So why not defining the former ("how") also as what they are? Requirements, that can be reused in projects and merged with the other requirements in the same developer tool!

Defining the corporate standards as requirements that match regulatory standards and are reused in the projects, then improved by the projects and finally synchronized back to the corporate standards, looks like being a smart and intrinsic approach. This also eases >tailoring< of the processes by reusing, filtering and adapting dedicated process requirements sets.

The steps can be repeated for each phase, stage, Sprint, release, sample, feature or however the project iterations or product increments are organized. The process requirements should be prepared accordingly, and maybe also in variants, e.g. for small local or large distributed projects, or maybe for projects with or without functional safety aspects. For >agile organizations< it may help to merge process requirements into the Epics, combining "how" and "what" in the Backlog for all the "work to be done" as a holistic approach.

Design Processes as Sets of Requirements

 
 
 
 
 

Details

Nowadays we perform projects or even organize companies in an >agile fashion< to stay focused, to inspect and adapt often, and to enable teams to do the right things. We see innovations spreading faster, new products emerging in many variants, and windows of opportunities closing quicker than ever. On the other hand the processes to be applied in the projects often get more and more heavy-weight and frozen, like being defined once and forever.

In all complex organizations that engineer complicated products, but also in many industries and special domains we see projects struggling with the regulatory standards and the corporate processes that are to be applied. During my coaching of complex projects in recent years I discovered 5 challenges. They all can be addressed by changing the way to deal with bulky standards and processes. Bringing these deeply into the projects makes them feel more intrinsic and natural. I derived dedicated needs from those challenges and went further down to requirements to figure out a systematic methodology, finally based on the PaRis (PaR information system). Together with KoDeCs I successfully applied a similar and more basic approach during the past years at an automotive supplier and this was driving me to work it out more systematically.

I created the PaR approach to address these challenges. While most companies and tool vendors try to set up the requirements according to the regulatory standards and corporate processes I bring those standards and processes also into the requirements tool, because they are nothing else than requirements. When the requirements engineering tool is also used for managing change requests and reviews and testing (validation and verification) and maybe also risk management, then it becomes an even more holistic approach.

Finally it became an own web space with lots of material and a rising community behind it: >https://ProcessesasRequirements.info<.

 
 
 ↑