PPM 301 - Project Management

Section 7. Project Planning and Control

Objectives:

This lesson discusses planning and maintaining control over projects. Objectives important to this lesson:

1. Project planning
   
2. Priorities
   
3. Scheduling
   
4. Monitoring, evaluation, and control
   
5. Risk management
   
6. Auditing
7. Scheduling standards
   
8. Outsourcing
9. Managing costs
10. Work breakdowns
11. Earned value
    

Concepts:

The last chapter took us to the point of starting a project. This one takes us to concerns that apply to running a project. We assume that we have decided that a project is needed, and will take place. Now, we need to plan what we will do in it.

Let's skip the part about convincing ourselves that we need a plan, and start with the Project Plan Contents on page 279.

• Scope statement - what are the goals of the project, the technology that is needed, the time line it will cover, and the projected cost
  
• Work breakdown structure (WBS) - the project is broken into logical or manageable parts as the first part of creating a schedule
  
• Schedule - the project is put on a time line, which should include milestones at which progress will be measured
  
• Project budget - the cost of the project is broken into parts
  
• Risk assessment - an examination of the risks of the project and plans for mitigation of those risks
  
• Interface plan - this applies to projects that require thhe installation of equipment that must interface with power, data, users, and other systems
  
• Work authorization plan - this is basically a plan for the acceptance of completed work units
  
• Logistic support plan - this play applies to the product of the project if it needs support, maintenance, or service over time
  
• Communication plan - a list of who must be given what reports about the progress of the project, and on what schedule that must occur
• Procurement plan - a plan that describes how to obtain the materials the project will need, when to request them, and what they will cost
• Quality assurance plan - actions that will assure that the project meets the client's needs
• Human resource plan - the human resources needed for the project are listed, and where they will be used on the project time line
• Stakeholder management plan - a plan that specifies who the stakeholdeers are and what the project staff will do to maintain a working relationship with them
• Project closeout plan - how the project will be completed, how sstaff will be reassigned, how responsibility for the product of the project will be handed over
• Product commissioning plan - if the product of the project needs to bbe installed, configured, tested, or operated to show functionality, this plan addresses those issues
  

The text catches its breath for a moment, then adds five more items that should be in a project plan.

• Project statement of work - a list of the work to be done in the prooject, statements of how it will be done, and whatever documentation is needed to make the details clear
• Technical specification - a detailed description of the project's product, including parts, components, and over the counter modules
• Technical goals for the project - the technical requirements for the project to be judged successful
• Schedule goals for the project - the time line, phases, and milestones for the project
• Cost goals for the project - a list of expenses for the project, which may spread across the project time line
  

The text also spends a few paragraphs on work packages, but it has already told us twice to define the work that will be done in the project. There is also a list of activities which provide opportunities for adverse effects on the project, but they have all been mentioned above, so let's move ahead.

On page 287, the text introduces project priorities. It introduces the subject with two anecdotes about people who have too much to do, and no guidance about which things are the important ones. It may well be, as in the second example, that the manager has no more idea about priorities than the workers themselves. In that case, how can we set priorities? The text suggests on page 289 that we could assign priority (or urgency) based on the contribution the project or task will make to the organization's goals. This list of goals shows we can think or more than money"

• keeping a promise
• increasing revenue
• enabling the start of a dependent task or project
• improving the company's image
• providing the potential for follow-up work
  

The text proposes that if no system of prioritization is used, then staff will make their own choices. Four kinds of choices are suggested, none of which fit the reasons above:

• the work is interesting or challenging
• the work is for a manager who is liked
• the work is easy
• the work will be with friends
  

While each of the factors above is a motivational factor for staff, those factors should be mentioned as inducements to accept assignments, not as reasons to prioritize them.

On page 290, the text offers a set of phrases that describe the urgency of a project. Several phrases are grouped as priority 1, several as priority 2, and a few are marked as priority 3. The more urgent the phrasing, the higher the priority. The trick is to determine whether something is needed, needed quickly, or needed soonest/earliest.

Whether your company uses this system or another one, the text recommends using one to allow requests to be rated on a common scale and measured in the same way.

On page 293, we turn to project scheduling. The text recommends using graphic scheduling tools that show phases, durations, dependencies, and milestones. In programs that create such plans, you will probably also have the ability to assign resources to tasks, which helps to track their availability for other tasks.

Page 298 takes us to monitoring, evaluation, and control. The text presents a graphic on page 299 that shows a circle marked with four actions:

1. Establish standards
2. Observe performance
3. Compare actual performance
4. Take corrective action
   

This strikes me as being very similar to Dr. Deming's cycle of Plan -> Do -> Check -> Act. The cycle in the text simply takes the point of view of a manager instead of that of a participant.

We are shown a long list of things that need standards. We are reminded that we have to watch performance or get reports on it, and we should watch for trouble in that data. We must analyze the data we collect. We must finally take action where it is required to improve performance on the project.

The text mentions that the actions above can take place as part of an audit of a project. We should pay attention to its observation that we can find things that are going well, as well as finding problems. Whichever we find, we should take the opportunity to share information and plan for improvement in all areas of the project.

On page 304, we turn to risk management. You may have encountered discussions of risk in other texts. This one follows the usual pattern, but has two new ideas:

• We identify risks: things that can go wrong, which will affect our project.
• We quantify the risks: what is at risk, how much damage is likely to be done, and how will we use this information to categorize the risks that may occur?
• We plan mitigation: what can we do to minimize or eliminate risks?
• We plan for contingencies: what do we do when things go wrong?
• We establish a contingency reserve: what funds can we put aside for the problems that will need them? This is a new idea, compared to most security texts.
• We put risks on our schedule: a project manager may place risks in the project plan, based on the probability of occurrence. This is also something that is not in most security texts.
  

On page 310, the text begins a section on auditing, which it has already mentioned. Most people will not associate the word audit with good feelings, but the text reminds us that we should be checking the performance of a progress at all times, and an audit is just a formal check.

The text lists seven kinds of audits, classified by their area of interest:

• progress audit - how is the project doing regarding its schedule, its budget, and its technical goals?
  
• process audit - how well are the processes and practices of the project moving us toward its goals?
  
• system audit - the auditors review a system created by the project to make sure it works
  
• product audit - the technical product is compared to the plan for it and rated on its match to that plan
  
• contract audit - project is rated on compliance with contract requirements
  
• general audit - any or all aspects of a project are rated; planned accomplishments are compared to actual accomplishments
  
• special audit - specific aspects of a project, not included in the audits mentioned above,
  

The text makes a point of explaining that audit teams for projects have a logical problem. An internal project audit team is composed of staff from the project, who will be familiar with the project, but who will not be working on the project while they are conducting the audit. An external project audit team is composed of staff from outside the project, so their work on the audit will not detract from progress in the project itself, but their lack of familiarity with the project may. The text recommends using a composite project audit team, composed of staff from the project and from other sources, for the best balance in conducting the audit and progressing with the project.

The next major topic is scheduling standards, which starts on page 316. The text explains that scheduling standards are the rules that are used when creating and maintaining the schedules for the project, which sounds pretty dull. It helps to have such standards because they provide common themes in the project documents. They allow the project staff to have expectations about such documents that will provide reference points from one document to another.

The text presents eighteen topics that relate to common features in schedules. They range from labeling standards to rules about the kinds of tasks we will have and how tasks are displayed and completed. Some are advisory, and some are much more involved instructions about creating schedules.

For several pages, the text discusses outsourcing project management, which seems strange, since the approach of the entire book has been about doing project management for other companies. That would make us the outsource, wouldn't it? This section seems less useful than some of the others, so we will move on again.

To fill up three pages, the text repeats its recommendation that we should choose a Project Management System, such as Microsoft Project, to create the schedules and plans for our projects. It talks about subsystems in such software, but the point of this section is obscured by the language the author uses. It you are reading this section, get up, walk around, move your arms, and breathe deeply. Coffee can be good.

It should be more useful to think about costs for a few minutes. On page 334, the text presents a list of common project costs (which continues on the next page):

• human resources
• material costs
• contracts
• support costs
• fringe benefits
• overhead
  
• administration
  

The text continues to discuss other sources of costs that should be considered, such as an add-on cost for profit. These items belong in an accounting discussion more than a project management text, so we will move on again.

On page 338, the text introduces the Work Breakdown Structure (WBS), which is simply a diagram of the parts of a project. It can resemble an organization chart, but the entity being described is your project, not an organization. As the text explains, a WBS can be used as a tool to break the project into work packages, which contain the work units that will be assigned in the project. The examples at this web site show us some variations in the way a WBS can be displayed. Note that we are told that the Tree Structure view is the most popular. In the examples shown, I think it may be the least readable.

The last topic in the chapter is earned value management. It is a system of measuring how well a project is complying with its initial plan. This seems like a laudable goal, but it strikes me as being too rigid to be of much use. I will suggest that we leave it behind by quoting von Moltke's first aphorism: "No plan of battle ever survives first contact with the enemy." If we do not recognize that all plans must change over time, we are doomed to failure.