PaR - Processes as Requirements

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!