PaR - Processes as RequirementsPaRamount
 
 

PaRamount explanation

 
 

(extracted from the introduction chapter of The Book)

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 functional and technical product requirements. So, why not defining the former ("how") also as what they are? As requirements that can be reused in projects and during work united with the product requirements in the same developer tool!

Defining the corporate standards in Processes as Requirements (PaR) that match regulatory standards and are reused in the projects, then improved by the projects and finally synchronized back to the corporate standards, is a smart and intrinsic approach. Furthermore, it is also beneficial for managements' money and for projects' efficiency.

Download as PDF

 (click to enlarge, see The Postcard in
"Downloadable" and "Purchasable")

 
 

The reuse 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 for different project sizes and types. This makes it a sophisticated process platform.

For agile organizations it may help to consider process requirements in the Epics, uniting "what" and "how" in the Backlog for all the "work to be done" as a holistic agile approach.

Uniting "what" and "how" long-term maybe even unites process and product platforms to become true holistic component models.