Ralf BürgerTidbits TOCPaR method
 
 

Processes as Requirements (PaR) - a methodical approach

PaR One-Pager

 
 

Did your processes become a heavyweight backpack to be carried by the projects, instead of a lightweight intrinsic approach that really helps the projects? This and more changes when processes are designed as requirements reused in the projects. Thereby also process platforms for product platforms can be established easier.

 
 
 
 

Abstract

 
 

Standards and processes should make up an exoskeleton that helps the projects to perform efficiently. Often the processes instead grow excessively, because they are designed by central departments that are acting far away from the projects. 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 standards and processes being rather extra effort than help, it is time again to transfer the essence >into the projects< efficiently.

Finally processes are just requirements "how" to do the "what". The latter ("what") often is given by a customer or platform as functional and technical product requirements. So why not defining the former ("how") also as requirements that can be reused in the projects and merged with the other requirements in the same developer tools?

So Processes as Requirements (PaR) to be reused into the projects, improved by the projects and synchronized back into the corporate standard 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 project phase, stage, Sprint, release, sample, feature, or however the development iterations or product increments are organized. The Process Requirements Sets should be prepared accordingly, and maybe also in variants, e.g. for small local projects, for large distributed projects, for projects with or without functional safety aspects. For >agile organizations< it may help to merge process requirements sets into the Epics, to combine "how" and "what", considering the Backlog collecting 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 and to inspect and adapt often. 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 are heavy-weight and static, like being defined once and forever.

Designing the processes as variable sets of requirements, that can be reused in the projects and thereby tailored as needed, passes back more responsibility and flexibility to the expert teams that engineer the products, giving them the opportunity to become more >self-organized<.

 
 

Which requirements to the process design should be satisfied when the processes are designed as requirements? ;-)

  • The process requirements sets shall be applicable in the projects as needed.
    Note: This can be achieved by arranging them as a >platform< of variable processes, becoming process variants when being reused in the projects. This is also commonly known as "process tailoring".
  • Duty and freestyle shall be separated while designing the structure of the process requirements sets.
    Note: "Duty" relates to e.g regulatory standards or basic customer regulations. "Freestyle" relates to e.g. own >best practices< improved from project to project. This separation can be achieved by designing multiple levels.
 
 
  • The design of the structure of the process requirements sets shall consider options and alternatives, to support different project situations.
    Note: This can be achieved by defining variation points for process requirements sets, to make the processes variable, e.g. to select Functional Safety level ASIL C instead of D, or to choose the corporate national organization regulations instead of the international ones, or contracting a supplier instead of doing the whole thing in the own company.
  • In a project the process requirements sets shall directly help the teams to satisfy the functional and technical product requirements.
    Note: This can be achieved by uniting "what" shall be created with "how" it shall be accomplished as an intrinsic approach, e.g. by holistic epics in a Product Backlog.
  • The abstraction levels of doing shall be clearly separated, focusing on the process levels, but enabling linking the operational levels.
    Note: This can be achieved by further separating "what" shall be accomplished from "how" it shall be performed. The focus shall be on the processes and sub-processes on higher levels, but linking the methods and principles, guidelines and templates, coaching and training from lower levels shall be considered.

how do what?

 
 

If we design processes as sets of requirements that we want to apply in the projects by reusing them to merge them with the product requirements, then we are talking about a >platform approach<. That means the processes are defined centrally, reused in projects and improved by feedback from those projects. While the processes are reused they are tailored. This means the projects select what they need, i.e. what really helps them or what is a must. Therefore the processes shall be defined in a variable fashion by defining variation points. Then the variability can be bound to variants by decisions (This means the projects select what they need, i.e. what ... ;-)

 
 

The diagram shown here is detailing the one shown in the abstract section at the top of this page. We see an example list of standards, in this case typical for automotive projects. We now also have added the Customer Standards Requirements to the Regulatory Standards Requirements. Both are a must and both are given - we can't tailor them in our company or even in our project.

The Corporate Standards Requirements are the typical processes that a company defines and that shall be compliant to the Regulatory and Customer Standards of the domain, in this case again for automotive projects. This often is called a PEP (Product Engineering Process), typically made up by phases, gates or samples. Automotive projects often deliver multiple samples of rising maturity during the engineering project. When the doing gets quite complex, then it is common practice to separate "what" should be done (the process) from "how" it should be done (the guidelines, or how-tos). The process may say that we need to define hardware-software-interfaces and guideline will say how to do it with the tool of choice. If dedicated work-products need to be created often, it is also a good idea to generalize them to templates that only need to be filled by the project.

We consider all this on the left side making up the platform, because it is done only once, and then often reused by the projects, applying it for a dedicated purpose and goal. The iteration needed for the development may be planned in different ways, maybe traditional in phases with milestones, maybe agile in Sprints with a Review event. The traditional approaches may focus on larger cycles like releases, while agile projects deliver more often and focus on the creation of features.

Design Processes as Sets of Requirements

 
 

And never forget the "Market Needs", because they describe how the world gets better by the product!
This makes up the real project purpose and scope that should always be in focus while discussing all the requirements.
For project success it is essential to understand the customer's business model, the company's domain and the product's market.

A Need tells us the problems to be solved with the product, "why" the product should exist. It is about business cases or use cases or environment or what someone wants - this makes stakeholder expectations explicit. Often the needs tell us more than the requirements, but least they help us to understand the requirements better.
A Requirement tells us "what" the product shall have or do to support the need. If you make a product as a service or as a supplier, you may mainly be faced with requirements and thereby are asked to do things you can not really fully understand. Requirements may be clustered to sets, to describe a whole product feature. Having a purpose-sentence for each feature (describing the need) may help to understand the requirements.
An Assumption by the project is a missing link in the requirements as long as it is not committed by the customer. Sometimes the team has to assume something to be able to go on. This should quickly be made explicit, because otherwise the customer may be surprised later on.

In the tools the Need and the Requirement should be something different (e.g. item types with different fields or attributes). An Assumption should rather be an attribute of a requirement, to be able to change it quickly when the customer accepts it to become a requirement. The attribute (or flag) could say "required by customer" or "assumed by project team". Requirements have lots of attributes anyway, maybe also to tag it as a stakeholder requirement (customer or management), a system requirement or a domain requirement (software, hardware, light, glass, etc.). You also may wish to separate functional (product specific) and non-functional (reusable standards) requirements, or technical requirements (rather constraints). All this is standard requirements engineering (RE) or requirements management and shall not be further discussed here, but always consider >variation points< in requirements.

 
 

Separating duty and freestyle ...
regulatory, customer and corporate ...
domains like automotive, avionic, medicare, ...
further corporate and department ...

Variable process requirements sets ...
binding variability to dedicated variant while applying (i.e. technically reusing) ...

Merging technical and functional product requirements with process requirements sets ...

Separating templates and guidelines from the process requirements sets ...
guidelines explaining ...
templates for output work products ...

In further detail market needs ...
and system vs. domain requirements ...
stack ...

Organizing the project ...
planning iterations (phases, stages, Sprints, releases, samples, features) ...
planning classical upfront or agile continuously ...

Continuous improvement by learning often ...

Design Processes as Sets of Requirements

 
 

...

Design Processes as Sets of Requirements

 
 

...

Design Processes as Sets of Requirements

 
 
 ↑