In a previous series of posts we took a look at drawing workflows. However, before you draw a workflow, you really have to understand the underlying business process.
Remember that our definition of a workflow referred specifically to the identified work object. This is because the workflow does not cover the entire business process but only those steps that directly affect the work object.
In this series of posts, we shall take a look at a Change Control process, taking from the As Is process, through the To Be process to the workflow. As you will see, not all the steps in the To Be process will make it into the workflow and by the end of these posts, you will see why.
The As Is Process
Let us imagine the customer has provided us with a document detailing their current Change Control Process. You can download the document here and see the process model here, but for your convenience I have provided you below (in green text) with an overview of the process that you might glean from interviews or workshops.
As the customer did not provide us with a high level version of the As Is process model, we draw one ourselves. High level process models can be useful in letting us see clearly what the various stages of the process are without getting bogged down in the steps within those stages. What’s more, having a high level To Be model can help us plan our workshops and interviews by process stage. Click here to see our high level As Is model. Notice that we have started using blue connectors to indicate what the customer considers to be the primary path through the flow.
In Part 2, we shall take a look at some of the problems the customer might be experiencing with this process.
If you want to see only the posts in this series, select the category Process Exercise.
Starting the Process
When someone identifies a need for a change to a baselined product (be it live software or a Project document), they are supposed to fill out a Change Request (CR), marking it “Urgent” if needs be, and e-mail it to the designated Change Manager. The Change Manager then logs the details of the CR on a MySQL database using a web interface and sends an e-mail acknowledgement back to the Requestor.
Selecting Evaluators
Assuming the CR was not marked “Urgent”, the Change Manager decides who needs to evaluate the CR for impact (e.g., for a change in requirement, the Project Manager, analysts, architects, developers and testers may all need to evaluate the CR) and e-mails a copy of the CR to all Evaluators. Each Evaluator evaluates the impact of the requested change in business hours and e-mails the evaluation back to the Change Manager, who then updates the CR with the evaluation on the Change Control Database (CCD). This evaluation stage is skipped if the CR was marked “Urgent”.
Reviewing the CR
The Change Manager then e-mails a copy of the CR, along with any evaluations, to the members of the Change Control Board (CCB). The Change Manager is the chair of the CCB and they review the CR at the next CCB meeting. In the case of urgent CRs, the Change Manager may call an extraordinary meeting. Requestors are often present at CCB meetings in order to answer questions. After the meeting, the Change Manager updates the CR on the CCD with the review outcome. There are three possible review outcomes:
- Approved
- Rejected
- Deemed not urgent (only relevant if marked “Urgent” in the first place)
Not Urgent
The Change Manager notifies the Requestor that the CR was deemed not urgent (even if the Requestor was present at the meeting) and the CR goes back to the stage where Evaluators are selected (see “Selecting the Evaluators” above).
Rejected
If the CCB rejects the CR, the Change Manager notifies the Requestor (even if the Requestor was present at the meeting) and the process ends.
Approved
If the CCB approves the CR, the Change Manager decides who needs to implement the requested change (i.e., modify the baselined products) and notifies the Requestor (even if the Requestor was present at the meeting) and the identified Modifiers. Usually, but not always, the Modifiers are the same people who evaluated the impact of the CR. The Change Manager sends a copy of the CR to the Modifiers, informing them to implement the change. The Change Manager also notifies the Project Manager and the Project Manager updates the Project Plan.
Modification
The Modifiers implement the requested change and notify the Change Manager when the work is complete along with details of actual effort in business hours. The Change Manager then updates the CCD and notifies the Requestor. The Requestor then verifies the change (e.g., by testing the software or reviewing a document) and notifies the Change Manager of the verification outcome. The Change Manager updates the CCD and notifies the Modifiers and the Project Manager of the verification outcome.
Verification Outcome
If the change was not applied correctly, the relevant Modifier then re-applies the change (see Modification above).
If the change was applied correctly, the Modifier releases the newly baselined product and notifies the Change Manager of the release. The Change Manager notifies the Requestor, Requirements Manager and Project Manager. The Requirements Manager updates the Requirements Traceability Matrix and the process ends.
In part 2 we’ll remind ourselves that the customer owns the process!
Leave a Reply