Klarity processes and user journey
This page describe the processes to be followed for the proper usage of Klarity.
Items
two types of items are subject to the validation process, the PCIV and its artefacts.
PCIV Validation
Each PCIV of a project has multiple versions articulated between three stages. The flow between the versions of a PCIV follows a process of validation which is described in this page.
Artefact validation
Each artefact can be validated by the team. Validating or rejecting an artefact contribute to the PCIV validation process as it provides insights to the PCIV responsible regarding the overall validity of the PCIV : A PCIV made up of artefacts that are all good, is probably valid itself. If the invalid artefacts are minor, he may consider correcting them in the next stage, or request a new scoping version to correct them without interrupting the current process. Finally, if certain essential artefactss do not meet expectations, he may simply refuse to validate the current PCIV and ask for the necessary corrections to be implemented.
Full process
Definitions
General Flow
Description
For any item (PCIV or its ArtefactGroup or an individual Artefact)
Comments (Capability) : User can comment the item as soon as it exists and is not read-only.
Proposal (Capability) : User can propose a validation or a rejection decision of the item. This user must be a responsible of the item, which means he holds the required capability. A proposal is made of two elements :
- A positive or negative decision
- A rationale explaining the proposed decision. The rationale is optional.
Review (Capability) : Users can review the proposal (the couple Decision + Rationale). This user must be a reviewer of the item, which means he holds the required capability. A review is made of two elements :
- An approval or disapproval of the proposal.
- A text explaining the review. Which is optional.
The review step is a configurable one and different rules might be applicable :
- A) Review are not expected.
- B) The reviews are just informative, the item responsible is free to take the decision he wants.
- C) The review step can require a quorum of review to be valid and allow a decision from the responsible. This quorum is also configurable :
- One person of each role has provided a review,
- Everyone has provided a review,
- A set amount/percentage of user has provided a review,
- A majority of approval reviews have been provided > automatic validation,
- A majority of disapproval reviews have been provided > automatic rejection.
- ...
The configuration is done in the PCIV configuration file, as explained here.
Decision (Capability) : User can decide to validate or reject the proposal. This user must be a responsible of the item and hold the required capability.
- If the proposal is rejected the status of the item does not change.
- If the proposal is approved, the associated decision is applied to the item.
- Validate : the item is validated. If the item was a PCIV, it goes read-only and a new version is requested depending on the stage. See versions for more details.
If the item was an Artefact Group or a Group, it only goes read-only. - Reject : the item is rejected. If the item was a PCIV, it goes read-only and a new version of the same stages is requested. The rationale associated to the propsal must be sufficiently explicit to provide the team with the orientations and work elements they need to produce a new version including the corrective elements.
If the item was an Artefact Group or a Group, it only goes read-only.
- Validate : the item is validated. If the item was a PCIV, it goes read-only and a new version is requested depending on the stage. See versions for more details.
The decision step is a configurable one and different rules might be applicable :
A) Validation or Rejection of the proposal is possible at anytime by the responsible.
B) Validation or Rejection of the proposal can only be done if the review step is valid.
- Decision can be contrary to the result of the quorum.
- Decision must be consistent with the quorum orientation.
- In any case, the review step must be configured so that rules define its validity otherwise, the decision step rule will switch to rule A : responsible can decide what he wants when he wants.
User with "Force Validation/Rejection" capability can force the decision he wants at anytime.
Process General Rules
- One proposal per item at the same time.
- One review per user per reviewable item.
- If a user post multiple reviews for the same item, the new review replace the previous one.
- The rejection of an item is only possible with the validation of a rejection proposal (which can be manual or automatic depending on configuration)
- Rejection of a validation proposal does not reject the item.
- The validation of an item is only possible with the validation of a validation proposal (which can be manual or automatic depending on configuration)
- Rejection of a rejection proposal does not validate the item.
Roles and Capabilities
Items hierarchy
There is a dependancy between the different items of a PCIV.
Example of a PCIV structure :
In this PCIV we have three Artefact Groups (A, B and C) Each Artefact group contains at least one Artefact.
Structure General Rules
1. The validation of a hierarchy level validate all the sub-levels :
- validating the PCIV will validate all the Artefact Group and therefore, all the artefacts.
- Validating the Artefact Group A will validate the artefacts 1A and 2A.
2. Validating all the leafs of a branch will validate the branch :
- e.g. validating artefacts 1A and 2A will validate artefact Group A.
- e.g. validating all artefacts will validate all Artefact group.
- Unless it is configured to be automatically validated, the PCIV must be manually validated/rejected by a responsible.
3. Each PCIV has at least one responsible defined by a validate capabiliity. It can be different for each stage.
4. Each Artefact Group has at least one responsible defined by a validate capability
5. Each artefact of inherit a responsible from its parent Artefact Group