Project Management Reference Notes

1
Project Management
Reference Notes
©Parag Mahajan, PMP. No parts of this material may be reproduced, stored in a retrieval system, reused, or transmitted in any
form or by any means, electronic, mechanical, photocopying, recording, or otherwise without the prior permission. Notes are
based on PMBOK 4 th Edition of Project Management Institute (PMI) USA
2
Key terms in Project Management
1. Project :
A project is "a temporary endeavor undertaken to create a unique product or service or

end result“
• Temporary: Time, People, Constraints, Assumptions
• Unique: Different in one or more parameters. Not necessarily always in functional
characteristics; but the uniqueness could be in the way it is developed, team structure, risks,
CTQs etc.
2. Progressive Elaboration :
Projects are progressively elaborated

• Progressively: proceeding in steps
• Elaborated: worked with care and detail
3. Project Management
"The application of knowledge, skills, tools and techniques to project activities in order
to meet or exceed stakeholder needs and expectations from a project.“
Key terms :
• Knowledge: functional, managerial, technical, etc.
• Skills: communication, leadership, people managing, etc.
• Tools: MS Project, SharePoint, Whiteboard, Pen-Paper, etc.
• Technique: Network diagramming, CPM, root-cause analysis, etc.
• Needs: Stated description that drives the demand
• Expectations: Assumed parameters that satisfies/ dissatisfies the user
• Stakeholder: Anyone getting effected or affected or can effect or affect by the success or
failure of the project…..!
3
Project Vs. operations ?
Operations -
• Semi-permanent charter, organization, and goals
• Purpose of status quo
• Pre defined & approved product or service
• Homogeneous teams
• Ongoing
• Fully known process deliverables
Projects –
• Create own charter, organization, and goals
• Purpose of change
• Unique product or service
• Heterogeneous teams
• Definite Start –Definite end
• Progressively elaborated process deliverables
Stakeholders: individuals and organizations who are actively involved in the project
• Often have conflicting expectations and objectives
• In general, differences should be resolved in favor of the customer – individual(s) or
organization(s) that will use the outcome of the project
• Stakeholder management is a proactive task
• Project Managers must determine all stakeholders and incorporate their needs into the project
Key project performance influencers:
• Internal Influencers : The management, Project Manager, The Team, The users, The
support teams, The sponsors, (Major Stakeholders) etc.
• External Influencers : P- E- S -T- L- E
Politics, Economics, Social, Technology, Legal (Regulatory,) Environment
4
Project Life Cycle : Definitions

• Process: A series of actions bringing about results.
• Project phase: "A collection of logically related project activities usually culminating in the
completion of a major deliverable."
Product life cycle: The natural grouping of ideas, decisions, and actions into product phases,
from product conception to operations to product phase-out.
Project life cycle: "Collectively the project phases are known as the project life cycle."
Project Life Cycle defines:

• Technical work performed in each phase
• Who is involved in each phase
Project Phases can overlap – “Fast Tracking”
Common Characteristics of Project Life Cycles:

• Cost and Staffing levels are low at start and move higher towards the end
• Probability of successfully completing project is low at beginning, higher towards the end as
project continues
• Stakeholder influence is high at the beginning and progressively lowers as project continues
Process Groups :
Integrate all the project Knowledge areas throughout “Project / Phases” with the help of
various processes.
5
Initiating Planning
Monitoring
Executin
&
g
Controlling
Closing
 Initiation process – Formally recognizes the start of a project. In this process, you need
to identify the business need and the stakeholders of the project. A business need is the
problem for which a business seeks a solution. Note that “problem” does not necessarily
indicate an error or a broken entity. Sometimes the "problem" might be that a business
wishes to upgrade one of its systems. During this process, you also identify the
assumptions, constraints, and priorities of your project. The result of the Initiation
process is the project charter.
 Planning process – Identifies the scope of the project, the tasks involved for meeting the
business need, and the cost and resource requirements for accomplishing the identified
tasks. This process also involves quality planning, risk identification and risk mitigation
planning, and procurement planning.
 Execution process – Puts the project plan into action. This process includes assigning
tasks to team members, deciding the order in which the activities will be performed,
and setting deadlines.
 Controlling process – Measures performances against the project plan. Any variance
from the project plan is identified, and a change control plan is initiated. For example, if
6
a project is delayed at the design stage, its effect on resource planning for subsequent
stages is taken into account.
 Closing process – Formally closes the project. In this process the client accepts the
project, all files are archived, and lessons are documented.
It is critical to note that all these processes are interlinked and do not follow a defined
sequence. For example, at each stage in the project, the development team needs to revisit the
Planning process to ensure that by following the current process, the business need will be
achieved. Similarly, at each stage, deviations from the project plan should be identified and
corrective action should be initiated.
7
Initiating Processes :
• To commit the organization to a project or phase (resources, priority, focus of top
mgmt, accountability of support group)
• To set the overall solution direction
• To define top-level project objectives (what are we delivering and what the organization
is seeking out of it – returns, growth, reputation, relations, knowledge base?)
• To secure the necessary approvals and resources
• Validate alignment with strategic objectives (is this our cup of tea? Is this contributing to
our mission?)
• To assign a project manager
Project Charter
"A document issued by senior management that provides the project manager with the
authority to apply organizational resources to project activities."
Contents
▪ Project Name
▪ Sponsor Name
▪ Business need
▪ Project objectives
▪ Project deliverables: Products & Service
▪ Assumptions: General & Schedule
▪ Constraints: General & Schedule
▪ Key staff
▪ Written authorization
▪ Risk identified, if any
If a PM doesn’t get a charter, PM is at loss… so one needs to DEMAND it till he/she gets one.
8
Project Scope Statement

A definition of the project that addresses and documents the characteristics and boundaries of
the project, its associated products & services as well as methods of acceptance and scope
control
Contents
▪ Project & product objectives
▪ Product and service requirements characteristics
▪ Product acceptance criteria
▪ Project boundaries, assumptions and constraints
▪ Initial WBS
Project Selection methods

Feasibility study
- Technological feasibility, Marketability, Can it be financed?
Criteria for project selection
- Benefit measurement methods (Murder boards, Peer review, Scoring models, Economic models,
Benefit-Cost analysis)
- Constrained optimization methods (Linear programming, Integer programming, Dynamic
programming, multi-objective programming)
Benefit/Cost analysis measures of Project Selection

Present value of future cash flows
• PV = FV / (1 + r) N
o FV = Future Value
o r = Interest Rate
o N = Number of time periods
Net present value: The present value of benefits minus the present value of costs
Payback period: The number of time periods it takes to recover the investment
Internal rate of return: The rate of return at which the present value of benefits equals present
value of costs
Benefit/cost ratio (BCR): Net inflows divided by Net costs
9
EVM Terms
EVM uses three key independent values, which are used together to get the performance status
and progress of the project.
Planned value (PV) or the Budgeted Cost of Work Scheduled (BCWS).

• BCWS is the physical work that was scheduled or planned to be performed plus the authorized
budget to accomplish this scheduled work.
Actual Cost (AC) or the Actual Cost of Work Performed (ACWP).

• This is the total cost that was Actually Incurred in accomplishing the work that was completed.
Earn Value (EV) Budgeted Cost of Work Performed (BCWP).

• This is the sum of the approved cost estimates for the physical work that was actually
accomplished on the project plus the authorized budget for activities or portions of activities
that have been completed.
• This value is based on the costs that were planned or budgeted to be incurred for completing
the work.
EVM Formula :
Schedule Variance = SV = EV – PV
Schedule Performance Index = SPI = EV/PV
Cost Variance = CV = EV – AC
Cost Performance Index = CPI = EV/AC
Expected at completion = EAC = AC + (BAC-EV)/CPI
BAC = Budget at completion (when the project started)
10
Project Scope Management

Project scope includes efforts required to generate products or services, and desired results of a project. Project
scope management defines the optimum total work content of a project. It ensures that only the work required to
produce the desired products or services of the project is included and there is no other undesired, unnecessary
work. When all the deliverables of a projects are identified and documented with clear boundaries, it becomes
easier for a Project Manager to manage, plan, control and execute the project successfully.
If the scope of client requirements is not fully understood and defined the project boundaries may creep inward or
outward. These changes need to be managed efficiently without affecting the relations with the customer or
sponsor of the project. Hence Scope Management forms an inherent precursor to the overall Project Management
Process.
It is important to ensure that only the work included in the scope baseline is performed during project executio n.
To exercise this control, scope management includes two processes from the Monitoring and Controlling process
group:
In short, scope management involves continuously ensuring that all the work required to achieve project
deliverables is being completed without any unauthorized changes to the scope baseline. It is important to note
that scope can refer to both product scope and project scope. However, the scope management processes
discussed in the PMBOK guide focus on managing the project scope.
• Product scope: It refers to the requirements and features of the product that the project will finally create.
Product scope description is provided as an input for developing the project charter. It can be based on similar
projects executed in the past. For example, if the project is to install lighting fixtures for a assembly line of a
car plant, historical data of product requirements for projects executed shall be of help. Product scope can
also be evolved as a part of the project. For example, while developing an altogether new software product
project team will put efforts for “proof of concept” testing to obtain further details of product features and
product scope to be included.
• Project scope on the other hand refers to the work required to deliver the product, service or result of the
project in line with all required features.
Scope Planning
Scope Planning is the process of identifying and documenting the work required to create the product of the
project. During this process, project team analyzes the information provided by project charter, preliminary scope
statement and other inputs to understand size of the project and level of complexities. This facilitates determining
the level of detailing to be done in scope management and tools to be used.
Scope Planning process creates a scope management plan.. A project’s success depends on how accurately the
project scope is defined and how effectively it is managed as the project progresses from initiation to closure. The
concept of “progressive elaboration” also holds good for scope planning as the scope management plan is
revisited, reviewed, and revised as the project progresses.
Each project will be unique in terms of it’s’ size, importance, and complexity. Hence, all projects may not
necessarily involve same level of scope planning activities. For example, a critical project like building a storm
water system in a city will require thorough, resource-intensive, and formal scoping activities. A smaller routine
project or a project similar to a previously executed project on the other hand will require less effort in scope
planning. For example, installing street lighting on a newly constructed service road in city.
11
The Scope Management Plan is generated by project team in Scope Planning. It describes how the project team
will plan, execute and control project scope throughout the project life cycle. Scope management plan provides
details of processes followed by the project management team for:
• A process that project management team will use for preparing a detailed scope statement. Scope statement
contains project deliverables & requirements.
• A process you will use to generate a work breakdown structure. WBS further breaks down the scope
statement into more manageable components. Details about how the WBS shall be maintained, what are the
approvals required and how to obtain them are also included in the scope management plan.
• A process of verifying accuracy of project deliverables before accepting the same.
• Details of how the scope changes will be controlled.
Project team will rely on expert judgment and templates to generate the scope management plan -
 Expert judgment: The inputs are to be analyzed and assessed further by people with required skills and
knowledge. This would ensure that a realistic scope management plan is created. Experts whose advice
you can seek can include the person who created the project charter, stakeholders and other project
managers who have worked on similar projects in past. Expert judgment can be instrumental in providin g
inputs on how to manage the scope of the project.
 Templates, forms, standards: The organizational process assets provide various templates that can come
handy in preparing the scope management plan. A central project office in your organization can prov ide
forms, standards, and templates to prepare the scope management plan. For example, WBS template and
standard scope change request forms used across your organization will provide information about how
to decompose the work to be performed and the components in scope change.
Scope Planning process would use information from below sources -
 Enterprise environmental factors: Scope management is influenced by enterprise environmental factors,

such as human resources, personnel policies, organization’s culture and structure, infrastructure, tools
available, market conditions.
Human resources : These influence the way in which scope is managed based on their skill levels, subject
knowledge, responsiveness to different situations, ability to escalate, and clearly communicate issues at
the right time to the right authorities.
Personnel policies : Policies governing these resources also affect the scope management decisions.
Personnel policies related to criteria for selecting people for a project, rotation, or retention policy of
resources on project are considered while defining how the scope of the project will have to be managed.
Organization’s culture and structure: Structure of organization will determine the extent of authority
project manager has in managing and controlling the project. For example, project manager will have
limited authority in functional organization and highest authority in projectized organizations. In an
organization that has cultivated aggressive culture, project manager’s suggestion to implement new ideas,
procedures will be readily accepted. Where as, a risk averse organization will not like to experiment with
the procedures and processes and will not deviate from previous project’s processes and policies. This
affects the way project team has to plan, manage and control the project scope.
12
Infrastructure refers to the equipments and facilities in organization within which the project is to be
performed. Market conditions will also govern the way project scope is managed. Make or buy decision
for the project or part of the project depends upon market conditions. For example, project team may
realize that procuring the part of the project is more economical or can improve project’s completion
schedule and so on
 Organizational process assets: Organizational process assets are the formal or informal policies and
procedures of the project that can impact scope management. These can include standard guidelines,
policies and procedures pertaining to project scope planning. Templates, historical information, lessons
learned and even scope management plan from previous similar projects can also be used to prepare the
scope management plan for current project on hand.
 Project charter: It provides information such as sponsor’s and stakeholders’ requirements, business
needs, high level project description, product requirements, assumptions, and constraints for the project.
 Preliminary project scope statement: It provides the details of project objectives, product requirements,
project boundaries, important schedule milestones, identified risks, and so on. The
 Project management plan: Project management plan provides details about how all subsidiary plans are
to be integrated to achieve the project objectives. It provides guidelines about the processes to be
followed, extent of implementation of these processes, and tools to be used.
Scope Definition
The scope management plan provides details about the processes to be followed in establishing detailed scope of
the project. After preparing the scope management plan, is Scope Definition process. It creates a document called
scope statement, which describes the project deliverables and actual work to be performed to achieve those
deliverables. The scope statement is used to manage and evaluate project performance. The scope statement
forms the basis for other processes project management documents, such as the schedule and budget. Scope
definition has a critical role to play in entire project’s success or failure.
In most projects, managers rush to start creating the schedule, risk assessments, budgets, and so on without giving
due importance to the detailed scope statement. This may lead to problems, such as inadequate time and resource
allocation for project execution. The more time you spend detailing out the scope statement, the less trouble you
will face during the execution of the project
The formal scope statement ensures that all the stakeholders have same understanding regarding the project’s
scope. It clearly states what the project will achieve and what it will not achieve. Poor scope definition process
shall mean lack of clarity for the project team about what to achieve. This in-turn will adversely affect project
baseline: rework, delay in deliverables, cost overruns and so on.
Project scope statement: Information provided in project charter and preliminary project scope statement is
analyzed, refined further in Scope Definition process along with other inputs to the process. Based on additional
information gathered till project planning phase, project scope is defined with greater details: project deliverables
and work required to create those deliverables. A detailed project scope statement conforming what is the extent
of work included and excluded from project, is essential for project success.
Project scope statement serves as an input for many of the planning processes in time, cost, quality,
communication, procurement and risk management. Hence, accuracy and extent of details covered in scope
13
statement define how well the project team can plan, execute and control the project. As the project progresses,
project team will be required to manage scope changes effectively to control project execution.
A signed scope statement is especially useful in change management. For example, a common problem in
information technology (IT) projects is scope creep. Scope creep occurs when the scope of the project as
understood at the start of the project changes to include unplanned features, products, tools, capabilities, and so
forth. A signed scope statement helps avoid this situation.
The PMBOK Guide states that a scope statement should include:
▪ Project goals – The scope statement should clearly state the goals and critical success factors for the project.
▪ Product/Service characteristics – The scope description should list the unique features that the product or
service will have. At the beginning of the project, it is not always possible to provide a detailed description of
the product’s features or functionalities. The purpose of this section is to describe the broad characteristics of
the product so that it meets the objectives as stated by the client.
▪ Explicit requirements – The project requirements section clearly states the requirements as stated by the
client, which must be met to consider a project complete and successful. These requirements are legally
binding for the organization implementing the project.
▪ Project boundaries – The scope statement must clearly state what the project will achieve and what it will not
achieve. To prevent scope creep, the scope should specify the features that will not be included in the
product. This will help ensure that the product or service being created meets the stakeholders’ expectations.
▪ Project deliverables – The scope statement should list the deliverables for the projects. Deliverables can be
delivered at the end of the project or there can be intermediate deliverables, such as a prototype or design of
the product. The project deliverables section also lists the reports that need to be sent to the client.
▪ Acceptance criteria – The scope statement should clearly state what the acceptance criteria will be for the
project. If the client has defined a bonus or penalty clause, it should be stated here. The requirements for
obtaining the bonus or the criteria on which the penalty will be implemented should be clearly stated.
▪ Project limitations – The scope statement should state the constraints under which the project is operating,
such as the unavailability of the final version of a software or unavailability of the client subject matter expert
from a particular date.
▪ Project assumptions – The scope statement should state any assumptions under which the project team is
working. For example, when creating a Web site, the project team might assume that the Web site needs to
be tested on only Internet Explorer 4.0 and above.
▪ Organizational structure – The scope statement should clearly list the key stakeholders and team members.
The hierarchy of reporting should also be clear.
▪ Risks – The scope statement should list any risks to the project. For example, in construction projects, the
delivery of raw materials by a certain date is a critical risk factor. Note, however, that risks can be positive or
negative.
▪ Schedule milestones – The scope statement should state the schedule milestones. This schedule can help the
client plan for reviews and know the health of the project.
14
▪ Funding constraints – The scope statement should state any kind of funding limitations that exist. For
example, a project might have a limitation that in the first quarter not more than $150,000 will be released to
the project.
▪ Cost – The scope statement should provide a rough estimate for the cost of the project, and it should also
assess the accuracy of the estimate.
▪ Configuration Management – The scope statement should list the documents and procedures for
orchestrating the technical and administrative processes for the project. Configuration management often
includes the change control system.
▪ Specifications – The scope statement should state if there are specification documents which the project
should comply with. The specifications shall include industrial specifications , government regulations,
technical specifications. For example, in a construction project of a high rise office building, project team must
ensure that they include the reference to safety regulations imposed for such buildings, by local governing
authorities for fire control and other safety measures.
▪ Approvals – The scope statement should state who has the authority to accept or reject a document,
Project team uses few tools and techniques in the scope definition process -
 Product analysis: Product analysis is a method of creating smaller, measurable project deliverables and
requirements based on the project objectives defined in project charter and preliminary scope statement.
Depending upon the nature of project any one of the below product analysis techniques can be used to
define scope of the product or service of the project: functional analysis, system engineering, value
engineering, system analysis, value analysis, product breakdown.
 Alternatives identification: This can be the most creative part of project planning. As the name suggests,
this is a technique to identify different options of achieving the desired project objectives. The project
team can select the best-suited option taking into consideration all the project requirements, constraints.
Brain storming and lateral thinking are often used for alternatives identification. Brainstorming is a
technique of generating and developing ideas, which is very effective when performed in a group. Lateral
thinking is about looking at the problem at hand from different angle, think out of the way to develop
different approaches to solve the problem.
 Expert judgment: Projects are often comprised of different application areas and hence to develop project
deliverables for each of these areas, expert judgment is used. For example: an expert of electrical systems
shall help preparing a part of scope statement related to laying cables, installing lighting fixtures etc
where as expert on mechanical equipments can provide inputs for scope statement on installing an
overhead crane, laying water pipe from reservoir to project site and so on.
 Stakeholder analysis: It identifies who the stakeholders of the project are, what are their interests, how
they influence project decisions. Stakeholder needs, wants are documented in project charter and
preliminary scope statement. The same are analyzed further to exactly describe stakeholder’s
expectations about product of the project. Stakeholder needs, wants are converted into quantified and
prioritized requirements.
15
While preparing the Scope Statement, project team derives required information from
 Organizational process assets:.
 Project charter.
 Preliminary project scope statement: It is developed based on the inputs received from the project
sponsors and stakeholders. Details like initial WBS, product acceptance criteria, project and product
objectives are covered in preliminary scope statement. These details are refined further in Scope
Definition process.
 Scope management plan
 Approved change requests: During the executing and controlling processes of the project, project team
based on additional information, requirements identified at that stage, will request changes. These
requested changes when approved in Integrated Change Control process can result in change to project
scope. You have to remember, that change in project scope may also impact quality, schedule as well as
cost. Relevant planning documents should also be modified.
Creating a Work Breakdown Structure

The project scope statement created in Scope Definition process provides details about the project deliverables
and objectives. It creates common understanding about the project scope amongst all stakeholders of the project.
However, these details are still at higher level and can not be used as it is for managing the project and hence are
required to be further divided and structured in a systematic manner. Project team achieves this during the Create
WBS process.
The project team divides and organizes the work to be executed, for achieving the project deliverables, in smaller,
more manageable components and creates a WBS. A work breakdown structure (WBS) is a hierarchical structure
that breaks down the deliverables of a project into small manageable parts of work. It covers the entire scope of
the project. The smallest work effort, at lowest level of the WBS, is called a work package. Work packages can be
scheduled, monitored and controlled.
To create a WBS, you can follow two approaches: you can break down the phases into work packages or you can
break down the deliverables into work packages. Whichever approach you follow, you will first need to identify the
tasks that are required to be performed in the project. You then need to break down the tasks into sub -tasks or
sub-projects based on their order of complexity. The lowest level of tasks is the level of work packages.
Note that all tasks will not be broken down to the same extent. Some tasks might need to be decomposed more
than others. It is important to be careful while decomposing tasks into work packages. Work packages should not
be decomposed excessively because it might lead to resources not being used efficiently and too much effort being
spent by the project manager to track the work packages. In other words, because work packages are used to
monitor the progress of the project, egregiously granular breakdowns will result in very tedious tracking. For
example, suppose part of your project involves programmers coding an application. Theoretically, you could
decompose this task into writing each module, each procedure, or even each line of code. Obviously this last
option is excessive. If the application were a very complicated one, then you might use individual code modules as
the work packages. For smaller applications, however, you might set the initial coding of the entire project as the
work package.
16
A Partial WBS Organized By Phases
Advantages of Creating a WBS
 A WBS provides a framework in which all the work items that must be performed to achieve the project
goals are clearly defined. The WBS helps to prevent surprises, which may come up when a project team
realizes that some other activity is to be performed to complete the task.
 A WBS helps to monitor the tasks closely. For a project to be successful, all team members must complete
all tasks on time. Because the WBS breaks down tasks into the smallest possible packages, the project
manager is able to monitor and initiate remedial actions for any variances that come up.
 A WBS is a useful tool for managing scope creep. A WBS is a scope baseline that lists all the tasks that
need to be completed to meet the project’s goals. Therefore, any scope creep is immediately detected.
 A WBS helps to motivate the team. By knowing what individual work packages must be completed, team
members can recognize short-term goals, monitor their progress towards these goals, and feel a sense of
accomplishment when the goals are reached.
Obtaining Management’s Approval
After creating the WBS, you need to get the project sponsor’s approval on the WBS. The project manager should
be ready to defend the rationale for creating the tasks and sub-tasks in the WBS. After the WBS is approved, the
project manager must present the WBS to the stakeholders. The project manager must elaborate on the phases,
17
deliverables, and tasks involved. A project manager should also be ready to address any concerns that the
stakeholders might have.
Key deliverables that project team generates at this stage are :
 Work breakdown structure: Approved WBS is the basis for many of the planning processes that are
performed subsequent to the Create WBS process. The work packages are used for :
• Cost Estimating
• Time estimating
• Scheduling
• Creating network diagrams
• Resource allocations
• Monitoring and controlling the project progress
Usually costs are assigned to work packages for monitoring and control. However, at times, the project
team can decide to assign and control costs at a level higher than the work package level. This is known as
control account.
 WBS Dictionary: Each WBS is accompanied by a document called the WBS dictionary. This contains
detailed description of all the work components. Details covered in the WBS dictionary for each WBS
component are :
• Unique identifier
• Statement of work that describes work to be performed in that work component
• Technical details and references such as drawings or specifications to be used for the specific
work component
• Organization responsible for completing the work component
• Schedule milestones to be achieved
• Contract information, as applicable
• Quality requirements to be met for the work component
• Details of other related schedule activities, resources required, cost estimate, and so on.
 Scope baseline: Approved project scope statement, associated WBS, and WBS dictionary form the project
scope baseline. These documents contribute towards preparing schedule, estimating resources, and cost.
The project team measures the project’s progress against the scope baseline and any change to the scope
baseline is authorized only through Integrated Change Control process.
The tools and techniques used in preparing the WBS are:
 Work breakdown structure templates: By definition of the project, each project is unique. However, the
projects executed within an organization can be similar in nature in terms of deliverables or project life
cycle. In such cases, the WBS used for previous project can be used as a template for the current project.
Industry specific WBS templates can also be obtained from organizational process assets, your project
management office, or standard publications like Project Management Institute Practice Standard for
WBS.
18
Decomposition: It is the technique used to generate a WBS. Decomposition breaks the project
deliverables as mentioned in project scope statement into smaller components. Some guidelines that the
project team should follow while decomposing the project are (PMBOK Guide):
• Identifying major project deliverables and work to be performed: The first step in decomposition is
to identify the major deliverables of the project and the work to be performed to achieve these
deliverables. These details are determined from the project scope statement by applying the expert
judgment technique.
• Determining structure of the WBS to organize all the project deliverables: A WBS template can be
used to determine structure of WBS to be used for the project. There are various types of WBS
structures for organizing the project deliverables. WBS can be generated by various ways, using any
of the approaches as mentioned below:
o Subprojects and major deliverables form the first level of WBS: Major deliverables are
used at the first level of decomposition in this structure. For example, in a project of
renovating office premises, first level WBS can consist of subprojects like removing the
existing furniture and disposing it, procuring new furniture. Similarly, major deliverable
such as creating a conference room for 20 people near entrance can also be at first
level of WBS.
o Subprojects for contracted component of the project: Part of the project that can be
contracted out is treated as the first level of WBS. Each contractor responsible for these
subprojects shall will develop the work required for this deliverable.
o Project phases are first level of WBS : A partial breakdown structure organized by
phases for a software project. Software development, documentation, training and
testing are four phases at level one of the WBS which are then be broken up further for
greater details.
o Combination of above subprojects, phases and / or deliverables within a WBS.
At times, the project team will not have enough information about few deliverables which will be created late in
the project life cycle. In such a situation, the project manager should wait to decompose these deliverables till
further details are available. This approach is known as rolling wave planning.
• Breaking or decomposing the WBS from one level to lower level components: While decomposing,
the project team must ensure that the WBS components in the next level are tangible, measurable,
and verifiable. Each component should have a clear deliverable: product or service.
• Assigning each WBS component an identification code or number referred to as code of accounts:
These identification codes help the project team while assigning resources and cost to the WBS
components. Additionally, the codes help while checking the status information for the work
performed by the team or individual.
• Ensuring that the level of WBS expansion is just sufficient: This is a verification phase where the
project team examines the WBS for completeness. The project team should ensure that each and
every component of WBS is defined with sufficient details to create the desired deliverables,
product, or service.
19
Information that project team uses in creating the WBS is
 Organizational process assets: As an input for Create WBS process, these provide the processes and
procedures followed within the organization while creating the WBS. Project team shall obtain details
about standard guidelines for creating the WBS, standard WBS templates used within the organization
and WBS of similar projects executed in past. These details are used a point of reference, basis to ensure
that nothing is missed out during WBS creation.
 Project scope statement: While creating the WBS, the project team must ensure that the latest and
approved scope statement is used.
 Project scope management plan: It provides the details of processes to be used by the project team while
creating the WBS. It also provides information about how to maintain the WBS, manage changes to WBS,
what approvals are required and how to obtain them during the project tenure.
 Approved change requests: Change requests approved during Integrated Change Control process may
result in changes in the project scope. The change in scope or deliverables must be incorporated in WBS.
Validating WBS
• All major elements been identified at top level?
• Decomposed into measurable components?
• Lower level(s) items necessary? All inclusive?
• Would stakeholders agree WBS is satisfactory?
• Can elements be scheduled, budgeted, and assigned to a unit that will accept responsibility?
• Too much or too little visibility and control?
• Can status reports be generated at all levels?
20
Project Time Management

Every project is a time-bound activity and must be completed within a given, agreed timeframe. To complete a
project successfully, it is important to plan and manage time effectively. Hence, project time management is one of
the important elements in project management
Project Time Management includes following processes:
 Activity Definition: This includes identifying the specific activities that must be performed to produce
various project deliverables. These activities are derived from the work breakdown structure (WBS).
 Activity Sequencing: This includes identifying and documenting the interdependencies between the
activities. These interdependencies determine the sequence in which all the activities must be performed
to achieve the project deliverables.
 Activity Resource Estimating: This involves identifying the type of resources and their quantity required
to perform each activity. Resources include people, material, and equipments.
 Activity Duration Estimating: During this process the number of work periods required to complete each
schedule activity is estimated based on various inputs, such as schedule activity s cope of work, resource
types and quantities required, resource availability.
 Schedule Development: This involves creating the project schedule by using the information gathered in
the activity definition, activity sequencing, and activity duration estimation phases.
 Schedule Control: This involves determining the actual status of the project; identify if there is a change
from schedule baseline; and manage and control the changes to the schedule.
Out of these six processes, Schedule Control process is part of Controlling and Monitoring Process Group and
other processes are part of Planning Process Group. These processes result in creating a project schedule,
which contains the start and end dates for each schedule activity, important milestone along with other
details which then become the basis for schedule control.
Before we discuss the project time management processes in details, it is important to mention about the
schedule management plan, which is a part of project management plan. This plan is developed before the actual
work on time management processes is started by the project team. Schedule management plan defines the
approach, basis for creating and monitoring the project schedule. It explains the how to structure, prepare, and
control the project schedule and what needs to be done to incorporate changes in project schedule. Schedule
management plan will be updated, if required, during the Schedule Control process.
Activity Definition process

The activity definition process is the first step towards creation of the project schedule. Each activity at lowest level
in WBS, referred to as work package, is decomposed into smaller elements called schedule activities. Project
manager needs to identify and prepare a comprehensive list of schedule activities that must be performed to meet
the project objectives. Such list is known as activity list and is an output of Activity Definition process. Activity list
provides description about each schedule activity to be performed in sufficient detail, to help the project team
understand what work is to be performed. Project team utilizes this information to estimate cost, resources and
time required to complete the activities and determining project schedule. It is very important to ensure that there
are no errors in this part, which otherwise will result in changes in project schedule and estimates.
21
Activity definition process would deliver below artifacts / details during the planning processes:
 Activity List: The activity list created during this process is used to ascertain whether all the deliverables
identified in the WBS are taken into account and whether the necessary work is mapped to the deliverables.
The activity list also helps to ensure that only work identified in the scope document—and no extra work—is
taken into account. The activity list is part of project management plan. The activity list has details associated
with it, which communicate to the project team what work is required to be done by them.
 Activity Attributes: These provide information about various aspects of the schedule activity, such as
description of the activity, predecessor or successor activity, dependencies with other activities. It also
contains details about the activities which can be performed in parallel or for which a certain gap is required,
and imposed dates for schedule activities which require the activity to start on a particular day or finish before
a certain date . These attributes provide vital information for project schedule development and are
particularly useful for selecting and sorting the schedule activities in a meaningful manner, in reports.
 Milestone List: This phase also results in the creation of a milestone list. A milestone is an important event
that marks the completion of a key phase of the project life cycle. Milestones can be mandatory or optional.
For example, completion of the application design might be an important milestone in a project for creating a
new application
 Requested Changes: While reviewing the WBS, the project team and the project manager may discover
discrepancies or inadequacies in the WBS. Activity definition process provides an opportunity to the project
team and the project manager to request changes in project scope statement and the WBS. These changes
can be reviewed and incorporated through Integrated Change Control process.
Project team can use various tools and techniques while creating activity list and other deliverables as discussed -
 Decomposition: It involves breaking the lowest level of work breakdown structure, work package, into smaller
activities called schedule activities. Schedule activity is more manageable and smaller as compared to work
package. Schedule activities combine to deliver the work package deliverables and the work package
deliverables contribute to project deliverables.
 Templates: These can be used for producing the activity list, which is an output, of this process. Any standard
activity list or an activity list of some old project can be used as a template. Details, such as activity attributes,
milestones, and resource requirements contained in the templates help in directing the project team to create
the new activity list.
 Rolling Wave Planning: This approach is applicable when the projects are of long durations or complex in
nature or all the project requirements are not clear. These unknown factors make it difficult for the project
team to actually break the WBS down to work package level, as information about all the deliverables is not
available at the time of creating WBS. In such case, project team applies the principle of progressive
elaboration and disintegrates only those work packages to schedule activity level for which sufficient
information is available. However, for the work to be performed much ahead in project, project team may not
create schedule activities from the lowest level WBS components and may do this detailing in future
 Expert Judgment: Experienced and skilled team members, experts who have worked on creating project
schedules, WBS, and scope statements can guide in creating the detailed Activity List for a project.
 Planning component: When a branch of WBS can not be broken down to work package level due to lack of
complete information about project scope, the last component in that WBS branch is known as planning
22
component. These planning components are used during project planning to plan the schedule work at high
level. There are two planning components:
o Control Account: Control account is a WBS component placed on the WBS at a level higher than work
package level and is a management control point. Control account forms the basis of planning till
information to break the WBS component further to work package level is available with the project
team. It is essential to document the work to be performed within the control account. Project team
will maintain a separate document, control account plan, for this purpose.
o Planning Package: This is a WBS component between control account and the work package. In case
of a planning package, work content is known, unlike control account, but it does not have detailed
schedule activities associated with it, like work package.
Apart from WBS & WBS Dictionary, other key references project team needs to consider in creating the Activity List
are:
 Enterprise environmental factors: Scheduling software tools available and project management information
system used within the organization are important inputs during this process.
 Organizational process assets: Organization’s policies, rules and guidelines pertaining to activity planning are
considered during this process. While creating the activity list, lessons learned data base and historical
information are to be looked into to find out how schedule activities were created, managed in past, what
turned out to be good or bad for the project and so on.
 Project scope statement: Details of project deliverables, constraints and assumptions covered in project scope
statement should be analyzed during activity definition. Constraints refer to the limitations imposed on the
project team such completion dates, availability of resources, funds and so on. Assumptions refer to the
aspects, issues of project which were considered and documented during project planning such as receipt of
3rd party equipment at works on week 21 of the project start, availability of 24 hour electricity and water at
the construction site to carry out the work round the clock.
Activity Sequencing
After obtaining the details about schedule activities, their predecessors, successors, and their scope description,
project team will compile it into activity list and activity attributes in Activity Definition process. Next logical step
for schedule development is Activity Sequencing which includes identifying and documenting the dependencies
between activities in logical order. This step involves reviewing the schedule activities in detail, product
characteristics, assumptions and constraints in order to determine the relationships between activities. It is
important at this stage to revisit the project scope statement and review available activity details for overall
accuracy.
The relationship or dependency between activities helps to determine whether the project should move forward
or wait for some activities to be completed. It also helps to distinguish between activities that can move in parallel
with each other and activities that must be completed before another activity can start, for example concrete
foundation of a building can be laid only after excavation of land is completed. However, electrical wiring and
plumbing activities can be done in parallel, once construction of the building is completed.
Project Schedule Network Diagrams get prepared as a result of activity sequencing process. This is a schematic
representation of schedule activities with their inter-dependencies. ADM and PDM are two different ways of
drawing project schedule network diagrams. These diagrams have associated descriptions to explain the
23
considerations made by the project team while sequencing the activities, details of discretionary dependencies,
and reasons for unusual sequencing.
Methods and techniques for creating the project network diagrams

The project team will use the activity dependencies and other inputs to prepare a project network diagram, which
represent the activity sequencing in a project. A project network diagram provides detailed information on the
tasks that must be performed for completing a project, and the sequencing of these tasks. A project network
diagram helps to perform:
 Project planning
 Tracking and monitoring of the project progress
 Developing contingency plans
 Monitoring resource requirements
A network diagram includes individual activities that must be completed before the project as a whole can be
completed. These activities are derived from the WBS. However, it is important to note that all the activities in the
WBS need not be denoted in a network diagram. Sometimes, it may be enough to include summary tasks on a
project network diagram. Projects can also be split into several smaller network diagrams. The network diagrams
can be created by using any of the two methods Precedence Diagramming Method (PDM) or Activity -on-Arrow
(AOA) method.
 Precedence Diagramming Method: In the Precedence Diagramming Method (PDM) networking model,
which is sometimes called the Activity-on-Node (AON) networking model, a rectangular node is used to
represent an activity. Arrows indicate relationship between various activities. To create a PDM diagram,
the project managers must think through the various tasks and identify the predecessor and successor
tasks. All the tasks in this technique, including concurrent tasks, must be linked to each other. The tasks
are linked together with arrows, and the arrows are always upstream, that is, they point from predecessor
to successor. This relationship between tasks determines the dependencies between tasks. Figure
represents a PDM / AON network diagram. The activities are represented as A, B, C, D, E and F, where A is
the first activity on the network and F is the last activity.
A PDM / AON network diagram
The dependencies between activities can be one of the following types:
1. Finish to start (FS) – According to this relationship, the predecessor task must finish before the
successor task starts. This is the most common relationship in projects. An example of this type
of dependency is “Water fall model” of Software Development Life Cycle – requirements must be
24
finalized first, then design should start, once design is completed then coding should start and so
on.
2. Start to start (SS) – According to this relationship, the successor task must start together with or
after the predecessor task. However, the tasks might or might not finish together. The tasks that
start together are closely related to each other. For example, you must commission new
software for your client by a certain date and also provide training for their team members. In
such a case, some members of your project team can start installing the software while the
others can start training the client’s team.
3. Finish to finish (FF) – According to this relationship, the completion of successor task depends
upon the completion of predecessor task. This dependency uses the just-in-time scheduling
approach. In the just-in-time scheduling approach, you place a new order for an item only when
your stocks for the item are just enough to keep the production going till the expected delivery
date of the new order. This approach is based on the consideration that you want to minimize of
storage requirements of items, cut down the investments in inventory.
4. Start to Finish (SF) - According to this relationship, the predecessor task must start before the
successor task can finish. This relationship is not widely used.
Types of activity dependencies
 Arrow Diagramming Method: Arrow Diagramming Method (ADM) also called as Activity-on-Arrow (AOA)
method, is a diagramming technique in which activities or tasks are represented as arrows, and events are
represented as circular nodes. The activities are connected together at points called nodes to illustrate
the sequence of activities. A node or an event represents the starting and ending points of an activity. The
event represented by the node has zero duration and does not use any resources. All activities that lead in
a node must be completed before the activities moving out of the node can start. The AOA method works
best for smaller projects; large-project diagrams can be cumbersome and confusing.
Unlike PDM, only finish to start type of relationship is used for showing interactivity dependencies in ADM
method. At times dummy activities are used to indicate dependencies accurately. Dummy activities are
shown by dotted lines and do not consume resources, do not have a work content and hence are zero
duration activities. Activity K in the Figure 4-5 below is an example of dummy activity.
25
An ADM / AOA network diagram
Apart from PDM & ADM, there are few other tools and techniques that can be used by the team
 Dependency Determination
Dependency is the relationship between activities which states how one activity is dependant on another
to start or complete an action. Dependency determination is a technique that deals with deciding
whether such activity dependencies exist or not. The types of dependencies used to define the activity
sequence of a project are:
1. Mandatory dependencies: Mandatory dependencies are also known as hard logic or hard
dependencies. These dependencies are inherent in a project, and the nature of work to be
performed establishes these dependencies. Physical limitations, functional considerations lead to
mandatory discrepancies. For example, you cannot start creating an application until you have
installed the software on which the application must be built. Another example of mandatory
dependency can be, you cannot drive a car without wheels.
2. Discretionary dependencies: These dependencies are also called soft logic or preferred logic or
preferential logic. Discretionary dependencies are defined by the project team. They include
good practices that the project team wants to implement based on past experience from
successful projects. For example, the project team will decide to start with the testing phase only
after all the modules of an application have been created. Discretionary dependencies limit
scheduling options for the project and hence project manager should obtain the buy-in of all the
stakeholders on the limitations caused as a result of these dependencies. Project manager must
record these dependencies in detail..
26
3. External dependencies: These dependencies occur because of external factors and include the
relation between project and non-project activities. These can be based on historical information
from previous projects or terms and conditions of contract. For example, a project might be
dependent on the delivery of an important component by an external vendor.
 Schedule Network Templates: Standardized templates can be used for creating the project network
diagram. Templates can be used to develop network diagram for the entire project or a small portion of it.
Previous project’s network diagram can also be used as a template. Similarly, when a project has many
identical deliverables, network diagram prepared for a particular deliverable can be used as a template
for balance deliverables. For example, schedule network diagram prepared for construction activities of
first floor of a building can be used for other floors as well. Templates save time of the project team and
give a kick-start to thinking process about project schedule network creation.
 Applying Leads and Lags: While determining the sequence of activities, you must identify the lead and lag
activities. Lead activities are activities that can run parallel to each other and help to reduce the schedule
duration. For example, you can start the installation of new software while your team is being trained on
it.
Lag activities are those activities that require a gap between two activities. Lag activities increase the
schedule duration. For example, you might need two days to physically move some server computers
from one location to another, so that you can start configuring the same at new location.
While creating the project schedule network diagram, project team shall require comprehensive list of schedule
activities, their description, dependencies and many other details captured in activity list and activity attributes
during the Activity Definition process. Milestone list provides the schedule milestones to be achieved during the
project. There are two more artifacts that are considered -
 Project scope statement: This is revisited to ensure that the product scope description reflected in activity
list and activity attributes us consistent with the original requirements and there are no discrepancies.
 Approved change requests: Approved change requests can result in change in project scope, activity
dependencies and hence are to be reviewed for their impact on Activity Sequencing process.
Activity Resource Estimating

After identifying dependencies between the activities and preparing a network diagram next step in schedule
development is estimating resources required to complete each of these activities. Resources can be people or
equipments or material or combination of any of these. Activity Resource Estimating deals with determining the
type and quantity of physical resources required to complete each schedule activity.
Resources contribute significant portion of project expenses and hence it is important to have a close co-
ordination between Activity Resource Estimating and Cost Resource Estimating processes
27
To determine how many resources, and of what type, will be required for each schedule activity project
management team will be required to review - Enterprise environmental factors, Organizational process assets,
Activity list, Activity attributes and Project Management Plan. Theere is one more :
 Resource Availability: As the name suggests, it explains for each type of resource, the period when the
resource (people or material or equipment) will be available to perform the schedule activities. It assists
project team to estimate the resource types considering factors such as geographic location of resources
and when the resource may be available. For Example – In case of a software project, project managers
wants to start testing the product immediately after the development end date of 15 th June. However the
resource availability document states that the testing resource is available only after 1 st August. In such
case, project manager needs to make schedule adjustments or explore alternative solutions such as using
another resource with less skill level, automated testing or outsourcing the testing till 1 st August etc.
Project team would generate below deliverables in the Activity resource estimating process:
 Activity Resource Requirements: It describes, for each schedule activity, the type of resources and their
quantity required. Using the same concept of bottom up estimating, the resource requirements of work
package are calculated by adding the resource requirements for all schedule activities under that work
package. The manner in which estimates were made, assumptions about resource availability made
during the process are also to be documented with the schedule activity. Details from Activity resource
estimating are used in Activity Duration Estimating process.
 Activity Attributes (updates): Activity Attributes are updated to include the resource details captured for
the schedule activity which are type and quantity of resources. Approved Change requests originating as a
result of this process, will also lead to updates in Activity List and Activity Attributes. For example, due to
resource constraints it is required to start the testing of software in parallel with the last phase of
software development against the original plan to start testing after completion of development. This will
lead to change in activity description, dependency details for both the activities, modifying activity
attributes.
 Resource Breakdown Structure: Resource Breakdown Structure is a representation of resources identified

to work on schedule activities. This hierarchical representation is done by resource category and resource
type.
 Resource Calendar (Updates): Resource calendar for a project covers information about working, non-
working days as well as quantity, availability and skills for each type of resource. Resource Calendar gets
updated to the extent to which the details recorded therein are affected during this process. Resource
calendar specifically identifies resource specific holidays (in case human resources), availability periods
(for equipments, material resources).
Further, as a result of all the analysis and review during this process, project team may also request changes in
project scope statement, WBS.
Project team uses various tools and techniques used in resource estimating -
 Expert Judgment: A person or a group who has expertise in resource planning and estimating is often
useful in assessing the inputs for this process.
 Alternatives Analysis: Many times there are more than one ways of performing a schedule activity and
achieve deliverables. Alternatives analysis aids in choosing from the possible alternatives. Project
manager can use different skill or size of resources, for example, during design stage of the project senior,
28
skilled resources can be used to finalize the outline and architecture of the product and as the project
moves to execution stage, less experienced resources can work on it. This can be true even for machines
or group of machines, high precision machines like grinding machines can be used in final operations
where as low precision machines can be used as first stage processing of the job. Similarly, adding or
reducing number of resources based on schedule requirements, make or buy decision are some other
types of alternatives to choose from.
 Published Estimating Data: There are various authorities and companies that regularly publish the
industry rates, guidelines, rates of resources across the resource types and geographic locations. Such
published data is referred to during this process to ensure that the estimates are fairly accurate.
 Project Management Software: It can help in estimating the resource requirements, documenting
availability of resources over a period of time and managing the resource pool. Based on the capability of
the software, resource calendar, resource rates, resource breakdown structure and resource availability
status can be developed.
 Bottom-up estimating: It is the process of estimating resources or even cost of resources (as the case may
be), at the lowest level and adding it up to get the total. When the schedule activity can not be used for
fairly reliable estimating, the activity is further broken down into smaller, detailed parts. Resource
estimating is done for these detailed parts and added up for each type of resource to get the resources
for the schedule activity. As this estimating is performed at detailed level rather than at higher level, the
estimates are more accurate. However, this method is very time consuming as each and every activity
needs to be evaluated and estimated accurately. Cost of this technique is directly proportional to the level
of accuracy desired, as higher level of accuracy means smaller and more detailed activity. For example, in
a project a WBS component is procurement of steel required for manufacturing a water tank. In bottom-
up estimating process, this element would be further broken down to find out quantity, cost of each of
the below mentioned items and then the total requirement is found out:
o 12 mm thick steel plate required
o 8 mm thick steel plate material
o 10 mm diameter steel rods
Activity Duration Estimating

After defining activities, determining their sequence & estimating resource requirements the next step is Activity
Duration Estimating. It refers to the time, resources, and work period required to complete the schedule activities.
Depending upon the nature of project work periods can be in days, weeks, months or in hours.
The duration of an activity includes the amount of time required to complete the activity and the time elapsed
before the start of the activity. For example, a project might require 40 work hours. But the resource working on
the activity might be available for only 4 hours per day. The duration will be 10 working days.
At the early stages of process duration estimates would be at a high level and would have to be progressively
elaborated when additional details about the deliverables, activities are available. Duration Estimates are critical
for the success of any project. Project team at this stage will generate below artifacts / details -
 Activity duration estimates: Activity duration estimate is the primary output of this process which gives the
estimated work periods required to complete the schedule activity. These quantitative measures are
expressed in terms of hours, days, weeks or months as the case may be, depending upon the nature of the
project. These estimates contain the range of expected activity durations, to indicate the effect of contingency
reserves. In our example of first slab of the building construction project, activity duration can be expressed as
29
15 hours +/- 10%. The variance of 10% indicates that the activity can be completed in 13.5 hours as minimum
or 16.5 hours as maximum.
 Activity attributes (updates): Activity attributes will be updated as an output of this process to include the
activity durations and assumptions, if any, made during this process to compute the activity durations.
While estimating the duration of an activity, inputs that are taken into account by project team are:
 Enterprise environmental factors: Organizations involved in the project will have a compiled reference data of
duration estimates and other related historical information. Such details can also be made available
commercially and are useful when activity durations are independent of the amount of work to be performed.
For example, what is the transit time for a shipment between two ports? This duration is independent of the
weight of the cargo: 1000 kg or 15000 kg and can be obtained from the enterprise environmental factors.
 Organizational process assets: Projects undertaken by an organization will have some common activities with
the projects completed in past. Historical data for such old projects can provide possible durations of s ome of
the activities. Details such as working and non working days, shifts on which schedule activities will be
performed are contained in a project calendar, which is received by the project team as a part organization
process assets.
 Project scope statement: Constraints and assumptions in project scope statement are reviewed during
estimating activity durations. Constraint is a limitation that narrows down the project’s options, affect the
outcome and impact the schedule of a project. For example, a critical employee going on leave during the
project, or the availability of a resource only on a particular date for a few hours, impacts the duration of the
activity. Similarly, all assumptions must also be reviewed to understand its impact on activity duration. For
example, assumption that the stainless steel material required for fabrication shall be available in batches of
5000 kg, for further processing in a schedule activity. This assumption may affect the activity duration
depending upon the capacity of machines selected to process the steel material received.
 Activity resource requirements: The resources identified to work on the schedule activity and their availability
will determine the activity duration. For example, if a particular task requires two software programmers, then
adding two more programmers might help in reducing the activity duration to a certain level. However, adding
10 more programmers might not yield favorable results. Law of Diminishing Returns, as it applies to project
management, states the tendency of a project to at first become more efficient and then less efficient as more
resources are added for a particular task.
 Resource calendar: Resource calendar provides information about the availability, quantity and capability of
human, material or equipment resources. Skill level and potential of human resources to perform schedule
activities will also be provided by resource calendar. These details contribute while estimating the activity
duration. The project manager may account for illnesses, resignations, and leaves while estimating duration of
activities for human resources.
 Project management plan: Risk register and activity cost estimates which are part of the project management
plan provide vital information to the project team while preparing duration estimates. Risks can have a
significant influence on durations and hence the project team will include appropriate amount of reserves for
high priority and high impact risks. Where as, activity cost estimates when available, provide the quantity of
resources required for schedule activities and aid in estimation of activity durations.
There are several tools and techniques used in this process:
30
 Expert judgment: Team members who are responsible to execute the activities can provide the most realistic
and accurate duration estimates based on their experience of carrying out similar activities in past. Expert
judgment along with historical information will be used by project team whenever possible as, the estimating
activity duration is a complex exercise and depends on many factors, such as resource level, resource
efficiency, risks identified, constraints imposed.
 Analogous estimating: This is also known as top down estimating. This technique can be used for a project as
well as for an activity. When project team has limited amount of information at the beginning of the project,
top down estimating is used for estimating the project duration. Basic requirement for such estimating is the
activities to be performed must be similar in nature and content with activities performed for a project
executed in past. Expert judgment is required to provide reasonable estimates based on historical information
available. This technique can also be useful during project selection process. The project team can provide
duration estimates to the project approving authority, to map it with business requirements and set priorities
amongst projects.
 Parametric estimating: This is an estimating method based on quantitative determination of activity duration.
It uses the information available from historical records, standards published or other information for
determining the projected duration. Quantity of work to be performed is multiplied by the rate at which work
can be performed, to find out the activity duration. For example the total concreting to be done for a first
floor slab during a construction project is 150 cubic meter and the rate of concreting with the available
machinery is 6 minutes per cubic meter, then the estimated duration of the activity is 900 minutes, that is 15
hours. Parametric estimating is used when detail information is not available to base the duration estimates.
Learning curve principle can be used for parametric estimating, as applicable. If the same resource is working
on a project of creating 10 software application modules, amount of time required to develop 10 th module will
be less than the first module as a result of improved work efficiency, knowledge gained in the process.
 Three-point estimates: When the activity estimates are uncertain, you can use three point estimates to
determine the activity duration. It uses a weighted average of three different duration estimates for
calculating the duration for each activity. In this technique, final time estimates are based on three types
estimates of activity duration: optimistic, most likely, and pessimistic. Most likely duration of an activity is
based on availability of resources as planed and there are no failures. Optimistic duration of an activity is the
fastest time in which the activity can be completed, and pessimistic duration estimates refer to the slowest
time in which the activity will be completed taking into consideration the possible hick -ups, failures. These
three estimates are used to calculate a weighted average for the duration estimate of each schedule activity.
Activity duration = [optimistic time + (4 * most likely time) + pessimistic time] / 6
PERT helps to project the completion date and to determine the probability of completion before a specified
date. It also helps to identify the activities that allow slack and are capable of lending resources to critical
activities.
However, these time estimates are subjective and may not be accurate because they are dependent on the
expertise and experience of the project manager.
 Reserve analysis: Project team can include some additional time in the project schedule to cover the schedule
risk. Inputs received from risk register and other details obtained during the Activity Duration Estimating
process assist the project team to decide upon the additional time also referred to as contingency reserve,
buffer or time reserves. This reserve can be calculated as a percentage of total duration or can be fixed work
periods. For example, in the earlier example of construction project the project team may choose to add a
31
contingency reserve of 10 % to ensure that the risks do not impact the project schedule. In such case, the
activity duration for first slab concreting shall become 16.5 hours (15 hours as estimated + 1.5 hours
contingency).
Schedule Development
After gathering all the schedule activity information such as detailed scope of work, dependencies and sequence in
which the activities are to be performed, resources required and estimated activity duration, in the earlier phases,
project team can start creating the project schedule. Schedule Development process determines the planned start
and planned end dates of each schedule activity. When resources are assigned and committed scheduled start and
scheduled end dates are obtained. Creating a realistic schedule is one of the most important tasks in planning
process as it provides a basis for monitoring the progress of the project.
In schedule development project team will generate below details -
 Project Schedule: It is a primary output of the Schedule Development process. It will contain information
about the start and finish dates for each of the project activities, resource assignments to perform those
activities. Project schedule must be approved by the project stakeholders before the same can be used for
managing the project execution. Schedule can be expressed in different forms such as
o Bar chart: This is a tool commonly used to display project schedule information. It is also known as
Gantt chart. Bar charts list project activities and their corresponding start and finish dates in a
calendar format. These bar charts use horizontal bars to illustrate the start and end time of activities.
The activities on the Bar chart coincide with the activities on the WBS. Bar charts provide a standard
format for displaying planned and actual project schedule information and are easy to create and
understand. Bar charts have limitations such as they do not give detailed information about individual
tasks and the relationships between tasks, they are better suited for smaller projects.
o Project Schedule network diagram: It shows activity dates, dependencies between them and critical
path of the project. AON and PDM are few of the ways of presenting the project schedule.
o Milestone charts: Milestones indicate completion of major deliverables of the project. For example,
in a software development project, approval of marketing requirements document, approval of
software design document, completion of integration testing, completion of acceptance test can be
some of the milestones of the project.
 Schedule model data: It refers to the supporting documents for the project schedule. It will include
milestones, schedule activities, activity attributes, assumptions, constraints, resource assignments,
contingency reserves. However, extent of details to be included should be just enough for the project
requirements and project team should try and avoid giving too much information.
 Schedule baseline: This is the version of project schedule which is approved by the project management team
and stakeholders. This provides baseline start and baseline end dates of the project. As the project progresses
project management team will keep on performing the iterative processes in planning, executing, monitoring
and controlling process groups, which can result in changes in project schedule. Schedule baseline provides an
basis for comparison for all such schedule changes and helps identify the difference between planned and
actual schedule.
In the process of creating the project schedule, project team will modify few of the outputs created in earlier
stages of the project planning: resource requirements, activity attributes, project calendar, project management plan,
schedule management plan and also result in requested changes..
32
Tools of Schedule Development

The commonly used tools and techniques for creating a schedule are:
 Critical path method (CPM) – A technique that helps to create and manage the schedule.
 Critical chain scheduling – A technique that helps to take resource constraints into account.
Critical Path Method
Critical path method (CPM) is a technique that is used to determine the project completion date. The critical path
is the longest path of tasks in a project that must be completed on time to ensure that the project meets the target
end date. The critical path does not have any slack or float. Slack or float is the time by which the project can be
delayed without affecting the project deadline.
Figure 4-8: Network Diagram for a Project
In this sample CPM chart for a fairly simple project, there are only two paths: ABCF and ADEF. By summing the
days for each of the two paths, we can tell that ABCF will take 6 days (1+2+3) and ADEF will take 8 days (2+3+3).
Therefore, the critical path is ADEF because it takes the longest amount of time. If any task along the ADEF critical
path extends beyond its scheduled duration, the entire project will be affected. By contrast, the ABCF path has a 2 -
day slack time, which means it can go over by 2 days before affecting the entire project.
The activities on a critical path must be completed on schedule for the project to be completed on time. However,
this does not mean that the other activities need not be completed. The other activities must be completed but
they are allowed slack.
It is important for the project manager to monitor the critical path throughout the life of the project. Monitoring
the critical path helps to make tradeoffs. For example, if one of many critical paths is behind schedule, the project
manager can decide whether adding more resources will help to bring the project back on track or whether the
project manager should renegotiate the project end date with the stakeholders. M onitoring the critical path
enables the project manager and the team to manage the project schedule in a proactive manner.
33
In case of multiple critical paths, the project manager should manage each critical path separately and monitor the
activities on each critical path closely.
To make schedule tradeoffs, you can use a technique that determines the free slack and total slack for each
activity. Free slack is the time by which an activity can be delayed without delaying the start of the next activity.
Total slack is the total time by which an activity can be delayed without affecting the project deadline.
To find the slack for each activity, you can use the forward pass and backward pass techniques. Forward pass
determines the early start and early finish for each activity. Early start is the earliest time by which an activity can
start provided its predecessor activities are complete. Early finish can be calculated by adding the early start for
the activity to the duration of time required to finish the activity.
Backward pass determines the late start and late finish for the project. Late finish is the latest time by which an
activity can be completed without affecting the project deadline. Late start is the latest time an activity can be
started without affecting the project's scheduled completion. It can be calculated by subtracting the time required
to complete the activity from the late finish.
Critical Chain Scheduling
Critical chain scheduling is a method that takes into account resource availability and buffers when creating the
project schedule. To determine the critical path, you do not require a knowledge of the resources that will be
working on the project. However, when creating the project schedule, you must take into account the limited
resources available for the project.
Critical chain scheduling takes into account the effect of both Parkinson’s Law and Murphy’s Law. Murphy’s Law
states that whatever can go wrong will go wrong. In order to safeguard against the uncertainties in a project, most
project managers try to add buffer. Buffer is the additional time required to complete a task and account for
various factors such as diversion, multitasking, and pressure. However, in most projects, the buffer added within
the activities is slowly used up. This leads to increased project risks.
Critical chain scheduling limits the effect of Parkinson’s Law and Murphy’s Law by adding buffers at the end of the
activity. In critical chain scheduling, the buffer is not added to the activity but as a separate time after the activity.
For example, a task takes two days and should finish on the 22 nd of March. In some approaches, the buffer would
be added to the activity and the revised schedule would indicate that the task must be completed on the 24 th of
March. However, critical chain scheduling indicates that the task must be completed on the 22 nd of March and the
time until the 24 th of March is the buffer. The project manager needs to monitor a task that is using its buffer in
order to see how the condition will affect the deadline.
Critical chain scheduling also discourages multitasking. Multitasking occurs when a resource works on more than
one task at a time. Critical chain scheduling assumes that resources do not engage in multitasking. When critical
chain scheduling is in effect, a developer cannot be simultaneously assigned to two tasks of the s ame project. If
multitasking is prevented, resource conflicts and time wasted in shifting between the tasks are also avoided.
Techniques for schedule optimization

The project team can optimize the duration of the project by assigning more resources, allowing activities to start
in parallel or by ensuring that resources are uniformly used throughout the project. Schedule compression and
resource leveling are most commonly used techniques for schedule optimization.
 Schedule compression: The project manager and the project team can shorten, or compress, the project
schedule by using two common techniques: crashing the schedule and fast tracking.
34
Crashing is one of the techniques used for shortening the project length. Crashing allows the project manager
to add more resources to effort-driven activities so that the activities will be completed faster. For example, to
crash the schedule, you can assign four resources instead of the two resources you had initially planned.
Crashing, however, leads to increased costs. Also, crashing does not always work; some activities require a
certain effort, and adding more resources to those activities does not help to shorten the schedule.
For instance, suppose one activity of your project is to stress test the Web site you are building. Further,
suppose that the stress test is done by software that, once a testing engineer configures it, is almost entirely
automated. If you originally scheduled and budgeted for one testing engineer to configure the software, and if
you later wanted to shorten the duration of this activity, you might be able to do so by having a second testing
engineer assist the first one. Adding a third and fourth engineer, however, would likely not further reduce the
duration because the configuration is not that complicated and the software may not allow numerous
engineers to be configuring it simultaneously.
Another technique that you can use for schedule compression is fast tracking. Fast tracking involves
performing activities that would normally be done in a sequence, in parallel with each other. For example, you
might initiate the writing of the second chapter of a technical writing project while the first one is still being
written. Fast tracking, however, leads to increased project risks
 Resource Leveling:
The success of a project partly depends on how well the project manager can manage the tradeoffs between
time, costs and resources. Resource leveling is the technique that project managers use to ensure that
resources are used uniformly throughout the life cycle of a project. To do so, they postpone or advance the
start or finish of a task by examining the project’s network diagram and identifying areas that have slack time
or float. Resource leveling has several advantages:
• Resource leveling enables project managers to predict the duration for which the resource will be
required. This visibility removes the uncertainty that a team member might have, increasing the
commitment towards the team.
• Resource leveling enables project managers to use a just-in-time (JIT) approach. This ensures that project
managers bring in expensive resources just when they are required.
• Resource leveling results in smooth operations because project managers can predict future requirements
of expensive external resources. This helps in negotiating the best possible deals with external resources
because the project manager is able to offer a clear visibility of future requirements.
There are few other tools and techniques used:
 What if analysis: What-if analysis: This is an analysis of series of questions that project team will ask itself to
assess the feasibility, probability of achieving the project schedule. Questions such as “What would happen if
hoist is not available in the building, for erection of equipments or what will happen if only 10 resources are
available instead of required 15 resources ?” are analyzed by the project team. Schedule network analysis is
performed using schedule data and information, known as schedule model, to compute effect of different
scenarios on the project schedule. Monte Carlo Analysis is a commonly used simulation technique to evaluate
effect of possible activity durations on overall project schedule.
 Project management software: It is widely used in schedule development. The software can be useful for
analyzing the various scenarios, resource leveling, automated calculations for the forward or backward pass
and generating various schedule alternatives.
35
 Applying calendars: Project calendars and resource calendars are used to determine dates when actual work
will be performed. Project calendars contain details applicable for all activities such as periods when work can
not be performed on the project due to weather conditions, regulatory requirements and so on. Resource
calendars provide details about when the resources will be available.
 Adjusting leads and lags: Modifications in leads or lags will be done to suit the project schedule and make it a
feasible solution.
 Schedule model: It is combined repository of schedule data and information. This tool is used to create the
project schedule in combination with project management software.
Schedule development process uses details available from organizational process assets, activity list, project
schedule network diagrams, activity resource requirements, resource calendars and activity duration estimates.
Other two inputs are
 Project scope statement: This provides constraints and assumptions which must be taken into consideration while
developing the projects schedule. Constraints can be broadly categorized as:
o Date constraints – Project managers are often required to adhere to preset deadlines, which are set
even before the project is accepted. You should draw up an accurate estimate of the time and effort
required to complete the project. Date constraints can be of the following types:
• No earlier than - This constraint specifies that a task should not start before the predefined date.
• No later than - This constraint specifies that the task must be completed before a predefined
date and must not go beyond that date.
• On this date - This constraint specifies that the task must be completed on a specific date. It
cannot end before or after the mentioned date.
• Key events or completion date of important deliverables, known as milestones, as specified by

the sponsor, project’s client.
o Management constraints – These refer to constraints caused by management decisions. For example, the
high costs of fixing problems may prompt a project manager to introduce intermediate review rounds.
This would lead to a longer project life cycle.
o Technical constraints – These constraints involve timing relationships. This constraint could be because of
a conscious decision on the part of a project manager, based on technical requirements for performing
the work, to start a task after the task started earlier is complete. For instance, a technical constraint
might be that task A must be completed before the task B can start (a FS relationship).
o Organizational constraints – The completion of another project in the organization may be a constraint for
your project to start. Therefore, the success of your project depends on the timely completion of that
other project.
 Project management plan: Its subsidiary plans such as: schedule management plan, cost management plan,
project scope management plan and risk management plan are used by the project team for schedule
development. Risk register identifies risks and risk response plans which will be considered in project schedule
development.
36
37
Project Cost Management

Project Cost Management deals with the estimation, budgeting and controlling of cost to complete the
project in the approved budget. It includes the following activities:
 Cost Estimation – Involves estimating the overall cost of the resources required to complete
the project. The resources can include people working on the project, infrastructure such as
workstations and computers, and so on.
 Cost Budgeting – Involves determining the costs for each individual work process. Cost
budgeting helps to define the project cost baseline.
 Cost Control – Involves managing the project costs during the Execution process.
Cost estimation and cost budgeting are part of the Planning process while cost control is a part of the
Controlling process.
Types of Costs
Project costs include direct and indirect costs. Direct costs are costs that can be directly associated with
a project. For example, the cost of human resources working on the project is a direct cost. Direct costs
can vary. Indirect costs are costs that cannot be directly associated with a project in a cost-effective
method. For example, the cost of electricity at the location where the project team of an organization
works is an indirect cost. Another example of indirect cost is the cost of communication for a project;
the project team uses the communication infrastructure of the organization while executing the project
however, the exact cost towards a projects communication may not be known. The manner in which the
indirect costs are accounted for is by having an average cost of all these indirect costs factored into the
project cost.
The direct cost components are described below.
The direct costs of a project can be broadly categorized as follows:
 Labor costs – Includes the cost of human resources that work full time or part time on the
project.
 Material costs – Includes the cost of materials used to execute the project. The material may
have been bought or rented for the project. For example, in one of your projects you need to set
up a CISCO lab, which is very expensive. You might decide to rent the lab from a training center
that uses such a lab. The cost of hiring the lab constitutes the material cost for the project.
 Equipment costs – Includes the cost of equipment that has been purchased for the project.
Unlike materials, equipment purchased for a project can be reused by the organization for some
other project. As a result, the cost of the all the equipment purchased is not included in the
project cost. For example, you might buy specific software for one of your projects. This
software can also be used by other projects.
 Management costs – This includes the cost incurred on project managers and senior
management working on the project. However, the cost of these people cannot be directly
assigned to any particular task in the project.
38
 Subcontracting costs – Includes the cost of labor and equipment of the work subcontracted to
another organization. However, these costs are not under the control of the parent
organization.
 Overhead and administrative costs – Overhead costs are costs attributed to overhead such as
procurement, transport, and so on. Administrative costs include costs incurred by or on support
staff.
 Fees and taxation costs – Includes legal costs, insurance costs, financial costs, and fees paid to a
person or organization other than the parent organization. Taxation costs include international,
federal, state, and local taxes involved in the project.
Apart from the listed costs, you must also account for contingency costs and inflation costs. Contingency
costs are costs that cover the risks involved in the project. For example, you might take out insurance
coverage for all your employees working on a construction site. Inflation costs are costs attributed to the
inflation in the economy. Inflation costs are encountered in long-term projects such as construction
projects.
Project Cost Estimation

During project cost estimation, the project manager and the project team assess the requirements of
resources for all schedule activities of the project; based on the cost of these resources, a project cost
estimate is derived. The cost estimate is usually given in the accepted currency (e.g. dollar, yen, euro,
pounds).The project team performs the cost estimation for projects often with the help of trained
professionals.
The project cost estimate arrived at an early stage in the project may not be very accurate and depends
upon the accuracy of the project requirements and resource cost data. At the beginning of a project, the
requirements are vague. As a result, the estimation accuracy is low. This type of beginning estimate is
known as a Rough Order of Magnitude (ROM) estimate, and the level of accuracy varies between –25%
and +75%. This kind of estimation is typically done during the Initiation process and when sending out a
project proposal.
As the project progresses from the Initiation process to the Planning process, the expectations and
requirements become clear and the level of accuracy increases. The preliminary estimates have a level
of accuracy that ranges between –15% and +25%. This preliminary estimate is used to establish the
initial budget and allocate funds for the project.
The level of accuracy is usually the highest before work starts on the project in the Execution process.
The project budget is drawn up at this stage. At this stage, the scope is clearly defined and the accuracy
level should range between –5% to +10%. Thus the estimate gets refined during the course of the
project.
Deliverables of the cost estimation process are
1. Activity cost estimates: This is the key output of the cost estimating. The activity cost estimate
is arrived based on the cost of resources, which are likely to be utilized for completing the
activity. The resources could include human resources, material, technology, equipments and
factors like the inflation of the rates and contingency or risk reserves.
39
2. Activity cost estimate supporting detail: The activity cost estimate supporting detail provides
the basis for the cost estimation, the assumptions made while estimation and any other related
details. According to the PMBOK guide activity cost estimate supporting detail should include
▪ Detail of the activity/ work for which the estimate has been done
▪ The description of the basis on which the estimate was done
▪ Assumptions which were made for doing the cost estimation
▪ Constraints if any applicable
▪ The range of the estimate
E.g. For a road construction project the project team does an estimation of how much would be
the cement cost for the first segment of the road measuring 50 miles.
▪ In this case the detail activity would be the construction of the first segment of 50 miles
from location A to location B.
▪ The description on the basis of which the estimate was done will be the stated width as
per contract and will have the specification in terms of the depth of foundation, the
stress level which it should withstand, the durability parameter and so on.
▪ The assumption, which will be made, could be that during the construction period the
cost of cement per kg will remain constant.
▪ The constraints could be the order size will be X quantity, the order fulfillment time will
have to be Y days and so on. This constraint could be forced as there may not be space
at the location to store large quantity of raw material.
▪ The range of estimate could be + or – 5% depending upon the vulnerability of the item
to changes in the price, the inflation factor etc.
3. Requested changes: The cost estimation process may result into some changes in the cost
management plan, resource requirements or even activity changes and these changes will be
triggered as per the change process defined for the project.
4. Cost management plan (updates): According to the changes required after cost estimation the
cost management plan is updated.
Tools and Techniques used in cost estimation process are -
1. Analogous estimation – This technique refers to using the costs of similar projects completed by
the parent organization in the past to determine costs for the new project. This technique is
typically used to derive early estimates called ballpark estimates. These estimates are made
when the information for the project is scanty and the project manager must come up with a
rough budget estimate. The estimate is used to decide whether a project is feasible for the
organization. This technique is simpler and easier to use than the parametric method. However,
estimates drawn up using this technique are not as accurate.
40
2. Determine resource cost rates – The project manager needs to have the rates applicable for the
use of various types of resources like the staff cost per hour for various types of resources, the
cost of other material likely to e used for the project. E.g. In a building construction project the
rate of the cement/unit, the steel price and so on. This data may be available in the organization
or else may be required to be gathered from supplier quotes, commercial data bases, industry
publications and so on.
3. Bottom-up estimation – This technique involves estimating the cost for each individual activity
in the project and then summing them up to form the total cost. This estimation technique
requires a thorough knowledge of the design. However, this can be an expensive technique.
Moreover, the accuracy of the bottom-up estimation is based on the accuracy of the scheduled
activities. Accuracy also depends on the size of the project. In a very large project, there is a
greater chance for under- or over-estimating the cost of an individual activity because there are
more activities to estimate. Bottom-up estimation is sometimes called (and associated with)
definitive estimating.
4. Parametric methods – This technique uses statistical and historical data to derive a pattern.
Based on the pattern in the statistical and historical data, the technique predicts the per-unit
cost for the work. For example, to estimate the cost of building a house using this technique,
you first need to estimate the cost per square foot of building one room. Based on the number
of rooms (or total square feet) in the house, you can then calculate the general cost of building
the entire house. These methods can be very accurate depending on the amount and quality of
data used as input. Some references consider parametric estimation as a form of top-down
estimation.
5. Project Management Software – The project management software tools like spreadsheets,
cost estimating programs, statistical analysis assist in the process of cost estimation. They also
help in providing quick and multiple alternative cost estimates.
6. Vendor bid analysis– In this tool and technique the information is collected from the vendors
based on the bids, which they submit for the project. The comparative study of quotes is done
and then the reasonable estimate of cost is arrived. This normally implies to projects which can
are normally given to vendors or some parts of the project are given to vendors to execute.
7. Reserve Analysis – Project cost estimate needs to keep aside or build in the cost of contingency
to present the true picture of what could be the actual cost of project. However, the
contingency may result into rise in the project cost and these needs to be highlighted while
presenting the cost estimate.
8. Cost Of Quality – This is the total cost incurred to maintain the project outcomes with in the
criteria of acceptable quality defined for the project. The cost of rejection, rework and
rechecking is also accounted for in this cost.
a. Non-Conformance Cost Rework Repair Scrap, Expediting, Additional material &

inventory, Warranty Repairs and Service, Complaint Handling, Liability Judgments,
Product Recalls, Product corrective actions,
b. Conformance Cost: Planning, Training and Indoctrination, Process Control, Process,

Validation, Test and Evaluation, Inspection and Field Testing
To generate cost estimates, project team needs to take into consideration various inputs -
41
The project scope statement, Work Breakdown Structure (WBS), WBS directory & Activity List provide
the inputs on the project scope towards the project completion. These inputs help the project team to
ensure that complete project scope and detailed activities are considered during the cost estimation
process. The other factors to be considered are
▪ Enterprise environment factors: During cost estimation, the enterprise environment factors,
which influence are in two broad categories. The first being the market conditions this would
include cost information on the competing products or services, the demand and supply
information on the product or service. The second factor is commercial databases these are
information banks on cots information related to project resources like the basic raw material,
human resource industry average costs, the price lists of various project related consumables
and so on.
▪ Organization process assets: The organization process asset inputs for the cost estimation
include the cost estimating policies & templates, the historical project information on the costs,
the project team knowledge and the lessons learnt from previous projects.
▪ Project Management plan: There are three key points considered in the project management
plan for the cost estimating process. Two of them are the Schedule management plan and Staff
management plan, which together provide the resources required for completing the activities
as per the schedule. The other key input is the Risk register, which provides the costs pertaining
to the risk mitigation, and the reserve to be built in for handling of risks is considered.
Few guidelines for estimating costs.

While estimating costs, you must ensure that you account for all the expenditure that your project is
likely to incur. The following guidelines can help you estimate costs:
 Take all work into account – Project managers often fail to account for an important task, or
they underestimate a task. This increases the actual cost.
 Do not commit to the best-case scenario – As a project manager, you might succumb to
pressure from your senior management or the client to finish the project as quickly as possible
and within a certain cost that borders on the most optimistic cost for your project. This can be
disastrous for your project. Make a decision to commit only after carefully analyzing the costs
and taking into account the possible risks.
 Do not commit based on the available budget – Project managers are constantly under
pressure to take up projects for which the client has a fixed budget. Do not commit to this until
you have ensured that the project is feasible within the available budget.
 Recognize estimating biases – Biases often creep in while estimating. You could be biased in
assuming that the work is very simple, or in overestimating the capability of the team or the
effort required to complete the project. Biases always exist. What is important is that you
identify and address the biases.
 Estimate costs for a long project by breaking the project into small projects of shorter
durations – One of the toughest tasks when estimating long projects is to determine the costs of
events that are likely to follow after four or five months. The best approach is to break the
42
project into smaller projects. You can then estimate the costs for the sub-project that is closest
to the phase you are currently in. After you complete your current phase, you can estimate the
next project, and so on. The work breakdown structure (WBS) helps with this task.
 Validate old estimates – If a cost estimate has been finalized before the new project team is
constituted, revisit the estimates. After you start working on the project based on the old
estimates, it is assumed that you agree with the estimates and it becomes difficult to alter or
modify the estimates.
 Estimate for both fixed and variable costs – Project managers often fail to account for the fixed
costs because fixed costs are not explicitly attributed to the project. Nonetheless, fixed costs are
a part of the project cost and need to be accounted for. For example, the cost of power in your
workplace is a cost that is not directly attributed to the cost of your project. However, this cost
is also incurred by your project and therefore your project also needs to bear some of its cost.
 Discuss client costs with your project sponsor or senior management – Some companies want
to calculate their total cost on the project by including time spent on reviews and meetings.
Consult your project sponsor or senior management and account for these costs, if required.
 Account for contingencies – You must always account for risks in your project. Risks are
inherent to all projects, and any or all of these risks may actually occur. Keeping this in mind,
you must create a contingency plan for each risk, and you should calculate costs for the
contingencies.
 Be prepared for the client’s objection to costs estimated by you – Your client might come back
to you saying that the cost you estimated is too high. Be ready to justify your estimate. Also, if
the client does not have the budget to meet your estimates, try the following measures to
revisit your estimates:
o Renegotiate on the critical success factors and reschedule the end date of the project to
a later date.
o Determine if any of the high-level quality requirements can be renegotiated.
o Check if your contingency reserve is too high. If it is, conduct more detailed activity
estimation in an attempt to reduce the contingency reserve.
o Ensure that the project meets only the scope requirements and does not provide
additional, unnecessary features.
43
Cost Budgeting
Cost budgeting process aggregates the detailed estimates, which are derived in the cost estimation
process. The estimates for the entire project activities are clubbed and the total project cost is arrived.
The cost budgeting process then establishes a cost baseline on which the project cost performance is
judged through the progress of the project. The cost baseline is the expected project cost. The cost
related only to the project are considered and included in the project budget.
Cost Baseline = Cost Estimates allocated to Work Packages in WBS over a period of time
Cost Baseline needs Cost Estimates + WBS + Schedule
The cost budgeting process would generate two key deliverables – cost baseline and project funding
requirements.
□ Cost Baseline: This the most important output of the cost budgeting process. The cost baseline
is the total of all the project cost elements and includes the contingency costs, risk cost
considerations and any other reserves as needed by the project. It is also called as the expected
cost of completing the project. The cost baseline forms the basis for controlling project costs
and to monitor the project cost performance as time passes. The cost baseline is represented in
a graphical form and is a ‘S” curve. The reason being during the start of the project the costs are
low as the project progresses the cost incurred rise significantly and towards the end of the
project, again the costs are low and taper off.
□ Project Funding Requirement: Project finding requirements are the money spent on the project.
This is determined based on the cost baseline and may include a management contingency
reserve over and above the cost baseline. The project cash flow is a continuous S curve but the
funds may not be taken on a continuous basis and this is what the project funding requirement
balances. At times the project cash flow may not match with the actual cash flow and this
difference may also have to be adjusted by the project funding requirements.
The cost baseline, project funding requirement and the cash flow are shown graphically below
with the help of an example. The project considered is building a wooden cabinet for the study
room of the house. Depending upon the discussions with the carpenter and the research on the
rates of the various raw materials you formed the project cost baseline. The carpenter provided
you with the milestones and the payment terms based on which you plotted the projected cash
flow line and then arrived at the project funding requirement.
The funds are made available at point 1, 2 & 3 and the amount is actually greater than the cost
baseline this is to take care of any adverse cash flows. At the end of the project at point 4 the
difference between the funding requirement and the cost baseline is the un utilized
management reserve. In this case the un used management reserve amount is 680-630 = 50
units
44
400
E
8 F
200 0
B A
2
C
D
600
5
1
“S” Curve for Cost Baseline and Cash Flow with the funding requirement
Cost budgeting process will consider various details available while generating the required
deliverables - Project scope statement this provides the budgetary constraints as specified by the
project sponsor. The work breakdown structure and WBS Directory provide the details on the project
activities. The activity cost estimates and their supporting details provide the cost aspects of each of the
project activities. The project schedule provides the milestones to which the corresponding cost
aggregation needs to be done. Resource Calendars and the contract provide the cost details on the
resources and the procurement of other services or products for the project.
Cost budgeting has two of its tools and techniques common to cost estimating process; these are
reserve analysis and parametric estimating. The other two are described below
□ Cost Aggregation: The schedule activity cost estimates are aggregated at the work package level
and then rolled up to the higher level of the WBS components.
□ Funding Limit Reconciliation: Depending upon the funds sanctioned for the project along with
fund usage restrictions if any (e.g. 20% funds can be spent for stage one of project completion)
the fund limit reconciliation is performed. Fund limit reconciliation is reconciling the project
expenses with the amount sanctioned for the project by the project sponsor or the customer.
During reconciling the project expenses are smoothened by tweaking the schedule.
45
46
Project Quality Management

It is often said that quality should be built in to the product and not inspected in. Quality management is
an ongoing process, which begins at project initiation and continues until the end of the project. Quality
management focuses on preventing mistakes, meeting customer’s stated and implied needs and on
continuous improvements. Quality management is categorized into the following three processes:
 Quality Planning process: It is part of Planning Process Group. This process identifies the
quality standards that ensure client satisfaction. This phase also describes how the quality
standards can be met. One of the targets of quality planning is to detect errors early in the
process. For example, it is easier to find and rectify quality problems in the analysis and design
phases than in the testing phase. Therefore, you should dedicate adequate time early in the
process to identify what constitutes quality for a project and what measures should be taken to
ensure that the quality standards are achieved.
 Perform Quality Assurance (QA) process : It is part of Executing Process Group. This process
involves following planned and systematic procedures to ensure that the product or service will
meet the requirements. QA also evaluates the project’s performance and helps to build
confidence in the processes of the project.
 Perform Quality Control (QC) process: It is part of Controlling Process Group. This process
includes monitoring the results of the project to ensure that the results comply with relevant
quality standards. The QC process identifies various ways to improve quality, and it uses tools,
such as the Pareto chart, to monitor and control quality.
Before discussing the above processes in detail, it is essential to understand what quality is and certain
important concepts related to it: cost of quality, cost of conformance, cost of non-conformance.
Definition of Quality
Quality has been interpreted in different ways by different organizations and different people. The
International Organization for Standardization (ISO), which is a group known for its development of
international standards, wrote in its ISO 8402 standard that quality is “the totality of features and
characteristics of a product or service that bear on its ability to satisfy stated or implied needs."
Stated and implied needs are considered during developing project requirements. Stated needs are
clearly specified by the customer whereas implied needs are assumed to be specified. Project teams
should identify implied and stated needs, convert them into requirements and document them.
Quality has also been described as “fitness for use,” “fitness for purpose,” “customer satisfaction,” and
“conformance to requirements.”
Fitness for use states that a product or service should be ready to be used by the customer. In other
words, the customer should be able to directly put a product or service to use. It is essential that the
customer gain economic satisfaction from the product or service.
Fitness for purpose determines whether the product or service meets the purpose for which it was
created.
47
Customer satisfaction indicates how the customer feels regarding the product or service that has been
delivered. For a product to be of economic value to the customer, the product or service should lead to
customer satisfaction.
Conformance to requirements means that the product or service meets the customer requirements.
Cost of Quality
Cost of quality (COQ) refers to the total cost involved in meeting the customer's quality requirements. The
cost of quality includes work that is necessary to ensure conformance to specifications, to avoid
nonconformance to specifications, and to fix any problems. The cost of quality can be broadly divided into
the following categories:
 Prevention costs – This is the cost associated with the measures taken to prevent errors. These
costs are undertaken because prevention is often better and cheaper than detection and
remediation. These costs could be costs incurred on good vendors, detailed planning,
experienced staff, and so on.
 Appraisal costs – These are expenses undertaken to evaluate the quality improvement
processes. These costs are undertaken because maintaining the processes results in better
quality deliverables. These costs are incurred by conducting inspections of the product, testing
the product, and so on.
 Internal failure costs – This cost includes expenses incurred to detect all errors before the
product or service is delivered to the client. These costs include costs incurred on rework and
inventory costs that result from failures.
 External failure costs – This cost includes the costs of defects detected after the product or
service is delivered to the client
Cost of Conformance and Cost of Non-conformance

The cost of training people to achieve desired quality, cost of detailed analysis and process studies are
treated as cost of conformance to quality. Where as, costs associated with rejections, defect repairs,
inventory and replacements or repairs in warranty period of the product, are known as costs of non-
conformance. It must be remembered that the costs of conformance can be justified only if the cost of
non-conformance for the product will be higher than the cost of conformance.
48
Quality Planning
The first step in quality management is quality planning. It involves determining the quality standard of a
project and the method of measuring the quality standard. Typically, the quality policy of a project will
depend on the overall quality policy of the parent organization. The organization’s policy will provide the
general guidelines for the project. However, some projects might include specific requirements that are
not covered by the company’s policy. A specific quality management plan is created for such projects.
Efforts spent in Quality Planning assist to avoid unnecessary expenses on rework, complete the
deliverables in time and satisfy the client. While creating a quality management plan, you must address
the following questions:
 Which quality processes must be used in the project?
 What are the potential risks involved in the project?
 How will quality be achieved?
 Who is responsible for assuring quality?
 How will quality and improvement techniques be implemented?
Inputs in the context of quality planning -
 Enterprise environmental factors: Existing standards and regulations applicable for the area of
work of the project will have to be considered while developing the quality management plan.
Understanding the basic differences between standards and regulations is necessary to
determine the extent to which the project team should use these in the quality planning :
Standard Regulation
Set of rules and guidelines approved by a These are rules and requirements imposed by
recognized body government or competent, authorized
institutions.
Standards are not mandatory, however it is Regulations are mandatory and demand
recommended to follow them compliance to them.
Standards can be set by organization or Regulations are normally set by government
independent bodies bodies
Example of standards : SEI CMM, Six Sigma, Example of regulations: Fire Safety regulations
ISO for high rise buildings
 Organizational process assets: One of the important parts or organizational process assets is
quality policy. It provides predetermined guidelines and policies which are approved by senior
management. Project manager should understand and adopt these guidelines in quality plan. In
case organization does not possess a quality policy, the project team should create it. Project
team needs to ensure that all the stakeholders are informed about the quality policy.
 Project scope statement: It documents major project deliverables, project objectives, project’s
product with technical details. Acceptance criteria for the project is also specified in the scope
statement, has a major influence on the quality planning and more so on cost of quality. For
example, the acceptance criteria for an electrical drive motor states that vibrations will not exceed
25 microns at motor top. This will require closer control on all the processes involved in
49
manufacturing of the drive motor as compared to the processes required if the acceptance criteria
was 40 microns.
Tools and techniques:
Following tools and techniques can be used in the Quality Planning process
 Cost-benefit analysis – This technique examines the cost of quality in monetary terms. It
examines the cost of achieving a specific level of quality compared to the benefit of achieving that
level of quality.
 Benchmarking – This technique uses other projects to measure the performance of the current
project. This process examines the processes, deliverables, risks, pitfalls, and successes of other
projects to measure how the current project is performing. The problem with this approach is that
the conditions in which different projects are being implemented change over time; therefore,
information from benchmarked projects might not be applicable.
 Design of experiments (DOE) – This technique uses a statistical approach to determine which
combination of variables will provide the best outcome. It analyzes how different factors of the
project work together so that the optimal conditions can be achieved. For example, if your project
involves a critical need for frequent data backups for a large number of users, you will need to
figure out the optimal combination of backup hardware, network connectivity, network congestion,
number of users, application scalability, and so on that will optimize data redundancy while
maintaining a reasonable level of functionality for the users. DOE helps in finding the most
appropriate solution by changing more than one variables or influencing factors at a time, and
then analyzing the results of such experiments.
 Cost of quality (COQ) – This technique involves calculating the sum of all the costs for achieving
the desired quality. COQ includes the costs incurred to conform to quality standards, to avoid
nonconformance to standards, and to fix errors.
 Additional quality planning tools – As per PMBOK Guide project team can also use other
planning tools like brainstorming, affinity diagrams, nominal group techniques, matrix diagrams,
flowcharts, and prioritization matrices. The tools used more frequently are :
o Brainstorming: It is a technique used to identify and generate exhaustive list of quality

requirements for the project. Experts, team members, quality management team
members, stakeholders who can influence the discussions come together in a room or
conversation and start identifying the issues, requirements pertaining to quality. Remarks,
comment from one person can trigger a discussion, other idea within the group.
o Nominal group techniques: This is pretty similar to brainstorming and Delphi technique.
Here the participants gather in a room and note one issue, suggestion or requirement
pertaining to quality on each piece of paper. All these papers are then collected and
displayed in the room for review of a panel, who then prioritize or rank the issues
resulting in a detailed list.
o Flowcharts: Flowcharts involve a graphical representation of the different processes in a

system. It shows the relationship between the different components of the system which
can aid project team during quality planning.
50
Note: Brainstorming and nominal group technique are also used in Risk Identification
process.
It is important to note that the quality plan is a part of the overall project plan and any changes in the
project plan that affect the quality plan, must be reflected in the quality plan.
Outputs:
Primary output of the Quality Planning process is quality management plan. This in itself is a subsidiary
plan of project management plan. Hence, project management plan (updates) is also an output of this
process. Whenever quality management plan changes as a result of corrections or modifications
recommended during quality assurance, project management plan also changes.
 Quality management plan: The quality management plan describes how the project management
team would implement its quality policy, related processes and procedures to meet quality
requirements of the project. It contains details about techniques to be used for quality assurance
and quality control, guidelines for continuous process improvements for the project.
 Quality Metrics: It is also known as operational definition. Quality metrics are used by project
team in Quality Assurance and Quality Control processes. Metrics define what are various
parameters, success criteria for the quality of the project and how they are measured during
quality control. Metrics quantify the quality requirements as laid down in quality management
plan. For instance, the quality management plan may define the following metrics for a software
development project:
1. Number of QA cycles allowed – maximum 3 nos
2. Number of Severity 1 bugs allowed in final product : Nil
3. Number of Severity 2 bugs allowed in final product : One
4. Number of bugs not resolved and carried forward to the next QC cycle: Nil
5. Meeting the project schedule : Milestone dates of the project such as – development end
date, integration test end date, Handoff to QC date, Acceptance date must be met.
At the end of the project, if the mentioned values for the metrics are attained quality has been
achieved for the project. Metrics prevent subjective assessments. Once identified or defined
during the planning processes, metrics are monitored and measured by the ‘controlling’
processes.
 Quality Checklists: A checklist is a systematic representation of steps required to complete a

specific task. It ensures consistent approach for the work to be executed across the organization.
Checklists are frequently used for quality control activities like reviews and testing. For example:
during final inspection of the two wheeler at the manufacturing plant a portion of simple checklist
will contain checks such as:
1. Is the assembly complete : Yes / No
2. Are the front & rear indicators working : Yes / No
3. Is the break lamp working : Yes / No
4. Is the headlamp working : Yes / No
5. Is the toolkit, manual kept in the vehicle : Yes / No
51
Checklists have a drawback, they limit creativity and people tend to limit themselves only to the
checkpoints mentioned therein. Project manager must ensure that checklists, when used, do not
remain stagnant and encourage users to innovate and suggest modifications to the checklists.
 Process improvement plan: Project manager is also required to work towards process
improvement while managing the project. These process improvements should lead to reduced
defects, effective utilization of time and money by reduction in wasted efforts, improved level of
satisfaction for the team members as well for the customers. process improvement plan, which in
turn is the subsidiary plan of project management plan, includes specific activities needed for
process improvement, such as: the sequence of processes, purpose of each process with the
process start and end and guidelines or suggestions for possible process improvements. For
example: in a software testing lab manual performance testing of new products is done by the
available resources. Process improvement plan may include guidelines to automate the
performance testing by developing some scripts or using some testing tools.
 Quality baseline: It is a quality objective of the project, as developed during Quality Planning
process. Baseline makes the project manager and the team accountable for the committed
quality performance on the project. It is used to measure and report the project’s quality
performance as the project progresses.
Quality Assurance
After you have carefully planned the quality processes, you need to ensure that the processes are carried
out effectively. QA is the process of managing and monitoring the performance of a project to ensure that
the quality requirements specified in the Quality Planning process are being met. Quality Assurance
verifies compliance with processes. It should be remembered that QA is not about checking specific
deliverables for correctness. QA is prevention driven and ensures that the processes and checks to
measure quality are present in the organization. QA is typically implemented at the organizational level.
For example, your company might be ISO 9000 or SECIMM certified, which means it follows some set
processes to adhere to the quality standards of these organizations.
Define Quality Assurance
According to the PMBOK Guide quality assurance is the application of planned, systematic quality
activities to ensure that the project will employ all processes needed to meet requirements. Quality
assurance (QA) systematically measures the overall performance of a project and ensures that the
project is on track and will be able to meet the specifications and quality standards. Quality assurance
aims to continuously improve the quality of processes and end products by reducing the redundant
activities or processes.
Whereas Quality Planning process is part of the Planning Process Group, Perform Quality Assurance
process is part of the Executing Process Group.
Quality assurance department or an organization is typically assigned to ensure that the processes are
followed meticulously. Project manager and the stakeholders including project team are responsible for
QA of the process.
52
Tools and Techniques:
 Quality Audits: An audit is a formal, independent examination to check that specified procedures
and processes for quality standards are being followed. Quality audits are also used to track
changes that might have been initiated because of a changed business need or nonconformance.
An audit should be conducted by an independent person or group either from within the
organization or from outside the organization. It is also mandatory that an audit not be conducted
by a person from the same department or by a person who is involved with the project. Also,
senior managers should not conduct quality audits to prevent forming a bias during performance
appraisals.
Audits can be categorized into three types:
o Project evaluation audit – This audit is an audit that checks the feasibility of the design.
o Internal audit – This audit is a quality check that ensures that the management processes are
followed and the project meets the quality, cost, and time requirements. An internal audit can
be conducted either by an internal team or by a third-party auditor.
o Post-completion audit – This audit is conducted after project closure, and it checks whether
the project has met the desired goals and in case of failures, evaluates the causes of the
failure. This audit can be conducted by the project manager and the team or as a debriefing
meeting.
During an audit, the auditor must have evidence of the processes following the quality plan. The
auditor should clearly document the audit finding and present them in a report. Audit reports
contain information, such as the status of a project at the time of the audit and the status of
activities that are critical for the success of a project. Audit reports also state the risks of a project.
This provides senior managers and stakeholders a chance to rectify, in advance, the issues that
can lead to the failure of the project.
The audit report should clearly list down the nonconformance issues and state a date by which
the nonconformance issues should be addressed.
 Process analysis: Process improvement plan, developed during the Quality Planning process,
provides the framework to identify the required technical as well as organizational improvements. One
of the techniques generally used for the same is root cause analysis. It examines the problems faced
during the project phases, constraints and other inefficient processes identified, with an aim of finding
the root cause of the problem. Necessary preventive actions are then developed to resolve identified
causes of problems.
 Quality Planning tools and techniques: The same tools that are used for quality planning, such as
benchmarking, cost-benefit analysis, design of experiments, and COQ can also be used for QA.
 Quality Control tools and techniques: Control charts, flowcharts, Pareto charts and other tools and
techniques of Perform Quality Control process are discussed in detail in the next topic.
Outputs:
All the outputs of Perform Quality Assurance process have been discussed in detail in earlier sections.
53
 Requested changes: As an output of this process changes in processes, procedures and policies to
improve the effectiveness of the processes. These requested changes, when approved in Integrated
Change Control process and implemented in project will result in improved efficiency of the
processes.
 Recommended corrective actions: These are generated as a result of quality audits or process
analysis. It is important to notice that these recommended corrective actions resulting out of the
quality audit or process analysis must be implemented immediately. For example, when you notice
that the drive shafts produced by the grinding machine are of larger diameter than specified, you
would be required to correct the process by changing machine settings. This will ensure that the drive
shafts are produced without any deviation from specifications.
 Organizational process assets (updates): The quality standards and processes followed in the
organization are revised in this process to improve their effectiveness and efficiency by removing
redundancy, flaws and wasted efforts. These updated standards and processes then become the
reference for QC and future projects.
 Project management plan (updates): Quality management plan, a subsidiary plan of the project
management plan, is revised during this process to reflect the changes in processes, policies,
standards and procedures as a result of continuous process improvement.
Quality Control
Quality control (QC) is inspection driven. This means that while implementing QC, the deliverables are
checked to ensure that they meet quality standards. QC also involves root cause analysis to measure
why things went wrong and what can be done to ensure that the same mistakes are not repeated.
Quality control (QC) measures are taken to ensure that the deliverables and the end result of the project
meet the specifications mentioned in the quality plan. QC also identifies various ways to eliminate the
causes of unsatisfactory results so that such results are not allowed to occur repeatedly.
Sampling and probability play key roles in the QC process, so as a project manager, you should be
familiar with some statistical analysis.
One should be acquainted with the following QC terminology:
 Prevention and inspection – Prevention intends to prevent errors in the project process while
the product or service is being made. Inspection is performed after the product or service has
been created, and it intends to keep errors away from the product delivered to the client.
 Attribute and variables sampling – Attribute sampling is the process of ensuring that the
product meets the specifications. Variable sampling measures the degree to which the product
conforms to the specifications.
 Tolerance and control limits – Tolerance is the acceptable range for a result that indicates that
the project is meeting its quality goals. Control limits are the limits for the quality results to be
considered within an acceptable range.
54
 Special and random causes – Special causes are unusual events that cause the quality to
exceed or fall short of expectations by an abnormal margin. Random, or common, causes are
factors that are considered a normal part of variations within a process.
Tools and Techniques for Implementing Quality Control

QC must occur throughout the project. There are several tools and techniques that you can use to
implement QC in your project:
 Cause and Effect Analysis: The cause and effect analysis, or the fishbone analysis, is a
systematic approach that analyzes all the inputs to unearth the potential causes of a problem.
The fishbone diagram, which is sometimes called an Ishikawa diagram, lists the effects or the
problems on the right side and the potential causes on the left side. The project team discusses
and explores the causes in a brainstorming session. This method invokes a better understanding
of the problem among the team members. The team members work together to resolve the issue.
Working together leads to team building. Figure5-4 shows a sample fishbone diagram.
Figure 5-4: A Sample Fishbone Diagram
 Control Charts : A control chart graphically displays the results of a process over a period of time,
and it measures the degree to which the product or service conforms to the standards. Quality
control charts allow you to determine whether a process is in control or out of control.
In a control chart, the upper and lower limits are specified. The upper limit, which is known as the
upper control limit (UCL), specifies the point where preventing errors becomes too costly. The
lower limit, which is known as the lower control limit (LCL), specifies the point below which the
project has too many errors. The permissible variance range lies between these two limits. The
mean or average of the samples measured is considered to be the process average. The process
average is the middle line of the control chart. The plotting of data on the control chart displays
the variations from the mean. If the data points lie within the UCL and the LCL, then the process
is considered to be in control.
55
When a process is in control, any variations in the results of the process are effected by random,
or common, events. When a process is out of control, variations in the results of the process are
caused by special events. You must focus on these special events and initiate corrective
measures to ensure that these special events do not occur.
Control charts are often used to monitor the volume and frequency of change requests, errors in
documents, and cost and schedule variances.
In analyzing control charts, the rule of seven is frequently used. According to the rule of seven, if
there are seven randomly plotted points on a chart even within the UCL and LCL ranges, then
there is something wrong with the project and an investigation must be initiated.
Even if two out of three, three out of seven, or four out of ten points occur in the outer range close
to the control limits, the situation should be investigated because the process may be going out of
control.
 Flowcharting : Flowcharting helps to analyze the phase or point at which the problem might be
occurring. After the problem has been identified, the project team can initiate corrective action.
For example, if during a quality review too many standard adherence issues are coming up, then
by looking at the flowchart the project manager can identify what stage a standards review should
be introduced.
 Histograms : Histograms list product defects in the form of bar chart, based on the type and
frequency of occurrence of the defects. The histograms depict the most critical defects. Using this
information, project managers can focus on correcting these critical issues
 Pareto Chart: Pareto analysis is based on the principle that 20 percent of the issues cause 80
percent of the problems. Pareto analysis enables you to focus on critical causes that give rise to
maximum problems and defects. Theoretically, if project managers use the Pareto analysis to
focus on 20 percent of the issues, then the project managers will be able to solve 80 percent of
the problems related to the project.
Pareto analysis uses histograms. Using this information, project managers can focus on
correcting these critical issues. In addition, Pareto analysis can also be used to determine
whether the corrective actions taken are effective or not.
56
Figure 5-5: A Sample Pareto Chart
It is important to note that the frequency of occurrence may not always be the best criteria for
ranking defects. The defects might be trivial issues. Therefore, the defects should be categorized
based on their importance in terms of critical success factors.
 Run Charts: Not a single process can qualify as perfect process. There will be variations in the
results of a process. Run charts show these variations over time by plotting the data points
against time and joining them by a line. Run charts indicate the trend in a process, improvement
or deterioration and are used in trend analysis. Trend analysis is a mathematical technique to
predict future results based on the past data. It is used to track the performance of the project by
monitoring cost and schedule variances over a period of time. It also monitors the technical
defects identified, resolved and which are yet to be resolved.
 Scatter Diagrams: Scatter diagrams depict the possibility and intensity of a relationship between
two variables. The two variables are plotted on a graph. The y-axis of the graph depicts the
dependent variable that must be predicted and the x-axis depicts the independent variable that is
used to make the prediction. Scatter diagrams are widely used for forecasting.
A Positive Trend Scatter Diagram
57
A Negative Trend Scatter Diagram
 Statistical Sampling : Statistical sampling methods are used when it is not possible or
economically feasible to review the all parts of a project for quality. For example, if a project
produces 2 million identical machine parts, it would take a very long time to test the quali ty of
each one. In such a case, a representative sample of the parts is checked. If a high number of
defects is discovered in the sample, then it is likely that the entire lot has a high number of
defects as well. Similarly, if very few defects are found in the sample, then statistical probability
indicates that very few defects would be found in the entire lot if the entire lot were tested.
However, when adopting the sampling method, you must bear in mind the following points:
o The size of the sample should represent the product lot.
o The criteria for rejecting the entire lot should be determined before using the sampling
method. Criteria may include the number of defects found.
 Inspection : Inspection is actual measurement or testing of the results to verify whether they are
acceptable as per the requirements and quality standards. Inspections can be carried out at
intermediate stages or at the end depending upon the nature of the product, resource availability
and budget. For example, during manufacturing of high discharge pumps you can carry out the
inspections after manufacturing various pump parts like shaft, casing, bearings, impeller and so
on. However, when the entire pump is assembled, you might not be able to do any performance
measurements as a result of test rig limitations.
Based on the results of inspection a decision to accept or reject the work can be taken. Rejected
work will have to go through rework if possible. For example if inspection rejects a drive shaft as
its diameter (35.5 mm) is less than the permissible value (36 to 36.5 mm) the shaft would have to
be scrapped. However, if the inspection rejects a drive shaft as its diameter (37 mm) is more than
the permissible value (36 to 36.5 mm) the shaft would have to undergo rework.
 Defect repair review: It is undertaken by a department responsible for quality control. It ensures
that the product defects identified in quality audits or inspection are repaired and they comply to
the quality requirements of the deliverable, product of the project.
Outputs:
The primary focus of the quality processes is quality improvement. All out efforts should be made to meet
the quality requirements as failure to do so shall lead to rework. Rework means duplicate efforts which will
58
adversely affect the project schedule, cost as well as team morale. This makes it imperative to monitor
quality periodically and keep the rework to minimum.
 Quality control measurements: These are the results of QC process that are given to Quality
Assurance to review and evaluate the quality standards, processes defined in planning stage.
 Validated defect repair: Recommended defects repairs, when fixed would be examined and either
accepted or rejected. Rejected defect repairs may require rework.
 Quality baseline (updates)
 Recommended corrective actions: It calls for adjusting the processes, which are identified by
measurements to be out of control. Management approval is required before implementation of
these corrective actions.
 Recommended preventive actions: These are the actions requested to ensure that future project
performance is within the acceptance criteria defined by quality standards. Trend analysis helps
the project team to infer future performance based on historical data and judge if there is a
requirement of preventive actions.
 Requested changes: the corrective or preventive actions recommended during the QC process
may require the project manager to initiate a change request.
 Organization process assets (updates): During this process the QC department may use
checklists to record the results or measurements of the audit or inspection. These updated
checklists should become part of project documents. Similarly, lessons learned during quality
control should go into historical database. These should include the causes of variances, reasons
of corrective actions and alternatives evaluated before selecting a corrective action.
 Validated deliverables: These are the result of the work performed on the project which indicates
deliverables meet the quality requirements and standards as per the quality management plan.
Recap
• Quality is "the totality of features and characteristics of a product or service that bear on its ability
to satisfy stated or implied needs."
• COQ refers to the total cost involved in meeting the customer's quality requirements. This cost
includes prevention costs, appraisal costs, and failure costs (both internal and external).
• Grade is the ranking of the product or service in terms of its technical characteristics or depth of
features.
• Quality planning identifies the quality standards that achieve client satisfaction.
• QA involves following planned and systematic procedures to ensure that the product or service
will meet the requirements.
• QC involves monitoring the results of the project to ensure that the results comply with relevant
quality standards.
59
• Quality planning tools include cost-benefit analysis, benchmarking, design of experiments, and
cost of quality analysis.
• QA is the process of managing and monitoring the performance of a project to ensure that the
quality requirements are being met.
• A quality audit is a formal, independent examination to check that specified procedures and
processes for quality standards are being followed.
• QC measures are taken to ensure that the deliverables and the end result of the project meets
the specifications specified in the quality plan.
• Peer reviews allow team members to review each other’s work.
• A control chart graphically displays the results of a process over a period of time, shows the
degree to which the product or service conforms to standards, and determines if the process is in
control or out of control.
• The rule of seven states that if there are seven randomly plotted points on a chart even within
the UCL and LCL ranges, then there is something wrong with the project and an investigation
must be initiated.
• Pareto analysis is based on the principle that 20 percent of the issues cause 80 percent of the
problems.
• Pareto analysis uses histograms to list product defects, based on the type and frequency of
occurrence of the defects.
• The cause and effect analysis, or the fishbone analysis, is a systematic approach that analyzes
all inputs to find the potential causes of a problem.
• Statistical sampling methods are used when it is not possible or economically feasible to review
the all parts of a project for quality.
• Scatter diagrams depict the possibility and intensity of a relationship between two variables.
• Trend analysis uses the results of past projects or events to predict future performances.
• Flowcharting involves a graphical representation of the different processes in a system.
• TQM is a process that is applied to all employees within an organization and in which the project
team not only works towards meeting the client’s requirements but also works at improving
productivity.

Project Management Reference Notes

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Project Management Reference Notes

Hochgeladen von

Copyright:

Verfügbare Formate

1

Key terms in Project Management

A project is "a temporary endeavor undertaken to create a unique product or service or

Projects are progressively elaborated

Project Vs. operations ?

Key project performance influencers:

• External Influencers : P- E- S -T- L- E

Politics, Economics, Social, Technology, Legal (Regulatory,) Environment

Project Life Cycle : Definitions

Project Life Cycle defines:

Project Phases can overlap – “Fast Tracking”

Common Characteristics of Project Life Cycles:

Project Scope Statement

Project Selection methods

Benefit/Cost analysis measures of Project Selection

Planned value (PV) or the Budgeted Cost of Work Scheduled (BCWS).

Actual Cost (AC) or the Actual Cost of Work Performed (ACWP).

Earn Value (EV) Budgeted Cost of Work Performed (BCWP).

Schedule Performance Index = SPI = EV/PV

Cost Performance Index = CPI = EV/AC

Expected at completion = EAC = AC + (BAC-EV)/CPI

BAC = Budget at completion (when the project started)

Project Scope Management

• A process of verifying accuracy of project deliverables before accepting the same.

• Details of how the scope changes will be controlled.

Scope Planning process would use information from below sources -

 Enterprise environmental factors: Scope management is influenced by enterprise environmental factors,

The PMBOK Guide states that a scope statement should include:

 Organizational process assets:.

 Scope management plan

Creating a Work Breakdown Structure

A Partial WBS Organized By Phases

Advantages of Creating a WBS

Obtaining Management’s Approval

Key deliverables that project team generates at this stage are :

The tools and techniques used in preparing the WBS are:

Information that project team uses in creating the WBS is

Project Time Management

Project Time Management includes following processes:

Activity Definition process

Methods and techniques for creating the project network diagrams

 Tracking and monitoring of the project progress

 Developing contingency plans

 Monitoring resource requirements

A PDM / AON network diagram

The dependencies between activities can be one of the following types:

Types of activity dependencies

An ADM / AOA network diagram

Activity Resource Estimating

 Resource Breakdown Structure: Resource Breakdown Structure is a representation of resources identified

Activity Duration Estimating

There are several tools and techniques used in this process:

Activity duration = [optimistic time + (4 * most likely time) + pessimistic time] / 6

In schedule development project team will generate below details -

Tools of Schedule Development

Critical Path Method

Figure 4-8: Network Diagram for a Project

Critical Chain Scheduling

Techniques for schedule optimization

There are few other tools and techniques used:

• Key events or completion date of important deliverables, known as milestones, as specified by

Project Cost Management

The direct cost components are described below.