Approval Status for Requirements, and other Project Artifacts

Like most Business Analysts, I’m typically not the audience for the different artifacts I create, so I don’t get to decide when what I’m working on is done, or “good enough” for use.  To mange the approval of the artifacts that I create, I’ve found that I use 8 main Status “states”, and 3 alternate Status states, and I’m using the term “artifact” to indicate: a requirement, model element, diagram, document, applications, systems etc.

Typical Status states that I use, and the order I use them in:

  1. New: A project member currently working on the artifact, it is not ready for review.
  2. Draft: A project member has documented an artifact that they want their peers to review, before it is proposed to the rest of the project team.   This is typically used when someone is still being trained and their work needs to be peer reviewed before it is shared with the rest of the project team.
  3. Proposed: The group who authored/created the artifact believes it is ready for review by one or more Subject Matter Experts (SMEs) (alternate: defective).
  4. Verified: The SMEs from the previous step have confirmed that the artifact is complete and accurate (alternate: defective).   The artifact is now ready to be reviewed by the project sponsor(s).
  5. Validated: The project sponsors have confirmed that the artifact is relevant to the project (in scope).  The information is now ready to be formally reviewed by the target audience.   E.g. if this is a requirement for an IM/IT solution, the IM/IT solution provider is the target audience.  (alternates: rejected, defective)
  6. Accepted: The artefact has been reviewed by the target audience, and they confirm they understand what to do with the information. (alternates: parked, rejected, defective)
  7. In-use: There are now other artifacts that are dependent of the artifact that was accepted in the last step.  The artifact is now formally under change management.
  8. Deprecated: The artifact is in-use, but is either in the process of being replaced, or will be retired without a replacement.  Any artifact dependent on this artifact must be migrated to remove the dependency, or move the dependency to the artifacts replacement.
  9. Retired/Replaced: The artifact is no longer used.
    • Retired: There is no replacement
    • Replaced: There is a replacement, and if I can, I update the artifacts metadata to reference the artifact(s) it was replaced by, and include in the replacement artifact(s) metadata which artifact(s) they replaced.

The Alternate Status states:

  • Defective: There is an error in the information that needs to be corrected, this can occur at any time.
  • Rejected: The artifact is not relevant to this project/architecture.  I typically keep the rejected artifacts in my model with notes explaining why each was rejected, this ensures that everyone knows something wasn’t “missed”, it was instead considered, and found unnecessary.
  • Parked: The artifact may be relevant to the project, but the sponsors are unsure and need to consult further before deciding.

A real world example of how to use these Status States:

By the Business Analysis Team

  1. New: A Business Analysis Trainee has reviewed some existing documentation and met with some Subject Matter Experts SMEs for a brainstorming session, and based on their notes creates a list of possible Business Scenarios, Stakeholder Requirement Statements and Business rules (the initial BA Artifacts).  They set the Status state as “New” for each of these BA Artifacts.
  2. Proposed: The Trainee’s coach/mentor reviews these “New” BA Artifacts, and finds that some aren’t clear, so changes their Status to “Defective”, but thinks the other BA Artifacts are clear enough to proceed, and updates their Status to “Proposed”.  (Alternate: The Trainee will either correct the “Defective” BA Artifacts, and then update their status back to “New”, or will delete them)
  3. Verified: A Business Analyst discusses the “Proposed” BA Artifacts with the SMEs.  The SMEs don’t agree that with the wording of some of the BA Artifacts, but cannot provided immediate clarification, so ask for a separate meeting to discuss further, the disputed BA Artifacts are updated to “Defective”, and the remaining BA Artifacts are updated to “Verified”.  (Alternate: The “Defective” BA Artifacts are either deleted or corrected then updated to “New” or “Proposed” depending on who is doing the corrections.)
  4. Validated: A BA and optionally a SME representative present the “Verified” BA Artifacts to the Project Sponsors.  The Project Sponsors do not believe that some of identified business scenarios are relevant to the project, these are updated to “Rejected”, additionally 2 of the Stakeholder Requirements are associated with activities that are being outsourced, so may or may not be within scope .  These 2 Stakeholder Requirements are updated to “Parked”,  one of the stated Business Rules references an out of date standard, that is has just been replaced, the affected business rule is updated to “Defective”, the remaining stakeholder requirements and business rules are updated to “Validated”(Alternate: The “Defective” BA Artifacts are either deleted or corrected then updated to “New” or “Proposed” depending on who is doing the corrections.  The “Rejected” BA Artifacts are either archived, or strengthened with more information and updated to “New”, “Proposed”, or “Verified” depending on who was involved in adding the additional information.   I always keep the “Rejected” BA Artifacts along with the rational for their rejection, this often prevents the same arguments for re-occurring)
  5. Accepted: A BA and optionally a SME representative present the “Validated” BA Artifacts to the IM/IT solutions providers.    The IM/IT solution providers do not understand some of the scenarios, and stakeholder requirements and ask for more information, these BA Artifacts are updated to “Defective”, one of the Business Scenarios involves clients working in remote locations with no internet access, the IM/IT solution do not have a product that supports that scenario, it is updated to “Rejected”, the remaining BA Artifacts are updated to “Accepted”.
  6. In Use: The IM/IT solution providers begin working on designs based on some of the BA BA Artifacts, the referenced BA BA Artifacts are updated to “In-Use”.
  7. Deprecated: Due to a new government regulation one of the Business Rules will need to be modified in 6 months, the Business Rule is updated to “Deprecated”.   The tractability chain(s) from the Business Rule are analyzed to determine the overall impact of the Rule change.
  8. Replaced: All the BA Artifacts that were dependent on the Business Rule have been updated, so the Business Rule can be updated to “Replaced”, and it’s “replaced by” property is updated to reference the new Business Rule.

By the IM/IT Solution Design Team

Essentially an identical flow to the Business Analysis Example, but the Audience for changes.

  1. New: A IM/IT Solution Designer Trainee has reviewed the Business Analysis artifacts, and information on technical constraints and based on these source artifacts, the Trainee proposes several Design Artifacts.  They set the Status state as “New” for each of these Design Artifacts, and document how these “New” Design Artifacts trace from the source artifacts.
  2. Proposed: The Trainee’s coach/mentor reviews these “New” Design Artifacts, and finds that some aren’t clear, so changes their Status to “Defective”, but thinks the other Design Artifacts are clear enough to proceed, and updates their Status to “Proposed”, for one of the Design Artifacts, the Trainee coach does not thing the Design is appropriate for this project buy might be useful to another project, that Design Artifact is updated to “Parked”.  (Alternate: The Trainee will either correct the “Defective” Design Artifacts, and then update their status back to “New”, or will delete/archive them)
  3. Verified: A Designer discusses the “Proposed” artifacts with the Business Analyst and/or the SMEs.  The BA/SMEs on reviewing the traceability information determine that some of the proposed Design Artifacts do not seem to address the requirements they are intended to support.  For most, the only issue was terminology, these Design Artifacts are updated to “Defective”, and the Glossary is also updated to “Defective”, with a note to add the missing terms.  The remaining Design Artifacts seem to address the requirements correctly and are updated to “Verified”  (Alternate: The “Defective” Design Artifacts are either deleted or corrected then updated to “New” or “Proposed” depending on who is doing the corrections, the referenced “Defective” BA Artifacts are either deleted, corrected, deprecated, or retired/replaced)
  4. Validated: A Designer discusses the “Verified” Design Artifacts with the Development Team (typically several options) to ensure that the design is “implementable” from an IM/IT perspective.
  5. Accepted: A Designer discusses the “Validated”  Design Artifacts with the Project Sponsor (typically several options) to ensure that the design is “implementable” from an Organizational perspective (cost, resources, timeline etc.)
  6. In-Use: Development work has started based on the Design Artifact….
  7. Deprecated: Due to an IT change a Design Artifact can no longer be used, and will not be Replaced.
  8. Replaced: All the Development Artifacts that were dependent on the Design Artifact have been updated, so the Design Artifact can be updated to “Retired”.

So far I’ve found that the same Status States can be used for any Artifact for any of the project teams.

Once I have time, I’ll update this entry to include BPMN diagrams of these two examples.

I’d love to hear more of what others have found that worked or didn’t work for them.

Leave a Reply

Your email address will not be published. Required fields are marked *