Uploaded by Thanuja M

MODULE 02 Project Mananagement -2022 BY. Dr. S B Mallur

advertisement
Organize / Plan / Perform
STUDY MATERIAL
PROJECT MANAGEMENT
(18ME745)
ON
Module-2:
Planning Projects
Module: 02:
System of Limits, Fits,By
Tolerance and Gauging:
Dr. Shekharappa B Mallur
Professor and former Chairman
Department of Studies in Mechanical Engineering
University BDT College of Engineering
Davanagere- 577004, Karnataka
(A Constituent College of VTU, Belgaum)
Fax: 08192-233412 http://www.ubdtce.org
Off.: 08192-250716:
Project Management-18ME745 (PM) Note by – Dr. S B MALLUR, Professor, UBDTCE, Davanagere
1
VISVESVARAYA TECHNOLOGICAL UNIVERSITY, BELGAUM
University BDT College of Engineering, Davangere
Mechanical Engineering Department
Sub Name: PROJECT MANAGEMENT
(18ME745)
Dr. S B Mallur, Professor, MED, UBDTCE, Davanagere
Module-2
Planning Projects: Defining the project scope, Project scope checklist, Project priorities, Work
Breakdown Structure (WBS), Integrating WBS with organisation, coding the WBS for the information
system
Scheduling Projects: Purpose of a project schedule, historical development, how project schedules are
limited and created, develop project schedules, uncertainty in project schedules, Gantt chart.
Course Outcomes (CO2):
CO2: Understand the work breakdown structure by integrating it with organization.
CO3: Understand the scheduling and uncertainty in projects.
Course Learning Objectives:
1. To understand how to break down a complex project into manageable segments and use of
effective project management tools and techniques to arrive at solution and ensure that the
project meets its deliverables and is completed within budget and on schedule.
2. To impart knowledge on various components, phases, and attributes of a project.
3. To prepare students to plan, develop, lead, manage, and successfully implement and deliver
projects within their chosen practice area.
4. Planning Projects:
PLANNING PROJECTS
1. Defining the project scope,
2. Project scope checklist,
3. Project priorities,
4. Work Breakdown Structure (WBS),
5. Integrating WBS with organisation,
6. Coding the WBS for the information system.
Scheduling Projects:
7. Purpose of a project schedule,
8. historical development,
9. how project schedules are limited and created,
10. develop project schedules,
11. uncertainty in project schedules,
12. Gantt chart.
Project Management-18ME745 (PM) Note by – Dr. S B MALLUR, Professor, UBDTCE, Davanagere
2
2.0. INTRODUCTION
 Planning is a large and critical part of project management.
 Planning may be largely completed before much executing work begins in traditional project
management, in a completely iterative fashion using Agile, or somewhere in between in a hybrid
environment.
 Project planning tends to be collaborative with many people involved and integrative in that many
factors need to be considered.
 Planning cover the various aspects of planning in distinct chapters to clarify what needs to be done
in each.
 Scope planning plan the scope by collecting requirements and creating work breakdown
structures, Scheduling Projects shows how to create and communicate project schedules.
2.1. DEFINING THE PROJECT SCOPE
Define Scope
Define scope is the process of translating stakeholder needs and requirements into detailed specifications
of the project outcomes and products.
Essentially, the project scope statement includes three things regarding the total scope.
First, the team needs to determine both what they will deliver to the project stakeholders at the
end of the project and what they need to deliver along the way to ensure they will be successful in
the end. These are the deliverables—the product scope. For example, if a final project deliverable
is a new computer program; intermediate deliverables may include an outline of what will be
included and a prototype.
Second, the team should decide what work needs to be accomplished to create the deliverables.
This is the project work statement—the project scope.
Third, the team needs to determine what will limit or influence the project work— such as
exclusions, constraints, and assumptions.
2.1a Reasons to Define Scope
 Scope definition is an important part of project planning because all other planning is based on the
project scope.
 While the requirements collected represent the customers’ statement of what they need, the
defined scope is the project team’s response—asking the customer, “If we provide this, will it
solve your problem?” It is impossible to estimate how much a project will cost, how many (and
what type of) workers will be needed, how long a project will take, what risks are involved, or
what quality standards will be invoked without first understanding what work is included in the
project.
 Scope definition also is vital in preventing scope creep.
 Scope creep happens for two common reasons.
 First, if the scope is not clearly defined and agreed upon, it is easy to add additional work (scope
creep) to the project with or without realizing that more time and resources (additional cost) will
be required. Second, sometimes when a project is going as planned, a customer is so excited that
he or she asks an innocent-sounding question: “Can the project output also do … ?” The person
performing the project work is often flattered and agrees without understanding the implications
of making this change.
 In contemporary business, pleasing the customer is desirable.
 However, the best time to gain customer understanding is when the project team is defining the
scope—not while executing the project scope work.
Project Management-18ME745 (PM) Note by – Dr. S B MALLUR, Professor, UBDTCE, Davanagere
3
2.1. PROJECT SCOPE CHECKLIST
2.1b How to Define Scope
 Scope definition can vary greatly from one project to another.
 For a small, routine construction project, it may be quite simple to determine what project
outputs will be created and what work is involved in creating them.
 On other projects, such as one large company acquiring another, it may be very difficult to
determine the total amount of work that needs to be accomplished.
 Regardless of how easy or difficult it may be to define scope and despite industry-specific methods
that may be helpful in doing so, all project teams need to complete each part of this process.
LIST DELIVERABLES AND ACCEPTANCE CRITERIA
The first step is to list project deliverables. The requirements elicited from the customer often
lead to some of the final deliverables.
Project teams need to understand that there are often multiple deliverables.
For example, if a project entails constructing a house, the homeowners probably want not only
the house but also documentation on systems within it, perhaps an explanation (training) on how
to use certain items such as an innovative thermostat, and a warranty procedure.
The project team also needs to list intermediate deliverables—those things that need to be
developed while making progress to complete the project.
Some of these were probably listed in the charter, but others may not yet be identified. Then the
project team needs to determine the acceptance criteria for each deliverable.
ESTABLISH PROJECT BOUNDARIES
 The second step in defining scope is to establish the project boundaries.
 Think of the project boundaries as the side-lines on an athletic field.
 By understanding what is in play and what is not, athletes know clearly when to play and when to
stop.
 Likewise, project team members need to know which tasks should be executed and which tasks
need not be executed.
 The first part of the boundary definition is to decide which features and work elements are
included (in scope) and which are excluded (out of scope).
 Collectively, clients and end users often request far more features and work than a project is
originally planning to deliver or can deliver.
 Therefore, the team needs to know and decide what is included and what is not. Usually, the
sponsor makes decisions regarding larger scope decisions, but the project manager and team still
have many detailed scope decisions to make.
 The second part is to manage expectations regarding any project. The project team members
need to understand the constraints imposed on the project.
 If the work must be delivered by a certain date or if only limited resources are available, the
project may be constrained, and the team should be careful to promise only what it can deliver.
 In planning, people make assumptions about dates, times, and availability of resources; for
example, a shipment of required materials will arrive by the date the supplier promised.
 These assumptions should be stated. If an assumption proves to be false, it frequently increases
the project risk and may also limit the project scope.
CREATE A SCOPE DESCRIPTION
o The final step is to create a scope description.
Project Management-18ME745 (PM) Note by – Dr. S B MALLUR, Professor, UBDTCE, Davanagere
4
o This description briefly states the work that needs to be accomplished to create the project
deliverables.
o A project scope statement guides the project team during subsequent planning and execution.
o For some very small projects, a well-developed project charter could also serve as a scope
statement.
o On most projects, a scope statement needs to be developed prior to development of the WBS.
An example scope statement for the Alternative Breaks project is shown in Exhibit 7.4.
Project Management-18ME745 (PM) Note by – Dr. S B MALLUR, Professor, UBDTCE, Davanagere
5
1.3 PROJECT PRIORITIES
7-3c Defining Scope in Agile Projects
 Agile strives to use smaller iterations to get feedback because understanding the desired outcome
tends to evolve as the customers see the work being done by the team. Humans tend to be poor
estimators, and the more unique the project, where volumes of reliable data are not available for
making estimates, the harder it is to be predictable.
 In construction, for example, there are software packages that help estimate how long it will take
to hang drywall or run electrical wire. However, in more creative endeavours like creating
software, there is little documented knowledge of how long a project will take. This is where the
adage to under promise and over deliver becomes words to the wise.
 With Agile projects, the project manager is challenged with conflicting aspirations and actions
between finalizing the scope specifications and maintaining flexibility to modify them to meet
changing business needs or adding new requirements of stakeholders.
 Agile scope definition is a complex process as the scope is not clear to either the project team or
the client.
 The project manager and the project team must demonstrate greater adaptability to frequently
changing scope and employ iterative or phased planning of scope.
 Consequently, Agile projects present more flexibility.
 On Agile projects, the scope definition starts with large chunks of work; for example, we want to
be able to take credit card payments on a website. This large feature, and there will be many of
them for a fully functioning website, will be broken down into stories and prioritized later. The
team creates “personas,” which are fictional people who represent user types.
 These personas provide information about what they will do with the project deliverables and
how they will benefit. These user stories define scope and functionality.
 Acceptance tests will also be agreed upon during the scope definition phase by describing the way
project deliverables will be tested and how they should prove workable.
 At the project outset, the overall scope is only defined at a high level, and a backlog of possible
work is identified. The customer representative (sometimes called the owner) prioritizes the scope
based upon business need, value, cost, and risk.
 The team then commits to the amount of work they can perform in the first iteration. As the
project progresses, the scope is described more specifically and is documented more closely.
 The level of documentation is less important and takes a secondary role. The primary measure of
success in an Agile project is working software.
 The Agile method for defining scope is primarily applicable when the project scope is unclear or
poorly defined.
Project Management-18ME745 (PM) Note by – Dr. S B MALLUR, Professor, UBDTCE, Davanagere
6
2.4.
WORK BREAKDOWN STRUCTURE (WBS),
 After scope definition is complete, the project manager will have a greater clarity about project
work and milestones as compared to the high-level understanding of the project when the project
charter is defined (discussed in Chapter 3).
 The milestones defined in the project charter are not necessarily accurate due to lack of complete
understanding of the total project work.
 It is important to note that the project charter must be seen as an authorization document with
accuracy of estimates (cost and time) in the range of + 50 percent.
 With the definition of scope, more details about the project are available to develop WBS and new
milestones.
 A detailed understanding of the project scope and work to be performed must be simplified for
execution, and it is essential to divide the total work into smaller and manageable elements.
 A tool that is used on virtually all traditional projects is the WBS.
 To understand this tool, we will first define it, tell why it is important, show several common
formats to use when constructing one, and then demonstrate the steps required to construct a
WBS.
2.5. INTEGRATING WBS WITH ORGANISATION,
7-4a What Is the WBS?
 The WBS is, or should be, a uniform, consistent, and logical method for dividing the project into
small, manageable components to manage project scope and for planning, estimating, and
monitoring (Rad and Anantatmula, 2009).
 It is a project planning tool that is defined as the concept of hierarchical decomposition for
transforming the project scope into deliverable work elements at the highest level.
 Its composition continues until it facilitates managing these work elements effectively. The WBS
helps develop an optimum project schedule and cost estimates at the work element level.
 The WBS is a tool that project teams use to progressively divide the deliverables of a project into
smaller and smaller pieces.
 The project team members start by identifying the major deliverables to be created and by
continuously asking: “What are the components of this deliverable?” The WBS is not a list of work
activities, an organizational chart, or a schedule.
 The WBS is a framework that is used as a basis for further planning, execution, and control.
 The WBS also is an important project planning tool that uses the concept of hierarchical
decomposition for transforming the scope into deliverable work elements.
 Typically, the WBS is created after the scope is defined on large projects. In contemporary project
management, particularly on small and middle-sized projects, the WBS may be created
concurrently with the scope statement.
 The WBS is normally developed by listing deliverables—major deliverables first and then
progressively smaller ones until the team feels that every deliverable has been identified.
 Managers of smaller projects sometimes perform another process concurrent with WBS
development: defining activities and milestones.
 Define activity is a project planning process that identifies and determines specific actions to
develop and deliver the project outcomes, such as products, services, or results.
 Many people find that work activities can be easily defined once the various deliverables are
itemized. To clearly distinguish between the work processes of WBS development and activity
development, WBS development is covered in this chapter, and activity development is covered as
part of project scheduling in the next chapter.
Project Management-18ME745 (PM) Note by – Dr. S B MALLUR, Professor, UBDTCE, Davanagere
7
 Developing the WBS and defining the activities form an example of how two separate work
processes are sometimes performed together (especially on small or simple projects) and
sometimes separately (especially on large or complex projects).
7-4b Why Use a WBS?
The reasons for using a WBS are many. Planning projects requires discipline and visibility. A properly
developed WBS encourages a systematic planning process, reduces the possibility of omission of key
project elements, and simplifies the project by dividing it into manageable units (Rad and Anantatmula,
2009).
A WBS can be used as a pictorial representation of project deliverables. By using a systematic process for
creating a WBS, project team members can ensure that they include all deliverables that are required to
be created. Deliverables that are not planned, but need to be, often add to schedule delays and budget
overruns.
The WBS provides a framework of common reference for all project elements, for specific tasks within the
project, and ultimately for better schedules and better estimates. It is the basis for all subsequent
planning of such important functions as schedule, resources, cost, quality, and risk. It also serves as an
outline for integrating all these planning elements. The WBS is easily modified and thus can handle the
changes that often occur on projects. The impact of these changes is then shown in the schedule, budget,
and other control documents. If a problem occurs during project execution, the WBS is helpful in
understanding exactly where and why the problem occurred. This helps to diagnose problems, manage
the quality of the project deliverables, and keep all the other facets of the project on schedule while the
isolated problem is fixed.
The WBS is also helpful in project communications. Typically, many stakeholders contribute to developing
the WBS, and this effort helps them understand the project. Further, it clearly shows the importance of
each work element, why it is required, and how it is integrated with project deliverables. In a nutshell, the
WBS presents the entire scope of the project and serves as an excellent communication and integration
tool. Software such as Microsoft Project enables a WBS to be shown in its entirety to people who need to
understand the details, but it also allows project details to be hidden so that others can see the big
picture.
Project Management-18ME745 (PM) Note by – Dr. S B MALLUR, Professor, UBDTCE, Davanagere
8
7-4c WBS Formats
There are various formats for constructing a WBS, but they all have the same purpose.
The overall project is considered the first level, as shown in Exhibit 7.5.
In this example, a WBS for a house is presented in the indented outline format.
The second level in this example depicts major deliverables from the house project, namely the
house in its framed state, when it is wired, and when it is dry walled.
This second level is indented one tab. Note that a section is included for the work of planning and
managing the project.
A WBS usually has one or more intermediate levels, which generally represent items that need to
be created to produce the final deliverables, such as drafts, prototypes, and designs.
These are frequently called interim deliverables. All levels of the WBS with at least one level
below are considered summary levels.
The completion of summary-level elements is based upon completion of all levels underneath. For
example, in Exhibit 7.5, the house would not be framed until the framing contractor, wood, and
assembled frame interim deliverables were complete.
Exhibit 7.5 used the indented outline format for the WBS method, but other methods are
sometimes used.
Another method is the hierarchical or “org chart” (short for organizational chart, which it
resembles) method. A third method is called free format because the facilitator is free to draw it in
any manner.
The same house project shown in Exhibit 7.5 in indented outline format is shown in Exhibit 7.6 in
org chart format and in Exhibit 7.7 in free format.
Project Management-18ME745 (PM) Note by – Dr. S B MALLUR, Professor, UBDTCE, Davanagere
9
A marker board or flip chart can be used to develop all these methods and also offers plenty of
room to add additional elements as the scope is revised.
The WBS method using indented outlines can easily be imported into MS Project.
Teams using the org chart or free format methods for WBS generally translate them into the
indented outline format for input into software.
7-4d Work Packages
The house example above has only three levels as follows:
Project Management-18ME745 (PM) Note by – Dr. S B MALLUR, Professor, UBDTCE, Davanagere
10
1. The first level, or project title level
2. One intermediate level, or summary level
3. The lowest level, or work package level
This process of dividing the deliverable items is continued until the project has been divided into
manageable, discrete, and identifiable items requiring simple tasks to complete.
A practical rule is to keep dividing the project until it no longer can be divided realistically. This point may
differ from project to project. The lowest level is known as a work package.
In a WBS, an element at the lowest level is called a work package, which is usually the work component at
the lowest level of the WBS for which cost and duration can be estimated and managed. Work packages
are the basis for all subsequent planning and control activities. Exhibit 7.8 shows a WBS in org chart
format with work packages in solid boxes.
One frequently asked question when breaking the deliverables into work packages is how small is small
enough. The answer is, “It depends.” In Exhibit 7.8, work packages occur at levels 3, 4, and 5. The work
package is the point from which:
 Work activities are defined
 The schedule is formed
 Resources are assigned
 Many of the control features are developed
Work packages need to be detailed enough to facilitate further planning and control. If they are too
detailed, the burden of tracking increases. The project manager needs to feel confident that the work to
create the work package can be assigned to one person who can estimate the schedule and cost and can
be held responsible for its completion. However, the work package may require multiple resources
(including more than one person) to complete it.
Project Management-18ME745 (PM) Note by – Dr. S B MALLUR, Professor, UBDTCE, Davanagere
11
If the work is composed of a single deliverable that is well understood, it is clear how the deliverable will
be judged for quality and completeness, and the assigned workers have proven credentials, then the work
package may not have to be too detailed. On the other hand, if the deliverable and/or how it will be
judged for its completion are poorly understood, and the assigned worker or workers are yet to be proven
reliable, a more detailed work package may make sense.
For ease of communication and comprehension, work packages and other components of a WBS are
usually stated in very few words; one should avoid verbs and instead use adjectives to describe WBS
elements at all levels. A WBS component is a work element that is part of the WBS at any level. The
phrases or words to describe WBS elements should not be repeated. However, because the names are
typically short, there is still the potential to get confused by exactly what is included in a work package or
WBS component.
Therefore, WBS components are often defined further using a WBS dictionary. A WBS dictionary is a
document that provides detailed information about each work package by providing details about the
associated deliverable, activity, scheduling information, predecessor, successor, person responsible for it,
resources required, and associated risks. An example of a WBS dictionary entry with detailed information
for a work package is shown in Exhibit 7.9. Note that some of this additional information such as
activities, resource assignments, effort, and cost will be described in subsequent chapters.
Project Management-18ME745 (PM) Note by – Dr. S B MALLUR, Professor, UBDTCE, Davanagere
12
7-4e How to Construct a WBS
The information for a WBS is drawn primarily from the project objectives statement, and from historical
files containing planning information of past projects. When a project team needs to construct a WBS, it
needs to include in its planning team a subject matter expert (SME) who understands how each segment
of the work will be accomplished. Teams approach this task in two ways. The first approach is that teams
include only the core team members and plan the WBS as in as much detail as they can. At that point,
different core team members are assigned to identify and seek the SMEs to plan the remaining details. In
the second approach, teams invite the SMEs to the WBS planning meeting right from the start and utilize
their input throughout the WBS development. Often, the choice of how to include SMEs is determined by
the size and complexity of the project and by the cultural norms of the company. The planning team uses
a top-down approach in creating the WBS. This is easy to start when the type of project is familiar and at
least some members of the planning team are likely to understand the general flow of work. If the project
is similar to past projects, either a template or the WBS from a previous project can be used as a starting
point. Then, using this template or WBS, the project team would identify additional project needs for
inclusion and irrelevant elements of the previous project for deletion. Templates and previous examples
can save teams a great deal of time, but caution must be exercised because each project is unique.
Sometimes, however, a project is so unique and different from previous projects that the team finds it
useful to jump-start the WBS construction by brainstorming to identify a list of project deliverables to
help to understand and develop the overall structure of the project WBS. However, once the overall
structure is understood, the team proceeds with the typical top-down approach for the remainder of the
WBS development.
IDENTIFY MAJOR DELIVERABLES The team defines the project deliverables by reviewing the project
planning completed thus far. The team members review the projectcharter, requirements traceability
matrix, and scope statement to define the project’s major deliverables. Remember that while many
projects may have a primary deliverable such as a house, almost all projects have additional deliverables
such as documentation and customer support. These could include training, service, or other means of
helping the customer use the project’s products effectively.
One of the first decisions is how to organize the second level of the WBS. (Remember, the first level is the
overall project.) As defined earlier, the WBS is, or should be, a uniform, consistent, and logical method for
dividing the project into small manageable components. WBS development is viewed as the process of
grouping all project elements into several major categories, normally referred to as level one; each of
these categories will itself contain several subcategories, normally referred to as level two. Alternately,
and more accurately, development of a WBS involves dividing the project into many parts that, when
combined, would constitute the project deliverable. This process of dividing the deliverable items is
continued until the project has been divided into manageable, discrete, and identifiable items requiring
simple tasks to complete. Three methods are shown in Exhibit 7.10. One method is by project phase, with
thesecond level being the signing of a contract, building the foundation, and framing the house.
Alternatively, the second level can be organized by design components (deliverable-basis), such as
kitchen, bedrooms, and bathrooms. Finally, the second level can be organized by work function (resourcebasis). A house project organized this way might have carpentry, plumbing, and electrical as second-level
elements.
Project Management-18ME745 (PM) Note by – Dr. S B MALLUR, Professor, UBDTCE, Davanagere
13
Organizing by project phase (schedule-basis) has the advantage of using the milestones in the project
charter as an organizing principle. It also facilitates rolling wave planning. Rolling wave planning is a
planning technique of identifying and defining the work to be completely accomplished in the near term
and planning the future work at a higher level. In other words, once the near-term work is complete, the
next phase of the project is planned in detail. In essence, it is an iterative process. If the planners of the
project in Exhibit 7.10 used rolling wave planning, the work associated with the contract would be
planned in detail immediately, and work for the foundation and framing might only be planned at a high
level at first with more detail worked out as the project team worked on the contract. Rolling wave
planning allows a team to get a quick start on a project—especially one in which details of later phases
may depend on the results of work performed during early phases. Rolling wave planning helps a project
team avoid either of two extremes. One extreme is to never start doing anything because the plan is not
yet complete, which is also known as analysis paralysis. The opposite extreme is not planning at all
because of fear that planning will take too long; this is known as ready, fire, aim.
Organizing by either phase or design components/deliverables helps to focus communications on project
deliverables and their interactions. Organizing by work function allows the functions to focus on their
specific activities, but often does not promote cross-functional discussion. Handoffs of work from one
group to another are not always as smooth. Therefore, if a project manager decides to organize the WBS
by work function, extra care needs to be taken in establishing interfunctional communications. Of the
three approaches, the most generally useful, and the most difficult, method for developing a WBS is to
use design components/deliverables as the basis of the breakdown of the project. It is also known as a
deliverable-based WBS. The deliverable-basis, or design-basis, is developed by looking at the project from
the client’s perspective and not from the project execution perspective. Further, it makes sense to all key
stakeholders and facilitates easy communication.
In this deliverable-basis or design-basis mode, the project is divided into individual distinct components
that ultimately comprise the project, such as hardware, software, physical structure, concrete foundation,
or steel roof. This deliverable-based WBS division can be based on product, function, or physical location
of the deliverable (Rad and Anantatmula, 2009). The deliverable basis of WBS development is far superior
to the other bases because it is customer focused and easy to facilitate during project execution. Note
that one additional second-level item is shown on all three methods—that of project management. This
includes the work of planning and managing the effort and includes preparing documents, attending
meetings, integrating diverse portions of the project, handling communications, and so on. Since much of
the work involved in project management is the level of effort, this section may not be decomposed. If
Project Management-18ME745 (PM) Note by – Dr. S B MALLUR, Professor, UBDTCE, Davanagere
14
the work of managing the project is left out, it is more likely that the project will not be completed on
time and within the budget.
It is very important to understand that, in many cases, the client is not concerned about the intricacies of
project execution or project management activities. From a client’s perspective, the focus is only on what
is delivered as the project outcome. So, project management is not typically included in a deliverablebased WBS. However, there are exceptions to this rule. For large and mega projects, programs, and
federal government contracts, it is possible that the client is interested in project management activities
and project progress reports. In such cases, including project management in the WBS may be sensible,
even in a deliverable-based WBS.
DECOMPOSE DELIVERABLES Once the major deliverables have been defined, it is time to break them into
smaller deliverables or components. This is called decomposition, a method of dividing the project scope
into many parts that, when combined, would constitute the project deliverable. It is the process of
breaking down the project scope until it has been divided into manageable, discrete, and identifiable
components requiring simple tasks to complete.
The team members can use the top-down approach, asking what all the components of each major
deliverable are. Alternatively, the team members may use a bottom-up approach by brainstorming a list
of both interim and final deliverables that they feel need to be created. Each deliverable can be written
on an individual Post-it Note. These deliverables are then assembled on a large work space where team
members group the smaller deliverables either under the major deliverables that have been previously
identified or into additional related groups that are then headed by major deliverables.
CONTINUE UNTIL DELIVERABLES ARE THE RIGHT SIZE At this point, the WBS has been formed and can be
reviewed for completeness. Once it is determined to be complete, the team can ask if the deliverables at
the lowest level need to be divided further for planning and control as described above. For example, in
the new car development project in Exhibit 7.11, level-two components, such as product design, are at
too high of a level to plan and control. Therefore, at least one more level should be included. If some of
those components, such as Product Goals, are still too broad, yet another level would need to be
developed.
Project Management-18ME745 (PM) Note by – Dr. S B MALLUR, Professor, UBDTCE, Davanagere
15
REVIEW At this point, several things should be considered to ensure that the WBS is structured properly.
One consideration with WBS construction is the parent-child concept. The higher level is considered the
parent and the lower-level elements are considered children. For example, in Exhibits 7.5, through 7.7,
“Framed House” is a parent to the children: “framing contractor,” “wood,” and “assembled frame.”
“Framed House,” in turn, is a child to “HOUSE.” The framed house component is not complete until all of
its children components are complete. The team asks if, once these elements are complete, the framing is
complete. In an effort to simplify the WBS, where only one child element for a parent exists, you would
not break it down. In fact, a good rule of thumb is to have somewhere between three and nine child
elements for each parent. The fewer levels a WBS has, the easier it is to understand. To avoid confusion,
each component in the WBS needs to have a unique name. Therefore, two similar components may be
draft report” and final report,” instead of merely calling each “report.” The team also assigns a unique
number to each component.
In one common numbering system, the number for a child item starts with the number assigned to its
parent and adds a digit. An example of a WBS with components numbered is shown in Exhibit 7.12.
Different organizations sometimes develop their own unique variations of project planning and control
techniques. Exhibit 7.13 describes the manner in which a large, complex organization (the U.S. Central
Intelligence Agency) combines stakeholder analysis with WBS.
Project Management-18ME745 (PM) Note by – Dr. S B MALLUR, Professor, UBDTCE, Davanagere
16
Project Management-18ME745 (PM) Note by – Dr. S B MALLUR, Professor, UBDTCE, Davanagere
17
1.6. CODING THE WBS FOR THE INFORMATION SYSTEM.
7-6 Using MS Project for Work Breakdown Structures (WBS)
As you have likely realized, the WBS is one of the most important and powerful project planning tools
available to the project manager. It is one of the key building blocks on which all further project activities
are based. By creating a WBS in MS Project, the project manager lays the foundation for automating
many other planning and communication tools the software has to offer. Complete the following steps to
set up a WBS in MS Project.
7-6a Set Up a WBS in MS Project
Setting up a WBS in MS Project has five basic steps:
1. Understand the WBS definitions and displays.
2. Enter project deliverable and work package elements.
3. Create the outline of your WBS.
4. Insert a WBS code identification column.
5. Hide (or show) the desired amount of detail in the WBS.
STEP 1: UNDERSTAND THE WBS DEFINITIONS AND DISPLAYS
MS Project refers to WBS task elements as summary tasks, tasks, and subtasks and displays them in an
indented outline table format:
 Summary tasks are the main or interim WBS deliverables and are displayed in bold font.
 Subtasks are all the tasks that make up the deliverables (work packages) and are indented below
their parent summary task.
WBS tasks can also be viewed in Gantt views with different graphical shapes:
Project Management-18ME745 (PM) Note by – Dr. S B MALLUR, Professor, UBDTCE, Davanagere
18

For instance, a summary task might also be a milestone that you would want to denote graphically
in your Gantt chart (typically a diamond in MS Project).
 You will see these graphical representations in future tutorials.
Exhibit 7.15 shows a Gantt table view of a WBS in MS Project. Note that MS Project codes the overall
project (Suburban Park Homes) as level zero, not level one. The task durations have not been defined at
this point and show “1 day?” for all tasks. If you are following along in MS Project, you will notice “Start”
and “Finish” columns to the right of the Duration column that also have not been defined. The Start and
Finish columns are not shown in the following exhibits for clarity’s sake.
STEP 2: ENTER WBS ELEMENTS (TASKS)
In Exhibit 7.16, you will see WBS task elements added to the existing Suburban Park Homes project
milestone list (from Chapter 3). In this WBS example, the existing milestones will double as the main
deliverables (summary tasks). Enter these WBS elements to your project as follows:
1. In the Task Name field, select the row below where you want the new row to be (after making your
selection, holding the SHIFT key and selecting a different row will highlight all rows between the two
selections and result in that number of blank rows being inserted in the next step).
2. Click Task Tab>>Insert Group>>Task.
a. Alternatively, you can Right-Click>>Insert Task.
Project Management-18ME745 (PM) Note by – Dr. S B MALLUR, Professor, UBDTCE, Davanagere
19
3. You will see a new row (or rows if you added multiple) with the words <New Task> in the Task Name
field. Click on <New Task> and enter the name of the desired WBS element (you may have to delete
<New Task> before typing in your new task name).
4. Repeat these processes as needed to enter additional tasks between the Suburban Park Homes
milestones until your WBS looks like Exhibit 7.16.
Project Management-18ME745 (PM) Note by – Dr. S B MALLUR, Professor, UBDTCE, Davanagere
20
STEP 3: CREATE THE OUTLINE FOR YOUR WBS
You now need to set up the outline structure of the WBS to show summary tasks and subtasks
(deliverables, interim deliverables, and work packages). To do this, use the Indent and Outdent controls
shown in Exhibit 7.17 (Task Tab>>Schedule Group>>Green Arrows).
1. Click the Task Name field of the row to be indented.
2. Task Tab>>Schedule Group>>Indent Task (right Green Arrow).
a. The task element above the indented task(s) becomes a summary row as indicated by a bold font.
b. Indenting a summary row will also indent its lower-level items.
c. Multiple rows under a summary row can be indented (or out dented) at the same time by Shift-Click
selecting all of them before clicking the Indent control.
3. Clicking Task Tab>>Schedule Group>>Outdent Task (left Green Arrow) will similarly decrease
indentation of the selected row(s) or summary task.
4. Indent to create deliverables, interim deliverables, and work packages until your WBS resembles the
outline shown in Exhibit 7.15.
STEP 4: INSERT WBS CODE IDENTIFIER COLUMN
MS Project can automatically assign identifier codes to all your WBS tasks. WBS codes allow the Project
Team to easily categorize and communicate information about project tasks in the WBS. In this example,
WBS codes will be assigned in a new column to the left of the Task Name column:
1. Right-click the Task Name column heading and click Insert Column.
2. A drop-down list appears in a new column.
3. From the drop-down list, choose WBS, as shown in Exhibit 7.18.
a. A WBS code column is now in place.
b. Resize the column to conserve space.
4. Right-click the Task Mode column heading and click Hide Column.
5. Your result should look like Exhibit 7.19.
Project Management-18ME745 (PM) Note by – Dr. S B MALLUR, Professor, UBDTCE, Davanagere
21
Project Management-18ME745 (PM) Note by – Dr. S B MALLUR, Professor, UBDTCE, Davanagere
22
STEP 5: HIDE (OR SHOW) SUBTASKS DETAIL
Some stakeholders will not want or need to see the lower levels of WBS detail (particularly in large,
complex projects with lots of WBS detail). You can easily “roll-up” (or “un-roll”) subtasks underneath their
parent summary task to hide (or show) detail. To display the appropriate level of detail, complete one or
both of the following steps:
Click the tiny triangle before the task name of any summary task to hide underlying detail (all details will
be “rolled-up” under the summary task).
Click the tiny triangle again to show underlying detail (all details “un-roll” under the summary task and are
again visible).
In Exhibit 7.20, the underlying detail for the “Land preparation, landscape, and foundation” deliverable
and the “Framing” interim deliverable summaries has been hidden.
Project Management-18ME745 (PM) Note by – Dr. S B MALLUR, Professor, UBDTCE, Davanagere
23
PMP/CAPM Study Ideas
It has been said that the discipline of project management lends structure to common sense. Nowhere is
this more true than with scope planning. If you can remember to conduct your planning with the end goal
in mind, many of the processes and activities in this chapter will seem intuitive. Another way of saying his
is that you will work backward from the outcome you desire (a successful product and/or project).
Begin by identifying what it would take for your product—and your project—to be successful. Be sure to
include your customers and end users in making this determination (“Collect requirements”), as well as
subject matter experts who can speak to the technical expertise needed and the feasibility of the project
plan. Identify the final deliverables, as well as any important interim deliverables.
Discussing these deliverables and what it will take to produce them is a good chance for the team to
further “define scope,” or determine what is included—and not included—in your project.
Once you have the main deliverables, you will use the process of decomposition to break them down into
smaller pieces, thus creating a Work Breakdown Structure. It is important to remember that the WBS
deals with things, not activities (though on a very small project, these may be planned concurrently). The
lowest level of the WBS is the “work package,” which is small enough that it can be easily planned and
overseen by one person.
To be sure, this is an oversimplification of everything that goes into planning scope, and you will need to
be fluent in all the activities and processes in this chapter in order to pass a CAPM or PMP test. But it can
be helpful to remember that there is an organizing structure to all this work—one that begins with the
end result in mind.
Summary
Once a project is formally approved by a sponsor ratifying its charter, it is time for detailed planning.
While project planning is iterative, normally the first steps are to identify stakeholders, plan
communications, and determine what will be created on the project. Project teams start this process by
asking customers what endof- project deliverables they want. From the customers’ response, the
planning team can determine both what interim deliverables need to be created and what work needs to
be performed to create all of the deliverables. Just as important as determining what will be produced
during the project is determining what will not be produced. These boundaries of what will and will not
be included constitute the project’s scope
Once the scope is defined, it can be organized into a work breakdown structure (WBS). A WBS is used to
progressively decompose the project into smaller and smaller pieces until each can be assigned to one
person for planning and control. The WBS serves as a basis for determining the project schedule, budget,
personnel assignments, quality requirements, and risks. As those other functions are planned, items are
commonly identified that should be added to the WBS. Some teams create their WBS by hand using the
org chart or free format methods, while others directly type their WBS into project scheduling software
such as Microsoft Project.
Project Management-18ME745 (PM) Note by – Dr. S B MALLUR, Professor, UBDTCE, Davanagere
24
Download