|
|
The Splashes
|
|
|
Click on the images of the splashes to make them becoming waves ;-)
|
|
|
|
|
|
Intro
|
Compliance
|
Platforms
|
|
|
|
Processes should be an exoskeleton that helps the team to move safely and efficiently through the storms
of the project. When your processes rather become a heavy backpack that a project must carry in addition,
then designing the "Processes as Requirements" (PaR) may be your solution.
|
When you design Processes as Requirements (PaR), compliance can be continuously monitored by bi-directional
traceability, using the standard features of your Requirements Engineering tool. This simplifies or even
saves audits and assessments.
|
When you design Processes as Requirements (PaR), variability management can create a process platform from
these process requirements, just like the product requirements of your product platform. The projects apply
both in a united fashion, solving an old problem of project planners also.
|
|
|
|
|
|
|
|
|
|
Agile
|
Teams
|
SWOT
|
|
|
|
When you design Processes as Requirements (PaR), uniting "what" and "how" on a feature or
component level makes good Epics for the Backlogs of scaled agile approaches.
|
When you design Processes as Requirements (PaR), you can organize in teams that really work together.
While the teams focus on their objective the members can switch from team to team to work in a
cross-functional fashion.
|
When you design Processes as Requirements (PaR), you should know the good benefits that you get
and the few risks that you take!
|
|
|
|
|
|
|
|
|