As a project manager who does not produce the product being delivered, we often need to reflect. What value am I providing my client? How are they better off with me around?
It helps to be both personal and impersonal.
How does it help them to have a project manager for this project? What value does this position provide?
How does it help them that I am the project manager for this project?
According to Shoji Shiba, knowledge has several levels. The first level is simply Exposure. You've heard of Linux, you know what it is, you've had the chance to do some basic stuff with it, like listing the files on the system. It is plain that such a level of knowledge is of very little use.
The second level is Skill. At this level, one's knowledge has reached some usefulness. You know how to ride a bike, and you can use the bike to get you from A to B without much falling down. At this level, your productivity is very basic and inefficient. Workers who are at this level are not very effective. They can do the job but need much supervision to ensure their work is satisfactory.
The third level is Understanding. You have reached the level where you know what you are doing and can make effective decisions.
The fourth, and final level is Mastery. You know how to use the skill at the highest levels and the highest effectiveness that the skill is able to deliver. This is where you are most productive.
It takes time to develop Mastery. It is worth taking the time to study the best ways to shorten the knowledge cycle from Exposure to Mastery.
After the project has been broken down into analysable components, we identify the source of the risk -- why is there uncertainty? What is causing this uncertainty or variability?
By addressing the causes or sources of the variability we will be better able to respond to the causes in addition to the effects.
Suppose we have identified a risk in the completion of the functional specification documents of a software development project. What we mean is that we have identified an uncertainty in the completion of these documents. They may take more or less time than expected. What might be the causes of this risk?
The specifications may take longer because the requirements may change as the project progresses. The specifications will change in proportion to the change in requirements.
The specifications may take longer because it may be realised later that the specifications do not cover its areas on the proper depth and scope.
These are two possible causes. Notice that responses required to mitigate the uncertainty could be very different. In the first cause, we need to look further at the requirements documents from which the specifications are being developed. In the second cause, we need to look at how we can identify gaps in the specifications documents. Of course it is possible that both causes occur.
Once we have identified the possible causes of the risks, we can proceed to identifying responses to address the causes, the risk, and the risk events.
* * *
References: Simister & Turner
