We looked at the people aspect associated with each project.

Specifically, in terms of

planning, it was the coordination among all parties involved and the smooth

integration of the various systems and mechanisms to control or reduce conflict in

complex projects that use multidisciplinary teams.

In further sessions, we will discuss about scoping, budgeting, scheduling, resource

allocation, and quality management taken up during the project planning process.

Scope Management

Scope management is a set of processes primarily

concerned with defining and controlling what is and

what is not included in the project. So project scope

consists list of all activities to be performed,

resource requirement, end result including quality

standards. Source: Google

Project management defines scope management as a set of 5 processes which are

 Plan Scope Management— Documents how the project and product scope will

be defined, validated, and controlled.

 Collect Requirements— i.e. determine, document, and manage stakeholder

needs and requirements to meet project objectives.

 Define Scope— develop a detailed description of the project and product.

 Create WBS— subdivide project deliverables and project work into smaller,

more manageable components.

 Validate Scope— formalize acceptance of the completed project deliverables.

 Control Scope— Monitor the status of the project and product scope and

manage changes to the scope.

The goal here is to achieve maximum efficiency through formation and execution of

plans. The scope management begins with a statement of goals to indicate what is the

underlying problem and what does the project intend to do?

Key Concepts for Project Scope Management

In the project context, the term “scope” can refer to:

 Product scope. Refers to the features and functions that characterize the

product or service.

 Project scope refers to the work performed to deliver the product or service

Project scope management will be affected by the life cycle approach taken. Lets

compare the way scope management differs according to the life cycle. Lets consider

two of the approaches- predictive approaches at one end to adaptive or agile

approaches at the other. In a predictive life cycle, the project deliverables are defined

at the beginning of the project and any changes to the scope are managed through

integrated change control process.

In an adaptive or agile life cycle, the

deliverables evolve over multiple iterations. At

each iteration, the detailed scope is defined and

approved. This requires decomposing the scope

Source: Google into a set of requirements also referred to as

backlog.
At the beginning of each iteration, the team will identify the highest-priority items on

the backlog list that can be delivered within the next iteration. Thus, we are repeating
three processes (Collect Requirements, Define Scope, and Create WBS) for each

iteration. Since, it involves high levels of change and it require ongoing stakeholder

engagement.

In an adaptive or agile life cycle, the sponsor and customer representatives have an

ongoing engagement with the project and provide feedback on deliverables as they

are created to meet their current needs. Two processes (Validate Scope and Control

Scope) are repeated for each iteration. In the predictive project, Validate Scope

occurs with each deliverable or phase review and Control Scope is an ongoing

process.

In predictive projects, work breakdown structure (WBS), is developed on the

approved version of the project scope statement which can be changed only through

formal change control procedures. This is also used as a basis for comparison for

Validate Scope and Control Scope processes.

Completion of the project scope is measured against the project management plan,

while completion of the product scope is measured against the product requirements.

Here, we are referring to requirement as the condition or capability which should be

present in the product or service that is being developed.

Once the scope has been defines, it needs to be validated and further changes need

to be controlled.
Validate Scope is the process of formalizing acceptance of the completed project

deliverables. Validate scope gives accepted deliverables that are formally signed off

and approved by the authorized stakeholder.

Once again, we emphasize here that the stakeholder needs to get involved early on

during planning (sometimes initiating as well) to provide inputs.

Trends and Emerging Practices in Project Scope Management

Eliciting, documenting, and managing requirements takes place within the Project

Scope Management processes. The emerging practices for Project Scope

Management focus on collaborating with business analysis professionals to:

1. Determine problems and identify business needs;

2. Identify and recommend viable solutions for meeting those needs;

3. Elicit, document, and manage stakeholder requirements in order to meet

business and project objectives; and

4. Facilitate the successful implementation of the product, service, or end result

of the program or project.

This process ends with the requirements closure. The role of the project manager is to

ensure that the requirements-related activities are performed on time and within

budget.

Considerations for Agile/Adaptive Environments

Often scope is not clearly understood at the beginning of the project in projects with

evolving requirements, high risk, or significant uncertainty.

Agile methods deliberately spend less time trying to define and agree on scope in the

early stage of the project and spend more time establishing the process for its

ongoing discovery and refinement. Many environments with emerging requirements

find that there is often a gap between the real business requirements and the business

requirements that were originally stated.

Therefore, agile methods purposefully build and review prototypes and release

versions in order to refine the requirements. As a result, scope is defined and

redefined throughout the project. In agile approaches, the requirements constitute the

backlog.

Different activities that are part of the scope management process:

1 Plan Scope Management: Plan Scope Management creates a scope management

plan that documents how the project and product scope will be defined, validated,

and controlled. It provides guidance and direction on how scope will be managed

throughout the project. Project scoping is based on the information in the project

charter such as project purpose, high-level project description, assumptions,

constraints.
The scope is influenced by both the internal and external factors. The organization’s

quality policy, methodologies will have an influence on how the scope will be

managed. The organization culture, infrastructure, personnel, market condition also

can influence the Plan Scope Management process

2. Collect Requirements

The next step in scope management is collect

requirement that determines, documents, and

manages stakeholder needs and requirements.

The the high-level project description and high-

level documented in the project charter are used

to develop detailed requirements.

Source: Google

There are different tools and techniques for eliciting requirements. The data is

gathered through brainstorming, interview and focus groups:

 Brainstorming helps to generate and collect multiple ideas related to project and

product requirements.

 Interviews. By asking prepared and spontaneous questions, information is

elicited form the stakeholders about features and functions of the desired product

deliverables.

 Focus groups. bringing together stakeholders and subject matter experts in a

focus group enables to learn about their expectations and attitudes about the

proposed product or service.

Once requirement is collected, a decision needs to be made about what to include and

what not to include or in other words refinement of the information gathered. This

can be done through voting or autocratic decision making where one individual
decides for the entire group or using a decision matrix to evaluate these ideas.

Whatever be the technique for requirement elicitation, the project manager needs the

interpersonal and team skills. This helps tea members to have a clear understanding.

Once the requirements are elicited, it is a

good idea to obtain a feedback through a

model of the expected product. Also called

prototype, it helps stakeholders to experience

the final product rather than discussing the

Source: Google abstract representation of their requirements.

Prototypes make it easier for stakeholders to give their feedback. With enough

feedback, requirement obtained become complete. Its always a good idea to create

requirement documentation to describe how the individual requirements meet the

business needs of the project.

Requirements start at a high level and become progressively more detailed as more

information about the requirements is known. A requirements traceability matrix

links product requirements from their origin to the deliverables. This way

requirements can be tracked throughout the project life cycle. It ensures that that

requirements approved in the requirements documentation are delivered at the end of

the project. In the end, it provides a structure for managing changes to the product

scope.

3. Define Scope

The Define Scope process selects the final project requirements from the

requirements documentation. The detailed project scope statement builds upon the

major deliverables, assumptions, and constraints documented during project initiation.

As more information about the project is available now, the scope is defined with

greater specificity.

The Define Scope process can be highly iterative. The project scope statement so

developed documents the entire scope, describes the project’s deliverables in detail

and provides a common understanding of the project scope among project

stakeholders. It also documents the acceptance criteria. It may contain explicit scope

exclusions which helps manage stakeholders’ expectations and reduce scope creep.

4. Create WBS

With the creation of the scope statement, there

is a common understanding among the

stakeholders. With this its time to proceed to

create work breakdown structure- i.e. subdivide

project deliverables and project work into

smaller, more manageable components. Source: Google

There are two more processes in the scope management- validate scope and control

scope. The Validate Scope is primarily concerned with acceptance of the deliverables.

Whereas, the Control Quality process is primarily concerned with correctness of the

deliverables and meeting the quality requirements specified for the deliverables.

5. Validate Scope

Validate Scope formalizes acceptance of the completed project deliverables. This

process brings objectivity by validating each deliverable. and increases the

probability of acceptance of the final product, service. The deliverables that are not

formally accepted are documented, along with the reasons for non-acceptance of

those deliverables.
This process of validate scope may be performed periodically throughout the project

as needed.

6. Control Scope

Change is inevitable; so, some type of change

control process is mandatory for every project.

Through control Scope process the scope is

monitored for managing changes to the scope

baseline. It ensures that all requested changes

and recommended actions are processed

through the Perform Integrated Change Control

process.

Budgeting

In terms of Project management body of knowledge, this is the knowledge area 4

termed as project cost estimation.

Why talk about Budget?

1. We need resources for the project. Senior management’s approval of the

project budget will allow allocation of resources. There are always constraint
while budgeting i.e. trying to fund at right level for funding. Overfunding
 produces waste and brings slack in management. Underfunding inhibits task
accomplishment, even adding to stress and frustration.
2. Secondly, budget is not just a plan for resource allocation. It is also a
mechanism of monitoring and control. It forms the baseline against which to
measure the difference between the actual and planned use of resources. In a
project, the manager deploys resources. This needs to be monitored for
deviation from planned usage to the progress. And an exception report can be
generated if resource expenditure are not consistent with the accomplishments.
If there is deviation, the pattern of deviation can be used to check if there is
going to be a significant departure from the project. With warning signs,
corrective action could be taken for the deviations.

In order to do so, data must be collected and analyzed. There should be proper
reporting process, so that the data goes to the right person at the right time. Delayed
data or sending it to the wrong person will not serve any purpose.

But budgeting should not be taken as the only measure of project progress.

In earlier session, we discussed about work breakdown structure (more commonly

referred to as WBS) that incorporated planning at different levels of project. If we
add cost step by step in the WBS, we will develop the project budget.

Estimating project budgets

As budget is dependent on the resource usage,

the first step would be to forecast what
resources would be needed, when they would
be needed, how much each resource would
cost including the price inflation. Forecasts
always have an element of uncertainty. But
somewhere it would be less uncertain than
others.
For example, software is an abstract concept where the developers write code based
on the understanding that they developed about the project outcome. Here chances of
error are higher as it is based on the number of man hours required to finish the job or
lines of code that will be required. The level of uncertainty is higher here. In case of
construction, estimation may be based per square feet and the material and time
needed to work. That is then extrapolated to the full project adding a factor of
inflation.

Every business has some way of estimating in addition to using tools and models. It
also depends on the collective experience gained over many years. Budget and audit
reports from past also serve as a guide. Although, projects are unique in nature, they
may have similarities with previous projects which can be used to forecast current
project budgets.

Another estimation technique, is earned value estimation (Zwikael, et al., 2000). Here
early in the project life cycle, the actual costs are compared to their estimates. The
actual to estimate cost ration so obtained is used to adjust the remaining costs.

Data gathering: There are two different strategies for data gathering- top down and
bottom up.

1. Top down budgeting

Here the top and middle managers, based on

their judgement, experience and past data,
create an estimate of the cost for entire project
and of the individual subactivities. These cost
estimates are then passed on to the lower level
managers who are expected to break it down for
specific tasks and wok packages.

Source: Google

This process is similar to the hierarchical project planning we discussed earlier. The
budget just like the project is broken down into finer detail starting from the top
level and follows the WBS.

Advantage of the top down process is that barring few errors, the aggregate budget
comes out quite accurate. The budget categories are stable as they are following the
project plan, its activities and subactivities. The statistical distribution within each
category is also stable. However, subordinates feel that the senior management has
strong inclination towards under estimating costs.

2. Bottom up budgeting

Another way is to go for bottom up

budgeting. Here, tasks, schedules and their
individual costs are estimated following the
WBS. To ensure best level of accuracy,
people associated with these tasks are
consulted. Estimates are made in terms of
resources and then converted to the
equivalent money. It is critical that elements
get included in the task list. It is so difficult
to create a list from bottom up. At times,
individuals overestimate their resource
needs in anticipation that senior
Source: Google management my cut budgets.

The advantage of this process is that, since it is create d by individuals closer to the
work who have more accurate idea of resource requirement, it has higher chances of
accuracy. The chance of acceptance of the result is higher by the lower level
managers since they had been involved in it. This is good managerial practice, giving
junior managers an experience in preparing budget.

Whether to use top down or bottom up approach depends on the organization and
management approach. Senior managers feel bottom up approach as risky thinking
that lower level managers do not have enough experience to think of all the
possibilities. They may be bit reluctant to hand over the control. They may feel that
their subordinates my overstate resource requirement in order to seem successful.

Whether top down or bottom up approach or a combination of both is adopted, the

major task is estimating the costs for each of project’s work elements. From the work
break down structure, each element is evaluated for its resource requirement and then
cost is estimated for each resource. This must include direct cost, overhead and any
administrative charges.
Cost category budgeting vs project/ activity budgeting

A traditional organization is process oriented

with function departments. So, the budgeting they
are used to is category oriented based upon the
historical data and expenses made by each of the
functional department which in turn was gathered
into categories. Basically, the category oriented
budget can be overlaid on the organization chart.

But as organizations are becoming more project oriented, the budget would now be
split up among many organizational functional units. This gave rise to project
budgeting divided by task/ activity and expected time of expenditure. Still the
accounting systems that organizations use may be functional not project oriented.

Improving the process of cost estimating

One thing with making plans is that things not necessarily, things will go precisely as
planned. There will be risks associated with the project. One way to account for that
is to keep 5 to 10% as contingency. Another way is to select “most likely”
“optimistic” and “pessimistic” estimate when forecasting.

Risk estimation

During planning an estimate is made about the duration of each tasks, resources
required and estimated value of the project. But all these and other aspects of project
are uncertain. While project manager works to reduce this uncertainty, it can not be
completely eliminated. So, one must be prepared to make decisions in the face of
ambiguity. Risk estimation does not remove ambiguity but provides the decision
maker with a useful insight.

There are various tools and softwares available for risk analysis such as Monte Carlo
Simulation. It creates a risk profile of the outcomes of the decision. Performing risk
analysis gives a picture of changes cost and time may experience.