What We Liked - WBS & PMO
Work Breakdown Structure
We were interested to see that Jolyon tackles the contentious topic of Work Breakdown Structures. This is a subject not well
covered in the software world and probably less often put into practice. He deals with it in the subsection titled "Defining
Project Activities" and carefully explains how to carry out this essential project management technique. A good example of a
software/hardware project WBS is provided in which we were particularly pleased to note that entries are shown as nouns except
at the lowest levels
of each WBS branch where the entries are verbs. That should please the diehards!
Since "activities" can be major and minor, and decomposed to almost any degree, the issue arises as to when is enough, enough? Jolyon suggests:
"In deciding whether to further decompose an activity, your sole consideration must be whether the activity is large, complex, or unwieldy enough to require further breakdown. In other words, an activity is 'small enough' when you are satisfied that it is manageable."[7]
On (activity) contingency, Jolyon observes that:
"A contingency is an allowance for problems. It is better to state it overtly as an activity in the WBS than to covertly bury it in each work activity. If it is overt, you can make explicit decisions to use some of it and to direct it to problem areas. If it is hidden, not only can it not be formally used, but the estimates for individual work activities are overstated by the amount of the contingency. The inevitable consequence is that the work will expand to occupy the inflated time period, the contingency will be used up, and the project will take longer than it should, and, when problems arise, there will be no contingency left to deal with them."[8]
Amen to that! But that does assume that management has not already "carved off the fat" (as they are inclined to put it) to set aside contingency for themselves. Our own strategy is to add a final (somewhat bogus but ample) activity titled "Administrative cleanup and closure". This prevents people from "helping themselves" to any item labeled "Contingency", management finds it difficult to argue with or even question, and it does give the project manager some elbow room.
Project Management Office
On the subject of a project management office (PMO), Jolyon opines:
"Until recently, most organizations treated project management as if managing projects were a matter of individual preference ... . [However,] Organizations have come to appreciate that there are two main problems with this approach:
- Project management is a discipline.[9] Those who do not exercise the principles of that discipline will see their projects struggle and often collapse. Therefore, the effectiveness of project management is as spotty as the variations in formality.
- When project managers leave the organization or are transferred to another project, it is extremely difficult for their replacements to step in and take over. This is because all of the project documentation conforms to the departing project manager's personal preference, instead of to an organizational standard."
"Some organizations, in an attempt to create standards, purchase methodologies that are supposed to provide structure and consistency to projects. Again, however, good intentions fall prey to three problems:
- Most of these methodologies are focused on project activities themselves ...
- The methodologies deal primarily with applications development projects ...
- Any methodology is only as good as the degree of its use."
Jolyon answers his own questions with:
"So how is an organization to create and enforce standards? The answer that is gaining wide acceptance is the project management office, or PMO. The PMO is a corporate department responsible for the practice and discipline of project management within the organization, or at least within that part of the organization that falls under its control."[10]
7. Ibid, p126
8. Ibid, p140
9. A "discipline" may be defined as: "Control gained by obedience or training".
10. Hallows, J., Information Systems Project Management, pp12-13
|
What
We Liked - Content
