Project Management

REPORT ON Business Strategy

Operational & Financial Strategies of Adobe
B

Group-9
Kiran Jacob
Rituparna Dutta
Ritesh Agarwal
Ramanathan K
Sunam Pal
Punneet K

Operational & Financial Strategies of Adobe Alliance University

Table of Contents

Chapter-1 ..................................................................................................................7
Introduction.............................................................................................................7
1.1 About Adobe:- ................................................................................................7
1.2 History of Adobe:...........................................................................................8
1.3 Products of Adobe: ........................................................................................9
1.3.1 Desktop software: ................................................................................9
1.3.2 Server software:..................................................................................10
1.3.3 Formats ................................................................................................10
1.3.4 Web-hosted services: .........................................................................10
1.3.5 Web design programs: ......................................................................10
1.3.6 Video editing and visual effects: .....................................................10
1.3.7 eLearning software: ...........................................................................10
CHAPTER-2...........................................................................................................11
PROJECT OPERATIONAL STRATIGIES .....................................................11
2.1 Software Development Lifecycle: ..............................................................11
2.1.1 Planning: .............................................................................................12
2.1.2 Implementation, testing and documenting: ..................................12
2.1.3 Deployment and maintenance .........................................................12
2.2 Software Project Management Plan: .........................................................14
2.2.1 Software Project: ................................................................................14
2.2.2 Project Management Activities: .......................................................15
2.2.3 SPMP Part 1: Introduction ................................................................16
2.2.4 SPMP Part 2: Project Organization:.................................................17
2.4 Software Development Models: ................................................................17
1|Page


2.4.1 Waterfall model:.................................................................................18
2.4.2 Spiral model:.......................................................................................18
2.5 Security in IT System: ..................................................................................19
2.6 ERP System in Projects: ...............................................................................21
2.7 SOFTWARE REUSABILITY: ......................................................................22
2.8 Project Control cycle ....................................................................................23
2.9 Project Monitoring .......................................................................................23
2.10 Project Metrics, Measurement & Analysis .............................................24
2.10.1 Benefits ..............................................................................................24
2.11 Project Review ............................................................................................25
2.11.1 Group review ...................................................................................25
2.11.2 One person review...........................................................................25
2.11.3 Peer review .......................................................................................26
2.11.4 Management review ........................................................................26
2.11.5 External review ................................................................................26
2.12 Program & Portfolio Management .........................................................26
2.12.1 Program Management ....................................................................27
2.12.2 Portfolio Management ....................................................................27
2.13 PMO .............................................................................................................28
2.13.1 Strategic PMO...................................................................................28
2.13.2 Tactical PMO ....................................................................................29
2.14 Resource Levelling .....................................................................................29
2.15 Resource Smoothing ..................................................................................31
2.16 Crashing a project schedule .....................................................................31
2.16.1 Techniques of crashing ...................................................................32
2.16.2 Key aspects while crashing a project schedule ...............................32
2|Page


2.16.3 Risks involved in crashing a project schedule ............................33
2.17 Project Compressing ..................................................................................33
2.18 Project Risks ................................................................................................34
2.18.1 Risk Identification.............................................................................34
2.18.2 Risk Prioritization .............................................................................34
2.18.3 Risk response planning....................................................................35
2.18.4 Risk Management Approaches…….……………………………37

2.18.4.1 Risk Avoidance ...................................................................35
2.18.4.1 Risk Reduction ....................................................................36
2.18.4.1 Risk Transfer .......................................................................36
2.18.4.1 Risk Acceptance (Risk retention) ....................................36
2.19 Six Sigma Approach to Project.................................................................39
2.20 Total Quality Management (TQM) .........................................................40
2.20.1 Principles of TQM ............................................................................42
2.20.2 The Cost Of TQM .............................................................................43
2.21 Lean Approach ...........................................................................................44
2.22 RFP ...............................................................................................................46
12.22.1 Components of an RFP .................................................................47
12.22.3 Benefits of RFP ...............................................................................48
2.23 Project charter ................................................................................................48
2.24 Process Model ................................................................................................49
Chapter-3 ................................................................................................................51
Operational Modelling .........................................................................................51
3.1 Project Confidence Level ............................................................................51
3.2 Earned value Analysis................................................................................52

3|Page


3.2.1 Effort variance ....................................................................................52
3.2.2 Schedule variance ..............................................................................52
3.3 Earned Value Management System (EVM) .............................................53
3.3.1 Planned Value (PV) ...........................................................................54
3.3.2 Actual Cost (AC) ................................................................................54
3.3.3 Earned Value (EV) .............................................................................54
3.3.4 Cost Variance (CV) ............................................................................54
3.3.5 Schedule Variance (SV) .....................................................................54
3.3.6 Cost Performance Index (CPI)` ........................................................54
3.3.7 Estimate at Completion (EAC) ........................................................54
3.3.8 Estimate to Complete (ETC) .............................................................55
3.3.9 Schedule Performance Index (SPI) ..................................................55
3.3.10 Variance at Completion (VAC)......................................................55
3.4 Control charts for variables ........................................................................55
3.4.1 X bar Control Chart: ..........................................................................56
3.4.2 R Control Chart: .................................................................................57
3.4.3 Run Chart ............................................................................................57
3.4.4 Capability Study: ...............................................................................58
3.4.5 Control Limit Improvement .............................................................59
3.5 Customer Lifetime Value ( CLV ) .............................................................59
3.6 Sensitivity analysis (SA)..............................................................................60
3.7 Gantt Chart ...................................................................................................60
3.8 PERT...............................................................................................................63
3.9 CPM: Critical Path Method ........................................................................65
3.10 RACI Matrix................................................................................................67
3.11 Work Breakdown Structure......................................................................69
4|Page


Chapter-4 ................................................................................................................72
Financial Strategies ..............................................................................................72
4.1 Project Cost estimation................................................................................72
4.1.1 Ballpark Estimate ...............................................................................72
4.1.2 Budget estimate (Top-down estimate) ...........................................73
4.1.3 Definitive estimate (Bottom-up estimate) ......................................73
4.2 Project Capital Budgeting ...........................................................................74
4.2.1 Need for Project cost budgeting ......................................................75
4.3 Project Cost ...................................................................................................76
4.3.1 Basis of Costing ..................................................................................77
4.3.1.1 Costing based on resources.................................................77
4.3.1.2 Costing based on tasks ........................................................78
4.3.1.3 Costing based on usage ......................................................78
4.4 Project Contingency .....................................................................................78
4.5 Project Scheduling .......................................................................................79
4.5 Cost Forecasting ...........................................................................................80
Chapter-5 ................................................................................................................81
Financial Modelling ............................................................................................81
5.1 Contingency Calculation ............................................................................81
5.2 Net Present Value Method .........................................................................81
5.3 INTERNAL RATE OF RETURN METHOD ............................................83
5.4 PROFITABILITY INDEX ............................................................................84
5.5 Return On Investment .................................................................................85
5.6 Break Even Analysis ....................................................................................86

5|Page


5.7 Ratio Analysis ...............................................................................................87
5.7.1 Liquidity Ratios: .................................................................................87
5.7.2 Efficiency Ratios: ................................................................................90
5.7.3 Profitability Ratios: ............................................................................92
5.8 Cost Forecasting ...........................................................................................95
5.8.1 Regression analysis............................................................................95
5.8.2 CAGR ...................................................................................................98
5.8.3 Moving Average ............................. Error! Bookmark not defined.
5.8.4 WEIGHTED MOVING AVERAGE .................................................99
5.8.5 EXPONENTIAL SMOOTHING ....................................................100
5.8.6 DOUBLE EXPONENTIAL SMOOTHING...................................100
5.8.7 MULTIPLICATIVE SEASONAL METHOD................................101
5.8.8 CAUSAL FORECASTING METHODS ........................................103
5.8.9 MEASURING FORECAST ERRORS ............................................103
Chapter-6 ..............................................................................................................105
Learning Outcome..............................................................................................105
6.1 Learning outcome from operational strategies .....................................105
6.2 Learning outcome from financial strategies ..........................................106

ANNEXURE ........................................................................................................107
Annexure-1........................................................................................................108
Annexure-2........................................................................................................109

REFERENCES .....................................................................................................107

6|Page


Chapter-1

Introduction

1.1 About Adobe:-

 Adobe Systems Incorporated is an American computer software
company founded in 1982 and headquartered in San Jose, California,
United States.

 The company has historically focused upon the creation of
multimedia and creativity software products, with a more-recent
foray towards rich Internet application software development.

 Adobe was founded in December 1982 by John Warnock and Charles
Geschke, who established the company after leaving Xerox PARC in
order to develop and sell the PostScript page description language.

 The company name Adobe comes from Adobe Creek in Los Altos,
California, which ran behind the house of one of the company's
founders.

 Adobe acquired its former competitor, Macromedia, in December
2005, which added newer software products and platforms such as
Coldfusion, Dreamweaver, Flash and Flex to its product portfolio.

 As of August 2009, Adobe Systems has 7,564 employees, about 40%
of whom work in San Jose. Adobe also has major development
operations in Orlando, Seattle, San Francisco, Orem, Minneapolis,
Waltham, San Luis Obispo in United States; Ottawa, Canada;
Hamburg, Germany; Noida, Bengaluru, India; Bucharest, Romania;
Beijing, China.

7|Page


1.2 History of Adobe:

 Adobe's first products after PostScript were digital fonts, which they
released in a proprietary format called Type 1.

 Apple subsequently developed a competing standard, TrueType,
which provided full scalability and precise control of the pixel
pattern created by the font's outlines, and licensed it to Microsoft.
Adobe responded by publishing the Type 1 specification and
releasing Adobe Type Manager, software that allowed WYSIWYG
scaling of Type 1 fonts on screen, like TrueType, although without
the precise pixel-level control. But these moves were too late to stop
the rise of TrueType.

 Although Type 1 remained the standard in the graphics/publishing
market, TrueType became the standard for business and the average
Windows user. In 1996, Adobe and Microsoft announced the
OpenType font format, and in 2003 Adobe completed converting its
Type 1 font library to OpenType.

 In the mid-1980s, Adobe entered the consumer software market with
Adobe Illustrator, a vector-based drawing program for the Apple
Macintosh. Illustrator, which grew from the firm's in-house font-
development software, helped popularize PostScript-enabled laser
printers. Unlike MacDraw, then the standard Macintosh vector
drawing program, Illustrator described shapes with more flexible
Bézier curves, providing unprecedented accuracy. Font rendering in
Illustrator, however, was left to the Macintosh's QuickDraw libraries
and would not be superseded by a PostScript-like approach until
Adobe released Adobe Type Manager.

 In 1989, Adobe introduced what was to become its flagship product,
a graphics editing program for the Macintosh called Photoshop.
Stable and full-featured, Photoshop 1.0 was ably marketed by Adobe
and soon dominated the market.

8|Page


 In 1993, Adobe introduced PDF, the Portable Document Format, and
its Adobe Acrobat and Reader software. PDF is now an International
Standard: ISO 32000-1:2008. The technology is adopted worldwide as
a common medium for electronic documents.

 Arguably, one of Adobe's few missteps on the Macintosh platform
was their failure to develop their own desktop publishing (DTP)
program. Instead, Aldus with PageMaker in 1985 and Quark with
QuarkXPress in 1987 gained early leads in the DTP market.

 Adobe was also slow to address the emerging Windows DTP market.
However, Adobe made great strides in that market with the release
of InDesign and its bundled Creative Suite offering. In a failure to
predict the direction of computing, Adobe released a complete
version of Illustrator for Steve Jobs' ill-fated NeXT system, but a
poorly-produced version for Windows.

 Despite these missteps, licensing fees from the PostScript interpreter
allowed Adobe to outlast or acquire many of its rivals in the late
1980s and early 1990s.

 In December 1991, Adobe released Adobe Premiere, which Adobe
rebranded to Adobe Premiere Pro in 2003. In 1994, Adobe acquired
Aldus and added Adobe PageMaker and Adobe After Effects to its
production line later in the year; it also controls the TIFF file format.

 In 1995, Adobe added Adobe FrameMaker, the long-document DTP
application, to its production line after Adobe acquired Frame
Technology Corp. In 1999, Adobe introduced Adobe In Copy as a
direct competitor to QuarkCopyDesk.

1.3 Products of Adobe:

1.3.1 Desktop software:
 Adobe Photoshop,
 Adobe InDesign,
 Adobe Illustrator,

9|Page


 Adobe Fireworks, and
 Adobe Sound booth.

1.3.2 Server software:

 Adobe ColdFusion,
 Adobe Content Server and
 Adobe Lifecycle Enterprise Suite.

1.3.3 Formats

 Portable Document Format (PDF),
 PDF's predecessor PostScript, Action Script,
 Shockwave Flash (SWF) and Flash Video (FLV).

1.3.4 Web-hosted services:

 Adobe Kuler,
 Photoshop Express, and
 Acrobat.com.

1.3.5 Web design programs:

 Adobe Dreamweaver,
 Adobe Contribute and
 Adobe Flash.

1.3.6 Video editing and visual effects:

 Adobe Premiere Pro and
 Adobe after Effects.

1.3.7 eLearning software:

 Adobe Captivate.

10 | P a g e


CHAPTER-2

PROJECT OPERATIONAL STRATIGIES

2.1 Software Development Lifecycle:

 A software development process, also known as a software
development life cycle (SDLC), is a structure imposed on the
development of a software product.
 Similar terms include software life cycle and software process. It is
often considered a subset of systems development life cycle.
 There are several models for such processes, each describing
approaches to a variety of tasks or activities that take place during
the process.
 Some people consider a lifecycle model a more general term and a
software development process a more specific term.
 For example, there are many specific software development processes
that 'fit' the spiral lifecycle model.
 ISO 12207 is an ISO standard for software lifecycle processes. It aims
to be the standard that defines all the tasks required for developing
and maintaining software.

Requirements
Analysis

Design

Implementation

System Testing

Delivery and Installation

11 | P a g e


2.1.1 Planning:
 An important task in creating a software product is extracting the
requirements or requirements analysis.
 Customers typically have an abstract idea of what they want as an end result,
but not what software should do.
 Incomplete, ambiguous, or even contradictory requirements are recognized by
skilled and experienced software engineers at this point.
 Frequently demonstrating live code may help reduce the risk that the
requirements are incorrect.
 Once the general requirements are gathered from the client, an analysis of the
scope of the development should be determined and clearly stated. This is
often called a scope document.
 Certain functionality may be out of scope of the project as a function of cost
or as a result of unclear requirements at the start of development.
 If the development is done externally, this document can be considered a legal
document so that if there are ever disputes, any ambiguity of what was
promised to the client can be clarified.

2.1.2 Implementation, testing and documenting:
 Implementation is the part of the process where software engineers actually
program the code for the project.
 Software testing is an integral and important phase of the software
development process. This part of the process ensures that defects are
recognized as soon as possible.
 Documenting the internal design of software for the purpose of future
maintenance and enhancement is done throughout development. This may
also include the writing of an API, be it external or internal. It is very
important to document everything in the project.

2.1.3 Deployment and maintenance
 Deployment starts after the code is appropriately tested, is approved for
release and sold or otherwise distributed into a production environment.

 Software Training and Support is important and a lot of developers fail to
realize that. It would not matter how much time and planning a development
team puts into creating software if nobody in an organization ends up using it.

12 | P a g e


People are often resistant to change and avoid venturing into an unfamiliar
area, so as a part of the deployment phase, it is very important to have training
classes for new clients of your software.

 Maintaining and enhancing software to cope with newly discovered.
 Problems or new requirements can take far more time than the initial
development of the software.

 It may be necessary to add code that does not fit the original design to correct
an unforeseen problem or it may be that a customer is requesting more
functionality and code can be added to accommodate their requests. If the
labour cost of the maintenance phase exceeds 25% of the prior-phases' labour
cost, then it is likely that the overall quality of at least one prior phase is poor.
In that case, management should consider the option of rebuilding the system
(or portions) before maintenance cost is out of control.

Requirements
Analysis

D
E
L
A
Y
Vaporware

13 | P a g e


2.2 Software Project Management Plan:

2.2.1 Software Project:

 All technical and managerial activities required to deliver the
deliverables to the client.
 A software project has a specific duration, consumes resources
and produces work products.
 Management categories to complete a software project:

 Tasks, Activities, Functions.

 The controlling document for a software project.
 Specifies the technical and managerial approaches to develop
the software product.
 Companion document to requirements analysis document:
Changes in either may imply changes in the other document.
 SPMP may be part of project agreement.

14 | P a g e


2.2.2 Project Management Activities:

Initiation

Problem
definition
statement

Initial top- Initial
level Design Planning
milestones

Team Communication
infrastructure
formation setup

Project
kickoff

15 | P a g e


Project
Steady

Status Risk
monitoring management

Project Project
replanning agreement

Termina

Installation Client Postmortem

2.2.3 SPMP Part 1: Introduction

1.1 Project Overview:

 Executive summary: description of project, product summary

1.2 Project Deliverables:

 All items to be delivered, including delivery dates and location

16 | P a g e


1.3 Evolution of the SPMP:

 Plans for anticipated and unanticipated change

1.4 Reference Materials:

 Complete list of materials referenced in SPMP

1.5 Definitions and Acronyms

2.2.4 SPMP Part 2: Project Organization:

2.1 Process Model:

 Relationships among project elements

2.2 Organizational Structure:

 Internal management, organization chart

2.3 Organizational Interfaces:

 Relations with other entities

2.4 Project Responsibilities:

 Major functions and activities; nature of each; who‘s in charge.

2.4 Software Development Models:

 Several models exist to streamline the development process.
 Each one has its pros and cons, and it's up to the development team
to adopt the most appropriate one for the project.
 Sometimes a combination of the models may be more suitable.

17 | P a g e


2.4.1 Waterfall model:

 The waterfall model shows a process, where developers are to follow
these phases in order:

 Requirements specification (Requirements analysis)
 Software Design
 Integration
 Testing (or Validation)
 Deployment (or Installation)
 Maintenance

 In a strict Waterfall model, after each phase is finished, it proceeds to
the next one.
 Reviews may occur before moving to the next phase which allows for
the possibility of changes (which may involve a formal change
control process).
 Reviews may also be employed to ensure that the phase is indeed
complete; the phase completion criteria are often referred to as a
"gate" that the project must pass through to move to the next phase.
 Waterfall discourages revisiting and revising any prior phase once
it's complete. This "inflexibility" in a pure Waterfall model has been a
source of criticism by supporters of other more "flexible" models.

2.4.2 Spiral model:

 The key characteristic of a Spiral model is risk management at regular
stages in the development cycle.
 In 1988, Barry Boehm published a formal software system
development "spiral model", which combines some key aspect of the
waterfall model and rapid prototyping methodologies, but provided
emphasis in a key area many felt had been neglected by other
methodologies: deliberate iterative risk analysis, particularly suited
to large-scale complex systems.
 The Spiral is visualized as a process passing through some number of
iterations, with the four quadrant diagram representative of the
following activities:

18 | P a g e


 formulate plans to: identify software targets, selected to
implement the program, clarify the project development
restrictions;
 Risk analysis: an analytical assessment of selected programs,
to consider how to identify and eliminate risk;
 the implementation of the project: the implementation of
software development and verification;

 Risk-driven spiral model, emphasizing the conditions of options and
constraints in order to support software reuse, software quality can
help as a special goal of integration into the product development.
However, the spiral model has some restrictive conditions, as
follows:

 The spiral model emphasizes risk analysis, and thus requires
customers to accept this analysis and act on it. This requires
both trust in the developer as well as the willingness to
spend more to fix the issues, which is the reason why this
model is often used for large-scale internal software
development.
 If the implementation of risk analysis will greatly affect the
profits of the project, the spiral model should not be used.
 Software developers have to actively look for possible risks,
and analyze it accurately for the spiral model to work.

The first stage is to formulate a plan to achieve the objectives with these
constraints, and then strive to find and remove all potential risks through
careful analysis and, if necessary, by constructing a prototype. If some risks
can not be ruled out, the customer has to decide whether to terminate the
project or to ignore the risks and continue anyway. Finally, the results are
evaluated and the design of the next phase begins.

2.5 Security in IT System:

 Information security means protecting information and information
systems from unauthorized access, use, disclosure, disruption,
modification, perusal, inspection, recording or destruction.

19 | P a g e


 The terms information security, computer security and information
assurance are frequently incorrectly used interchangeably. These
fields are interrelated often and share the common goals of protecting
the confidentiality, integrity and availability of information; however,
there are some subtle differences between them.
 These differences lie primarily in the approach to the subject, the
methodologies used, and the areas of concentration. Information
security is concerned with the confidentiality, integrity and
availability of data regardless of the form the data may take:
electronic, print, or other forms.

 Computer security can focus on ensuring the availability and correct
operation of a computer system without concern for the information
stored or processed by the computer.
 Should confidential information about a business' customers or
finances or new product line fall into the hands of a competitor, such
a breach of security could lead to lost business, law suits or even
20 | P a g e


bankruptcy of the business. Protecting confidential information is a
business requirement, and in many cases also an ethical and legal
requirement.
 For the individual, information security has a significant effect on
privacy, which is viewed very differently in different cultures.
 The field of information security has grown and evolved significantly
in recent years. There are many ways of gaining entry into the field as
a career. It offers many areas for specialization including: securing
network(s) and allied infrastructure, securing applications and
databases, security testing, information systems auditing, business
continuity planning and digital forensics science, etc.

2.6 ERP System in Projects:

 ERP‘s best hope for demonstrating value is as a sort of battering
RAM for improving the way your company takes a customer order
and processes it into an invoice and revenue—otherwise known as
the order fulfillment process. That is why ERP is often referred to as
back-office software.
 It doesn‘t handle the up-front selling process (although most ERP
vendors have developed CRM software or acquired pure-play CRM
providers that can do this); rather, ERP takes a customer order and
provides a software road map for automating the different steps
along the path to fulfilling it.
 When a customer service representative enters a customer order into
an ERP system, he has all the information necessary to complete the
order (the customer‘s credit rating and order history from the finance
module, the company‘s inventory levels from the warehouse module
and the shipping dock‘s trucking schedule from the logistics module,
for example).

21 | P a g e


2.7 SOFTWARE REUSABILITY:

There are at least 15 different software artifacts that lend themselves to
reusability. Unfortunately, much of the literature on software reuse has
concentrated only on reusing source code. Following are the 15 artifacts
that are potentially reusable for software projects:

1. Reusable architecture
2. Reusable requirements
3. Reusable source code (zero defects)
4. Reusable designs
5. Reusable HELP information
6. Reusable data
7. Reusable training materials
8. Reusable cost estimates
9. Reusable screens
10.Reusable project plans
11.Reusable test plans
12.Reusable test cases
13.Reusable test scripts
14.Reusable user documents
15.Reusable human interfaces

Software reuse is a key factor in reducing costs and schedules and
improving quality. If the quality levels of the reusable materials are good,
then reusability has one of the highest returns on investment of any known
software technology. The average volume of high-quality reusable material
in typical applications today is less than 25%. What is needed is a step-by-
step plan that will raise the volume of high-quality reusable material up to
more than 85% on average, and more than 95% for common applications
types.

22 | P a g e


2.8 Project Control cycle

2.9 Project Monitoring

Key aspects of project monitoring is Visibility of project status. The project
managers need to have visibility into the true status of the project. The best
approach for this is the quantitative measurement of key parameters. The
usage of metrics helps to provide this visibility Interpretation of data and
taking corrective actions This data collection to provide feedback about the
current state and any required corrective actions constitute the basic
foundation for project management.
Based on the feedback received and analyzed, corrective action needs to be
taken. The plan for taking corrective action includes description of the
action, person to whom action has been assigned, planned date for initiating
the action, target closure date, and actual date of closure of the action item.

23 | P a g e


2.10 Project Metrics, Measurement & Analysis

In a project, measurements are performed to control the project effectively.

Metrics could be used to quantitatively characterize the processes in the
project (Process metrics) or the outcome of the project (product
metrics).Metrics in a project could be related to Quality, Reliability,
Productivity, Functionality, etc.

The utilization of metrics requires that measurements need to be made for
obtaining data. The metrics to be used and the measurements to consider
depend on the project and the organizational goals.

Examples of metrics include:

 Size of the project
 Schedule variance (schedule deviation)
 Effort variance (efforts deviation)

2.10.1 Benefits
A collaborative project management system facilitated managers to view
metrics
 It also enabled creation of schedules with a view of resources allocated
across projects and across the whole organization
 It enabled team members, team leaders, and project managers to
quickly complete reporting on Earned Value metrics much faster. The
automation of earned value analysis helped team leaders and project
managers since they needed to spend less time in analyzing the status
and performance of the project. This enabled them to have more time
available for billable hours in the project.
 The project managers were able to know the project status metrics in a
real time manner.
 Apart from improved productivity, automation in metrics reporting
also helped project managers to quickly take decisions leading to
reduced project budget and cost overruns. This in turn translated to
increased profitability of the projects

24 | P a g e


Let us consider two important aspects in project monitoring namely Effort
variance and Schedule variance.

2.11 Project Review

2.11.1 Group review
A formal group review is one of the best methods for identifying defects and is
also called as inspection.

2.11.2 One person review
These are formal reviews, but the effort and cost involved in review is less since a
large review team is not involved.

25 | P a g e


2.11.3 Peer review
Peer review for a project is done by peer professionals (e.g., senior project
managers) to give feedback and advice to the project. They could provide advice
based on their experience in other projects

2.11.4 Management review
These types of reviews involve the senior management. These reviews do not
involve review of specific work-products. The objective of these reviews is to
review the status of the project and to see if any help is required to be provided by
the management. These reviews could happen at various levels such as project,
program, unit/department, and organizational levels.

2.11.5 External review
External reviews involve conduct of review by an external organization. Audits
are one type of reviews. In the case of audits, external auditors review the project
to assess the conformance to the standards that are expected to be followed. The
auditor could have a look at the planning documents, work products, processes
followed, etc. and identify non-conformances to the standards

2.12 Program & Portfolio Management

26 | P a g e


2.12.1 Program Management
 A Program is a group of related projects managed in a coordinated
manner.

 A Program manager leads a team of Project managers / project leaders
who are responsible for the individual projects within the program.

 As an example, if there are 5 small projects getting executed within the
same domain and for a specific customer, it could be grouped as a
Program.

 The grouping of similar projects as a program could help in considering
the customer requirements from an overall perspective, greater
customer focus, improved sharing of resources among projects, etc.

2.12.2 Portfolio Management

 Let us consider an organization working on several projects and there
are an additional 20 projects in the pipeline which need to be taken up.

 If the funding that is available will support only a few additional
projects, how does the organization decide which of the 20 projects are
to be executed subsequently?.

 This is the concept of portfolio management. In Portfolio management,
the focus is at a more aggregate level.

 Portfolio management of projects helps in determining the right mix of
projects and the right level of investment to be made in each of them for
the achievement of organizational objectives. Portfolio decisions such as
whether it is required to fund a new project or continue to finance an
existing one are based on information provided at the project level.

27 | P a g e


2.13 PMO

 PMO (Project Management Office)

 Provides support for managing a multi-project environment

 Focus areas of PMO

▪ Coordination and Communication on the entire set of programs and
projects in the organization

▪ Function as a center of knowledge and provide training, leadership,
mentoring, best practices, methodologies and standards for project
governance, etc.

▪ Provide support to project managers in the execution of the project

▪ Provide monitoring and coordination for on-time delivery of projects
and within budget

▪ Facilitate in measuring the returns in comparison with the risk

▪ Facilitate optimized resource allocation

▪ Reporting on schedules, cost, risks, resources, quality, and scope
across all the projects

▪ Provide necessary information for executive decision-making

▪ Provide help in prioritizing and balancing project initiatives

Roles of PMO

2.13.1 Strategic PMO
The PMO works towards supporting prioritization of projects,
management of project performance, and realization of benefits. A

28 | P a g e


Strategic PMO helps to take strategic decisions on important projects
and to help in planning for investments in the overall project portfolio.

2.13.2 Tactical PMO
The PMO provides support to projects in various areas of execution
and provides information needed for decision making at the
operational level.

Responsibility of PMO

 Plan, Coordinate, Supervise, and monitor the various projects in an
organization

 Link the projects of the organization and business strategy

 Function as an operational center and provide support to the projects

 Serve as an enabler in the delivery of projects

 Monitor the outcome of projects and communicate the status to the
senior management

 Advise and support project managers

 Facilitate enhanced communication and coordination across projects

2.14 Resource Leveling
 Resource leveling

 Match resource requirements of the project with the availability of
resources

 Optimize resource allocation for projects or activities

 During the process of estimating resources for performing activities, the
type and number of resources required for each activity are identified.

29 | P a g e


The total number of resources required for performing an activity at a
specific point of time is called as ‗Resource intensity‘.

 Resource leveling techniques are used to match the resource
requirements of the project with the availability of resources.

 Resource leveling is an important aspect, especially when there is a
requirement to assign resources to multiple activities or multiple
projects that need to be executed in parallel

 This is required to optimize the allocation of resources for projects or
activities

 When there are problems in the availability of resources and hiring of
external resources is not feasible within the project budget, the following
options could be considered:

 Allocation of the resources to activities having higher priority and
staggering the dates of other activities (this helps to reduce the resource
intensity)

 Utilization of different, underutilized types of resources for some
activities (however, in some cases this may not be possible)

In the scenario relating to requirement of 20 designers as discussed
earlier, let us consider a situation in which only 15 designers are
available in a particular week. Assuming that Activity ‗B‘ is most
critical, five designers could be allocated to this activity to ensure that
there is no impact in its duration and sequencing. The remaining 10
designers who are currently available could be allocated based on the
importance of the remaining three activities, resource requirements for
succeeding activities, etc.

30 | P a g e


2.5 Resource Smoothing

In a project-based structure, proper utilization of resources is required to
maintain a balance between the demand for resources and its availability.
This could be achieved through resource smoothing.

Resource smoothing is a type of resource leveling. The focus is to maintain
the most efficient utilization of the pool of types of resources across the
project. This is done by smoothing out the peaks (highs) and valleys (lows)
in the resource intensity. It helps to make the demand for resource types to
be more level across time durations by working within the float of
individual activities.

Example

A project has 9 units of a specific resource available at any point of time.
The resources could be utilized such that 4 resources are used in one week,
9 in the other, 3 in the next, and so on for completion of an activity in the
project. In this case, there is a series of peaks and lows in the resource
deployment. We could consider ―smoothing‖ such that 7 resources are
utilized across various weeks for completion of the activity. However, it is
required to consider which particular resource(s) should be given a priority
in the ―resource smoothing‖ process.

2.16 Crashing a project schedule

Any activity would require a specific duration (days or weeks or months)
for its completion. In other words, this is the normal time required for the
activity to be completed. The time required for completing the activity
could be reduced but this would increase the cost. This concept of getting
an activity completed quickly using alternate ways which would cost more
money is called as ‗Crashing‘

31 | P a g e


2.16.1 Techniques of crashing

Increasing number of resources

This is a common method deployed for project schedule crashing. It
involves adding more resources to the project to achieve reduction in the
time taken to perform the individual activities in the project. However, the
issues in increasing the number of resources include:

 Learning curve for the new resources (which consumes time)

 Competency level of the new resources

 Existing resources need to spend time to guide the new resources

Fast tracking

This involves performing tasks in an overlapping manner instead of
sequentially executing them as planned initially. Fast tracking could also
involve reduction of lag time between tasks, scope reduction to eliminate
less important tasks, etc.

2.16.2 Key aspects to be considered while crashing a project schedule

 Attaining maximum reduction in schedule time at minimum cost

 Crashing only the critical activities

 Crashing from the least expensive to the most expensive tasks

 Crashing an activity only until it reaches maximum reduction in time

 Crashing an activity until it causes another path also to become critical

 Crashing the schedule until it becomes more expensive than not
crashing it (i.e. leaving the schedule as it is)

32 | P a g e


2.16.3 Risks involved in crashing a project schedule

 Budget-related risk: Since more resources have been added to the
project, the project will be beyond the budget

 Coordination-related risk: Increasing the number of resources could
result in increase of communication-related challenges

 People-related risk: Existing people could get de-motivated since the
tasks assigned to them initially are being assigned to the new resources

2.17 Project Compressing

Compressing a project schedule involves conducting project activities in
parallel. Similar to crashing, compression also cannot be applied to all
activities of a project. Coordination could become an issue when a project
schedule is compressed. However, compression of a project schedule is
better than crashing it since the risk involved is less.

 As an example, let us consider a scenario from the construction
industry.

 Let us assume that it takes 20 days for the process of purchasing bricks
to be completed. The purchase of bricks could be done while the
foundation activity is in progress. This would reduce the waiting time
for bricks to be made available. This would help in compressing the
overall construction schedule. However, it is not possible to compress
the project schedule by planning to lay the roofing when the
construction of walls is in progress.

33 | P a g e


2.18 Project Risks

Risks could impact the schedule, cost, or the project‘s outcome. Early
identification of risks facilitates in handling them better. All identified risks
need to be managed adequately .Monitoring closed risks reduces the
probability of its recurrence. Risks need to be communicated to
stakeholders in a project so that they could also help in managing the risks

Steps in Risk Management

2.18.1 Risk Identification
 To list possible risks in a project

2.18.2 Risk Prioritization
 Analysis of potential impact of a risk if it actually occurs.

 Provides information to help focus on important risks.

34 | P a g e


 Risk exposure is used to prioritize risks

▪ Risk Exposure (RE) = Probability of occurrence of risk x Loss due
to risk

2.18.3 Risk response planning
 Identification of actions (mitigation steps) required for minimizing
the consequences of the risks

 Incorporation of the mitigation steps into the project schedule

 Risk monitoring and tracking

 Monitoring and tracking risk perception for the project

 Tracking progress of risk mitigation steps

2.18.4 Risk Management Approaches

2.18.4.1 Risk Avoidance
 Not performing an activity to avoid risks

 Avoiding all risks, we would also avoid all opportunities for
achievement.

 Further, if we avoid doing the activity itself considering that it has
risks involved, we may not be able to do any activity in our day-
to-day life.

 As an example, it is not possible to avoid traveling by flight
because there are risks such as the possibility of occurrence of a
crash, mid-air collisions, bird-hits, etc.

 An example for risk avoidance could be avoiding setting up an
industry in an earthquake prone area to avoid the risk of damage
due to occurrence of an earthquake

35 | P a g e


 In the Metro project discussed, risk avoidance could be adopted
by shifting the position of the line for the metro away from
underground water pipelines so that damage during digging
could be avoided.

2.18.4.1 Risk Reduction
 Adopting mechanisms or methods to reduce potential loss
associated with a particular risk.

 Though the risk cannot be totally avoided, it helps to minimize the
impact / consequences of the risk.

 Example

 The availability of fire alarms and fire safety equipment in a
building is an example of risk reduction. These cannot
prevent or avoid a fire from happening, but could help in
reducing the loss if a fire breaks out

 The Metro project example

 The risk of road traffic being disrupted during construction
of the metro could be reduced by planning and setting up an
alternate road for vehicle movement.

2.18.4.1 Risk Transfer
 Transferring the impact / consequence of a risk to another entity

Once the risk is transferred, the transferor of the risk need not worry
about the consequences of the risk since these will be addressed by the
transferee

2.18.4.1 Risk Acceptance (Risk retention)
 Accepting the risk that has been identified

 This is also known as Risk Retention. It involves simply accepting
the risk that has been identified.

36 | P a g e


 The risk is accepted without adopting any methods to prevent or
minimize the probability of occurrence of the risk or the associated
loss if it occurs.

 A risk acceptance approach is usually used in any of the following
cases:

 Risks that do not result in a great extent of loss if they occur

 Risks that are very difficult to prevent from occurring

 Risks that would be more costly to manage than to accept
and allow them to occur

2.18.5 Best Practice Risk Management

Framework for Risk Management can be benchmarked in terms of:

» Policies

» Methodologies

» Resources

2.18.6 Categories of variation

» Within-piece variation

» One portion of surface is rougher than another portion.

» A piece-to-piece variation

» Variation among pieces produced at the same time.

» Time-to-time variation

» Service given early would be different from that given later in the
day.

37 | P a g e


2.18.7 Source of variation

» Equipment

» Tool wear, machine vibration, …

» Material

» Raw material quality

» Environment

» Temperature, pressure, humidity

» Operator

» Operator performs- physical & emotional

2.18.8 Control Chart Viewpoint

Control charts are powerful aids to understanding the performance of a
process over time. Variation due to

 Common or chance causes

 Assignable causes

Control chart may be used to discover ―assignable causes‖

38 | P a g e


2.19 Six Sigma Approach to Project

Business Definition

A break through strategy to significantly improve customer satisfaction and
shareholder value by reducing variability in every aspect of business.

Technical Definition

A statistical term signifying 3.4 defects per million opportunities.

• Degree of variation;

• Level of performance in terms of defects;

• Statistical measurement of process capability;

• Benchmark for comparison;

• Process improvement methodology;

• It is a Goal;

• Strategy for change;

• A commitment to customers to achieve an acceptable level of performance

39 | P a g e


2.20 Total Quality Management (TQM)

Total Quality Management (TQM) is an approach that seeks to improve
quality and performance which will meet or exceed customer expectations.
This can be achieved by integrating all quality-related functions and
processes throughout the company. TQM looks at the overall quality
measures used by a company including managing quality design and
development, quality control and maintenance, quality improvement, and
quality assurance. TQM takes into account all quality measures taken at all
levels and involving all company employees.

At its core, Total Quality Management (TQM) is a management approach
to long-term success through customer satisfaction.

In a TQM effort, all members of an organization participate in improving
processes, products, services and the culture in which they work.

40 | P a g e


The methods for implementing this approach come from the teachings of
such quality leaders as Philip B. Crosby, W. Edwards Deming, Armand V.
Feigenbaum, Kaoru Ishikawa and Joseph M. Juran.

A core concept in implementing TQM is Deming‘s 14 points, a set of
management practices to help companies increase their quality and
productivity:

1. Create constancy of purpose for improving products and services.
2. Adopt the new philosophy.
3. Cease dependence on inspection to achieve quality.
4. End the practice of awarding business on price alone; instead,
minimize total cost by working with a single supplier.
5. Improve constantly and forever every process for planning,
production and service.
6. Institute training on the job.
7. Adopt and institute leadership.
8. Drive out fear.
9. Break down barriers between staff areas.
10.Eliminate slogans, exhortations and targets for the workforce.
11.Eliminate numerical quotas for the workforce and numerical goals
for management.
41 | P a g e


12.Remove barriers that rob people of pride of workmanship, and
eliminate the annual rating or merit system.
13.Institute a vigorous program of education and self-improvement for
everyone.
14.Put everybody in the company to work accomplishing the
transformation.

The term ―Total Quality Management‖ has lost favor in the United States
in recent years: ―Quality management‖ is commonly substituted. ―Total
Quality Management,‖ however, is still used extensively in Europe.

2.20.1 Principles of TQM

TQM can be defined as the management of initiatives and procedures that
are aimed at achieving the delivery of quality products and services. A
number of key principles can be identified in defining TQM, including:

Executive Management – Top management should act as the main
driver for TQM and create an environment that ensures its success.
 training – Employees should receive regular training on the
methods and concepts of quality.
 Customer Focus – Improvements in quality should improve
customer satisfaction.
 Decision Making – Quality decisions should be made based on
measurements.
 Methodology and Tools – Use of appropriate methodology and
tools ensures that non-conformances are identified, measured and
responded to consistently.
 Continuous Improvement – Companies should

 continuously work towards improving manufacturing and quality
procedures.
 Company Culture – The culture of the company should aim at
developing employees ability to work together to improve quality.
 Employee Involvement – Employees should be encouraged to be pro-
active in identifying and addressing quality related problems.

42 | P a g e


2.20.2 The Cost Of TQM

Many companies believe that the costs of the introduction of TQM are far
greater than the benefits it will produce. However research across a
number of industries has costs involved in doing nothing, i.e. the direct
and indirect costs of quality problems, are far greater than the costs of
implementing TQM.

The American quality expert, Phil Crosby, wrote that many companies
chose to pay for the poor quality in what he referred to as the ―Price of
Nonconformance‖. The costs are identified in the Prevention, Appraisal,
Failure (PAF) Model.

Prevention costs are associated with the design, implementation and
maintenance of the TQM system. They are planned and incurred before
actual operation, and can include:

 Product Requirements – The setting specifications for incoming
materials, processes, finished products/services.
 Quality Planning – Creation of plans for quality, reliability, operational,
production and inspections.
 Quality Assurance – The creation and maintenance of the quality system.
 Training – The development, preparation and maintenance of processes.

Appraisal costs are associated with the vendors and customers evaluation
of purchased materials and services to ensure they are within specification.
They can include:

 Verification – Inspection of incoming material against agreed upon
specifications.
 Quality Audits – Check that the quality system is functioning correctly.
 Vendor Evaluation – Assessment and approval of vendors.

Failure costs can be split into those resulting from internal and external
failure. Internal failure costs occur when results fail to reach quality

43 | P a g e


standards and are detected before they are shipped to the customer. These
can include:

 Waste – Unnecessary work or holding stocks as a result of errors, poor
organization or communication.
 Scrap – Defective product or material that cannot be repaired, used or
sold.
 Rework – Correction of defective material or errors.
 Failure Analysis – This is required to establish the causes of internal
product failure.

External failure costs occur when the products or services fail to reach
quality standards, but are not detected until after the customer receives the
item. These can include:

 Repairs – Servicing of returned products or at the customer site.
 Warranty Claims – Items are replaced or services re-performed under
warranty.
 Complaints – All work and costs associated with dealing with customer‘s
complaints.
 Returns – Transportation, investigation and handling of returned items.
2.21 Lean Approach

Lean manufacturing, lean enterprise, or lean production, often simply,
"Lean," is a production practice that considers the expenditure of resources
for any goal other than the creation of value for the end customer to be
wasteful, and thus a target for elimination. Working from the perspective
of the customer who consumes a product or service, "value" is defined as
any action or process that a customer would be willing to pay for.
Essentially, lean is centered on preserving value with less work. Lean
manufacturing is a management philosophy derived mostly from
the Toyota Production System (TPS) (hence the term Toyotism is also
prevalent) and identified as "Lean" only in the 1990s. TPS is renowned for
its focus on reduction of the original Toyota seven wastes to improve

44 | P a g e


overall customer value, but there are varying perspectives on how this is
best achieved. The steady growth of Toyota, from a small company to the
world's largest automaker, has focused attention on how it has achieved
this.
Lean manufacturing is a variation on the theme of efficiency based on
optimizing flow; it is a present-day instance of the recurring theme in
human history toward increasing efficiency, decreasing waste, and using
empirical methods to decide what matters, rather than uncritically
accepting pre-existing ideas. As such, it is a chapter in the larger narrative
that also includes such ideas as the folk wisdom of thrift, time and motion
study, Taylorism, the Efficiency Movement, and Fordism. Lean
manufacturing is often seen as a more refined version of earlier efficiency
efforts, building upon the work of earlier leaders such as Taylor or Ford,
and learning from their mistakes.

45 | P a g e


Lean for Production and Services

A popular misconception is that lean is suited only for manufacturing. Not
true. Lean applies in every business and every process. It is not a tactic or a
cost reduction program, but a way of thinking and acting for an entire
organization.
Businesses in all industries and services, including healthcare and
governments, are using lean principles as the way they think and do. Many
organizations choose not to use the word lean, but to label what they do as
their own system, such as the Toyota Production System or the Danaher
Business System. Why? To drive home the point that lean is not a program
or short term cost reduction program, but the way the company operates.
The word transformation or lean transformation is often used to
characterize a company moving from an old way of thinking to lean
thinking. It requires a complete transformation on how a company
conducts business. This takes a long-term perspective and perseverance.
The term "lean" was coined to describe Toyota's business during the late
1980s by a research team headed by Jim Womack, Ph.D., at MIT's
International Motor Vehicle Program.

2.22 RFP
A request for proposal (RFP) is an early stage in
a procurement process, issuing an invitation for suppliers, often through
a bidding process, to submit a proposal on a specific commodity or service.
The RFP process brings structure to the procurement decision and allows
the risks and benefits to be identified clearly upfront. A request for
proposal (RFP) is a document that an organization posts to elicit bids from
potential vendors for a product or service.

The RFP may dictate to varying degrees the exact structure and
format of the supplier's response. Effective RFPs typically reflect the
strategy and short/long-term business objectives, providing detailed
insight upon which suppliers will be able to offer a matching perspective.

46 | P a g e


For example, a new business or a business moving from a paper-
based system to a computer-based system might request proposals for all
the hardware, software, and user training required to establish and
integrate the new system into the organization. Another business might
draft an RFP for a custom-written computer application they wanted
to outsource.

The quality of an RFP is very important to successful project
management because it clearly delineates the deliverable RFQ) is
sometimes posted when the requirements are very clear-cut - for example,
in the purchase of hardware.

2.22.1 Components of an RFP

1) Background information about the company, business problem, and
the computing environment. It may also include results of any needs
assessment performed.
2) Schedule of important dates such as when the supplier‘s RFP
response is due, when the decision is expected, when the actual
purchase is expected, and when implementation is expected.
3) Contact names and sources for answering questions for the RFP.
4) Instructions for formatting the response to the RFP. Some RFPs
include an explicit description of what the supplier should and
should not include in their response.
5) Specific requirements being sought.
6) Technical requirements for the system, such as specifications for an
operating system or a network environment.
7) List of documents required as attachments, such as sample reports
and standard contract language.
8) Additional requirements for the selection process, such as supplier
presentations, supplier demonstrations, or on-site installation and
testing.

47 | P a g e


2.22.3 Benefits of RFP

 Informs suppliers that your company is looking to procure and
encourages them to make their best effort.
 Requires the company to specify what it proposes to purchase. If
the requirements analysis has been prepared properly, it can be
incorporated quite easily into the Request document.
 Alerts suppliers that the selection process is competitive.
 Allows for wide distribution and response.
 Ensures that suppliers respond factually to the identified
requirements.
 By following a structured evaluation and selection procedure an
organization can demonstrate impartiality - a crucial factor in public
sector procurements

2.23 Project charter

In project management, a project charter or project definition is a
statement of the scope, objectives and participants in a project. It provides a
preliminary delineation of roles and responsibilities, outlines the project
objectives, identifies the main stakeholders, and defines the authority of the
project manager. It serves as a reference of authority for the future of the
project. The terms of reference are usually a part of the project charter.

The project charter is usually a short document that refers to more
detailed documents such as a new offering request or a request for
proposal. In Initiative for Policy Dialogue (IPD), this document is known as
the project charter. In customer relationship management (CRM), it is
known as the project definition report. Both IPD and CRM require this
document as part of the project management process.

48 | P a g e


The project charter establishes the authority assigned to the project
manager, especially in a matrix management environment. It is considered
industry best practice. The purpose of the project charter is to document:

 Reasons for undertaking the project
 Objectives and constraints of the project
 Directions concerning the solution
 Identities of the main stakeholders
The main uses of the project charter are :

 To initiate the project
 To authorize the project - using a comparable format, projects can be
ranked and authorized by Return on investment
 Serves as the primary sales document for the project – ranking
stakeholders have a 1-2 page summary to distribute, present, and
keep handy for fending off other project or operations runs at project
resources.
 As a focus point throughout the project - for example: project as
people walk in to team meetings and use in change control meetings
to ensure tight scope management.

2.24 Process Model
The term process model is used in various contexts. For example,
in business process modeling the enterprise process model is often referred
to as the business process model. Process models are core concepts in the
discipline of process engineering.

Process models are processes of the same nature that are classified
together into a model. Thus, a process model is a description of a process at
the type level. Since the process model is at the type level, a process is an
instantiation of it. The same process model is used repeatedly for the
development of many applications and thus, has many instantiations. One
possible use of a process model is to prescribe how things
must/should/could be done in contrast to the process itself which is really

49 | P a g e


what happens. A process model is roughly an anticipation of what the
process will look like. What the process shall be will be determined during
actual system development.

The goals of a process model are to be:

Descriptive

 Track what actually happens during a process.
 Take the point of view of an external observer who looks at the way a
process has been performed and determines the improvements that
must be made to make it perform more effectively or efficiently.

Prescriptive

 Define the desired processes and how they should/could/might be
performed.
 Establish rules, guidelines, and behavior patterns which, if followed,
would lead to the desired process performance. They can range from
strict enforcement to flexible guidance.

Explanatory

 Provide explanations about the rationale of processes.
 Explore and evaluate the several possible courses of action based on
rational arguments.
 Establish an explicit link between processes and the requirements
that the model needs to fulfill.
 Pre-defines points at which data can be extracted for reporting
purposes.

50 | P a g e


Chapter-3

Operational Modeling

3.1 Project Confidence Level

• 34.13% of data lie between  and 1 above the mean ().
• 34.13% between  and 1 below the mean.
• Approximately two-thirds (68.28 %) within 1 of the mean.
• 13.59% of the data lie between one and two standard deviations
• Finally, almost all of the data (99.74%) are within 3 of the mean.

• Based on our knowledge of the normal curve, a control chart exhibits a
state of control when:

51 | P a g e


♥ Two thirds of all points are near the center value.

♥ The points appear to float back and forth across the centerline.

♥ The points are balanced on both sides of the centerline.

♥ No points beyond the control limits.

♥ No patterns or trends.

3.2 Earned value Analysis

3.2.1 Effort variance

The project is likely to be completed within the budget or The project is
likely to cost 25% more than what was projected earlier‖, etc.

Effort variance (in percentage) is computed using the following formula:

= (Actual effort –Planned effort) /Planned effort x 100

Let us consider a project that is estimated to require an effort of 1200 person-days
(e.g. 4 persons working for 300 days, or 6 people working for 200 days, etc.).
If it is now re-estimated based on current scenario in the project that it would
required 1500 person-days of effort, let us compute the effort variance:

Effort variance = (1500 - 1200)/1200 x 100 = 25%

In other words, this project has consumed require 25% more effort than
estimated

3.2.2 Schedule variance

Since projects are driven by schedules, deadlines, and milestones it is one
of the key metrics. Usually, calendar time is used to measure the deviation
(variance) in schedule.

52 | P a g e


Schedule variance (in percentage) for an activity or for a project is
computed using the following formula:

Schedule variance

= (Actual duration –Planned duration) Planned duration /x 100

Let us consider that a project has been initially expected to be completed in 300
days. If it is now re-estimated that it would take 400 days to complete, the schedule
variance is computed as follows:

Schedule variance = (400 –300) / 300 x 100 = 33.33%

In other words, the project would take 33.33% more time than initially
estimated

3.3 Earned Value Management System (EVM)

A collection of management practices. A structured method for
establishing a Performance Measurement Baseline
A structured method to measure and analyze performance

The Earned Value Analysis (EVA) technique is widely used in assessing the
performance of a project.
EVA
Considers three key aspects, namely
 Planned Value (How much should we have done at point X?)
 Actual Cost (Amount actually spent till date)
 Earned Value (How much has actually been accomplished as on date;
i.e. how much value has been realized)

Terminology Description Formula

53 | P a g e


3.3.1 Planned Value (PV)
IndicateswhattheprojectshouldbeworthatthispointoftimeintheSchedule.Itis
alsocalledasBCWS(BudgetedCostofWorkScheduled).

3.3.2 Actual Cost (AC)
It is the actual amount of money spent so far. It is also referred as ACWP
(Actual Cost of Work Performed).

3.3.3 Earned Value (EV)
It is the actual work completed till date and the authorized budget for it. It
is also known as BCWP (Budgeted Cost of Work Performed).

3.3.4 Cost Variance (CV)
It is the difference between the Earned value and Actual cost. A negative
value indicates that there is a cost overrun in the project
CV = EV –AC

3.3.5 Schedule Variance (SV)
It is the difference between Earned Value and the Planned Value. A
negative value indicates that there is Schedule overrun in the project
SV = EV –PV

3.3.6 Cost Performance Index (CPI)`
Cost Performance Index (CPI) is the ratio of Earned Value to the Actual
cost. If CPI is less than 1, it indicates that the project is beyond the budget.
Similarly, if CPI is greater than 1, it denotes that the project is within the
budget
CPI = EV / AC

3.3.7 Estimate at Completion (EAC)
This indicates the estimated total cost (forecast) of the project at
completion. It is a ratio of Budget at Completion to the Cost Performance
Index
54 | P a g e


EAC = BAC / CPI

3.3.8 Estimate to Complete (ETC)
This is the difference between the Estimate at Completion and the Actual
Cost
ETC = EAC –AC

3.3.9 Schedule Performance Index (SPI)
Schedule Performance Index (CPI) is the ratio of Earned Value to the
Planned Value. If SPI is less than 1, it indicates that the project is beyond
schedule. Similarly, if SPI is greater than 1, it denotes that the project is
within the schedule
SPI = EV / PV

3.3.10 Variance at Completion (VAC)
Variance at Completion is the difference between Budget at Completion
and the Estimate at Completion. A negative VAC indicates that it is not a
favorable scenario
VAC = BAC –EAC

3.4 Control charts for variables

X-bar chart

• In this chart the sample means are plotted in order to control the
mean value of a variable (e.g., size of piston rings, strength of
materials, etc.).

R chart

• In this chart, the sample ranges are plotted in order to control the
variability of a variable.

55 | P a g e


S chart

• In this chart, the sample standard deviations are plotted in order to
control the variability of a variable.

S2 chart

• In this chart, the sample variances are plotted in order to control
the variability of a variable.

Centerline

• shows where the process average is centered or the central
tendency of the data

Upper control limit (UCL) and Lower control limit (LCL)

• describes the process spread

The Control Chart Method

3.4.1 X bar Control Chart:

UCL = XDmean + A2 x Rmean

LCL = XDmean - A2 x Rmean

CL = XDmean
5.10
UCL
5.08
5.06
5.04
X bar

5.02
5.00 CL
4.98
4.96 LCL
4.94
0 1 2 3 4 5 6 7 8 9 10 11

Subgroup 56 | P a g e


3.4.2 R Control Chart:

UCL = D4 x Rmean

LCL = D3 x Rmean

CL = Rmean

0.25 UCL

0.20
Range

0.15
CL

0.10

0.05
LCL
0.00
0 1 2 3 4 5 6 7 8 9 10 11
Subgroup

3.4.3 Run Chart
6.70
6.65
6.60
Mean, X-bar

6.55
6.50
6.45
6.40
6.35
6.30
0 5 10 15 20 25
Subgroup number

57 | P a g e


3.4.4 Capability Study:

PCR = (USL - LSL)/(6s); where s = Rmean /d2

UCL  X  3
LCL  X  3
  standard deviation

58 | P a g e


3.4.5 Control Limit Improvement

In certain cases, control limits are revised because:

1. out-of-control points were included in the calculation of the
control limits.

2. the process is in-control but the within subgroup variation
significantly improves.

3.5 Customer Lifetime Value ( CLV )

In marketing, customer lifetime value (CLV), lifetime customer value (LCV),
or lifetime value (LTV) is the net present value of the cash flows attributed to
the relationship with a customer

CLV = ∑ ] power k

CLV: Customer Lifetime Value

59 | P a g e


PC : Profit Contribution

d : Discount Rate

n : Number of years

k : Time unit

3.6 Sensitivity analysis (SA)

Sensitivity analysis (SA) is the study of how the variation (uncertainty) in the
output of a mathematical model can be apportioned, qualitatively or
quantitatively, to different sources of variation in the input of the model

I(X)

O ( X, Y)

I(Y)

If f ( x ) is altered, than to what degree O ( X,Y ) would change.

3.7 Gantt Chart

A Gantt chart is a type of bar chart that illustrates a project schedule. Gantt
charts

illustrate the start and finish dates of the terminal elements and
summary elements of a project. Terminal elements and summary elements
comprise the work breakdown structure of the project. Some Gantt charts
also show the dependency (i.e., precedence network) relationships between
activities.

60 | P a g e


A Gantt chart is a graphical representation of the duration of tasks
against the progression of time. A Gantt chart is a useful tool for planning
and scheduling projects.

A Gantt chart is helpful when monitoring a project's progress. A
Gantt chart is a type of bar chart that illustrates a project schedule. Gantt
charts illustrate the start and finish dates of the terminal elements and
summary elements of a project.

Terminal elements and summary elements comprise the work
breakdown structure of the project. Some Gantt charts also show the
dependency relationships between activities.

Gantt charts only represent part of the triple constraints (cost, time and
scope) of projects, because they focus primarily on schedule management.
Moreover, Gantt charts do not represent the size of a project or the relative
size of work elements, therefore the magnitude of a behind-schedule
condition is easily miscommunicated. If two projects are the same number
of days behind schedule, the larger project has a larger impact on resource
utilization, yet the Gantt does not represent this difference.

Example
In the following example there are seven tasks, labeled A through G.
Some tasks can be done concurrently (A and B) while others cannot be
done until their predecessor task is complete (C cannot begin until A is
complete). Additionally, each task has three time estimates: the optimistic
time estimate (O), the most likely or normal time estimate (M), and the
pessimistic time estimate (P). The expected time (TE) is computed using the
formula (O + 4M + P) ÷ 6.

61 | P a g e


Time estimates
Activity Predecessor Expected time
Opt. (O) Normal (M) Pess. (P)

A — 2 4 6 4.00

B — 3 5 9 5.33

C A 4 5 7 5.17

D A 4 6 10 6.33

E B, C 4 5 7 5.17

F D 3 4 8 4.50

G E 3 5 8 5.17

Once this step is complete, one can draw a Gantt chart or a network
diagram.

62 | P a g e


Advantages of using Gantt charts

 It provides a clear view of the sequence of tasks
 The progress of a project is easily visible since we know where we
are and where we should be since a specific time duration is
allocated for each task
 It enables us to clearly understand dependencies existing between
tasks
 It helps us during the planning and execution of a project
 It facilitates monitoring the project and ensuring that it is on track

3.8 PERT
A PERT chart is a graphic representation of a project‘s schedule,
showing the sequence of tasks, which tasks can be performed
simultaneously, and the critical path of tasks that must be completed on
time in order for the project to meet its completion deadline. The chart can
be constructed with a variety of attributes, such as earliest and latest start
dates for each task, earliest and latest finish dates for each task, and slack
time between tasks.

PERT is a method to analyze the involved tasks in completing a given
project, especially the time needed to complete each task, and identifying
the minimum time needed to complete the total project.

PERT was developed primarily to simplify the planning and
scheduling of large and complex projects. It was developed for the U.S.
Navy Special Projects Office in 1957 to support the U.S. Navy's Polaris
nuclear submarine project. It was able to incorporate uncertainty by
making it possible to schedule a project while not knowing precisely the
details and durations of all the activities.

63 | P a g e


It is more of an event-oriented technique rather than start- and completion-
oriented, and is used more in projects where time, rather than cost, is the
major factor. It is applied to very large-scale, one-time, complex, non-
routine infrastructure and Research and Development projects. An
example of this was for the 1968 Winter Olympics in Grenoble which
applied PERT from 1965 until the opening of the 1968 Games. This project
model was the first of its kind, a revival for scientific management,
founded by Frederick Taylor and later refined by Henry Ford. A PERT
network chart for a seven-month project with five milestones (10 through
50) and six activities (A through F) is shown in the figure below.

A PERT chart can document an entire project or a key phase of a
project. The chart allows a team to avoid unrealistic timetables and
schedule expectations, to help identify and shorten tasks that are
bottlenecks, and to focus attention on most critical tasks.

A network diagram can be created by hand or by using diagram
software. There are two types of network diagrams, activity on arrow
(AOA) and activity on node (AON). Activity on node diagrams is generally
easier to create and interpret.

64 | P a g e

Project Management

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (18)

Destacado

Destacado (20)

Similar a Project Management

Similar a Project Management (20)

Más de Sunam Pal

Más de Sunam Pal (8)

Último

Último (20)

Project Management