Civil Service College, Dhaka
Course: MS in International Economic Relations
Module PDM: Unit 3: Project Planning
Unit Overview: This unit is the heart of this text, just as project planning is the heart of project management. This unit focuses on the crucial time at the beginning of a typical project when important planning functions occur.
1.0 Project Planning
Overview: In a project's life cycle, the most important and extensive planning is performed before implementation. Planning skills involve the use of both core and facilitating processes. The core processes that a project manager must master include planning the project scope through the use of a work breakdown structure, scheduling the project, planning project costs and planning for the use of project resources. Depending on the nature of the project, the project manager may need to use facilitating processes during planning, which include planning for risk, procurement planning, communications planning and quality planning. The key output of all these planning processes is the overall project plan.
2.0 Core Project Team
One of the first steps the project manager should take to optimize the effectiveness of project planning is selecting a core group of key people, each of whom offers an expertise or specialty crucial to the project. For example, in the case of an IT project, the core team may consist of the project manager, a software engineer, a hardware engineer and a finances expert. The number of people and specialties will vary with the project.
You should note, however, who should not be part of this core team. It should not include everyone on the project (unless, of course, it is a tiny project) since you want the core project team to be a small, highly interactive, flexible group. Preferably, its members will be self-starters and the group as a whole will be comfortable with self-direction. This is not the place for senior management. Rather, this team reflects the project, not your stakeholders. Core project team members are involved people who will actively plan and aid in the implementation of the project.
Sometimes you can identify and recruit whom you want; sometimes you are "stuck" with staff. Obviously, it is to your advantage to have desirable team members in mind and to work to get them assigned to your project. For example, if you realize that your project will involve a lot of testing; ensure that you have a person on the core project team with that expertise. Often, senior management needs to weigh in on your behalf to obtain such resources, particularly when you are going outside of your division to recruit team members.
Although you are looking for specialists, you must be able to take a broader view. No matter how talented they may be, you don't want people who can only focus on their discipline. You do want people who think ‘we're all in this together.’ If they are dispersed geographically, you should try to assemble them at least once (hopefully, for the basic planning work) for the face-to-face contact that makes subsequent e-mails and phone calls run more smoothly.
Why address this team now? The core project team must be involved in the project planning about to be discussed. They are your planning helpers.
3.0 Scope Panning
Overview: The first type of planning that needs to be accomplished is scope planning. The PMBOK Guide defines scope as “the sum of the products and services to be provided as a project."
It defines scope planning as "the process of progressively elaborating and documenting the work of the project, which includes developing a written scope statement that includes the project justification, the major deliverables, and the project objectives."
Scope planning is the most important type of planning because planning for everything else, including costs, resources, risks, and so on, depends on it. It drives the other planning processes and thus the project itself, so it is not just a paper exercise. If you haven't planned well for the scope (recognizing that there will be changes along the way), how can you accurately plan the time and costs involved? How can you manage customer expectations? How can you monitor and control execution of the plan?
Having outlined project scope in the project initiation phase and having documented it in the PRD, the scope planning stage is the time to focus on project details. Has the scope, which was provided in general terms from project initiation, been well defined? Does it make sense? If not, the project manager must get clarification and understand how it was developed. The scope statement that results from the scope planning process will be the basis for the work breakdown structure (WBS).
4.0 Work Breakdown Structure (WBS)
4.1 Overview: The PMBOK Guide defines the WBS as "a deliverable-oriented grouping of project elements that organizes and defines the total work scope of the project. Each descending level represents an increasingly detailed definition of the project work."
You should not conclude from this definition that the WBS is defined only to the deliverable level. Neither resources and budget, nor schedule can be estimated with any accuracy unless the WBS is taken to the task or work package level, wherever that level of detail may be. In many cases, the project cannot be managed with a WBS that addresses only the deliverable level. An alternative definition would be “a task-oriented grouping of project in a structured way that breaks down the project into work packages.”
In other words, a WBS is essentially the scope statement reduced to individual pieces of work.
Almost everyone involved in project management will have developed a WBS or heard of the concept, although it may be called by a variety of names in different organizations. The WBS proceeds from the most general or "highest" level (for example, "build a plane") through intermediate levels to the most specifically detailed or “lowest" level. Each progressively lower level will further break down the work described in the level above into pieces of work that constitute the whole (such as, from "build the wings" to "rivet aluminum to frame" and "polish assembled wing"). The hierarchical organization of the WBS, in which larger elements are broken down into smaller ones, is the key to understanding it. The WBS is not just a scattered to-do list.
An excellent WBS is a crucial source document for project planning and control. It can protect the project manager from the "gold-plating" that can occur as a project moves along and can thereby prevent the project team from expanding time and resources on work that should not be done.
4.2 Benefits of a WBS: One of the primary reasons for project failure is the lack of understanding of the project requirements. The WBS is the primary means for ensuring that the customer's needs are met and that only the work that the scope defines is considered in the project effort. Its benefits can be summarized as follows:
§ Identifies all the work necessary to accomplish the objectives; and refines the objectives
§ Identifies only the work necessary
§ Identifies specific work packages for estimating and assigning work
§ Provides a structure for measuring success
§ Clarifies responsibilities
§ Forces detailed planning and documentation
4.3 Uses of a WBS: The WBS is the most important project management tool because it completely identifies all the work that the project scope describes and provides the basis for detailed planning, implementation, and control of the project. Its resulting uses can be summarized as follows:
§ Planning
§ Budgeting
§ Funding
§ Estimating
§ Scheduling
§ Performance measurement
§ Configuration management
§ Integrated Logistic support
§ Test and performance evaluation
With a very well defined WBS, the project manager can develop every other tool that is necessary to plan, implement and control the project. For example, although the WBS itself is not a schedule or a network, it is a necessary first step and primary source of information for the development of these tools.
4.4 WBS Models:
The WBS can take on multiple forms, and each format has its own advantages. The two most common forms for a WBS are indented and graphic. The same information can be displayed in different formats, as the following summer vacation examples show.
A. Indented Format:
v Summer Vacation
Destination Activities
Ø Attend theme park day
Ø Attend water park day
Ø See baseball game
Ø Make family visit
Travel
Ø Obtain Motor Club-marked maps
Ø Reserve en route hotels
Ø Plan for kids’ in car activities
B. Graphic Format
The indented format offers several advantages. It is easier to include project details, it is easy to load into major software tools such as Microsoft project and it is easy to edit. It lends itself to printed reports and computerized monitoring.
The graphic format is good for showing the relative levels of the work and how smaller components of the project roll up into larger ones. For presentation purposes, this format also facilitates adjusting the depth of detail that is appropriate for various audiences.
Some people interpret information easier when they view it graphically; others prefer lists. It depends on the project team and the customer's needs. You may find that it is best to create both: perhaps an indented format for your team so you can guide them in greater detail and a graphic diagram to use for briefing senior management or the client.
There is also more than one-way to handle wording in the WBS: Some people prefer subject entries that identify the work output (for example, a construction project would have entries for roof, windows and so on). This deliverable-oriented approach can work for projects with mostly clear, discrete outputs. It was used in the destination and finances sections of the sample WBS above.
Others prefer brief verb-object entries that specify the tasks being performed (for example, lay roof, install windows and so on). In service-oriented cases, task-oriented wording better describes the work. For example, a wedding reception project may have entries for coordinating the catering, setting up a receiving line, arranging the punch serving, and so forth. The travel section of the sample WBS above uses this convention.
Either style is acceptable. You should select the one that fits your project. The real key to success is not the format chosen but the inclusion of all the work in the WBS, regardless of how it may be described and depicted.
4.5 How to Build a WBS:
With a clear statement of the scope of work in hand and preferred WBS style to use, how do you build your WBS? This crucial step in project management is achieved best by following these seven steps:
1. Understand the purpose of your project.
2. Establish the major breakout segments of the work.
3. Break down these large pieces into the next level of components.
4. Break down each component into subcomponents.
5. Continue down to the level where you will assign and monitor project work.
6. Hold a review session with the core project team, client and other key stakeholders to gain buy-in and identify missing items.
7. Prepare the WBS dictionary.
In essence, you first analyze the project scope by proceeding from the general to the specific, breaking down the project into progressively smaller components until you have reached the optimum level for managing the various tasks required for completion. You complete the process by reviewing and documenting the resulting WBS.
Steps 2 through 5 imply that you will have at least three sublevels of project components under the overall project heading. Although it is possible to have less, it is fairly unusual for projects of any significance. The key point in this regard is found in step 5, which addresses the final breakdown of the project to the work package level. A WBS with too few levels will be too broad to be useful in assigning and monitoring work. To the contrary, if it is too detailed, it will become a micromanagement nightmare.
The entire core project team, not just the project manager, should provide input for a WBS. To be complete and effective, the group effort is essential, as is buy-in from team, client and other key stakeholders.
4.6 Key WBS Terms:
Two key levels of the WBS are the work package and the cost or control account. The work package is the lowest level of the WBS. It is the level where work is assigned and monitored and is the primary level for addressing schedules, costing, and resource requirements. Through work packages, the project manager can assign resources and track progress without getting bogged down in too much detail.
The question of level of detail is a nagging one that will never go away. So how big or how small should a work package be? There is no hard-and fast answer, but here are some good guidelines:
· A work package should be small enough to assign to an individual or small team.
· One guideline is the "80-hour rule," which states that no work package should exceed 80 hours of work.
· Keep the goal in mind. If a work package looks like it will require you to micromanage of work progress difficult or overly general, it is too large.
· If you find that you need to consider part of the work package here and part there (as you do costing, scheduling, and resource allocation), it is probably more than one work package.
Every activity that the PRD requires must be covered in a work package. If it is not in a work package, it will not be accomplished. Obviously, however, there will always be individual actions that contribute to completing work packages, but these do not belong in the WBS. Much of this detailed information does go into the WBS dictionary (which will be discussed shortly).
Cost or control accounts constitute a level of the WBS that is used for management reporting. There terms are not used in an accounting sense but as a project management term: They are the level at which costs can be tracked in a meaningful way for senior management and for more general monitoring without too much detail. They are typically found at a level above the work package.