Unit 3

Project initiation and scope planning

Project initiation
Scope management involves defining and controlling the components you want to
include or exclude from the project. To manage the scope of a project successfully,
you need to understand the components of scope management'

• Project initiation -Recognition of a new project.

• Scope planning - Writing a scope statement-
• Scope definition - Dividing project deliverables into small parts.
• Scope verification - Formalizing the acceptance of the project scope
• Scope change control - Identifying and managing changes in the project scope.
Continued………….
In addition to identifying the components of scope management, you
need to understand the processes involved in scope management and
how these processes fit into the overall project management process
groups. For example, project initiation is part of the initiating process
group, but scope planning and definition are part of the planning
process group. Scope verification processes belong to the executing
process group, and scope change control processes belong to the
controlling process group.
Impact of historical information
The information from finished projects is often used during project
initiation. This information can include performance reports,
documentation of past decisions, and documentation of the results of
completed projects.

Historical reports are a good source of information for project managers.

You can refer to these reports to find benchmarks for a current project,
for example, or to learn how another project manager solved a problem
similar to what you might face.
Initiating a project
Project initiation takes place when an individual or group recognizes
the need for a project. Although project initiation is not always a clearly
defined process, it frequently includes determining the project
objectives, defining specific goals, and developing a project charter.
These actions might vary with the organization.
Authorizing projects
After an idea for a project is developed, the project must be authorized.
Projects are authorized based on an organization's needs. For example,
a project might be authorized in response to changes in the market or
in government regulations. A project might also be authorized because
of an internal business development or operational necessity or to take
advantage of new technology. Additionally, projects can be authorized
when customers express a need or when senior managers request
them.
Project selection methods

The methods of selecting projects typically include quantitative, qualitative,

subjective, objective, and various cost-benefit analyses. Project selection methods
can be grouped into two general categories:

• Benefit measurement methods - These methods include benefit-cost models,

peer reviews, and various scoring models.
• Constrained optimization methods - These methods include (decision trees,
forced-choice models, and logical framework analysis.

No matter how projects are selected, it's important to make sure that they align
with the organization's goals.
Project deliverables
After selecting a project, you need to identify the deliverables, or the output
of the project. For example, the purpose of a project might be to create a
new service or to fix a defect in the current product. The term deliverable is
used frequently in project management because it implies output. Focusing
on the output helps keep the project team focused on the ultimate goal.

There are both intermediate and end deliverables: An end deliverable is the
final product of the project. For example, a document that identifies the
technical specifications for a new software program is an intermediate
deliverable, and the software program is the end deliverable. All deliverables
should be defined in terms of a tangible, verifiable product or service.
Continued……………
As a project is in development, a detailed description of the end deliverable will help
you identify the features necessary for the product or service. A detailed description
is beneficial in many ways:

• It enables the project manager to identify factors such as cost, schedule, and
materials.
• It enables the project team to clearly understand the ultimate project goal.
• It helps in the development of a project charter.
The description of the end deliverable is generic in the beginning of the project and
becomes more detailed as product characteristics are refined.
Continued……….
A project charter is not used to manage changes that occur during a
project, but it should be modified or re-created depending on the
extent of changes. If large-scale project changes both outdate and
nullify the original charter, then a new charter should be written and
signed. However, if a project change occurs without nullifying the
charter, then the original charter can be updated to reflect the changes.
It's important that your project charter is always current and accurately
depicts the project to date.
Project Charters
A project charter formally recognizes the existence of a new project. The
charter describes the project objectives, which are the quantifiable criteria
that indicate completion of the project. To grant the project manager the
authority allocated budget and to use the organization's resources to
accomplish project activities , an individual with authority must sign the
project charter.

In some organizations, an authority (an individual or a committee) authorizes

that the charter be signed. In other organizations, the project manager,
functional managers, senior managers, and clients sign the project charter.
The signing of a project charter is a statement of dedication and commitment
to the project.
Elements of a project charter
The elements of a project charter vary depending on the project and
the organization.
Items covered in the project charter might include a general description
of the business need that the project addresses and a description of the
end product or service.
Project constraints and assumptions
In addition to developing a project charter, project managers and teams
need to identity a project's constraints. A constraint is a factor that
limits the project management team's options for a project. Some
possible project constraints include contractual provisions,
performance requirements, time, cost, schedule, technology, and the
need to map the project to the organization's goals.
Constraints are decided or negotiated when the scope statement is
developed. For example, the project manager must operate within the
boundaries identified in the scope statement. These constraints can
include budget limitations, maximum allowable time, and contractual
provisions
Continued………….
Experienced project managers can proactively manage, in some way, all
constraints that limit options. However, it's important to realize that the
project manager might have to make trade-offs to handle a project
constraint even if the project is being managed proactively.
Examples of trade-offs include time and money, such as the decision to
hire external consultants to accelerate project work. Hiring consultants
can get the work completed faster, but it also increases the cost of the
project. Another example of a trade-off is purchasing a ready-made tool
rather than developing it in-house . Frequently, a trade-off can affect
several aspects of a project. Therefore, it's important to examine trade-
offs critically and thoroughly before taking action.
Project assumptions
Project managers and teams must also understand how their
assumptions affect a project. Project assumptions are conditions that
must fall into place the way they're planned for a project to be
completed successfully. Assumptions are accepted as true, real, or
certain during the planning of the project, and they typically include
cost, time, and performance issues.

Assumptions are not absolutes, so there is a degree of risk involved in

adopting them . For example, you might assume that adequately skilled
resources will or will not be available during the project, and then plan
for the use of these resources based on your assumption.
Scope planning

Because projects are dynamic, it's important to keep them in balance.

The project scope (Size) must be clearly defined. Defining a project's
scope ensures that the project manager, team members , and
stakeholders understand the key tasks that must be accomplished and
the time frame and budget within which they need to operate.

A Written scope statement details the project's scope and provides

everyone involved in a project with a document that they can refer to
throughout the project life cycle. The scope statement can include the
project's goals, time frame, major deliverables, or resources needed for
completion.
Continued…………
You should write the scope statement during your scope planning. As part of
scope management, scope planning belongs to the planning process group.
Before you begin a project, it's critical that you understand its scope. If you
realize that the scope 1s too
broad or too narrow early in the scope planning process, you can split the
project into sub-projects. These sub-projects can help make a project more
manageable .
If you determine that the scope is too narrow late in the project planning or
controlling process, the project might require add-on projects. Both of these
situations can cause a
project to fail. When you're planning the scope of a project, it's critical to
balance complexity and simplicity.
Taking action
To help balance complexity and simplicity, consider taking these actions
in your scope planning process:

• Complete a product analysis.

• Conduct a cost/benefit analysis.
• Ask for recommendations from experts.
• Identify alternatives.
Completing a product analysis
When you're planning a project's scope, it's important to understand the project's
end product or service. Completing a product analysis enables you to determine if
the product meets your organization's business needs.

To complete a product analysis, you can use various techniques, such as value
analysis and function analysis. Value analysis techniques, such as net-present-value
and return- on-investment calculations, enable you to identify the value that a
product will bring to
an organization.
For example, if you plan to develop a new product, these techniques can help you
determine whether it meets your organization's needs or whether you need to add
another product to meet remaining needs, if any. Completing a function analysis
enables you to determine the function that a product will add to your company.
Conducting a cost/benefit analysis
Conducting a cost/bene fit analysis helps you determine how to
develop the products to achieve maximum benefits. Estimating tangible
and intangible costs and benefits enables you to assess the value of
project alternatives.

Tangible costs include the cost of making a product or completing a

project. Intangible costs (also called opportunity costs) are related to
the opportunities missed by choosing one project over another. In
other words, by opting for Project A, what does theorganization miss by
not choosing Project B?
Continued…………….
Completing a cost/benefit analysis helps you determine whether the
benefits of a project exceed the costs by a margin that is acceptable to
your organization. During a cost/benefit analysis, companies consider
both short- and long-term benefits over the project's life cycle. For
example, pharmaceutical companies can have a 10-year development
cycle. The long duration of the development cycle might not yield many
short-term benefits, but if a company is the first to market a new drug,
the payoff is significant.
Asking for expert recommendations
Asking experts with experience on similar projects enables you to learn
about issues that might affect the scope of your project and plan for
possible scope changes.
Identifying alternatives

Identify different approaches you can take to complete your project.

Brainstorming, or "lateral thinking," can generate different, more
effective alternatives with which to approach a project.
Creating a scope statement
Every project must have well-defined, achievable goals and a roadmap
for achieving them. A scope statement outlines the specifics of a
project. Project stakeholders review the scope statement before
accepting it.

If the scope statement does not meet the stakeholders' requirements,

it's modified until it meets their approval. However, they might decide
not to go ahead with a project on the grounds that it will prove too
costly. When the scope statement is approved, the project can proceed
to the next phase of project management, which involves developing a
detailed project plan.
continued………
The scope statement document is often referred to for future project decisions .
Therefore, it should outline clear project boundaries, making it easier for the
project manager and team members to identify any additional work that should be
performed as part of the executing process group. The scope statement describes
the following aspects of a project:
• The problem or opportunity that the project addresses
• The project goal and objectives
• The measures of project success
• The risks and assumptions that might affect the project outcome

In addition, the scope statement defines the boundaries of the project, such as
size, budget constraints, and the span of time within which the project must be
completed .
The statement of work

A key component of a scope statement is the statement of work (SOW).

The statement of work describes the products or services that an
external entity will complete for a project. After you identify the part of
the project to be outsourced, the SOW should be created and included
in the scope statement.

The SOW can be a critical part of the scope statement because

outsourced companies and vendors rely on the SOW to define product
requirements. If an entire project is outsourced, the SOW takes the
shape of a scope statement for the project.
Primary items of a scope statement
A completed scope statement either includes several other documents
or includes references to other documents. A scope statement should
include these four primary items:

• Project justification
• Product description
• Project objectives
• Project deliverables
Project justification
The project justification describes the business need that the project will
address. This business need is identified when the project is authorized. For
example, if an organization loses business because a technological advance
has outdated its internal network, upgrading the network would be a
justifiable new project.
Project justification provides a benchmark for evaluating trade-offs that arise
during the project management process. For example, suppose that a
company upgrading its network determines that the new network will
produce a 10% increase in operational efficiencies. During the project, this
10% increase can be measured against the cost associated with the upgrade.
In this example, the company needs to conduct a study to determine the
current efficiency levels to use the justification as a benchmark.
Product description

Another item in a scope statement is the product description. The

product description explains the characteristics of the product or
service and helps the project team to clearly understand its ultimate
goal.
Project objectives
A third item to include in the scope statement is the project objectives.
Every project's objectives must be clear to project personnel,
managers, and stakeholders. If the objectives are not communicated
clearly and effectively, the team members involved in the project might
interpret the goals differently.

For clarity, project objectives should be specific, measurable, realistic,

and consistent with organizational plans, policies, and procedures.
Project deliverables
Your scope statement should include a summary list of the project
deliverables. This list is important because successful completion of
these items indicates completion of the project. For example, the major
deliverables for an updated internal computer network might include
installing a fully functional updated network, distributing information
about the new network, and setting up training classes for employees.
Scope creep
An important factor to keep in mind when writing a scope statement is
the possibility of scope creep. Scope creep is a common project affliction
that results from adding work during the life cycle of a project, without
handling the changes through scope change procedures.
scope creep can result in project cost increases, deadline failure, and
other problems. A Clear scope statement can help control scope creep
because the statement enables the project team to manage any extra
work that's added to the project.
Changes during a project life cycle are inevitable. The project manager
must be aware of these scope changes and manage their consequences
so that they do not negatively affect the project objectives.
Scope management plans
Another way to prevent scope creep is to follow a scope management
plan, which is a step-by-step process for managing changes in the
project scope. This plan indicates how scope changes will be identified,
how they will be integrated into the project, and which approvals are
required. Scope management plans might also include the probable
stability of the project so that the stakeholders know how frequently
the scope might change and to what extent it might change.
It's common to create a generic scope management plan so that a new
plan is not required for every new project. Scope management plans
might contain basic or in- depth information and can be formal or
informal documents.
Unit 4
Scope definition ,
verification, and change
control
Scope definition
To manage the scope of a project, you need to understand each
component of the project. By defining a project's scope, you can
identify the smaller deliverables that make up the project and take
smaller steps toward achieving the final goal.
Scope definition is the process of dividing all the major project
deliverables into smaller elements. This process must be completed for
each of the project deliverables listed in the scope statement. The
processes for scope definition are part of scope management, so scope
definition falls under the project management planning process group.
Decomposition of a project
To define the scope of a project, you must decompose the project
deliverables into small tangible items.
Decomposition is the process of breaking a project into manageable
chunks of work, resulting in parts of deliverables that constitute the
final product and that are easy to plan, manage, and schedule. The
smallest level of a decomposed item is called a work package.
To decompose a project, you should follow these four steps:

1. Identify all major deliverables. The major deliverables will depend on the type
of project. For example, when building a house, you identify the grounds, the
house structure, and the utilities as major deliverables.
2. Determine cost and duration. This step involves determining whether cost and
duration can be identified for each major deliverable. If they cannot be
identified, you need to further split the deliverables. For example, the building
materials required for a house could be categorized as plumbing, electrical, and
mechanical systems.
3. Decompose major deliverables. You should then decompose the major
deliverables to the smallest possible element that can be reasonably planned and
managed. When doing so, remember that every deliverable must be defined in
terms of tangible, verifiable results. For example, for the house's plumbing
system, one of the smallest elements you could identify might consist of putting
in the faucets.
4. Clarify deliverables. Make sure all deliverables are clearly identified so that
you can sequence, schedule, and budget them. In addition, make sure each
deliverable is assigned to the correct individual or group.
Advantages of decomposition
Using the previous steps to decompose a project can have several advantages:

• Estimates for cost, time, and resources are accurate.

• The small deliverables are easier to manage, resulting in negligible changes after
the project starts.
• Each project deliverable can be assigned to a team member, resulting in high
levels of accountability.
• The project manager can measure team members' performance with respect to
the completion of these smaller deliverables.
• Controlling the project is easier because you can manage smaller pieces of it.
Work breakdown structure
It's important to display decomposed deliverables in a manner that is
accessible to all stakeholders. By using a work breakdown structure,
you can represent each project task and deliverable, displaying team
member assignments and interrelated activities.

A work breakdown structure (WBS) is the foundation for project

planning and is one of the most important project management tools.
Identifying all deliverables required for a project, a WBS is a standard
way to organize work. To complete a WBS effectively, you must
decompose each deliverable necessary to complete a project so that
you understand the project's full scope.
A sample WBS is shown in Exhibit 4-1
Continued …………….
A WBS can be set up in an outline or a graphical format. An outlined
WBS lists the first-level deliverables on the left side, with any successive
levels indented beneath them.
This structure is a practical way to list a large number of deliverables.
Exhibit 4-2 shows an example of an outlined WBS.
Continued………….
Continued….
A graphical WBS provides a visual representation of all deliverables in a
tree-like structure, with small deliverables branching out from the large
deliverables they support. This layout helps simplify the relationships
between deliverables. A sample graphical WBS is shown in Exhibit 4-3.
Continued………
New Vehicle
0

Engine Chassis Body Interior Cable looms

1.0 2.0 3.0 4.0 5.0
Example of a WBS
Example of WBS
Continued
When you're creating a WBS, it's important to involve all team
members so that they share the same understanding about all aspects
of the project.
Organizing a WBS
When all work packages in a WBS are identified, the project manager must organize
them in the most logical manner. Different aspects of the project can be emphasized
depending on how work packages are organized. There are many ways to organize a
WBS:
• According to the phases in which the product will be developed
• Based on the physical elements of the product or service, listing each element as
a high-level deliverable
• According to the general project objectives that the deliverables need to meet
• Based on the chronology of the major steps in a product's life cycle
• According to various locations, if the project is geographically dispersed
• According to functional departments, and then within each department, using the
most appropriate WBS
Other breakdown structures
There are many other types of breakdown structures that are used to present project
information. It's important to be aware of these structures so that you do not confuse
them with a WBS:
• A bill of materials (BOM) is a breakdown of the physical elements needed to
assemble a manufactured product.
• A contractual work breakdown structure (CWBS) is used to detail the work
breakdown of any project-related products or services that are provided by an
external source.
• An organizational breakdown structure (OBS) identifies the deliverables
assigned to functional departments within the organization.
• A resource breakdown structure (RBS) identifies the deliverables assigned to
individuals within the organization.
Designing a WBS
A work breakdown structure is an essential part of a project because it enables you to:
• Finalize the scope of a project because any work not listed in the WBS is outside the
scope of the project.
• Plan the project.
• Outline a budget for the project.
• Link deliverables to available company resources.
• Establish accurate cost and schedule estimates.
• Assign work responsibilities to specific team members.
• Monitor the progress of the project as a whole, since each deliverable is a
measurable unit of work.
• Monitor schedules, costs, and performance throughout the project.
• Establish status-reporting procedures.
Elements of a WBS
A WBS categorizes all the project work into deliverables. All
deliverables should be defined to provide the basis for the following:

• Scheduling definite start and end dates

• Providing a benchmark that compares results to expectations
• Developing a product or service or part of a product or service
• Providing minimum documentation for the project office
Continued………….
As deliverables are broken into small components, they become more detailed. A WBS lists three
types of deliverables:

• High-level deliverables give a broad overview of the project. For example,

when a house is built, a high-level deliverable is the "structure.“
• Summary deliverables are not executed but summarize the subordinate work
packages. Summary deliverables are important because they communicate the
high-level deliverables of the project to the stakeholders. When a house is built,
summary deliverables that fall under "structure" can be foundation, framing,
exterior, interiors, and roof.
• Low-level deliverables, commonly called work packages, are manageable units
that can be planned, budgeted, scheduled, executed, and controlled effectively.
For example, when a house is built, a work package for "foundation'" can be to
"grade the site."
Work packages
Work packages should be written as actions, such as "Develop the
instruction manual.“ A work package gives the project manager a basis
for knowing if a project is running according to schedule. The smaller
the work packages, the easier it is to identify when corrective action
must be taken to complete the project as planned.

Large work packages that are difficult to control and manage can pose
problems in the project management process. When a work package is
unmanageable, it can take longer than planned to complete. To limit
work packages to a manageable size, follow these rules:
Continued……….
• A work package should consist of 8 to 80 hours of work.
• A work package must be limited to the duration extending between
subsequent status reports. For example, if you hold weekly status
meetings, an individual work package must be completed within one
week.
• For each work package, the progress should be easy to track, and
accountability should be easy to assign. If this is not the case, the
work package might be too large.
Indicators of a fully decomposed work
package
Making sure work packages are fully decomposed makes them easier to manage and enables you to track
progress more effectively. The following five characteristics can help you determine when a work package is
fully decomposed:
• At any time, the project manager must be able to accurately estimate a deliverable' s percentage of
completion.
• The start and end criteria of each deliverable must be clearly defined.
• The end of a deliverable represents a physical accomplishment, which is the product or service.
• The project manager must be able to arrive at accurate cost and time estimates
for each work package.
• Each work package should be independent so that work can continue without additional input or
interruptions.

After a work package is completed, any additional related work will require a new work package.
Creating a WBS
A well-written WBS facilitates the planning and management of a
project. To create an effective WBS, follow these steps:
1. List the breakdown of deliverables.
2. Review with responsible individuals.
3. ldentify data relevant to the WBS.
4. Continually examine actual resource use.
5. Compare actual progress to scheduled progress.
Listing the breakdown of deliverables
A good WBS breaks a project into descending levels of detail. To design an effective
WBS, Start by listing high-level deliverables and then split them into summary
deliverables. Finally, create separate work packages from the summary deliverables.

To identify high-level deliverables, identify the major elements of the product that
the project will develop. For example, when you're building a house, the major
project deliverables include the house structure, the utilities, and the landscaping.
Each of these is a high-level deliverable in your WBS. The utilities can then be broken
into summary
deliverables, such as electrical systems, heating and air conditioning, and plumbing.

When you're creating work packages, the activities required to develop a product
must be defined. Work packages for the summary deliverable of completing plumbing
might include such items as running the pipes and switching on the water heater.
Reviewing with responsible individuals
It might be difficult fora project manager to identify all the necessary
work packages required fora summary deliverable. Ask the people
assigned to particular deliverables to identify work packages that you
might have missed. Doing so increases the accuracy of the WBS and
increases team members' buy-in. These individuals must review the
work packages you identify to make sure they are accurate. Seeking the
team's approval of the WBS gives team members a high sense of
ownership for the outlined tasks
Identifying data relevant to the WBS
After the WBS is decomposed to the work package level, you identify
project requirements, such as vendors, equipment, cost, duration,
resource needs, assumptions, risks, and materials. In addition, you list
the individuals or organizations responsible for each deliverable. These
details enable you to monitor each work package and identify areas
that require special management coordination.
Continually examining actual resource use
After you plan your WBS, you can use it to monitor and control the
project. As a project manager, you can use the WBS as a benchmark for
resource use during the project. For each work package, you can
compare actual resource use against planned resource use, making it
easier to identify when corrective action is necessary.
Comparing actual progress to scheduled
progress
The WBS functions as a benchmark for project progress. Comparing
actual progress with scheduled progress at the work package level lets
you easily evaluate the project's progress. You can then take action to
correct any deviations from the original project plan and schedule.
Tips to follow when developing a WBS
To make sure your WBS helps you plan, communicate, and control I your project,
it should meet the following criteria:

• The WBS should be clear and easy to understand to anyone who reads it.
• Each work package should be a direct subset of a summary deliverable, and
each summary deliverable should be a direct subset of a high-level deliverable.
• Summary deliverables should be broken down so that all the work packages
necessary to complete the summary deliverable are listed below it.
• All tasks listed on the WBS should produce a deliverable.
• Deliverables listed on the WBS should be tangible milestones, making it easy to
recognize when milestones are achieved.
Using a VBS template
Keep in mind that a WBS might exist for your project. Although each
project is unique , for projects that are similar, organizations might
maintain a standard WBS that you can use as a template. Using a WBS
template can save time when you plan a project.
Benefits of a WBS
Several benefits result from a solid WBS:
• The project team develops confidence in achieving its goal.
• The WBS provides a framework in which you can identify projects
separately from organizations, accounting systems, and funding sources.
• Specific work packages are available that can help you estimate and
assign work.
• Responsibilities are clearly defined, resulting in accountability.
• Team members are able to focus their attention on project objectives.
• It's easier to develop detailed plans and documentation.
Scope Verification
Scope verification is the process by which project stakeholders formally
sign off on the project scope. This process is used to gain stakeholders'
acceptance of the project's current status. Stakeholders might review
completed deliverables or any current project documentation.

Scope verification is part of scope management. The processes used to

verify a project's scope fall under the controlling and executing process
groups. For example, the status reports used during scope verification are
generated using controlling processes. The executing processes include
deciding how the customer will verify the scope and determining the
periods when the scope will be verified. Scope verification requirements
 Scope verification requirements
To verify a project's scope, stakeholders need access to several pieces of information. This information
includes the project plan and scope statement, status reports, descriptions of completed deliverables,
specification documents, work products, and the WBS.

Stakeholders use the project information to assess whether the project has maintained its value. Scope
verification can be performed in various ways. The project manager meets with the customer, and together
they review the work products. This meeting is often
called a walkthrough.

If the project uses business requirements and technical specification documents, such as
for software development projects, then the project manager and customer analyze these
carefully to make sure each item in the software meets all the requirements and
specifications. Next, the customer signs off and formally accepts the work products.
The timing of scope verification

Scope verification occurs at the end of each project life cycle or when
project milestones are completed. These are natural breaks in the
project when the project manager and can plan future corrective action
if stakeholders reject the work results.
If the scope cannot be verified, the project manager, team, and
customer develop clearly defined specifications and descriptions based
on the customer requirements. This group then compares the
specifications and descriptions to the project achievements to date to
determine how closely the results match.
Continued…….
Then, the project manager, team, and customer assess the cost that
will be incurred-in terms of time, resources, quality, and money-to take
the project from its current state to the end point. Finally, based on
costs and other constraints, the group decides which actions it can
take.

Managing the scope of a project requires the participation of all

stakeholders. This process helps the project manager determine if the
project is running as planned and if the end products or services will
meet the needs of the customer.
Scope change control
Change is inherent in any project. To manage changes, you need to
handle all aspects or project management effectively. Controlling
projects involves measuring, monitoring, and adjusting actions to
produce required outcomes and progress toward project goals.

Controlling a project requires knowledge of its status, which means that

you need to continually monitor project work. Comparing a project's
current status against the plan will help you determine which areas
must be controlled.
Continued……….
A scope change is any adjustment made to the project scope as defined by
the WBS. A scope change occurs when a variation from the original scope
takes place. A change in project scope can lead to changes in cost, time,
quality, or other project variables.

Keep in mind that scope changes might or might not result in corrective
actions. For example, if a client requests scope change and the request is
approved ahead of time, as it should be, the action is not considered
corrective. However, suppose that a scope change made without the client's
approval steers a project away from its goals. This situation calls for
corrective action in the form of an answering scope change that will guide
the project toward its goals.
Continued…….
Because scope change is an important part of scope management, it's
important that you understand how to control scope changes. Scope
change control is part of the controlling process group, which also
includes change control processes for time, cost, quality, risk, and
contracts . Depending on the situation, a scope change can either expand
or contract a project's scope. Controlling such changes involves the
following:

• Identifying factors that create scope changes

• Recognizing that scope changes occur
• Managing scope changes when they occur
• Making sure that scope changes are beneficial to the project
Continued…..
Controlling changes also involves updating the required project
documents to make sure they contain accurate information. These
updates include making sure stakeholders are aware of the changes
and adjusting project baselines. Baselines are the plans approved
before the project began, such as the original budget, which is the cost
baseline.
Determining if scope changes are beneficial
to the project
There are several factors to consider when determining whether or not
scope changes are beneficial to a project. For example, a scope change
that adds a hot selling feature to the end product can boost the
product's sales. Such a change might be detrimental to the project,
however, if it extends the project timeline or exceeds the budget. It's
important to weigh all aspects of a scope change before deciding to
implement it.
Scope change control systems
Scope changes should be controlled so you can run the project as
planned and successfully complete project deliverables. To help control
scope changes effectively, you can develop a scope change control
system.

A scope change control system-which is part of an organization's overall

project change control system-defines the steps needed to change the
scope of a project . This system includes a description of the types of
issues that require scope change, approvals that authorize the change,
and the documentation to be completed for the scope change.
Performance reports
One piece of paperwork that can help measure scope change is a
performance report . These periodic reports summarize the current
status of a project and provide information about the deliverables
completed and the ones that are incomplete . This information can
alert the project manager to possible unauthorized scope changes.
Change requests
Another valuable piece of paperwork is the change request form. Because change
requests frequently trigger the need to re-plan parts of a project, it's important to
follow procedures to process the requests expediently. A change request might be
oral or written and can be initiated by the project team or an external source.

The following situations can result in change requests:

• External events, such as a lack of resources

• A missing element when the product and/or project scope is defined
• An addition to the project that adds value to the end product
• A reduction in scope that removes one or more aspects of the project or end
product
Continued…….
After a change request is approved, the change must be documented in the
scope statement, and the appropriate stakeholders must be notified of the
change. Often, project managers and teams do not change the original
wording of the scope statement when changes are made, but create a new
document that describes the change, its purpose, and its effects. This
document is then filed with the scope statement.

Updating the documentation about the scope statement is important because

a change can affect the project objectives and deliverables. If the project
deliverables are affected by a change, it's important to make related changes
in the WBS.
Database of lessons learned
When managing the scope of a project, you should document and
maintain a database lessons learned during the project. For example, if
it turns out that the scope changes you made negatively affected the
project, you should log details of the change, the Circumstance's, and
the consequences in a historical database, You should also use the
database to record corrective action taken to account for scope
changes. Any information you can track can be used for future projects.
 UNIT 5

Time management
 Activity definition and sequencing
The goal of time management is to identify and follow the most efficient course or action toward
project completion. Before beginning a project, you need to understand how time management
components are integrated into the project management process.

The components of time management are:

• Activity definition and sequencing- Identify the activities necessary for a
project and the order most appropriate for their completion.
• Activity duration assessment- Estimate the time needed to complete each
activity and the entire project.
• Schedule development - Allocate time for each activity based on resource
availability and budget limitations.
• Schedule control- Consider factors that might alter the original schedule, and
manage those factors.
Continued……..
Activity definition and sequencing, activity duration assessment, and
schedule development are part of the planning process group.
Schedule control, the fourth component of time management, is part
of the controlling process group.

Effective time management helps ensure that projects are completed

within an appropriate time frame. It also helps prevent a project from
exceeding its assigned budget.
Activity definition and sequencing
Defining and sequencing activities helps ensure that no activity is omitted or
left incomplete. Activity definition clarifies the main project activities, outlined
in the work breakdown structure (WBS). Activity sequencing arranges
activities in their logical order of completion.

To sequence activities, you must first start with clear definitions of the
activities. An activity definition should include the following information:

• What kind of work is required

• Where the work will be performed
• Who should complete the work
Continued………
During activity definition, it's also helpful to assign a numeric code to
each activity. The codes can be used to sort the activities, using project
management software. For example, suppose that project work will be
completed in Los Angeles and Cincinnati. Using the software, you can
create Los Angeles activity codes beginning with 5, and Cincinnati codes
beginning with 7. If you need to see the activities taking place in Los
Angeles, you can display only the activities with codes starting with 5.
Activity lists
As you use the WBS to define the project's main activities, you must
compile the activities into an activity list. The finished activity list then
functions as a guide for sequencing activities, You can also use the
activity list to identify skills needed for each activity and to track a
project's progress.

Before starting activity definition, choose a duration estimating

technique so that you know the detail level of activity definition needed.
It can be helpful to consult subject matter experts and other experienced
personnel. If experts are not available within the organization, you might
need to contact special interest groups or professional organizations.
Decomposition
Decomposition is a method of activity definition. Decomposition splits
the major work deliverables from the WBS into action steps, or
activities. Activities have a projected time and expected cost, and they
use resources. Because activities are more easily quantifiable if divided
into small pieces, it's easier for project managers and team members to
calculate accurate time, cost, and resource estimates for each activity.
Project managers then use these estimates during the schedule
development process.
Tasks, activities, and events
Different project management approaches use different terms to represent the
concepts. The following definitions are employed throughout this course:
• Tasks are the smallest, most finely detailed elements of work as described in the
WBS. Because tasks are small, they do not always use a measurable duration,
cost, or resource expenditure.
• Activities are made up of tasks.
• Events, or milestones, are high-level markers on project network diagrams or
schedules. Events indicate completion of an activity or set of activities, the
release of a progress report, or a testing point.
You can think of tasks, activities, and events as layers in a pyramid. Tasks form the base of
the pyramid, activities are in the next layer up, and events are at the top of the Pyramid.
Ativity relationships
An important part of activity sequencing is recognizing the different
types of activity relationships. You should be aware of the following
three types of activity relationships:

• Predecessor
• Concurrent
• Successor
Predecessor

Predecessor activities must be completed before other activities begin

because predecessor can produce sequence constraints. Sequence
constraints, inherent in some activities, limit a project team's options
by dictating the order in which activities are completed. It's important
to identify sequence constraints so that activities can be scheduled
accordingly.
Concurrent
Concurrent, or parallel, activities can be completed simultaneously .
Performing activities at the same time often shortens the duration of
the project. When you're scheduling concurrent activities, make sure
enough resources are available to execute the activities at the same
time.
Successor
The start of successor activities depends on the start or end of one or
more other activities. Therefore, successor activities are links in the
chain of activity flow from a project's start through its completion. After
a successor activity is completed, it can be either a predecessor for
other activities or the final activity of a project. Some successor
activities can also be completed concurrently with other activities.
Activity dependencies
identifying activity relationships helps you describe the logical flow of
work among activities. Dependencies dictate when or how an activity
can be performed, which in turn affects activity sequencing. You should
be aware of the following three types of dependencies:

• Mandatory dependencies
• Discretionary dependencies
• External dependencies
Mandatory dependencies

Mandatory dependencies are restrictions specific to an activity, and

they require one activity to be completed before another can begin. For
example, when you're building a house, the foundation must be laid
down before the walls can be erected. Mandatory dependencies never
change. Another name for mandatory dependencies is hard logic.
Discretionary dependencies
Discretionary dependencies are restrictions outlined by the project team. These
dependencies are based on two factors. First, if there are multiple ways to perform an
activity, team members choose the best method. For example, the project team might
decide to conduct software training that is just in time" as part of project
implementation, or the team might decide to conduct the training earlier in the project
so that end users can come up to speed before implementation. Second, if there are
many activity sequencing possibilities, team members pick the one most desirable for
the project goals.

Discretionary dependencies are also called soft logic. It's important to use discretionary
dependencies only after careful consideration because they can affect the sequence of
activities for the entire project.
External dependencies
External dependencies are restrictions that result from activities
outside the project. Project managers and team members cannot
control external dependencies. These dependencies include waiting for
deliverables from other projects or waiting for approval from the
executive committee before proceeding with a project phase.
Effect of milestones on activity sequencing
In addition to dependencies, milestones can affect activity sequencing.
Milestones are important points in a project, such as the completion of
a deliverable or the start of a new phase. When sequencing activities,
you and your team members must include all of the steps needed to
achieve a milestone.