In Part 2 we took a moment to remind ourselves that the customer owns the process and that we must be sensitive to that.
Having been presented with a documented As Is change control process, we must investigate what the stakeholders think about that process. There are different techniques available to us.
One-to-one interviews are an important technique because they allow us to build a rapport with each stakeholder. Moreover, the privacy of the interview gives the stakeholder the opportunity to speak more openly than they might choose to in a workshop environment.
Less effective would be a questionnaire, but if we find a particular stakeholder is unavailable for interviews, then this could be an option.
We would also run a facilitated workshop once all the interviews are over in order to discuss the findings.
Strategic Goals
However, before we interview anyone, we need to take into account any strategy analysis that has been done. If none has been done (as is often the case), we should ask the stakeholders what their strategic goals are. Let us assume that the following strategic goals apply:
- All workflows will be automated where it is felt the return on investment will result in cost savings.
- In workflows, and where possible, decisions will be made automatically by the workflow system based on pre-defined business rules, rather than user whim, in order to ensure consistency in business practice.
- In workflows, and where possible, pre-defined business rules will be maintainable by the business, in order to ensure flexibility in the business model.
Now let us suppose our interviews and workshop have revealed the following:
The Change Manager
Feels that having to update the database periodically involves duplicating the effort of inputting data that someone else has already spent time typing into an e-mail. The other stakeholders agree that this often makes the CM a bottleneck.
The CM also comments that acting as a routing hub for all e-mails related to the process was understandable from the point of view of making sure the communications were sent, but feels this creates another bottleneck and wonders whether technology could do this. The other stakeholders agree.
The CM also says that hand-offs can be bottlenecks if someone completes their task but does not inform the CM. The other stakeholders agree that this can be a problem but also recognise that even with an automated workflow, a user might fail to update the workflow application.
The Project Manager
Although the process shows that the project plan should be updated before a change is implemented by the Modifier, this does not always happen in reality.
Moreover, the process only caters for a change to a single product. However, in reality a CR might require multiple products to be updated. For example, a change in requirement might result in a requirements document, some code and a testing document to be updated and the CR should not be considered completed until all products have been verified and released.
We observe that the same applies to the impact evaluation stage if the CR affects more than one product.
The PM also feels that other plans should be updated to reflect an approved CR, i.e., the Development Plan, the Test Plan and the Release Plan. The other stakeholders agree. This would involve adding new roles to the process.
The Requirements Manager
Says that the Requirements Traceability Matrix should be updated as soon as the CR is approved. While the process shows this happening as the final step, the RM in fact does it as soon as the CR is approved.
Thoughts from the Workshop
Several customers express a concern that people sometimes circumvent the process altogether, for example when a customer approaches a developer directly to make a change to some code. However, all agree that this is a question of training and discipline, rather than internal to the process itself.
All feel that the manual creation and sending of e-mails is time consuming and ask if this could be automated.
Our own observation
If the Requestor wants to amend and resubmit a rejected CR, the process starts all over again. However, this is not clearly reflected in the As Is process. The Stakeholders agree it should be explicit in the process.
Marking up the As Is model
The next thing we could do would be to produce a new version of the As Is process model, marked up to reflect these comments and goals.
It is also important for us to understand exactly where in the process work is handed from one participant to another, so we should make this clear in our marked up version also.
This does not have to be done formally and could simply be done manually on a print-out of both our high level model and the customer’s original model. However, I have done pretty versions for you in Visio (HL here and LL here). Remember that we are using blue connectors to indicate what the customer considers to be the primary path through the process.
Keeping a formal log
Marking up the model is a handy technique but need not be done formally, that is, it need not be presented back to the customer. However, we do need to keep a formal log of the observations and points made during our interviews and workshops. This log would detail , among other things, the points, their source, the date and how the point will be taken into account in the To Be model. I have done this in a simple spreadsheet, which you can see here.
In Part 4, we will draw both high level and low level versions of the To Be model.
Leave a Reply