Process Definition Reviews & Approvals
At some point, the outputs produced during Creation & Evolution of a Process Definition will mature. In due time, they become ready for review and approval. While the final word ultimately belongs to the Process Owner, it is important for other stakeholders to offer their input as well.
This step is necessary to validate that the resulting artifacts accurately depict the desired future-state, and to gain acceptance from key stakeholders. In effect, it establishes the goal posts for many Solution Definition and Solution Delivery activities which follow. In other words, it sets objectives which future actions seek to achieve.
Basically, this is the final action to define a Process. However, firms can also use the same guidelines below to review and validate interim, draft, or work-in-progress, materials. Of course, completed Definitions are never carved in stone. When appropriate, updates are OK. However, recognize that moving goal posts can affect all downstream efforts.
Specifically, each Process Definition includes: Level 0 - Level 3 Process Diagrams; a Process Detailing Matrix; and a Process Requirements Matrix. Accordingly, Teams should submit diagrams and matrices together, as a versioned set, for Review & Approval. As a result, people have items to reference when providing feedback, or developing related artifacts.
First Look at a Future State
To begin, recognize that all Process Definition outputs are living documents. That is, expect change over time, as the Business determines new, better, and/or alternative ways they choose to operate.
Therefore, Review & Approval achieves a point-in-time approval by appropriate Business representatives, and other relevant stakeholders, to define a fixed, target future-state. Afterwards, the approved future-state then sets objectives for later actions, such as Analysis & Design and Build, Test and Deploy.
As noted above, expect the future-state to change over time. However, manage later changes through appropriate Change Processes. Alternatively, stakeholders may re-execute the same actions which defined the Process in the first place. In other words, avoid allowing ad-hoc changes which tend to move goal posts.
Two-Step Approach
Generally, gaining stakeholder support and buy-in occurs in two cycles - first Review, then Approval. To clarify, conduct Reviews until the documents achieve a steady state. Thereafter, request Approvals.
Step 1 - Review
During Review, the Business Analyst makes Process Definition documents available to the participants in the table below. Afterwards, they ask each Reviewer to provide any edits, questions, comments, or concerns. Ideally, the Process Owner should be the person to solicit feedback. However, if the Process Owner chooses, the Business Analyst may solicit feedback on their behalf.
In general, Teams will incorporate feedback they receive, and/or note the result of the feedback, as appropriate. If this results in significant change, whether by volume or criticality, then it may warrant subsequent rounds of Review. Organizations should encourage any stakeholder who disagrees with how the Team addresses their input to discuss their concerns with the Process Owner.
Additionally, it is reasonable to include reviewers, beyond those who participated in Process Definition development and who appear below. For instance, implementation partners, executives, or other senior management. However, the list shows whose reviews are most relevant. Failure to obtain input from these stakeholders often leads to impediments and problems later on.
Furthermore, do not simply send the materials out (i.e., fire & forget). Instead, require that each of these individuals provide a response, even if that response is "no comment". Again, failure to obtain buy-in at this point is a good indication an organization is not ready to proceed with subsequent work. Much of which depends upon these results.
| Reviewer | Request |
|---|---|
Process Owner | |
Product / Solution Owner(s) | Review from a subsequent implementation and deployment perspective. For example, do the materials provide sufficient content with which to progress on to subsequent Analysis & Design tasks? Specifically, are the materials appropriate for identifying and defining increments of Business Value (i.e., Features) which the future Solution should support? Furthermore, were the right people, from the right organization(s), involved in creating the materials. That is, were groups that subsequent changes will impact involved at this stage? |
Business Analyst | Review from a business function perspective. In general, do the materials adequately identify and sequence the actions - Processes, Activities, Tasks and Steps - the Business plans to use in future-state operation? Is each action uniquely identified? Similarly, have appropriate business rules and key data values been identified? If there are any related Process Scenarios, then are valid representations based upon underlying defined Process(es)? |
Application Analyst / | Review from a technology perspective. To clarify, do the materials identify the application functions and components required to support the designed Processes? Similarly, have interactions between entities and/or systems been highlighted sufficiently to identify and describe integrations? Furthermore, do the materials provide sufficient context, content, and requirements to proceed with Analysis & Design activities of a subsequent implementation? |
Test Analyst | Review from a test and quality perspective. To explain, do the materials adequately convey the information needed for subsequent Quality Assurance and Change Management efforts. For instance, are all organizational units which the Process impacts identified? Similarly, are the roles within those units identified, along with the Tasks or Steps each is expected to perform? Additionally, are related responsibilities and/or requirements sufficiently described to ensure subsequent Analysis & Design should result in adequate detail to enable Test & Training design and development? |
Subject Matter Experts | Review from perspectives appropriate for their remit. In other words, is the defined Process both achievable and desirable? Have impediments to achieving the planned future-state been identified and captured? |
Architect (Enterprise or Solution) | Are the materials suitable for subsequent Solution Definition and Solution Delivery? Basically, have target technologies been identified, and/or have technology gaps been identified? Does the defined Process fit with other Processes and Solutions? Has the planned Solution been incorporated into the broader Solution Portfolio? |
Step 2 - Approve
To conclude, after reaching a steady state following Review and update, as described above, present the resulting Process Definition artifacts to the following Approvers.
Ideally, present and walk through the materials to allow for Q&A.  Again, seek formal, documented approval from each Approver. Even an email record is sufficient acknowledgement of their approval.
Of course, if there are qualifications, record them. If the documents require more change, then resume the Process Definition activities until adequate changes have been made. Afterwards, return to this Review process as described above and then return for Approval once complete.
| Approver | Request |
|---|---|
Enterprise Executive / | Acknowledge whether they are willing to sponsor and support the changes the Process Definition artifacts describe or not. State whether they will help drive those changes within their affected organizational unit(s). |
Process Owner | Assess whether the materials adequately describe the desired future state of how the Business would like to operate or not. |
Product Manager | Evaluate whether the materials are sufficient to proceed into Solution design efforts or not. |
Product Owner(s) | Acknowledge whether the materials are sufficient for identifying target business objectives or not. |
Architect (Enterprise or Solution) | Assess whether the materials describe a future-state suitable for, and in alignment with, other related initiatives or not. |
Finally, there are times when another perspective can help facilitate discussions or communicate content. In these cases, look to Process Scenarios. Scenarios can augment, but not replace BPDs.