Professional Documents
Culture Documents
PJM - All Merged
PJM - All Merged
Team Members
➢ Narendran Ulaganathan- 20BSPHH01C0761
➢ Bhaveshri Shah - 20BSPHH01C0295
Dillard’s Case Analysis
• This case highlights the difficulties of matching staffing numbers to
varying workloads in retail stores, as well as how staffing and scheduling
decisions affect operational performance and labour quality in the stores.
• The case describes the tasks that are both in-store logistics and customer
service tasks that are carried out by store employees at one Dillard's
department store.
• Dillard’s store employed 165 hourly sales associates where full time
employees worked 35-39 hours/week and part time employees worked
25- 28 hours/week (6-9pm & weekends)
• The Higher conversation rates happened between 11a.m. and 12 p.m. and
between 8 p.m. and 9p.m.
• IBM’s Smart Surveillance System (S3), a video-mining technology, had
been used where they had collected 12 weeks of store-traffic data at a
Texas location of Dillard’s department store chain in the United States.
• The S3 solution is used to count traffic in and out of the store and
departments and to provide retailers with loss prevention, operations and
merchandising and marketing benefits.
• The cameras in different locations were used to get the required data. The
cameras were mounted in each store entrance, in the perimeter of the
shoe department, near escalators and in some specific areas to view
brands that were particularly likely to be stolen.
• This resulted in a way to increase a store’s conversion rate by modifying
the staffing of the store to take advantage of when customer traffic
varied during the day and week. Then hourly traffic data is combined with
hourly sales-transaction data.
• The analysis showed a strong relationship between conversion rates
(transactions/visitors) and staffing levels adjusted by traffic (labour
hours/visitors). This concluded that Dillard’s had a great opportunity to
improve sales at its store in Arlington.
• Thus, we conclude by saying Resource redirection is adopted by the
Dillard’s, Inc.
What is a Gantt chart?
Definition
A Gantt chart is a project management tool assisting in the planning and scheduling of
projects of all sizes, although they are particularly useful for simplifying complex
projects. Project management timelines and tasks are converted into a horizontal bar
chart, showing start and end dates, as well as dependencies, scheduling and deadlines,
including how much of the task is completed per stage and who is the task owner. This
is useful to keep tasks on track when there is a large team and multiple stakeholders
when the scope changes.
As it's in a bar chart format it is possible to check on progress with a quick glance. You
can easily see:
Project management solutions that integrate Gantt charts give managers visibility into
team workloads, as well as current and future availability, which allows for more
accurate scheduling. Gantt charts have been around for nearly a century, having been
invented by Henry Gantt, an American mechanical engineer, around 1910.
To create a chart you need to know all of the individual tasks required to complete the
project, an estimate of how long each task will take and which tasks are dependent on
others. The very process of pulling this information together helps a project manager
focus on the essential parts of the project and begin to establish a realistic timeframe for
completion.
In summary:
• When you set up a Gantt chart, you need to think through all of the tasks involved in your
project and divide them into manageable components.
• Then decide who will be responsible for each task and delegate to the team.
• Identify task relationships and decide on the completion date sequence for each task, showing
the expected time duration of the whole project and the sub tasks. A Gantt chart will show the
tasks in a sequential order and display task dependencies (ie. how one task relates to another).
• Anticipate the risks and problems you may encounter and create a contingency plan for
potential problems.
• Establish the initial project schedule - who is going to do what, when and how long will it take.
• Make project adjustments - the initial plan will need many adjustments.
• Control and communicate the schedule - clear visuals for stakeholders and participants.
• Identify and report problems - As everything is depicted visually you can immediately see what
should have been achieved by a certain date and, if the project is behind schedule, you can
take action to bring it back on course.
• Gantt charts are not perfect and can become overly complex with too many
dependencies and activities. It is better to produce a clear and simple plan that
shows the main work packages in summary, than a plan with so much detail that
the overall impression of project progress is lost.
• Gantt charts are also not good at showing the relative priorities of individual tasks
and the resources expended on a task. They can clearly show the elapsed time
of a task but don't easily communicate how many people may be needed to
complete it. This is where using additional techniques such as a precedence
diagram (sometimes called a PERT chart), for instance, becomes useful.
• Step 1. List your project schedule in an Excel table. List each task as a separate
row and structure your project plan by including the start date, end date and
duration.
• Step 5. Transform the bar graph into the Excel Gantt chart through formatting.
• Apache OpenOffice
• Microsoft Project
• Open Workbench
• ProjectLibre
• OpenProj
Advantages of fixed price contracts include throwing all the risk on the seller. The main disadvantage is
that the seller may start cutting scope or quality in order to finish on time and on budget.
• Fixed Price Incentive Fee (FPIF) – If project finished little bit earlier, an additional amount will be
paid to the seller.
• Fixed Price Award Fee (FPAF) – If the performance of seller exceeds as planned earlier an
additional amount will be paid to the seller.
• Fixed Price Economic Price Adjustment (FPEPA) – The fixed price can be re-determined
depending on the market pricing rate.
• Cost Plus Fee (CPF) or Cost Plus Percentage of Costs (CPPC) – The seller will get the total
cost they incurred on the projects plus a percentage of fee over cost (as a profit). Always
beneficial for seller.
• Cost Plus Incentive Fee (CPIF) – A performance based extra amount will be paid to the seller
plus actual cost they have incurred on the projects.
• Cost Plus Award Fee (CPAF) – The seller will get a bonus amount plus the actual cost incurred
on the projects.
This graph shows the amount of risk that each of the seller and buyer has in different types of contracts
• The individual tasks that lead to the deliverable, and who these tasks are assigned to.
• The resources needed for the project including facilities, equipment, and QA procedures.
Audience
This tutorial has been designed keeping in mind the needs of beginner level MS Project
user. Project managers and Project planners from varied backgrounds who have not used
MS Project, especially the 2013 edition before can use this tutorial for scheduling, planning,
and reporting their projects of any size. This tutorial is designed with Project Standard
features, hence there is no need of Project Professional.
Prerequisites
A basic understanding of Computers and Windows Operating System is all it takes to get
started. Hardware: A reasonable home desktop configuration. Software: MS Project 2013
on Windows OS. (At the time of writing this tutorial, Project 2013 is not available for Mac)
All the content and graphics published in this e-book are the property of Tutorials Point (I)
Pvt. Ltd. The user of this e-book is prohibited to reuse, retain, copy, distribute or republish
any contents or a part of contents of this e-book in any manner without written consent
of the publisher.
We strive to update the contents of our website and tutorials as timely and as precisely as
possible, however, the contents may contain inaccuracies or errors. Tutorials Point (I) Pvt.
Ltd. provides no guarantee regarding the accuracy, timeliness or completeness of our
website or its contents including this tutorial. If you discover any errors on our website or
in this tutorial, please notify us at contact@tutorialspoint.com.
i
MS Project 2013
Table of Contents
About the Tutorial ..................................................................................................................................... i
Audience .................................................................................................................................................... i
Prerequisites .............................................................................................................................................. i
MS Project UI .......................................................................................................................................... 10
Project Information................................................................................................................................. 13
ii
MS Project 2013
iii
MS Project 2013
Project Report......................................................................................................................................... 78
iv
MS Project 2013
1. MS Project 2013 – Settings
Each one of you might be using a different setting for MS Project 2013. To ensure the
results are not different from what is shown in this tutorials, ensure the settings as follows.
Remember all these are the default settings you will have when you first install MS Project
2013 on your computer.
Step 1: File -> Options -> General tab -> Project view -> Default view.
1
MS Project 2013
Step 2: File -> Options -> Display tab -> Show Indicators and Options Buttons For.
2
MS Project 2013
Step 3: File -> Options -> Schedule tab -> Schedule -> Show Assignment Units.
Step 4: File -> Options -> Schedule tab -> Calculation -> Calculate Project after Each
Edit.
3
MS Project 2013
Step 5: File -> Options -> Save tab -> Save projects -> Save Files In this format.
4
MS Project 2013
Step 7: File -> Options -> Advanced tab -> Display -> Show Status Bar -> Show Scroll
Bar.
5
MS Project 2013
Step 8: Resources -> Level -> Leveling Options -> Leveling Calculations.
Set to manual.
6
MS Project 2013
Step 9: Resources -> Level -> Leveling Options -> Leveling calculations -> Look for
Overallocations.
7
MS Project 2013
2. MS Project 2013 – Introduction
Project creates budgets based on assignment work and resource rates. As resources are
assigned to tasks and assignment work estimated, the program calculates the cost, equal
to the work times the rate, which rolls up to the task level and then to any summary task,
and finally to the project level.
Each resource can have its own calendar, which defines what days and shifts a resource
is available. Microsoft Project is not suitable for solving problems of available materials
(resources) constrained production. Additional software is necessary to manage a complex
facility that produces physical goods.
Project Management
MS Project is feature rich, but project management techniques are required to drive a
project effectively. A lot of project managers get confused between a schedule and a plan.
MS Project can help you in creating a Schedule for the project even with the provided
constraints. It cannot Plan for you. As a project manager you should be able to answer
the following specific questions as part of the planning process to develop a schedule. MS
Project cannot answer these for you.
What tasks need to be performed to create the deliverables of the project and in
what order? This relates to the scope of the project.
What are the time constraints and deadlines if any, for different tasks and for the
project as a whole? This relates to the schedule of the project.
How much will each task cost to accomplish? This would relate to the cost of the
project.
What kind of risk do we have associated with a particular schedule for the project?
This might affect the scope, cost and time constraints of your project.
Strictly speaking, from the perspective of Project Management Methodology, a Plan and
Schedule are not the same. A plan is a detailed action-oriented, experience and
knowledge-based exercise which considers all elements of strategy, scope, cost, time,
resources, quality and risk for the project.
Scheduling is the science of using mathematical calculations and logic to generate time-
effective sequence of task considering any resource and cost constraints. Schedule is part
of the Plan. In Project Management Methodology, schedule would only mean listing of a
project's milestones, tasks/activities, and deliverables, with start and finish dates. Of
course the schedule is linked with resources, budgets and dependencies.
8
MS Project 2013
However, in this tutorial for MS Project (and in all available help for MS Project) the word
‘Plan’ is used as a ‘Schedule’ being created in MS Project. This is because of two reasons.
One, MS Project does more than just create a schedule it can establish dependencies
among tasks, it can create constraints, it can resolve resource conflicts, and it can also
help in reviewing cost and schedule performance over the duration of the project. So it
does help in more than just creating a Schedule. This it makes sense for Microsoft to
market MS Project as a Plan Creator rather than over-simplifying it as just a schedule
creator.
Of course, a project manager should also be able to answer other project-related questions
as well. For example:
Track information about the work, duration, and resource requirements for your
project.
9
MS Project 2013
3. MS Project 2013 – Getting Started
In this chapter, we will take a close look at the user interface of MS Project.
MS Project UI
Windows 7: Click on Start menu, point to All Programs, click Microsoft Office, and
then click Project 2013.
Windows 10: Click on Start menu -> All apps -> Microsoft Office -> Project 2013.
The following screen is the Project’s start screen. Here you have options to open a new
plan, some other plans, and even a new plan template.
Click the Blank Project Tab. The following screen pops up.
10
MS Project 2013
The screen should have the MS Project interface displayed. The major part of this interface
are:
Quick Access Toolbar: A customizable area where you can add the frequently
used commands.
Tabs on the Ribbon, Groups: With the release of Microsoft Office 2007 came the
"Fluent User Interface" or "Fluent UI", which replaced menus and customizable
toolbars with a single "Office menu", a miniature toolbar known as "quick-access
toolbar" and what came to be known as the ribbon having multiple tabs, each
holding a toolbar bearing buttons and occasionally other controls. Toolbar controls
have heterogeneous sizes and are classified in visually distinguishable Groups.
Groups are collections of related commands. Each tab is divided into multiple
groups.
Commands: The specific features you use to perform actions in Project. Each tab
contains several commands. If you point at a command you will see a description
in a tooltip.
View Label: This appears along the left edge of the active view. Active view is
the one you can see in the main window at a given point in time. Project includes
lots of views like Gantt Chart view, Network Diagram view, Task Usage view, etc.
The View label just tells you about the view you are using currently. Project can
display a single view or multiple views in separate panes.
View Shortcuts: This lets you switch between frequently used views in Project.
Status bar: Displays details like the scheduling mode of new tasks (manual or
automatic) and details of filter applied to the active view.
11
MS Project 2013
12
The NASA Program/Project Life Cycle Process Flow
Mission Feasibility Mission Definition System Definition Preliminary Design Final Design Preparation for Deployment and Mission Operations Disposal
• Establish complete, validated detailed design Fabrication & Integration
• Define mission objectives and top level functional and performance requirements • Establish validated (segment level) requirements which meet
• Establish validated requirements for End Items
(complete functional baseline)
• Establish a design solution that fully meets mission needs
• Complete test and verification plan • Complete all design specialty audits • Produce items that conform to specifications and acceptance criteria
Deployment Operational Verification • Perform Mission • Decommission/dispose of system items
• Ensure mission technical and programmatic feasibility mission objectives • Establish manufacturing processes and controls • Launch / deploy system • Sustain system
• Complete ™architecture∫ level of design. • Establish design dependent requirements and interfaces • Assemble and integrate the system • Configure system for launch / deploy
• Confirm customer©s mission need • Establish architectural and top level operations concept • Finalize & integrate system interfaces • Establish operational envelope of system • Improve/augment System
• Mitigate technical risk: critical technology, long lead items. • Complete "implementation" level of design • Validate and verify system • Establish readiness to launch / deploy
• Identify technology risks and mitigation plan • Establish firm estimates of programmatic and technical resources • Develop capability to use system to perform mission • Establish system logistics
Management • Refine programmatic resource need estimates • Mitigate programmatic risks • Prepare facilities for production, maintenance and operation
Decision • Demonstrate system can be built within cost, schedule, Management Management
Management Management Management Management Management
performance constraints Decision Decision
Decision Decision Decision Decision Decision Management
Mission Decision
Concept Iterate Requirements and Concepts to establish 3.8. Integrate 4.8. Integrate System / Segments / Elements/º 5.7. Integrate System / Segments / º
Mission 6.11. Integrate System, Control and Verify Interfaces System
Start Iterate Requirements and Concepts to establish feasibility Review optimal system requirements & top level architecture Preliminary Flight Operational
Definition Resource Balances System Resource Balances Resource Balances Critical Design Acceptance Decommisioning
Analytic Integration Design Analytic Integration Readiness Readiness
Review Definition Analytic Integration
Review(s) Review Review
Mission Needs Review(s) Review Review
Goals and Objectives Mission Segment C System
Review(s)
Programmatic Guidelines
Requirements Segment B Requirements
Understand Customer Identify Feasible Alternatives Analyze Mission Requirements Establish Optimum Architecture Segment A
1.10. Synthesize Review Review
Analyze System
Element C
1.3. Develop Top Science Rqts 1.6. Flowdown & Downselect 2.8. Synthesize Establish Optimum System Design Element B
1.1 Refine User Mission Rqts Mission Needs System Rqts Requirements
Level Mission Top Level System 2.1. Refine Top Goals and Objectives 2.4. Define & 3.3. Flowdown & Lower Level
Element A
Needs & Science Rqts
Science Rqts & Downselect Requirements
Requirements Requirements Level Mission Mission Rqts
Refine System Disposal Rqts
3.1. Mission & Refine Verification Rqts Matrix
Objectives Report / Proposal
Verification Rqts
Assumptions, Guidelines, Production
System Specification Requirements Assumptions, Requirements Requirements Requirements and Constraints
Guidelines, and System Specification Preliminary Design Readiness Test
Mission Needs System / Segment Rqts
Constraints Tech Dev Rqts
Analyses 4.2. Perform Final Design Operations
Goals and Objectives
5.1. Define & Review(s) Readiness 9.6.
1.5. Develop 3.6. Evaluate Design Deployment & 9.8. Update 9.10.
2.3. Develop & 3.5. Allocate Control Cost/Effectiveness Review(s) Prepare for Distribute
Evaluation
Refined Mission Rqts and Analyze Analyses 4.6. Evaluate, 7.2. Configure Operational 9.1. Configure Design & Sequential
1.8. Allocate Refine System Rqts Requirements to Detailed I/F
Environmental Verification & Deployment Mission
1.2. Refine Criteria 2.6. Allocate 2.7. Analyze & Verification Rqts System End Item Verify, &
Failure Modes & Effects
Manufacuture & Assembly Integration & Test H/W for Launch Verification for Operations Documentation Production
Requirements Evaluation Applicable Standards End Items Logistics Support Acceptance Products
Constraints & Requirements Evaluate Concepts Design Analysis Reports Validate Design
Nuclear
Criteria 4.1. Analyze Trade & Analysis Results
Interface Control Documentation Producibility 6.6. Assemble
Assumptions Evaluation Criteria to Segments / Architectures & 3.2. Develop System Specification Cost/Effectiveness P/L to Carrier Integration Plan Manufacturability 6.2. Fabricate / 6.5. Test / 6.9. Test / Sequential Production
Reference Missions
Evaluation Criteria Design-To Specification Logistics Support and Refine Reliability
6.1. Ready & Physically 8.1. Launch /
TPM Allocated Rqts
Reference Missions
Elements Concepts System Evaluation Verification Matrix Producibility/Manufacturability Safety / Hazard Assemble End Verify End Verify 9.2.
Assumptions, TPM Budgets & Margins
TPM Interface Rqt Reliability Requirements Cost/Effectiveness Specialty Engineering
Production Integrate Deploy 9.9. Improvement,
Guidelines, and Performance Rqts Cost/Effectiveness Analyses Criteria TPM Budgets Safety / Hazard Analysis Environmental Life Cycle Cost Item Item System Conduct
Constraints 1.9. Analyze & TPM Budgets & Margins Environmental Assessment 3.4. Develop & Specialty Engineering Failure Modes & Effects 5.2. Perform Facilities System 7.3.Configure Block Changes Product improvement Rqts
1.7. Develop Feasibility Assessment Life Cycle Cost 4.3. Perform Logistics Support 5.5. Evaluate, 7.1. Deliver / Mission Modifications
1.4. Develop Top Evaluate Specialty Engineering Studies Refine Prime/ Trade & Analysis Specification Updates 4.5. Perform Nuclear Detailed Design End Item Integrated System S/W for Launch System Disposal
Feasible System 2.2. Refine Life Cycle Cost Estimates Evaluation Criteria Design Disclosure
Flowdown Rqts Engineering Producibility Verify, & Support Items Verified H/W Support Equipment
Verification Rqts Compliance Install System Disposal
Level Functional 2.5. Develop Trade & Analysis Results Reference Missions Critical Item Interface Control Documentation
Disposal Requirements Preliminary Manufacturability Spares V & V S/W &V Evaluation Results
7.7. Complete Mission Productsl
Concept(s) Mission TPM
Integration and Assembly
Interface Requirements Development Reliability Validate Design Quality Assurance Results Verification Rqts Compliance Tested System
Mission Concept Cost/Effectiveness Analyses Alternative System Acceptance Criteria Concepts Manufacturing
Design Safety / Hazard Integrated
Concept(s) and Launch Operations Tests Specialty Engineering 6.3. Complete 8.2 Configure 10.1.
Environmental Assessment
Architectures & System Concept & Architecture Operations Design Disclosure 6.7. Complete
System Concept & Architecture Feasibility Assessment Operations Design Disclosures Integrated Logistics Support Development Test Results
Life Cycle Cost
Material and Processes Data End Item Prelauch for checkout and 9.3. Train Decommission /
Functional Mission Concept Design Disclosures Specialty Engineering Studies
Concepts Product Breakdown Structure 3.7. Synthesize / Engineering Items Integration and Assembly Test Plans & Delivered / Installed System 7.4.Configure
Product Breakdown Structure Life Cycle Cost Estimates Mission Concept(s) Operations Concept
Design Disclosure
Verification Test 6.10. Perform Final System Documentation Checkout operations Personnel Dispose
Operations Concept Trade & Analysis Results Operations Concept(s)
Select Optimal
Electronics Parts List
Hardware/Software List
Documentation Support System
Preparations for System Acceptance for Launch Readiness Reports
Option
Instr Pgm & Command List
5.3. Perform 5.6. Complete Incidents Reports 9.7. Disposed Items
4.4. Define Verification Procedures & Data Testing Problem / Failure Reports Assess Decommisioned Items
1.12. DevelopTools & Iterate requirements and concepts to establish optimal design-to baseline 4.7. Complete Engineering Detail Design & Test Facilities & Equipment Verification Procedures & Data Trained Personnel
Recycled Items
In-flight Checkout Plans
2.10. DevelopTools & Interfaces Plans & Tests Production Plans Trends Waste
Methods Deliverable System
Acceptance Data 8.3. Demonstrate
Analysis Models Methods Documentation 6.4. Complete 6.8. Complete 7.5.Prepare
Systems Engineering Tools Development Test Results Operational 9.4. Problem / Failure Reports
Analysis Models Engineering Items Integrated Schematics for Qual Items Development Test Results Plans / Plans & Personnel Maintain Readiness Reports
Systems Engineering Tools Interface Control Documentation Engineering Items Build-To Specification Trained Personnel Capability Lessons Learned 10.2. Store /
Test Facilities & Equipment Qualification Item Plans Verification Requirements Documentation Documentation System
3.9. Develop Technology and Specifications "As Built" Documentation Monitor
1.11. Technical Planning & Management 5.4. Fabricate / for End Item Technical Manuals and Data for System Operational Evaluations Results
User©s Manuals In-flight Checkout Results
2.9. Technical Planning & Management 7.6. Update
Lessons Learned Test Final "As-Built" Documentation
Operations Procedures
Program/Project Management Plans Lessons Learned
Engineering Master Plan / Master Schedule Qualification Qualification Items Mission Ops
Program/Project Management Plans Technology Development Plan Lessons Learned 3.11. Develop & Refine Tools Qualification Results
Plans & 9.5.
System Engineering Management Plan Integrated Logistics Support Program Plan 4.9. Technical Management & Planning Items
Engineering Master Plan / Master Schedule Risk Management & Methods Analysis Models Trained Personnel Procedures
Operations Data Support
Configuration Management Go/No Go Criteria
Training Facilities, Equipment, & Materials
Information Management System Engineering Tools
Test Facilities & Equipment
Program/Project Management Plans Verification Plans Reliability Program Plan Operational Readiness Criteria System
System Engineering Management Plan Logistics Plan Configuration Management Plan
Engineering Master Plan / Master Schedule Integration & Assembly Plan Documentation Tree 6.12. Train Spares
Mtrls & Process Control Plan Drawing Tree/List 5.8. Technical Management & Planning
3.10. Technical Management & Planning Manufacturing Plan
Quality Assurance Plan
Information Management Plan
Specification Tree
EMI/EMC Control Plan Risk Management Plan Program/Project Management Plans
P/L to Carrier Integration Plan Statement of Work Revised /Updated Plans
Program/Project Management Plans Verification Plans Integrated Logistics Support Program Plan Lessons Learned Engineering Master Plan / Master Schedule Lessons Learned
System Engineering Management Plan Logistics Plan Reliability Program Plan System Safety Plan 6.13. Technical Management & Planning
Engineering Master Plan / Master Schedule Integration and Assembly Plan Configuration Management Plan
Manufacturing Plan Documentation Tree
Quality Assurance Plan Drawing Tree/ Engineering Drawing List Program/Project Management Plans Problem / Failure Reports Revised /Updated Plans
Engineering Master Plan / Master Schedule Waivers Lessons Learned
EMI/EMC Control Plan Information Management Plan
Payload to Carrier Integration Plan Specification Tree
System Safety Plan Risk Management Plan
Technology Development Plan Statement of Work
System Maturity Feasible Concept Alternative Architectures Top Level Architecture Functional Baseline Design-To Baseline Build-To Baseline As-Built Baseline
As-Deployed Baseline
- Functionally Complete Design
Legend - Focus on Feasibility The System
- Focus on Optimality
The System - Optimized Top Level The System -Allocations to Element Level System - Architecture & Implementation of Components - Complete Design Realization - Assembled & Tested Flight Units - System Deployed & Integrated
- Limited Range of Concepts - Broad Range of Concepts Architecture The System The System
- Technology & Risk Mitigation - Engineering Demonstrations & Tests - Qualification Items - Systems and Segment Tests - Operationaly Certified
Requirements - Multiple Options Considered Segment The System The System
H/W & S/W - Restricted Number of Options Segment Segment - Critical Technology - Demonstrations Segment - Mock ups & Models
Design - Increased Depth Segment Segment
- Limited Depth Options & Risks - Proofs of Concept - S/W Prototypes Segment
- Subsystem Concepts Element Segment
- Major Subsystems Element Element - S/W Prototypes Element
Rqt/Design H/W or S/W - Critical Technology Element Element
- Technical Feasibility Element Element
Conceptual Engineering Item Subsystem Subsystem Subsystem
Subsystem Subsystem Subsystem
Preliminary Qualification Item Subsystem Subsystem
Assembly Assembly Assembly Component Assembly
Final/Approved End Item
Assembly
Assembly Assembly Evolution
Representative
Staffing &
Rqts PDR CDR PRR TRR SAR
MCR MRR Peer Mid-Term MDR Peer SRR SDR
Peer Review ∑Larger Size Team
Validate/Refine
Validate/Refine ÈA
Management Mission Analysis ∑Small Team Mission Analysis ∑Moderate Size Team ∑Formal Studies Fabricate Items FRR ORR
∑Moderate Size Team Requirements/ Requirements/
∑∑Full-Time Lead ∑∑Full-Time Lead ∑Keys skills: System Build-To ∑Large Team ∑Large Team Operate
Concept Options ∑∑Full-Time Lead Requirements Specification Update/Derive Subsystem/Component Specification Item Test Plans Deliver/Install
Requirements ∑∑Part Time Members Update/Derive Update ∑∑Full Time Members Architect, Top-level ∑Formal Studies ∑Formal Configuration
∑∑Full/Part Time Members ∑∑Part Time Experts ∑Keys skills: Detail
Definition Flowdown
∑Special Studies Requirements Designer Eng Development Tests Test/Verify Item ∑Keys skills: Builder, Train
Derived ∑∑Part Time Experts ∑Formal Studies Eng Development Tests Designer, Integrator Train
∑Keys skills: Analyst, Tester Definition Flowdown
Criteria & Priorities ∑Formal Studies Trades & Analyses Item Documentation
Conceptual Designer Criteria & Priorities ∑Keys skills: System Trades & Analyses Trades & Analyses ∑Large Team ∑Dedicated Operation Team
∑Keys skills: Analyst Architect Maintain/Support ∑Formal Configuration
Assemble/Physicallly Complete Documentation ∑Formal Configuration
Concept Definition Mission & Ops Concepts Designs & Margins Interface Definition & Control Interface Definition & Control ∑Keys skills: Operator
Integrate Sytem ∑Keys skills: Launch
Launch Preparation Integrator, Check out Changes
Trades & Analyses Design System Test Plans
Evaluations Design Operator
Analysis & Evaluation Designs Risk, Cost, Safety, FMEA, etc Preliminary
Production
Risk, Cost, etc Integration Integration Test/Verify System
Engineering Plans On-Orbit Checkout
Evaluations Complete Documentation
Risk, Cost, Safety, etc Parametric Grassroot Evaluations Evaluations Lessons Learned
Tools & Methods Technology & Acceptance Testing
Plans Plans
Tools & Methods Risk Mitigation
Integration Disposal
Months Tools & Methods Qualification Items Qualification Items Build/Test
Months for subsequent phases Plans
Near term use Training Months to Years
Tools & Methods Tools & Methods
Months Months to Years
Months to Years Months to Years
DoD Pre-Milestone 0 Concept Exploration & Definition Demonstration & Validation Engineering & Manufacturing Development Production & Deployment Operations & Support By L. Pieniazek
Project Management
6th July
RACI Matrix
Request For Quotation: already know who are trustworthy and directly contact the bigger players in the
market.
Request for Information: same companies only collect information which may or may not have actual business
plan
12th July
Mediocre
(main bulk, representing the hump of the
normal curve)
→ Collection of frequency histograms, arranged in numbers from the data sets: normal curve
→ Tallest histogram in the hump
→ A-O-N: activity on the node
A-O-A: activity on the arrow
→ Single time estimate from all the values in the distribution: expected value
→ Slack or Buffer: even if a task is postponed to this time, project completion time is not affected.
→ After effective time, entire method is same as CPM
→ If slack is 0, you may or may not be on the Critical Path. If you are on the critical path, slack will always
be 0.
Slack = 0, necessary but not sufficient for CP
Some Terminologies
𝐶𝐶 − 𝑁𝐶
𝑐𝑜𝑠𝑡 𝑝𝑒𝑟 𝑑𝑎𝑦 𝑟𝑒𝑞𝑢𝑖𝑟𝑒𝑑, 𝑐𝑟𝑎𝑠ℎ 𝑠𝑙𝑜𝑝𝑒 =
𝑁𝑇 − 𝐶𝑇
For one day reduction, “crashed slope” amount of money has to be spent
Normal cost exists even after crashing. Crash cost is just an addition
REQUEST FOR PROPOSAL [RFP] FOR PROCUREMENT OF NEW AIRCRAFT FOR
AERIAL REMOTE SENSING
[TENDER DOCUMENT]
2
nrsc
1.INTRODUCTION
1.1 Indian Space Research Organization (ISRO), Department of Space (DOS), Government
of India (GoI) is the premier organisation in the country responsible for developing
space based systems comprising launch vehicles, satellites and ground segment facilities
to meet the country’s applications requirements in communication, broadcasting,
meteorology and remote sensing.
1.2 National Remote Sensing Centre (NRSC) is one of the centers under the Indian Space
Research Organisation (ISRO), Department of Space (DOS), Government of India, with
the mandate of providing Earth observation data from space and aerial platforms to
users, develop technologies for the management of natural resources, support disaster
monitoring and management and capacity building for utilization of Earth Observation
data. Aerial Services & Digital Mapping Area (AS&DMA) of NRSC is the only civilian
Government entity in the country with end-to-end state-of-the-art infrastructure and
capability in the domain of aerial photography, Laser Scanner and Synthetic Aperture
Radar surveys. It is a premier national facility for airborne data acquisition and large
geospatial database generation in India.
1.3 NRSC owns & operates two SKA B200 aircraft for aerial data acquisition. These aircraft
have modifications suitable for installation of airborne sensors which are being used for
Aerial Surveys for Remote Sensing applications.
1.4 Currently, the following activities are carried out with sensors like Aerial Cameras, Laser
Scanners and Synthetic Aperture Radar. The different types of aerial remote sensing
services offered are:
a. Aerial photographic surveys using Large Format Digital Camera System.
b. Airborne LiDAR and digital camera surveys for close contouring /DEM generation.
c. Airborne Synthetic Aperture Radar (ASAR) surveys.
d. Aerial Services for range calibration and instrument validation.
e. Airborne data acquisition services for atmospheric research.
1.5 NRSC invites proposals from Vendors for supplying of two new aircraft of same model
customized and certified for aerial remote sensing operations.
1.6 The objective of this RFP is to facilitate the vendors to participate in the bidding process.
3
nrsc
2. GENERAL INSTRUCTION FOR SUBMISSION OF PROPOSALS
2.1.1 The Vendors submitting their proposals should be either the manufacturer or an
authorised dealer of the aircraft. In case of authorised dealers, documentary proof of
authorisation valid as on date to be submitted in the technical proposal. Since the
aircraft procurement involves manufacturing, modifications and certification of the
new aircraft, NRSC has no objection for bidding with one company as a sole
representative of all parties involved, substantiated with appropriate authorization by
all the parties involved.
2.1.2 The vendor must have an authorised Maintenance Repair Overhaul Organisation
(MRO) in India or must have an agreement with an Indian MRO for carrying out
scheduled and unscheduled maintenance, warranty support, etc, preferably in NRSC
hangar in Hyderabad
2.1.3 The Bidder should have at least 5 years experience in supplying aircraft and providing
maintenance.
2.2 The technical bid should also contain
2.2.1 Filled in Technical compliance statement as given in Annexure-I.
2.2.2 Authorisation certificates from the OEMs for Engine, Propeller, Avionics and all major
sub-systems indicating the willingness to provide technical & maintenance support
during warranty and extended warranty period.
2.2.3 Detailed data sheets giving all the specifications and performance parameters/type
Certificate and Type certificate data sheet of the aircraft.
2.2.4 List of deliverables (including the list of continued airworthiness support
documents/aircraft post delivery documents like Airplane Flight Manual(AFM),
Structural Inspection and Repair Manual(SRM), Illustrated Parts Catalogue (IPC),
Maintenance Manual (MM)) etc
2.2.5 Contain the following undertaking by the vendor.
QUOTE
I / we have gone through all the terms and conditions indicated in RFP TENDER No: NRSC
___________________ and accept all of them. The information contained in this submitted proposal
is true to the best of my / our knowledge.
4
nrsc
Signature of authorised representative
With Office Seal
Date :_______________
Place :_______________
UNQUOTE
2.3 The commercial bid must contain all the pricing details in the format provided in Annexure-
II. Don’t indicate actual commercial details anywhere in the technical bid. The pricing
details should be entered only in the entries provided against each item in the enclosed
format. No attachment submitted in the technical or the commercial bid shall have the
pricing details except in the entries in the price bid. If the commercial details are mentioned
either in part or full in the technical bid, NRSC reserves the right to reject the bid. The empty
commercial bid format should be enclosed in the technical bid. The empty commercial bid format
should indicate the complete details of all the items whose price is given in the commercial bid.
2.4 Offers must be valid for 18 months from the last date for submission of the bids.
2.5 Prebid Meeting: Pre Bid Meeting between NRSC and the vendors interested in submitting
proposals will be held at NRSC Hyderabad on ……………………. from ………..hrs. It is strongly
recommended that all the vendors attend the pre-bid meeting to avoid further queries and
clarifications later. It also is advisable that the OEM representatives of the aircraft attend the
pre-bid meeting along with their Indian partners (if any). Those who wish to participate
should send their willingness regarding their participation with name, designation, address
and contact details before …………………... Foreign nationals must indicate their nationality,
passport details. The Visa must be a Business Visa. Tourist Visa is not acceptable. A copy of
the passport must be sent to Head, Purchase and Stores, National Remote Sensing Centre,
ISRO, Balanagar, Hyderabad-500037, AP, India. email: purchase@nrsc.gov.in
2.6 Interested vendors can be present at NRSC during opening of Technical bids. Technical bids
will be opened in the presence of the attending vendors or their authorised representatives.
Authorised representatives must carry a proper identification proof and an authorisation
letter. The commercial bids will be opened in the presence of the attending vendors or their
authorised representatives on a date that will be notified individually to the vendors whose
technical bids are found to be suitable.
5
nrsc
2.7 PROPOSAL FOR EACH MODEL SHOULD BE SUBMITTED IN TWO SEPARATE (TECHNOCOMMERCIAL
AND PRICE) SEALED COVERS. Each cover should be suitably superscribed as `TECHNO‐COMMERCIAL
BID’ or `PRICE BID’ along with `TENDER NUMBER’ and `MODEL NAME’. All the sealed covers
can be sent as a single package by post (or delivered by hand at NRSC). However, the package must
be superscribed with `TENDER NUMBER’. DO NOT SEND PROPOSALS BY e‐mail. DO NOT
INCLUDE ANY PRICING DETAILS IN THE TECHNICAL BID.
6
nrsc
3.1 The aircraft should be currently in series production with assured maintenance and spares
support in India over the expected life of 25 years. Pre owned aircraft will not be considered.
3.2 The aircraft is intended for remote sensing applications and hence vendor has to supply
aircraft with modifications as described in the subsequent chapters.
3.3 The vendor should get the aircraft certified to operate under rules and regulations of the
Indian aviation regulatory authority, currently, Directorate General of Civil Aviation (DGCA),
India. NRSC will support for providing the necessary documentation as an Operator.
3.4 Cabin area of Aircraft should be adequate to accommodate six persons (excluding pilots),
sensor equipments and the modifications as described in Chapter-4(Aircraft Modifications).
3.5 The aircraft should be supplied with six operator chairs to conveniently monitor the airborne
sensor equipments.
3.6 Aircraft Type : Pressurized Twin turbo prop
3.7 Engines : Twin turbo prop
3.8 Service ceiling : 31000 ft MSL or higher
3.9 Maximum Cruise Speed : 290 knots or higher
3.10 Stall Speed : 95 knots or lower
3.11 Maximum Payload Weight(MPW) : 1200 Kg or higher
(Sensor + 2Pilots + Pax + Luggage)
3.12 Endurance with Maximum Payload : 6 hours or higher
Configuration(MPC)--MPW+Empty
Aircraft Weight+ Maximum fuel with
MPW
3.13 Seating Configuration ( Pilot + Pax) : 2+6
3.14 Avionics : Collins Proline / Honeywell / Garmin
Integrated Avionics Suite including auto-pilot
coupled Flight Management System, Moving
Map LCD Display
7
nrsc
8
nrsc
combination set with solid state Memory supporting a minimum of 2 hours
recording. FDR should be of Category IA with Minimum of 32 parameters
monitored.
3.18.2 Traffic Collision Avoidance System (TCAS II) with Traffic Advisory (TA) and
Resolution Advisory (RA).
3.18.3 Water Activated and Impact Activated Emergency Locator Transmitter (ELT) with
operating frequency of 406 MHz
3.18.4 Reduced Vertical Separation Minima (RVSM) compliance systems
3.18.5 Enhanced Ground Proximity Warning System (EGPWS) including wind shear
warning.
3.18.6 Automatic Dependent Surveillance System ( ADS)
3.19 Instrument data Outputs(Optional): The following parameters along with Digital/ Analog
outputs from aircraft instruments or as additional installation should be made available in
the cabin for logging and Analysis purpose. Provision for onboard storage of data with GPS
time stamping and download after aircraft landing is also acceptable.
3.19.1 RADAR Altimeter
3.19.2 Radio Altimeter supporting upto 35000ft.
3.19.3 Barometric Altitude
3.19.4 Inertial Navigation system (lNS)
3.19.5 Global Navigation Satellite System (GNSS) position
3.19.6 Cabin Temperature and Humidity
3.19.7 Outside Pressure, temperature and Humidity
3.20 Voice and data communication system (optional) from aircraft, while in flight, to ground with
reasonable bandwidth for transmitting few images to ground in case of disaster scenario.
3.21 The vendor shall supply the complete set (both softcopy and three sets of hardcopy) of flight
manuals, maintenance manuals, pilots check lists, etc.. that are mandatory along with each
aircraft.
3.22 The vendor shall provide the complete drawings and documentation of the modifications
carried out in softcopy and one set of hardcopy, at the time of delivery of the aircraft, to
facilitate installation of equipment, and to carry out any repair in the event of failure of the
parts used in modification.
3.23 The vendor shall also provide copies of all the approvals (FAA/EASA/DGCA), STCs
9
nrsc
implemented for carrying out the modifications in both the aircraft.
3.26 TRAINING: The vendor should provide training to four pilots identified by NRSC at vendor’s
facility. The price of training per pilot shall be given in the commercial bid. The payment for the
pilot training shall be made depending on the actual number of pilots identified by NRSC for
training. Training to DGCA officials if required shall also be the responsibility of vendor. All the
expenses for the travel and accommodation of the DGCA officials during the training shall be
borne by the vendor
10
nrsc
4. AIRCRAFT MODIFICATIONS
4.1 Modifications to the aircraft for installation of payloads such as airborne sensors,
atmospheric probes and Airborne Synthetic Aperture Radar(ASAR) antenna has to be
carried out by the aircraft supplier. The modifications include cutouts suitable for scientific
payloads, optical wells, radome, pressure box, GPS antennas etc. Suitable EMI/EMC shielding
to be made to aircraft wiring such that the airborne remote sensing equipment and aircraft
avionics does not interfere with each other.
4.2 Antenna, Radome and Racks will be permanently fitted in the aircraft. Required modification
to be done duly certified by FAA/EASA and approved by DGCA. The modifications required
aircraft wise is given in the table below.
Sl. Provision/ Modification Aircraft1 Aircraft2
No
1 First Camera well with Optical flat with
electrically operated door
2 Second Camera well with Optical flat with X
electrically operated door
3 Cutout for Waveguide for ASAR Sensor X
4 Cutout for Atmospheric sensor probes
5 Radome at the belly for ASAR Sensor X
6 Pressure box X
7 Two Additional GPS Antenna for interfacing to
airborne sensors
4.3 The approximate dimensions & Location for Aircraft modifications are described in the table
below. Cabin height, length and width should be capable of accommodating these airborne
sensor equipment racks.
11
nrsc
4.4
12
nrsc
4.5.1.12 Dimensions : About 55cm X 60cm
4.5.1.13 Should have thermal and structural Stability to withstand differential
temperatures and pressures at all altitudes up to the ceiling of the aircraft
4.5.3 Specifications of the Optical flat for TIR region(to be supplied in Aircraft-2)
4.5.3.1 Material : Suitable for Thermal region
4.5.3.2 Wavelength : 8μm to 14μm
4.5.3.3 Internal Transmittance : Greater than 95%
4.5.3.4 Surface Quality(Scratch/Dig) : 80/50
4.5.3.5 Durability : MIL-C-675A
4.5.3.6 Wedge : better than 1 arc min
4.5.3.7 Parallelism : Less than 2 arc seconds
4.5.3.8 Dimensions : Circular port of 25cm diameter
4.5.3.9 Should have thermal and structural Stability to withstand differential
temperatures and pressures at all altitudes up to the ceiling of the aircraft
13
nrsc
70cm 48cm
2cm
FLIGHT DIRECTION
56cm
6cm
70cm
6cm
OPTICAL FLAT
Fig 1: The well and optical flat arrangement for optical sensors
14
nrsc
4.6 Specifications for Cutout for Waveguide and Radome for ASAR Sensor
4.6.1 The ASAR antenna will be mounted as and when required below the waveguide well
at the belly of the aircraft as shown in Fig.2 below.
4.6.2 The well will be of the dimension 390mm (L) X 470mm (w) X 220mm (D).
4.6.3 This will be a part of the cabin and will contain wave guides coming from C band
antenna along with subsystems like IMU, polarization switch etc. The material used
for the radome should be transparent to C and X band frequencies and should
withstand the differential temperatures and pressures upto to the ceiling height of
aircraft. The ASAR antenna radome should not block the view through optical flat
meant for optical sensors.
4.6.4 The bottom plate of well will have a cutout of 240 mm X 240 mm that will be
accessible from the outside.
4.6.5 The C-band antenna will be of the size 1.5 m X 0.32 m (under the belly of the
aircraft).
4.6.6 ASAR antenna will be covered by Radome. The Radome should be symmetric about
the bottom cut-out and should have usable flat of dimensions of about 2500 mm (L) X
750mm (W) X 650mm (D).
4.6.7 In mounted condition, gap between bottom of the Radome and ground should be
sufficient to protect the radome in the event of tyre burst condition.
4.6.8 Cutouts and well along with associated structural reinforcement to aircraft and
radome should be provided by the vendor with FAA/EASA/DGCA approval.
15
nrsc
4.7 Specifications for Atmospheric sensor probes:
4.7.1 The aircraft should have suitable cutout for mounting atmospheric sensor inlets on the
fuselage or window with STC from FAA/EASA and approval from DGCA. The required
arrangement is shown in Fig.3 below
4.8 Specification for pressure box: Pressure Box with approx dimensions 45 cm X 45 cm X 50 cm,
to accommodate airborne multispectral/thermal sensors, and having cutout looking
downward with electrically operated door (without optical flat). This is required for sensors
which require access to the outside environment directly and at the same time providing
isolation between the outside environment and the pressurized aircraft cabin.
16
nrsc
17
nrsc
4.10 Details of the Sensor racks placed in the Aircraft Cabin( Racks shall be provided by NRSC)
Sl Dimensions in
Rack Aircraft I Aircraft 2 Payload
No: mm(HxDxW)
1 Rack I 1240 X 800 X 600 X ASAR
2 Rack II 900 X 650 X 550 X ASAR
3 Sensor Rack 860 X450 X 540 Camera
4 Sensor Rack 860 X450 X 540 X Camera
5 Sensor Rack 860 X450 X 540 Atmospheric suit
6 GSM3000 183(H)X614(L)X617(W) Camera
18
nrsc
5.TERMS & CONDITIONS
5.1 The terms & conditions defined in this RFP shall be considered for this procurement and
supersede the general terms & conditions enclosed if any.
5.2 DELIVERY: The vendor shall deliver( including supply, permissions from the regulatory
authorities (like DGCA and WPC and final acceptance) the aircraft with all the modifications,
certified by FAA/EASA & approved by DGCA at NRSC Hangar, Begumpet Airport, Hyderabad
within 12 months from the date of release of Purchase Order.
5.3 REGULATORY AUTHORITIES PERMISSIONS: All the permissions from the regulatory
authorities for importing, registration, airworthiness and flying of the aircraft in India has to
be obtained by the vendor. Any expenses incurred for the above has to be borne by the
vendor. NRSC shall provide documentary support wherever required and feasible. In case
vendor fails to obtain permission, NRSC reserves the right to cancel the order and reject the
aircraft.
5.4 INSURANCE: Any expenses for the insurance from the OEM factory to NRSC shall not be
borne by NRSC.
5.5 INSTALLATION: The vendor shall prepare an Acceptance Test Procedure (ATP) document
which shall be sent to NRSC after the PO is placed. The ATP document shall be finalised on
mutual agreeable basis and will be used for acceptance of the aircraft at NRSC Hyderabad.
5.5.1 In case of foreigners visiting NRSC, Hyderabad for installation and acceptance, the
passport and VISA details of the personnel have to be sent to NRSC well in advance to
get necessary approvals from Dept. of Space and Bureau of Civil Aviation Security
(BCAS) clearances.
5.5.2 The vendor is responsible for problem free demonstration of aircraft in NRSC & any
onsite issues should be appropriately resolved by the vendor.
5.6 Factory Acceptance Test: The expenses for the test flights during factory acceptance test of
the aircraft by NRSC engineers shall be borne by the vendor. The travel & accommodation
expenses will be borne by NRSC.
19
nrsc
5.7 Site Acceptance Test: The Site acceptance test at NRSC shall be carried out with the Pilots
from the vendor and all the expenses for these test flights shall be borne by the vendor.
5.9 CUSTOMS DUTY EXCEMPTION: NRSC is entitled for concessional Customs Duty payment
(currently@5.15%) and shall provide Customs Duty Exemption Certificate for availing the
same upon submission of necessary documentation by the vendor.
5.10 PAYMENT TERMS: NRSC normal payment terms are 90% payment after receipt, installation
and acceptance of the aircraft and balance 10% after submission of performance bank
guarantee. However, If any advance payment is required by the vendor, a maximum of 30%
of base price (aircraft cost + cost of modifications) excluding warranty and training cost can
be paid against bank guarantee from a nationalized bank as per the format provided by
NRSC. This bank guarantee shall be valid till the completion of supply and acceptance of the
aircraft. NRSC decision in this aspect shall be final.
5.11 PERFORMANCE BANK GUARANTEE: The supplier has to provide a performance bank
guarantee for 10% of base price (aircraft cost + cost of modifications), valid till the
completion of warranty period plus three months as claim period as per the Proforma which
shall be sent along with the PO.
5.12 ACCEPTANCE: The aircraft will be accepted only after successful test flights at NRSC
Hyderabad, meeting all the requirements including modifications and obtaining approvals
from regulatory authorities. A mutually agreeable acceptance document shall be prepared
21
nrsc
and used for acceptance.
5.13 During acceptance testing with sensors installed, the vendor should carryout field
modification on the aircraft (if required) and obtain DGCA approvals for resolving the
EMI/EMC/other compatibility issues if any.
5.14 LIQUIDADTED DAMAGES: For delays attributable to vendor in completion of entire supply
beyond 12 months (including supply, permissions from the regulatory authorities like DGCA
and WPC and final acceptance), Liquidated Damages (LD) shall be applicable at 0.5% per
week or part there of subject to a maximum of 10% of the order value.
5.15 FORCE MAJEURE: Neither NRSC nor the supplier shall be liable to the other for any delay in
or failure of their respective obligations under this procurement caused by occurrences
beyond the control of NRSC or the supplier because of fire, floods, power, acts of God, acts
of public enemy, wars, insurrection, sabotage, any law, statute or ordinance Agreement,
action or regulations of the Governments or any compliance therewith similar to the above.
Either party shall promptly. but not later than thirty(30) days thereafter notify the other of
the commencement and cessation of such contingency and prove that such is beyond the
control and affects the implementation of this procurement adversely and if such
contingency continues beyond six(6) months, both parties may mutually agree to discuss and
agree upon an equitable solution for cancellation of this purchase order or otherwise decide
the course of action to be adopted.
22
nrsc
6. DETAILS OF TECHNICAL INFORMATION
6.2 The scheme for meeting the other requirements including power supply, air conditioning,
installation of GPS antenna, recording parameters etc .
6.3 A list of aircraft instruments that are required to be supplied as part of this RFP and their
performance specifications and model numbers
6.4 Vendors should provide Lead time for delivery of aircraft and modifications.
6.5 Vendors should provide a detailed plan for aircraft maintenance during the warranty period
and also thereafter in the post warranty period.
6.6 Proposal should mention the aircraft model suggested by the vendor and provide detailed
specifications and drawing of the aircraft.
23
nrsc
Sl.No Parameter Details
16. Engines Model
17. Engine TBO
18. Propellers
Manufacturer
19. Propellers Model
20. Propellers Type
21. Thrust Reverser mechanism if applicable
22. Take-off Distance
23. Landing Distance
24. Rate of Climb
25. Service Ceiling
26. Maximum Speed
27. Stall Speed
28. Differential Pressure
29. Time to Cruise Altitude
30. Cabin Noise Levels
31. Cabin altitude @ certified ceiling
32. List of standard avionics items
40. Name and Address of the Vendor along with contact numbers.
24
nrsc
RFP Reference
Sl.
Clause Item Compliance Page No of Remarks
No.
bid
1. 2.1.1 Manufacturer or Dealer? YES/NO
Submitted proof of authorised dealership
2. 2.1.2 Has an MRO or has an agreement with an Indian YES/NO
MRO? Details provided?
3. 2.1.3 5 years experience in supplying aircraft and YES/NO
providing maintenance and proof
4. 2.2.2 Authorisation from subsystem OEMs as per 2.2.2 YES/NO
attached?
5. 2.2.3 All details & datasheets as per 2.2.3 attached? YES/NO
25
nrsc
RFP Reference
Sl.
Clause Item Compliance Page No of Remarks
No.
bid
25. 3.18.2 TCAS-II with Traffic Advisory and Resolution YES/NO
Advisory provided?
26. 3.18.3 Water Activated and Impact Activated Emergency YES/NO
Locator Transmitter (ELT) with operating
frequency of 406 MHz provided?
27. 3.18.4 RVSM compliant? YES/NO
26
nrsc
RFP Reference
Sl.
Clause Item Compliance Page No of Remarks
No.
bid
50. 4.6.8 Acceptance of clause 4.6.8 YES/NO
51. 4.7 Acceptance of clause 4.7 YES/NO
27
nrsc
RFP Reference
Sl.
Clause Item Compliance Page No of Remarks
No.
bid
77. 5.16 Acceptance to Arbitration Clause 5.16 YES/NO
28
nrsc
ANNEXURE-II: COMMERCIAL BID FORMAT
Sl. Price
No.
Item Remarks
1 Price of Aircraft-1
st
3 Price for maintenance for 1 year of
Aircraft-1
nd
4 Price for maintenance for 2 year of
Aircraft-1
rd
5 Price for maintenance for 3 year of
Aircraft-1
6 Price of Aircraft-2
st
8 Price for maintenance for 1 year of
Aircraft-2
nd
9 Price for maintenance for 2 year of
Aircraft-2
rd
10 Price for maintenance for 3 year of
Aircraft-2
11 TA/DA for the engineers on outstation
during the 3yrs maintenance period. Will be
multiplied by 300 for a total period of 3ys.
12 TA/DA for the technicians on outstation
during the 3yrs maintenance period. Will be
multiplied by 300 for a total period of 3ys.
13 Training cost per Pilot
29
The Systems Approach nutshell
The systems approach to project management has several aspects that would require to be
taken into consideration.
All elements within a project are dependent on each other and each one of them would have
their own special needs or characteristics. Every element would have its own complete
properties that are unique and would need to be properly understood.
There have to be goals or end results even for intermediate stages of a project, and the project
manager would always have to be working towards these and fully understand the importance
of these results.
All inputs into a project would have to be determined and kept constant or added to whenever
necessary. Some inputs may be external to the project and would have to be kept in mind as
they could have an impact on the end result in terms of quality, money and time. Inputs get
transformed into outputs and result in progress of a project towards the end result.
Every project would have some sort of disorder or a state of randomness in certain elements
which a project manager would have to be aware of. A project also requires that there is some
sort of ordered feedback which allows the monitoring of project as it proceeds to its predictable
end.
A project would have a number of specialized units performing specific functions, and could also
be composed of a number of smaller projects or subsystems which would add up to a whole for
the project. Different approaches may be needed for such specialized functions or subsystems.
A project manager would always keep in mind a number of alternative methods to complete and
achieve each objective.
It may also be possible for a project manager to visualize different objective using common
inputs in order to achieve some economy of effort.
Using a systems approach to project management enables a project manager to keep the
objectives and end results constantly in mind so that the end results are as desired by the client.
Microsoft Project 2010 - Module 1
WPL_J400
Tasks
This table is comprised of over 240 columns (or fields) which contain all sorts of information about the
tasks such as scheduled start, scheduled finish, name, duration, cost, and the like. Some of these
fields require you to enter data, while others are calculated and filled by Microsoft Project for you.
ID Name Duration Start Finish Fixed Cost etc...
8 Erect fencing 2 days 1/2/2013 3/2/2013 No $500
Resources
This table contains over 200 fields (or columns).
ID Name Initials Group Max Standard Overtime Rate etc...
Units Rate
3 Builder FG Contractor 4 $55.00/h $75.00/h
Views
To help you see, or view, your data, Microsoft Project adopts techniques used in spreadsheets,
databases, and graphics packages.
For example you can see your task or resource table in sheets on the screen. Sheets are similar to
spreadsheet programs where data is presented in rows and columns. In fact, many of the operations
used in spreadsheets, such as widening columns, deleting data, selecting cells, and the like, are also
found in Microsoft Project.
You can also see, or view, your data in forms. These forms are similar to a form view that you receive
for data entry screens in database programs. Forms allow you to add or edit data and you can usually
cycle through the cards as you would in a normal database.
If you wish to see your data graphically you can view it as a Gantt Chart or Network Diagram.
In addition you have a variety of other graphs for displaying resources.
Ribbon
Active
pane
indicator
Sheet
Gantt
view
chart
Ribbon The Ribbon displays the commands required to use Microsoft Project. It is made up of
tabs (File, Task, Resource, etc) which each contain groups of commands organised into
logical order.
Active pane The active pane indicator is a vertical bar with a dark colouring that runs down the left
indicator side of a screen (or a view). The one above contains the words Gantt Chart so that you
know you have a Gantt Chart as the active view. You can actually have two different
views open by splitting the screen – only one view, however, can be active because
things like the commands on the Ribbon are controlled by what you are viewing. The
indicator shows which view is currently active.
Sheet view Your project’s tasks and resources can be seen as a table, much like a spreadsheet. In
Microsoft Project this is referred to as a sheet view.
Scheduling mode Your project can be scheduled manually (the default) or automatically. This (very
important) indicator tells you which mode is currently applicable.
Status bar Watch this space – it tells you what Microsoft Project is currently up to.
Quick view buttons There are many ways to change the view of the screen. These four buttons provide
quick access to the four most common views saving you the hassle of locating the
commands to do this on the Ribbon.
Gantt chart The Gantt Chart is the world’s most favourite view of a project. It shows your project’s
tasks as a series of timelines. It is the default view of Microsoft Project when it is first
started and, in reality, will most likely be the one you use most.
The Ribbon
When you need to do something with the data in the work area, such as format it, colour it, analyse it,
move it, copy it, change the view of it and much more, you’ll find all of the relevant commands on the
Ribbon. The Ribbon has commands organised thematically using a series of tabs across the top.
Commands on each tab are further organised into groups of like-commands. It’s not too hard to get the
hang of where a command can be found. Remember, a project is simply a view of task and resource data
– hey, have a look at the Ribbon and you’ll find a Tasks and a Resources tab! So whatever you need to
do with tasks can be found on the Tasks tab, and anything you want to do with resources can be found
on the Resources tab.
Backstage
When you want to do something with
the data in your work area, such as
save it so that you can access it again
later, print it, share it with a colleague,
send it to your boss, protect it from
prying eyes, or whatever, you will
need to access the Microsoft Office
Backstage area of Microsoft Project.
The Backstage is accessed using the
File tab on the Ribbon. Rather than
offering you commands on a Ribbon,
Backstage occupies the entire screen
and has a series of options down the
left side. Here the Print option is
active, and that is why you can see a
preview of the work area and a series
of print-related options on the right
side of the Backstage.
1
Try This Yourself:
Before starting this
exercise ensure that
Microsoft Project has
started...
Click on Calendar in
Task Views to see the
screen laid out as a
calendar
About Tables
Since there are literally dozens of fields for both Tasks and Resources, Microsoft Project organises
these in specialised groupings into tables. For example, fields for tasks associated with costs are
organised into a Cost table, fields that are commonly used for data entry are organised into an
Entry table, and so on.
Task Tables
There are 17 pre-defined tables for tasks as follows:
Baseline Earned Value Export Summary
Constraint Dates Earned Value Cost Indicators Hyperlink Tracking
Cost Earned Value Schedule Indicators Rollup Table Usage
Delay Entry Schedule Variance
Work
Resource Tables
There are 10 pre-defined tables for resources as follows:
Cost Entry – Material Resources Hyperlink Usage
Earned Value Entry – Work Resources Summary Work
Entry Export
1
Try This Yourself:
Before starting this
exercise ensure that
Microsoft Project has
started...
Double-click on the
vertical line to precisely
align it to the nearest field
2
Try This Yourself:
Before starting this
exercise ensure that
Microsoft Project has
started...
Click on [Cancel] to
close the dialog box
without doing anything
Click on 3 Sample
Project.mpp
Click on Exit
You may be prompted to
save changes made to the
project. We haven’t made
any changes worth keeping
so we can ignore this
message…
NOTES:
WPL_V515
1 2 3 4 5 6 7 8 9
A task is automatically formatted as bold when a task below it is indented. The bolding
indicates that the task is a summary task and the indented tasks below it are subtasks of the
summary task. Note that you cannot edit the duration of a summary task, only its subtasks.
The Start date determines the start position of the task bar.
The Finish date determines the end position of the task bar.
The Duration of a task determines the length of the task bar. You can either enter the
Duration or let Visio calculate it by typing a Start and Finish date. Type the Duration as a
number followed by w for weeks, d for days, h for hours, or m for minutes (for example, 3d for
3 days).
A task with a duration value of zero is a milestone (see task 8 Go to Airport above).
The % Complete indicates the progress of a task. The value is highlighted in the task bar to
give additional graphical information. This column may not be showing by default, but can be
added in manually.
The percentage complete is reflected in the task bar by a proportion of the task bar appearing
in a different colour, see tasks 1 and 2 above.
Linked tasks are connected by connector lines. By connecting tasks, if the end date of one
task changes, the connected tasks will automatically adjust to reflect the impact on the
progress of the project.
Each task is represented graphically by a task bar. This makes it much easier to gauge the
progress of a project.
1
4
2
3
2 3
The Number of tasks option is only available when you are first creating a Gantt chart.
Once this dialog box has been activated and the Gantt chart created, you cannot create
additional tasks by using this option. Instead, you must either click on New or drag the
Row shape from the Shapes window to add extra tasks.
The Format determines the way in which the values will display in the Duration column of
the Gantt chart. Durations are displayed as w for weeks, d for days, h for hours, and m for
minutes (preceded by the number of those units).
The Timescale range determines the period of time displayed in the Gantt chart. The start
time and finish time fields are only available if Hours has been selected in Minor units.
The Time units determine the level of detail where the task bars are displayed on the Gantt
chart. In the Gantt chart, there are two levels of headings where the task bars are displayed.
The top heading is determined by the Major units selected in the dialog box and the lower
headings are determined by the Minor units selected.
1
Try This Yourself:
Continue using the
Same
File
CREATING SUBTASKS
If you have a task in a project that comprises a you identify a task as being a subtask, the parent
number of other tasks, then you can break down task is referred to as a summary task and it is
the ‘parent’ task into subtasks and thereby track formatted bold in the Gantt chart to indicate its
each individual aspect of the parent task. When status. The summary task and subtasks are linked.
2
Try This Yourself:
Continue using the previous
Same
File
Click on Indent
Tasks group
in the
2
Try This Yourself:
Continue using the previous
Same
File
Click on Link
group
in the Tasks
Press
clearly
to see the link more
Click on Previous
the Navigation group
in
Click on Go To Finish
in the Navigation group 2
This adjusts the drawing
so that the final date is
visible, but you might
need to scroll across to
see it
2
Try This Yourself:
Continue using the previous
Same
File
Click on [OK]
2
Try This Yourself:
Before starting this
Open
Click on [OK]
Now the Gantt chart will
print over two pages…
Russell D. Archibald1
Ivano Di Filippo2
Daniele Di Filippo3
Abstract
A holistic systems perspective of projects and programs is required today to achieve the full benefits of
systems thinking4 in project management. To achieve this perspective, the need to establish a
Comprehensive Project Life Cycle definition and to promote its application on all important projects is
first presented. This Comprehensive Project Life Cycle Model recognizes that there is always a Project
Incubation/Feasibility Phase prior to the currently existing Project Starting Phase of most project
management (PM) standards, and also recognizes that there must be an additional Post-Project
Evaluation Phase after the standard Project Close-out Phase. These phases are defined and discussed
for two basic types of projects: 1) delivery or commercial projects and 2) transformational projects. It is
recommended that this Comprehensive Project Life Cycle Model be considered for adoption as a
standard for important projects. While many PM practitioners and authorities limit the scope of ‘project
management’ to the traditional start-plan-execute-closeout phases, projects begin their existence
before the traditional start phase and their products or results continue to exist and must be evaluated
after the projects are closed out. The authors assert that these before and after phases must be
recognized as belonging within the domain of project management. Regarding the Post-Project
Evaluation Phase the need to differentiate between ‘project success’ and ‘project value’ is discussed.
Genesis of this paper: The authors became acquainted early in 2012 via the Internet through the Istituto Italiano di
Project Management/ISIPM LinkedIn discussion group. After an initial on-line exchange of ideas, this multi-
generational, multi-cultural trio decided to collaborate to produce this paper. Russell, age 88, an American who has
lived in 6 countries on 3 continents, brings a perspective formed by 62 years in engineering, executive, program and
project management across several industries and cultures; Ivano, age 52, an Italian, brings a perspective formed by 20
years in IT, 15 in project management and 25 years in charge of ‘front-end’ human resources in the Operations Center
of the largest Radiotaxi company in Italy and Europe, in addition to his university student years in the medical field;
Daniele, age 22, also Italian and the son of Ivano, has of course grown up in the Digital Age, has a strong interest in
human behavior, and completed his university degree in IT engineering in July 2012. This unique combination has
produced a team effort that has created the perspectives presented in this paper. Short CVs of each follow the
References.
Acknowledgement: The authors wish to acknowledge with gratitude the comments, suggestions, and
criticisms of an earlier version of this paper by Wayne Abba, Franco Caron, Prof. Gianluca Di Castri, Prof.
Dr. Jean-Pierre Debourse, Prof. Dr. Harold Kerzner, Prof. Dr. Stanislaw Gasik, David Pells, Dr. Darci Prado,
1
Chairman Emeritus, Archibald Associates; PhD (Hon), MSc, PMP, Fellow PMI, Honorary Fellow APM/IPMA (russarchibald.com).
2
In charge of GenialSoftware, Certified PM and Member, Istituto Italiano di Project Management/ISIPM; in charge of human
resources in the Operations Center of Radiotaxi 3570 Roma, Italy.
3
ISIPM member, IT/Engineering Student at Roma3 University in Rome, Italy.
4
Senge, Peter M. (1990), The Fifth Discipline, Doubleday/Currency; Gharajedaghi, Jamshid (1999), Systems
Thinking: Managing Chaos and Complexity, Burlington, MA: Butterworth-Heinemann.
1
Bob Prieto, and Prof. Jorge Tarazona, whose brief CVs are shown in Appendix A. The content remains
solely based on the opinions of the authors, however, except where quotations are specifically stated.
Part 1. Introduction
A company that wants to compete in the international market knows the importance of adopting a
Business Process Management (BPM) model as a holistic management approach. The BPM Model is the
set of activities needed to define, optimize, monitor and integrate business processes in order to create
the desired outcome for each stakeholder. In addition to driving a company’s on-going operations,
Business Process Management (which includes the concept of Business Performance Management) (Ref.
1) drives its projects and programs, integrated with their multi-project portfolios to achieve high
performance development that is characterized by new success criteria, where project management
metrics are based on performance indices as shown by a matrix between KPIs and CSFs (Ref. 2):
Key Performance Indicators (KPIs) are commonly used by an organization to evaluate its success
or the success of a particular activity in which it is engaged.
Critical success factor (CSF) is the term for an element that is necessary for an organization or
project to achieve its mission successfully, and for ensuring the success of a company. Critical
success factors are those few things that must go well to ensure success for a manager or an
organization, and therefore they represent those managerial or enterprise areas that must be
given special and continual attention to bring about high performance.
In achieving improved success in project, program, and portfolio management there are two desirable
goals:
A new way to define more broadly and manage more comprehensively the Project Life Cycles
for both the transformational and the delivery projects and programs within an enterprise; and
The proper and effective use of Information Technology (IT) with Business Process Management
(BPM) plus Project, Program and Portfolio Management (PPPM.)
Use of Information Technology (IT): In order to implement the powerful and widely used Business
Process Modeling software systems and the business software systems for managing projects,
programs, and their portfolios, we must have integrated information models of those projects and
programs. Examples of these software systems (applications) are listed in Appendix B. In fact, these
powerful systems are the enablers that make it possible to gain the insights of systems thinking in
improving all management processes, procedures, and practices. The greatest challenge in this regard
today is to properly integrate project management software with corporate and operations
management software within a large organization5. The full benefits from application of these powerful
information systems can only be achieved through development of fully integrated project life cycle
models that are the subject of this paper.
Project versus Product Life Cycle Management and Models: Since a project ends when its final results
(or products) have been delivered to the owner, investor, marketer, or user in accordance with the
project contract or internal project charter, the standard project life cycle comes to an end when the
5
Bob Prieto says: “Often a barrier to effective lifecycle management is a split responsibility within an owner’s
organization for CAPEX [capital expenditures], OPEX [operations expenditures], and sales. Another barrier to
lifecycle management systems is often corporate accounting systems which do not provide a total cost of
ownership picture that includes initial studies, CAPEX, OPEX, cost of sales and financing costs.”
2
project close-out phase is complete. The product life cycle begins at the moment the product begins to
be used, sold or placed in operation, thus producing the benefits that justified the project in the first
place. There may be some overlap between the standard project close-out phase and the initiation of
the product usage and thus its product life cycle. For consumer products the product life cycle typically
has five phases: introduction, growth, maturity, decline, and termination. There may of course be
product improvements (new projects) to extend the product life. If the project produces a new facility,
such as a petrochemical processing plant, the product life cycle will consist of these phases:
commissioning (usually also an overlapping phase with the project that produced the plant), operation
(with periodic maintenance and modification projects interrupting productive operation),
decommissioning, and demolition (including any ecological cleanup.) For an IT software project that
produces an information system, the product life cycle phases will include commissioning (placing the
system in full operation), operation, and decommissioning (usually replaced by a new system.) When
agile project management methods are in use, there will often be a long period of continuous
improvement as new features are added or unforeseen deficiencies are corrected during the project
execution phase. In these cases it may be difficult to know when the original project scope has been
achieved and to identify exactly when the project has been closed out and the system (product)
operation phase begins.
Significant versus Small or Trivial Projects: This paper focuses on significant projects within human
organizations. Of course there are many small, simple, relatively unimportant projects (perhaps fairly
informal ‘task forces’) that exist in any organization, and they can usually be managed without the
application of the ideas presented here. Determining whether or not a specific project is ‘significant’
enough to require application of these ideas must be accomplished by the responsible managers within
each organization. Any project that is considered to be strategically transformative will be significant
regardless of its size in terms of cost or number of people involved.
The Importance of Project Life Cycle Models: All projects consist of a number of different phases that
form the life cycle (or life span) of each project. In the early years of the development of modern project
management practices it was common to see each phase of a project being planned, scheduled, and
managed as a separate project, from start to finish of each phase. Frequently a new project manager
would take over as the next phase was started. This usually resulted in many un-resolved design or other
conflicts being swept forward into the next phase, especially in design/construction/field operation
projects, as well as in IT projects. The field project manager of a new process plant, for example, had to
solve the problems during that construction phase that should have been solved during the design
phase. The cost of operating the plant was often increased because the designers and constructors took
short-cuts to reduce their costs and increase their profits, but these short-cuts increased the cost of
operating and maintaining the plant.
As the project management discipline matured it was recognized that overlapping these phases when
practical will save a considerable amount of time and money, and assuring that one project manager
maintains responsibility for the entire project life cycle forced the resolution of conflicts as early as
possible in the project life cycle. This led to ‘fast-tracking’6 in the engineering-procurement-construction
categories of projects, as well as in many other project categories.
6
Bob Prieto says: “’Fast tracking’ was driven by a need to accelerate time to market initially but later was
recognized as a way to aggregate and transfer risks, particularly those risks in the ‘white space’ between project
phases that were often unmanaged.”
3
As the power of business process and project management information systems grew over recent
decades, building on the rapid advances of computer supported systems and information technology in
general, the power and benefits of documenting and integrating all of the project life cycle phases
became more evident and more important.
This led to the development and use today of a number of project life cycle process models consisting of
a number of phases or stages and related decision points for the many different project categories and
sub-categories that exist (Archibald, 2003, pp 45-46; see also Appendix C, as discussed later.) The
models within each category and sub-category show similarities but in most cases there are significant
differences from one category/sub-category to the next. To be sure, the simplest four-phase life cycle
model (starting or concept, organizing or definition, execution, and closeout) will be the same for all
categories (PMI 2008, p 16.) But such a simple model is of little practical value in actually planning,
authorizing, scheduling, and controlling any complex project.
Purposes of Project Life Cycle Process Models: The purposes of designing and documenting the overall
project life cycle process for any project or project category (Archibald 2007) are to:
Enable all persons concerned with creating, planning and executing projects to understand the
processes to be followed throughout the life of the project.
Capture and document the best experiences within the organization so that the processes
within each project phase can be improved continually and applied on future similar projects.
Enable all the project roles and responsibilities and the project planning, estimating, scheduling,
monitoring and control methods and tools to be appropriately related to the overall project life
cycle management process; this includes most importantly assigning qualified persons to the
roles of Project Executive Sponsor and Project Manager at the proper points in the project life
cycle phases, as discussed later in this paper.
Enable the effective application of project management software application packages that are
integrated with all appropriate corporate information systems.
In other words a well-documented project life cycle model enables us to apply systems thinking to
creating, planning, scheduling, and managing the project through all of its phases, and to evaluating
both the success and the value of both the project and the results that the project has produced. This is
of greatest benefit to the project owner, key stakeholders, the ultimate user of the project results, and
the social beneficiaries of those results -- whether it is a new process plant, a highway, a new business
process or system, or a new product. It will not be of similar interest to a project manager or an
organization that only holds responsibility for one phase, or one aspect of one phase, of the entire
project. Unless a well-documented, integrated, understandable picture of the overall life cycle process –
the model -- for each project category/sub-category exists, it will be difficult to achieve the full benefits
of modern, systematic project management.
Life Cycle Phases and Decision Points: There is generally held understanding (PMI 2008 p 16) that the
four broad, generic project phases are as shown in Figure 1:
Starting the project (concept, authorization, initiation, identification, selection, project charter
and business case, planning, scheduling.)
Organizing and Preparing (definition, feasibility confirmation, development, demonstration,
design prototype, quantification.)
Carrying out the work (execution, implementation, realization, production and deployment,
design/construct/ commission, installation and test.)
4
Closing the project (handover of the project results to the user, project termination, sometimes
including post-completion evaluation.)
Each of these phases contain critical decision points (proceed, cancel, revise
scope/cost/schedule/quality.)
Figure 1. Typical current “standard” top level project life cycle model. (PMIa 2008, p 16)
An “Extended life cycle” model is promulgated in the widely used Association for Project
Management/APM Body of Knowledge is shown in Figure 2, in which these four basic phases are clearly
shown and labeled “Project life cycle.” This model also shows an ”Extended project life cycle model”
that moves toward the comprehensive model proposed in this paper, but is still incomplete, as
discussed in the remainder of this paper.
Figure 2. A second “standard” project and extended life cycle model. (APM 2006 p 80.)
The phases shown in these two models are so broad and the titles so generic that they are of little value
in documenting a specific project life cycle process so that it can be widely understood, used,
reproduced, and continually improved. What is needed is the specific definition of six to ten (or more as
needed) basic phases for each project category and sub-category, usually with several sub-phases
defined within each of the basic phases. Archibald (2007 and 2003 Chapters 2.5 and 3.5) discusses in
detail the need for such specific project life cycle models and the application of systems thinking to such
models, and presents a number of examples of both predictive and adaptive project life cycle models:
Predictive life cycle models “favor optimization over adaptability” (Desaulniers and Anderson
2002) and include:
o Waterfall (also known as traditional and top-down): linear ordering of the phases, which
can be strictly sequential or overlapping to some extent; no phase is normally repeated.
5
o Prototyping: functional requirements and physical design specifications are generated
simultaneously.
o Rapid Application Development (RAD): based on an evolving prototype that is not
thrown away.
o Incremental Build: decomposition of a large development effort into a succession of
smaller components.
Adaptive life cycle models “accept and embrace change during the development process and
resist detailed planning” (Desaulniers and Anderson 2002) and include:
o Adaptive Software Development/ASD: Mission driven, component based, iterative
cycles, time boxed cycles, risk-driven, and change-tolerant. The
IBM Rational Unified Process (RUP) (Ref. Appendix B), driven by risk and customer need
is a good example of an adaptive software development model.
o Spiral: Repetition of the same set of life-cycle phases such as plan, develop, build, and
evaluate until development is complete.
o Extreme Programming/XP: Teams of developers, managers, and users; programming
done in pairs; iterative process, collective code ownership.
o Agile and SCRUM: Similar to above adaptive life cycle models with iterations called
“sprints” that typically last one week to 30 days with defined functionality to be
achieved in each sprint; active management role throughout.
Figures 3 through 6 illustrate some typical examples of project life cycle models now in use for a few of
the many different project categories.
6
Figure 4. Overview of a typical Stage-Gate™ project life cycle process for new product development.
Source: Robert G. Cooper et al, Portfolio Management for New Products (Cambridge, MA, 2001), p. 272.
www.perseuspublishing.com
Figure 6. United States DoD 5000 Defense Acquisition System Life Cycle
Source: DoD Defense Acquisition System
7
https://dag.dau.mil/Pages/Default.aspx
The Defense Acquisition System (Figure 6) is the management process that guides all USA Department of Defense (DoD)
acquisition programs, clearly showing the need for the Incubation/Feasibility Phase (User Needs and Technology Opportunities
& Resources) prior to the decision to proceed with the Pre-Systems Acquisition Phase. As stated in DoD Directive 5000.01, the
Defense Acquisition System provides the policies and principles that govern the defense acquisition system. DoD Instruction
5000.02, Operation of the Defense Acquisition System, in turn establishes the management framework that implements these
policies and principles. The Defense Acquisition Management Framework provides an event-based process where acquisition
programs proceed through a series of milestones associated with significant program phases. The instruction also identifies the
specific statutory and regulatory reports and other information requirements for each milestone and decision point.
Figure 7. Proposed six-phase comprehensive top level project life cycle model.
These two additional phases are required when the intermediate phases are expanded to show the
detailed life cycle model for specific projects within any of the various project categories that exist.
8
Jean-Pierre Debourse: “Your proposal is very excellent and there is nothing to change; it's the best
presentation I've seen and I think that its diffusion will be very important.”
Gianluca Di Castri: “In my opinion, all matters relevant to project management and controls will be
extended in the next years in two different directions: horizontally including on one side the strategic
phase and on the other side the complete life cycle of the project, until its dismissal or revamping, as
well as vertically, to include multi-project, programme and, in some cases, portfolio management. It is
important to take into consideration the distinction between hard projects (infrastructure, industrial,
military operation) and soft projects (information technology, research, change) since both metrics and
management techniques are in some way different. Project metrics will become more important in hard
projects, while in soft projects priority could be given to other skills.”
Bob Prieto: “In the discussion of project life cycle process models you deliberately bold the term
“systems thinking” which I whole heartedly agree with. In fact, I believe this is the real, central tenet of
what you are trying to convey and that it is intimately linked to the “holistic” management approach you
call for at the beginning of Part 1…. In my March, 2012 paper7 in PMWorldToday, “Application of Life
Cycle Analysis in the Capital Assets Industry”, I focus on this more holistic aspect by calling for Life Cycle
Analysis (that is an analysis with a triple bottom line perspective8) versus more traditional lifecycle
costing (only the economic bottom line). In that paper I schematically show a simplified lifecycle which
includes a generic planning and preparation phase before the initiation of all the various design,
procurement and construction activities and I will expand my thoughts in that regard as it relates to your
paper below. Finally, your post-project evaluation period also warrants more specific comment but you
will see in the above referenced paper I have included actual decommissioning as this is a more
significant lifecycle cost in many areas of the capital assets industry.”
Jorge Tarazona: “I think that your work is a very important contribution to the holistic and systems
thinking approach applied to Project Management. I totally agree that it is very important to develop
detailed life cycle models for each specific project category.”
What the project will create (new product, facility, service, information system, organization,
other principal deliverables);
What business benefits will be produced for the organization that will pay for the project, as will
be detailed in the Business Case that is produced during the Project Starting Phase;
Verification that the project is aligned with the strategic plans and objectives of the sponsoring
organization;
A reasonable idea of the overall scope of the project together with its expected time schedule
and cost, and whether the needed money and other key resources can reasonably be expected
to be available, as will be verified and detailed in the Project Charter that is produced during the
Project Starting Phase.
7
Not available on-line; contact Bob Prieto (see Appendix A.)
8
Prieto, Bob, “A Triple Bottom Line Opportunity For Our Cities,” March 8, 2008. Contact Prieto.
9
Preliminary or conditional approvals that the project will require from governmental authorities
or other agencies (environmental, economic, health, others) as well as any intellectual property
and physical rights of access that are needed for the project to succeed.
Overall economic, technological, political, social9, and physical feasibility of the project,
including the level and acceptability of the various risks that are involved..
A project will not normally be authorized to enter the Project Starting Phase (as that phase is now
described in various project management standards) until sufficient information, as listed above, is
available and its feasibility has been established. The basic question here is “Where does this initial
‘embryonic knowledge and understanding’ about the potential project come from?” This information
must be accumulated through a process of “information buffering10” (Di Filippo 2011) over a period of
time prior to authorizing any project to enter the current standard Project Starting Phase, and this
occurs in every case during the previously undefined but always present Project Incubation/Feasibility
Phase. This information buffering is similar to downloading a movie on your television set: the movie (or
the project) cannot begin until sufficient data and knowledge has been obtained and compiled locally.
Project Empowerment during the Incubation Phase: During this incubation/feasibility period we also
begin creating the project empowerment. While we are compiling the information we are
simultaneously loading the cognitive strengths needed to go till the end of the project. We begin
attenuating the Cognitive Constraints11 during this phase within the stakeholders and potential project
team members, and during the project starting, planning and execution we will work to remove them
completely. Our objective here is to create the “heuristic consent”, which is that particular mental state
that can build the:
9
For example, the social feasibility of designing and constructing a nuclear power plant in 2013 near Fukishimo,
Japan, is considered to be close to zero.
10
We “buffer” and store in an appropriate manner the information about the project, its scope, results and
feasibility, and the COGNITIVE CONSTRAINTS that exist within the project team members:
• information compiled during a cognitive pre-SWOT analysis
• noting what are the cognitive change resistances
• noting the context where the project results will be used or placed in action
• identifying what are the KPIs and CSFs.
11
See “Cognitive Constraints: A Key Element in Project Management Metrics," Russell Archibald, Ivano Di Filippo,
Daniele Di Filippo, 2012, for a discussion of this subject.
12
In the Esopo Experiment some people are asked to act together to remember something. At the end of the
experiment you usually can see the creation of a new team (almost self-generated) who did not even know each
other. The cognitive overload perceived by the participants became the motivation to overcome the cognitive
dissonance overload.
13
“Agency” in the Bandura theory can be defined as the ability to act, both actively and proactively, in a context in
which someone has to achieve a result. The perceived self-efficacy is the engine of agency.
14
“P inclusion” is for “Project inclusion.” The stakeholder involvement is important, the team member involvement
is essential; everyone can become the success key of the project.
10
GOING TO A RESULT: we communicate to the potential members of the project team and the
key project stakeholders the positive feeling of “moving towards”, “moving to creating”,
“getting something done”.
This enables a rapid transition between the Project Incubation/Feasibility Phase and the Project Starting
Phase when the project is formally authorized to begin.
Origins of Projects: To fully understand the several sources or origins of projects we must point out that
there are two types of organizations that plan and execute projects (Archibald 2003, p.7):
1. Project-driven organizations that derive most (if not all) of their revenue and/or other benefits
from creating and delivering projects (software systems developers, engineering/construction
contractors, consulting firms, some government agencies such as NASA, others); and
2. Project-dependent organizations that derive most (if not all) of their revenue and/or benefits
from producing and selling products or services, or otherwise providing services (as most
governmental agencies do), and depend on projects to create or improve new products and
services, enter new markets, or otherwise improve or change their organizations.
Frequently there are project-driven departments (such as the IT or new product departments) within
large, otherwise project-dependent organizations.
Within both of these organizational types there are two general types of projects (Archibald 2011):
1. Commercial or Delivery Projects that are similar to projects that the organization has planned
and executed before, including as examples projects to modify and install a new information
system; to design and construct a building, plant, or other facility with minor site adaption
changes to a previous facility; and similar mostly repetitive projects; and
2. Innovative, Development or Transformational Projects that are substantially different from
other projects that the organization has executed or purchased, including as examples new
products or services development using new technologies or materials; new management or
physical production processes; creating new organizations; acquiring and/or merging existing
organizations; and other projects that transform the organization in some significant manner.
These projects may be innovative in regard to the project management processes themselves,
or to the results that the project creates, or in regard to both of these aspects.
Table 1 indicates the usual sources of the “embryonic knowledge and understanding” of these two types
of projects within the two organizational types described above.
15
Tikkanen et al 2007.
11
customers that result from usually long-
lasting relationships and extensive
marketing efforts, or develop proposals
initiated internally:
> Project proposals that comply with well-
established strategic goals and are within
the known capabilities of the organization
are prepared and approved prior to
submittal to the customers.
> Project Starting Phase is not initiated
until a proposal is negotiated and a
contract is signed by both parties.
> A full-time Project Manager is usually
appointed only during the Project Starting
Phase.
> Project management functions must be
applied in proposal preparation but
frequently they are not.
Project-Dependent > Few if any commercial/delivery projects > Ideas for projects for major
exist in these organizations. If so the above organizational change;
Organizations comments apply. acquisitions; mergers; or new
markets, products, processes or
services come from strategic
managers, marketing/business
development, R&D, past
customers, consultants, or
individuals.
> Development of the idea into
project objectives, scope, et al
occurs over a period of time prior
to the project entering the
Starting Phase.
> Only when the ‘embryonic
understanding’ of the potential
project has been approved does
the project enter the Project
Starting Phase.
It is worth noting that many transformational projects or programs include the purchase of delivery
projects from outside suppliers that are actually project-driven companies or agencies. This depends on
the internal decision whether to “buy” or to “make” the products or results for selected portions (sub-
projects) of the transformational project or program.
Definition of the Project Incubation/Feasibility Phase: The Project Incubation/Feasibility Phase in the
Comprehensive Project Life Cycle is the phase prior to initiation of the Project Starting Phase, during
which the necessary information and “embryonic knowledge and understanding” of the potential
project is collected, compiled, buffered, and analyzed sufficiently to enable a well-informed decision to
proceed with initiation of the Project Starting Phase. The time required for this Project
Incubation/Feasibility Phase will vary from a few days to many months, depending on the nature of the
industrial, business or governmental sector; the project itself, its category and its complexity and risks;
12
the time required to obtain the needed clearances, approvals, technology and physical access; and the
availability of the pertinent information. The time, money, and skilled resources that are expended
during the Project Incubation/Feasibility Phase are provided, justified, and recovered in several ways, as
indicated in Table 2, for both the organization types and whether the project is either a delivery or
transformational type.
Table 2. Sources and recovery of the cost of the Project Incubation/Feasibility Phase.
13
Development costs of the
organization, or they may be
accounted for and recovered as
either direct or overhead costs.
Project Incubation/Feasibility Phase for Transformative Projects: Within both project-dependent and
project-driven organizations the initial ideas for transformative projects, which are in every case
significant innovations of some type, may come from any one of the several sources listed in Table 1.
Those organizations that conduct periodic strategic planning activities find that many of their
transformative projects emerge from that activity. Good practice demands that an Executive Sponsor
and a Project Manager be assigned to each potential transformative project as soon as it has been
decided that the project should be incubated and its feasibility established.
Commercial Projects are often part of Transformative Projects (or Programs): In many if not most
cases, commercial projects delivered to a second organization are vital parts of a larger transformative
project or program within the organization that purchased the commercial project. Thus the owner of
the transformative project/program must include the delivery project (often there will be more than
one of those) within its overall plan for the transformative project or program.
The Need for the Project/Feasibility Phase and Its Relationship to Organizational
Capacity Planning
Harold Kerzner says, in commenting on an earlier version of this paper:
“Perhaps the most challenging problem facing executives today is the determination of how much
additional work they can take on without over-burdening the existing labor force. We refer to this as
capacity planning. Executives can always come up with ideas for new projects, even opportunistic
projects that create business value and are aligned with strategic objectives as stated in your paper on
P.9. But having great ideas for projects and insufficient resources defeats the purpose of having an
Incubation Phase. The later you perform capacity planning, the more time and effort may have been
fruitlessly expended on projects that may never get approved. We traditionally perform capacity
planning after a well-defined business case is prepared just to learn that we have insufficient resources
or funding for such a project.
14
“There are also other constraints that may identify the need for an Incubation Phase. As an example, if
projects require some degree of innovation, then we may have added complexity to the project. We can
look at the levels of innovation:16
“As we read down the list of bullets, a significant increase in resource capacity is most likely required
together with the possibility of large capital expenditures. If there are limitations to available resources,
facilities and capital, then proceeding to the Scope Development Phase or business case development is
inconsequential. The Incubation Phase must include high level estimates to properly evaluate whether
these possible limitations exist. The scope development phase must then validate either the accuracy of
these estimates, refine the estimates or decide that the idea requires euthanasia.
“For the incubation phase to work effectively, the organization must have a clear understanding of the
differences between benefits and value. Value is the quantification of the benefits. In other words, if
these benefits actually materialize, then what is the "financial" value to the firm? It is true that for some
projects the value may be difficult to quantify in the incubation phase. The actual value may not be able
to be determined until we have the beneficial use of the deliverables possibly after the project has been
completed.
“I have seen way too many companies embark on projects simply because the benefits looked good on
paper without attempting to determine that actual business value of the project. A classical case was
the Iridium Project which was designed to create the 8th wonder of the world, namely a satellite rather
than totally land-based telecommunications system. Investors lost over $6 billion dollars developing
technology for technology's sake rather than for a valid business purpose17. Developing deliverables and
products, and then wondering how you will find customers, is never a valid business model. The
incubation phase is the first attempt to validate the relationship between benefits, value and strategic
objectives. Unfortunately, companies seem to be burdening the PMO with this responsibility after the
business case has been developed. While there may be some merit to have the PMO validate what is in
the business case, looking at capacity planning in the Incubation Phase may be best.
“Another important characteristic of the Incubation Phase is the determination of the availability of a
qualified project manager for the project at hand. Regardless of the PM's years of experience and
exposure to educational opportunities, not all project managers are equal in project management
capability. The size, nature and complexity of the project should be used as a first look at the
qualifications needed to manage such a project. This first look must also appear in the Incubation Phase.
16
Harold Kerzner, Project Management: A Systems Approach to Planning, Scheduling and Controlling;
11th edition, John Wiley and Sons Publishers, Hoboken, 2013; pp. 427-430. To be released in March,
2013.
17
Ibid; see Chapter 26 for a description of the Iridium Project.
15
Project Management practices can and should be employed prior to the Project
Starting Phase
Two conclusions stand out from these two studies. One, that following the PMBOK Guide®
elements may be sufficient to deliver projects properly in process and practice terms but
probably is not enough to ensure that the project is successful. Two, that to do the latter one
needs to concentrate more on the managing the front-end.
But it is the contention of this paper that one can take the argument a stage further: project
execution is itself improved by concentrating more on the front-end; and that the project (and
program) management professional has a significant role to play managing projects and
programs for business success18. Benchmarking data in the oil and gas industry for example
shows conclusively that effort spent (up to a point) on front-end definition (so-called ‘Front-end
Loading’ – FEL) correlates positively with project outcome performance. And second, there are a
number of practices which the ‘project management’ professional can deploy which will
positively enhance the strategic value of the project to the sponsoring organization(s). It is these
contentions that this paper explores.”
….
Summary and conclusions: We have come full circle. What you give out, you get back. If we
position project management as an execution-only discipline19, we will be seen as just that and
cut-off from the really important parts of the project: those where value can most be created:
the front-end.
The reality, as shown by the results of two separate surveys, is that the overwhelming majority
of practitioners polled believe that project management does apply in the pre-execution stages.
The survey of seven organizations’ life cycles shows that these companies expect project
management practices and principles to be applied in these pre-execution phases as well in the
downstream execution ones.
But as the four case studies show, there is still confusion in practice, with some organizations
seeing project management pre-eminently as a managerial, execution oriented activity. The
PMBOK Guide® and OPM3™ fully support such an interpretation. Yet it is at odds with what the
literature, and many companies’ experience, shows to be the case: that managing projects
effectively begins in the very earliest of phases (Milestone 0). If projects, and programs, are only
done for a purpose, they should be dynamically connected to the enterprise strategy. For, as the
case studies show, the evolution of projects generates new information which often needs to be
fed in to the enterprise’s ‘emergent’ strategy.
18
Note by this current paper’s authors: This point is emphasized in the various PM standards, as for example the
PMI Standard for Program Management, 2008, and the PMI Standard for Portfolio Management, 2008.
19
Note by this current paper’s authors: This attitude is still widely held by many practitioners in spite of the
movement in recent years to include program and project portfolio management within the project management
realm.
16
As a post script: there are some who will claim that project management is indeed about
execution and it is really the responsibility of program management to be concerned with
strategy and business benefit. In some cases, in some companies, it may work like this, but as a
generic answer for the discipline as a whole this surely is inadequate. We need to be voicing a
view of the discipline which provides a holistic approach to managing projects, and programs,
from their earliest stages to their last in order to deliver business benefit. I call this ‘the
management of projects’. (Peter Morris 2005)
The Project Executive Sponsor and Project Manager roles exist during the
Project Incubation/Feasibility Phase but are rarely formally assigned20
Common practice in almost all industry and government sectors today is to assign the Executive Sponsor
(if indeed one is assigned) and a Project Manager only when the Project Starting Phase begins. However,
both of these roles actually exist when the original idea or concept starts to be investigated as an
embryo project. There is a need for a person at the executive level to take on the Executive Sponsor role
at this early stage, for both commercial and transformative projects. At the same time there is a need
for one person to take on the integrative role of the Project Manager, even if this does not require that
person’s full time, in order to apply the project manager perspective to the embryo project. The same
advantages accrue from filling these roles during the Project Incubation/Feasibility Phase as accrue from
assigning these roles during the Project Starting, Definition, Execution, and Close-Out Phases. Usually
during the Incubation/Feasibility Phase these two roles are scattered between various people within the
Business Development, Marketing, and Strategic Planning executives and managers. In the case of the
Project Executive Sponsor it is very desirable for the same person to carry that responsibility throughout
the entire project life cycle, but it becomes more problematic to maintain the Project Manager
responsibility throughout the entire project with the same person, even though that is equally desirable.
According to Stanislaw Gasik the main point of this front end procedure is that each proposal must be
assessed by independent experts. He states:
20
Jorge Tarazona says: “I totally agree with this statement.”
17
opportunities into capital projects. In other words, during the FEL phase, the questions of Why,
What, When, How, Where and Who21 are answered.
“The goal of the total FEL phase is to secure a detailed definition of a project’s scope needed to
satisfy the business objectives for the capital investment. By providing a detailed project
definition that can be communicated and agreed upon by all project participants prior to
authorization22 [emphasis added—this usually means prior to authorization of the Project Start
Phase], the FEL phase aims to reduce the number of changes in later project stages. Thus, the
project outcomes should be more predictable. The FEL phase is defined as the period from when
a business opportunity is identified and to the point at which a project capitalizing on the
business opportunity is authorized“.
Milton Jones (2004) has this to say about FEL: “This paper has attempted to indicate the overall
desirability (improved safety, enhanced operability, etc.) and the specific financial benefits available
from pre-investing time and resources in project pre-planning (Front End Loading) and in the use of risk
reduction techniques such as constructability studies. It has been conclusively demonstrated from a
review of available industry statistics that improvements in ROI and TIC of between 6% and 23% are
possible and have historically been achieved as a direct result from employing either one or (even
better) a combination of these methodologies. We have also shown that it is possible (and, indeed, both
practical and advisable), using established and creditable processes and systems, to employ available
and industry-accepted methodologies (Project Definition Readiness Index) that measure (using easily
quantifiable metrics) the relative readiness of projects to proceed through the quality “gate” to full
authorization (funding).”
Darci Prado states that "FEL model was greatly improved by IPA (Independent Project Analysis23) and
has also developed the FEL indicators to be used during the project/product life cycle and at the end of
the project. On the other hand, I think that the idea of formalizing the Incubation Phase for all kinds of
projects certainly will make the project/product life cycle more robust. To conclude, I mean, I do not
look at the Incubation Phase as an innovative idea, but I think that formalizing it in the project life cycle
for all kind of projects is an innovative idea. The Cognitive Constraints approach is a good contribution to
how to operate the Incubation Phase."
David Pells states that “*This+ is not a new phase. Otherwise known as the Project Feasibility Phase, this
stage is well established in the project finance and economic development fields, and in aerospace,
defense and some other sectors where the business models/financing processes drive the entire project.
Of course, this phase has been generally ignored in the life cycle models advanced by professional
21
And who will be disturbed or adversely affected is also extremely important; without these deliberations project
initiation will be weak, according to Stanislaw Gasik.
22
Stanislaw Gasik says: “This is misleading. In my experience when a project is sufficiently big you may not
forecast its scope in detail. The current trend in contracting, especially in construction industry (led as I can see by
prof. Kumarawswany from Hong Kong goes in the direction of “relational contracting”, called sometimes ‘Japan-
style contracting’. The main point in signing a contract is not the precise definition of contract scope (leading
usually to intensive litigations), which is virtually impossible, but selecting a partner who will want and be able to
cooperate on constant scope refinement and re-definition. “Spend your money for constructing and not for
lawyers” they suggest. So the goal of this phase is mainly to build a cooperating and collaborating team – from the
contemporary point of view. The scope should be initially defined but it will continually be changed; not only are
the change procedures important, but also the attitudes of project team members.”
23
As in public projects in Norway.
18
bodies like PMI, primarily because project managers and project management are seldom
assigned/implemented until after the investment decision has been made. There are many in the PM
field who have recognized and complained about this weakness for many years.”
Bob Prieto says: “Your addition of an incubation or feasibility phase I think is a correct one but I am not
sure that this is necessarily a new construct. In today’s large capital projects, the FEL phases, linked to
stage-gates, are preceded by an extensive “Conception” period during which extensive and often time
consuming activities are undertaken. In some instances these will be synonymous with FEL 1 but in
other instances they will include pre-FEL efforts often generically referred to as “studies”. These
activities typically include: a)Computer models, b) Conceptual level estimates, c) Environmental studies,
d) Feasibility studies, e) Labor and wage studies, f) Master plans, g) Permitting, h) Project financing, i)
Scope definition, j) Siting, k) Technology/licensor selection, l) O&M readiness reviews.
“With respect to FEL, terminology varies by owner and even by EPC firm as you can see in the following
example. I discuss FEL stage focus in ‘The GIGA Factor’ published by CMAA24.
Project Phase Contractor Owner A Owner B
Definition Definition Definition
FEL Phase 1 Business Plan Appraise Conceptual
FEL Phase 2 Conceptual Engineering Select Feasibility
FEL Phase 3 Preliminary Engineering Define Front-End Engineering
Phase 4 EPC Execute Execution
Phase 5 Startup and Operation Operate Operation
”A Studies Phase or as I referred to it above, a ‘Conception’ Phase, precedes FEL, and it is where strategy
is translated into tactics that respond to an ‘efficient frontier’ (Project Selection in Large Engineering
Construction Programs; PMWorldToday; June 2011) created by what I believe is increasingly multi-
dimensional optioneering. One may argue that this Conception Phase and Strategy Phase should be
grouped but I see different skills sets and focus being brought to bear.”
Tarazona states: “The Project Life Cycle of my Modelo T25 has the following phases APEO (Alignment of
the project with the strategy of the organization), FORMULACIÓN and EVALUACIÓN, which contain
components of your Project Incubation/Feasibility Phase. On the other hand, your Project
Incubation/Feasibility Phase contains some elements of the process that some organizations call “Ex-
Ante Evaluation” and which is performed before the Project Execution Phase starts.”
24
See
https://online.cmaanet.org/cmaassa/ecssashop.show_product_detail?p_product_serno=214&p_mode=detail&p_
cust_id=&p_session_serno=204812&p_order_serno=214233&p_promo_cd=
25
Jorge Tarazona, “Algunas Verdades Sobre La Gerencia Moderna de Proyectos (GMDP)”, Primer Congresso de
Gerencia de Proyectos, PMI Bogotá Chapter, Nov. 1-3, 2012.
19
Bob Prieto states: “In this Strategy stage an organization, whether that is at the highest level or a major
division level, begins by defining what its strategic business objectives are. The significance of this step
cannot be overstated. Ed Merrow, President & CEO of IPA , highlights the importance of clearly
articulated objectives in his paper presented at the European Construction Institute’s26 23rd Annual
Conference this past year. It is only when these SBO’s are clearly articulated, and importantly agreed to
and supported by the appropriate organizational governance regime, that a Strategy can be developed
and implement utilizing what I referred to as a Strategic Program Management approach in my book of
the same name. Strategy is translated into tactics (build this thing, in that place, with these
characteristics) during the “Conception” phase. Optioneering is a technique of growing importance as
complexity grows and trade-offs become multi-dimensional through the considerations of non-financial
bottom lines in addition to more traditional optimization points such as NPV or ROI.”
The Post-Project Evaluation Phase, described in the following section, deals directly with this issue.
26
http://www.eci-online.org/
27
“Managerial success” according to Turner et al 2010, p. 87.
28
“Products and products success” and “business success of project owner(s)” according to Turner et al 2010 p.87.
20
This evaluation phase will also identify weaknesses and threats that can be turned into opportunities
that lead to the incubation/feasibility phase for future projects for the organization.
“In my textbooks, I refer to this phase as the Customer Satisfaction Management Phase. Before
providing my comments on this, it is important that I describe my vision of the future of project
management.
“Historically, project management methodologies were heavily burdened with policies and procedures,
thus limiting the freedom that project managers needed to effectively apply the methodology. All
projects were often required to use the same enterprise project management methodology. This held
true regardless of the number of life cycle phases used or the nature of the phases. Gate reviews were
established to provide further controls on the project managers.
“When working with customers (primarily external customers), telling them that you will solve their
business problem (i.e., the project) using your methodology which is based upon your company's
business model can be viewed as trying to squeeze a cube into a round hole. What customers are asking
for today is for the contractor to have a flexible or adaptive methodology that can solve the client's
problems in the context of the client's business model or business environment.
“For this to work, the contractor's firm must have more faith in the project manager's abilities than ever
before and give the project manager more freedom in how to apply the methodology to generate the
business solution desired by the client. Simply stated, methodologies are being replaced with forms,
guidelines, templates and checklists rather than the more rigid policies and procedures. The
methodology now becomes a project management framework with built-in flexibility, and where the PM
has the freedom to decide what forms, guidelines, templates and checklists should be used on this
project.
“If you provide the client with a business solution to their problem, and you do it according to the
client's business model rather than your firm's business model, then there is high likelihood that
addition work from this client will be forthcoming. In other words, flexibility when used correctly can
and will generate additional business.
“Now, we can return to Post-Project Evaluation (or Customer Satisfaction Management) Phase and
address the issues from the client's perspective. Let's envision a meeting with the client after the Project
Closure Phase has been completed. Sitting in the room from the contractor's organization are the
project manager, the sponsor or other members of the project's governance group, members of the sale
force, some of the team members and possibly a member of the PMO. And then one question is asked:
"’What changes can we make to our framework to better serve you on the next project?’
“This is the way that a contractor can build up a strategic partnering relationship with the client for
future business. There is no guarantee that the customer's requests for changes will be adhered to, but
it does lead to customer satisfaction.
“In this phase, we tend to focus on what we can do to benefit us internally. But we must also focus on
the client and what we can do to benefit them. Successful relationships between a client and a
contractor may very well induce the client to bring the project on board earlier than usual. The
21
contractor might even be brought on board during the client's Incubation Phase in order to assist in the
evaluation of ideas. This would then be a win-win situation for everyone.”
Comment by this paper’s authors on Dr. Kerzner’s remarks above: We certainly agree with all of these
points, but wish to emphasize that Dr. Kerzner’s perspective here is from that of a project-driven
(contractor) company that is delivering projects to a buying organization. His comments apply equally
well to project-dependent organizations who often purchase projects from project-driven organizations.
22
Communities (local, regional, and even virtual) that are affected by the project and its products
or results:
o Immediate neighbors of new construction of facilities;
o Users of communication systems and devices.
Gasik states: “I would add success as seen by stakeholders other than the project owner (after
all the owner is the most important stakeholder). But we must have in mind that there are
negative stakeholders for whom “project success” will be project failure. So success from the
stakeholder perspective is success for positive stakeholders and converting as many negative
stakeholders as possible to a positive attitude.”
And others?
High project stakeholder satisfaction thus will enable the project organization to become the leader in
its market. If the project manager and the team members are not satisfied, the project will lose
effectiveness and efficiency and the project results will not be the best that they could have been.
Similarly, if the other key stakeholders are not well-satisfied the perceived success of both the project
and the project results will be adversely affected.
4. The Cognitive Constraint Dimension29: Cognitive Constraints have always had an important impact
on the success of a project as well as on the end results produced by the project. Only recently have
they begun to be recognized in the project management community. The CSFs associated with this
dimension include how the project manager and the project team handle:
High decelerations or accelerations during the project
Contingency factors that are hard to manage
The Student Syndrome
Parkinson's Law
Overloading Stress
Multi-tasking Stress
Burnout Syndrome
Internal conflicts that can lead to crises
Drastic commitment reduction
“Competence Borderline Syndrome” (I’m going to do just what I have to do, no more!)30.
… and so on…
Achieving good success in this regard will have long-lasting impacts on all future projects and programs
within the enterprise, as well as on the results of any specific project being evaluated.
Prado states: “The inclusion of the COGNITIVE CONSTRAINT DIMENSION to measure PROJECT SUCCESS…
is really an innovative and revolutionary idea. I think that a lot of work should be done for the
acceptation of the idea in the practical world, but this is another story …”
Gasik says: “This is a great idea; I agree with Prado’s statement” *above+.
Tarazona comments: “About measuring the overall project success: I would suggest to take into account
something about the compliance with the agreed standards and rules of the game, and contribution of
29
See “Cognitive Constraints: A Key Element in Project Management Metrics," Russell Archibald, Ivano Di Filippo,
Daniele Di Filippo, 2012, for a discussion of this topic.
30
We believe this statement represents the first formal recognition of this cognitive constraint.
23
the project to the enrichment of the Project Management Knowledge Base of the organization.
31
We are indebted to Stanislaw Gasik for introducing this concept.
24
For those project-driven organizations that only planned and executed a portion of the overall project or
program this Post-Project Evaluation Phase will be of less interest and benefit. For those organizations
the first ‘project management’ dimension will be of primary interest, but they can also benefit a great
deal from the results of the other three evaluation dimensions.
David Pells states: “I very much like the discussion of the 4 ‘Dimensions for delivering project success’
…. The expanded emphasis on the ‘Post Project Evaluation Phase’ is very good. As you point out, this
phase has been sorely missing and inadequately addressed in PM models, standards, and the
professional literature. I see this subject now strongly supported by the new emphasis on green PM and
sustainability. Of course it also gets to the heart of the whole ROI set of issues – does the product of the
project deliver the desired benefits?”
Bob Prieto says: “I struggle with the discussion on the post-project evaluation phase. Is the project first
delivery of the asset only? If so I am driven to optimize around first cost, ease of turnover and no
problems during the warranty period. If, however, lifecycle is truly that, then my optimization point is
about achieving ALL the SBOs the project was to address, over the complete lifecycle of the facility. In
some instances, such as those with high end of life costs, ultimate success may only be at some point in
the distant future. This does not stop intermediate assessment of achievement of “outcomes” as well as
refinement of business and other models to assess the likelihood of achieving the lifecycle objectives
that underpinned the project in the first place. In this context, any post evaluation period must be
carefully defined as well as the points of evaluation and the “scoring” methodology.“On a related note,
lifecycle analysis raises interesting questions with respect to:
Jorge Tarazona comments that “The managerial subprocess TERMINAR of my Modelo T [Tarazona
2012] contains components of your Post-Project Evaluation Phase. On the other hand, your Post-
Project Evaluation Phase contains some elements of the process that some organizations call “Ex-Post
Evaluation” and which is performed after the product of the project has been in operation.
25
Proposal for Adoption as a Standard for Important Projects
We will submit and propose this definition of the comprehensive project life cycle model to the several
professional associations and organizations that have established standards related to the project
management discipline for their considered evaluation for inclusion in their published standards and
project management bodies of knowledge, as appropriate.
Prior to that submittal we will publish this paper on-line at the PM World Journal at
http://pmworldjournal.net/ and request comments, criticisms, questions and other feedback from PM
practitioners around the world. The authors welcome this feedback for further improve and develop the
concepts presented in this paper: russell_archibald@yahoo.com, ivano.difilippo@genialsoftware.it and
Daniele Di Filippo at project4001@live.com .
26
Appendix A
Reviewers who have commented on earlier versions of this paper
Wayne Abba, MPA, Principal, Abba Consulting, Falls Church, Virginia, USA: Earned Value
Management expert specializing in the public sector, part-time member of the Research Staff at
the Center for Naval Analyses, retired from the Office of the Secretary of Defense in 1999 as
senior analyst for contract performance management. Contributing author of the Government
Accountability Office’s 2009 “GAO Cost Estimating and Assessment Guide: Best Practices for
Developing and Managing Capital Program Costs,” and of chapters 7 (Cost) and 12 (Procurement)
in the PMBOK ® Guide 4th Edition. Contact: abbaconsulting@cox.net .
Franco Caron, M.Sc. Electronic Engineering at Politecnico di Milano, Italy, currently Professor
of Project Management with the Management, Economics and Industrial Engineering
Department at Politecnico di Milano, in charge of the course of “Management of Large
Engineering Projects” both in the Systems Engineering and Industrial Engineering Programs.
He is also in charge of the course of Project Risk Analysis and Management both in the
Master in Project Management (MPM) and the Master in Strategic Project Management
European - developed jointly by MIP-Politecnico di Milano, Heriot Watt University Edimburgh
and UMEA University (Sweden). Currently specific research interests concern: project risk
management, proposal management, portfolio management and financial risk in project
development. Member of PMI Northern Italy Chapter. Contact: franco.caron@polimi.it .
Gianluca di Castri, Chartered Mechanical Engineer (1972), MBA, Certified Cost Engineer (EIE /
ICEC A, 1992): Wide professional experience in Total Cost Management as well as in Project
Management and Controls for Engineering & Construction Projects, achieved as project
manager, member of the general management team and then director of international
Engineering & Construction Companies. In recent years his consulting activity has been in Cost
Management, Project Management and Controls, Contract and Claim Management, and he
lectures in these disciplines at Bocconi University in Milano and at LUISS University in Roma.
He is author of more than fifty papers as well as of two books: “Project Management per
l’Edilizia (2009)”, “Lineamenti di Ingegneria Economica (1999)”. In June, 2012, has been
awarded the Distinguished International Fellowship of the ICEC (International Cost
Engineering Council). From 2005 to 2011 he was President of the AICE (Italian Association for Total Cost
Management), after having been for more than ten years member of the Directive Board as well as Delegate to
the ICEC. In 2012 he has been appointed by the council of the delegates of the ICEC as Director for Region 2
(Europe of Middle East) through October, 2014. Contact:
gianluca.dicastri@aice-it.org .
Jean-Pierre Debourse, PhD, MSc, Professor Emeritus and Director of Research, the University
of Littoral (ULCO), Dunkirk, France; Founder and Director of a research laboratory on
Entrepreneurship and Project Managementat ULCO, integrated in the LEM-National Scientific
Research Center (CNRS) with team members from 7 Universities; former Dean, ESC Lille
School of Management and Professor Emeritus, the University of Lille. Over 40 years of
experience in Project Management and Project Management Education, a founder of one the
first PM Master Degrees in Europe in 1979, a founder of the Regional Development Agency of
the North-Pas de Calais Region, the analyst for the Regional Council of Northern France of the
projects competing for the Channel Tunnel, former CEO, Fonds Régional de Garantie. Contact:
jeanpierredebourse@yahoo.fr .
Stanisław Gasik, PhD, Adjunct Professor at Vistula University, Warsaw, Poland and owner of
Sybena Consulting http://www.sybena.pl/index_ang.htm. Over 15 years of practice as
project manager, consultant, educator and auditor of projects, especially in IT and
construction in public and private sectors. Stanisław participated as a volunteer in
preparation of several PMI standards. His research interests include project knowledge
management, public projects, portfolio management, Project Management Offices, client –
supplier relationships in project environment, project management maturity and meta-
maturity, and foundations of project management. Contact: sgasik@sybena.pl .
Harold Kerzner MS, PhD, MBA, is Senior Executive Director for Project Management for the
International Institute for Learning. He has an MS and PhD. in Aeronautical and Astronautical
Engineering from the University of Illinois and an MBA from Utah State University. He is a
prior U. S. Air Force Officer and spent several years at Morton-Thiokol in project management.
He taught engineering and business administration at the University of Illinois and Utah State
University, and for 32 years taught project management at Baldwin-Wallace University. He has
27
published or presented numerous engineering and business papers, and has published more than 50 college
textbooks on project management, including later editions. His two latest books are (1) Project Management: A
Systems Approach to Planning, Scheduling and Controlling (11th edition - to be released in Feb 2013) and (2)
Project Management Metrics, KPIs and Dashboards (2nd edition to be released in Q2 2013.) He travels around
the world each year conducted lectures in Japan, China, Russia, Brazil, Singapore, South Africa, Germany, Spain,
Belgium, The Netherlands, Sweden, Finland, France, Italy, England and Switzerland. His recognitions include:
• The University of Illinois granted Dr. Kerzner a Distinguished Recent Alumni Award for his contributions
to the field of project management.
• Utah State University provided Dr. Kerzner with the 1998 Distinguished Service Award for his
contributions to the field of project management.
• The Northeast Ohio Chapter of the Project Management Institute gives out the Kerzner Award once a
year to one project manager in Northeast Ohio that has demonstrated excellence in project management.
• The Project Management Institute (National Organization), in conjunction with IIL, has initiated the
Kerzner International Project Manager of the Year Award given to one project manager yearly anywhere in the
world.
• The Project Management Institute also gives out four scholarships each year in Dr. Kerzner's name for
graduate studies in project management.
• Baldwin-Wallace University has instituted the Kerzner Distinguished Lecturer Series.
Contact: Harold.kerzner@iil.com .
David Pells, President, PM World, Inc, and Managing Editor of the eJournal PM World Journal
http://pmworldjournal.net/, Dallas, Texas, USA: Over thirty years of experience in project
management related activities and positions on a wide variety of programs and projects,
including engineering, construction, transit, defense and high technology, and ranging in size
from several thousand to ten billion dollars. PMI Fellow and former member of the board of
directors of the Project Management Institute (PMI®), and an Honorary Fellow of APM (UK),
PMA (India) and the Russian Project Management Association (SOVNET). Contact:
pells@pmworldinc.com .
Darci Prado, PhD Engineering, graduate degrees in Logistics and Engineering Economics,
Certified Project Manager (CPM), IPMA. Since 1996 Managing Consultant with
INDG/Management Development Institute, Brazil, the largest consulting firm in Latin
American, responsible for staff of 200 project management consultants with assignments in
many private corporations, NGOs, and governmental agencies at the state and national level.
24 prior years of experience with IBM in the USA, Europe, and Brazil. Author of 7 books on
project management in Portuguese and co-author of one book in Italian. Contact:
pradodarci@gmail.com .
Bob Prieto is a Senior Vice President of Fluor Corporation, one of America’s largest engineering,
construction and project management firms, where he is responsible for strategy in support of
the firm’s Industrial & Infrastructure Group and its key clients. He focuses on the development,
delivery and oversight of large, complex projects worldwide. Prior to joining Fluor, Bob served
as chairman of Parsons Brinckerhoff Inc. He served as a member of the executive committee of
the National Center for Asia-Pacific Economic Cooperation, a member of the Industry Leaders’
Council of the American Society of Civil Engineers (ASCE), and co-founder of the Disaster
Resource Network. He is a member of the National Academy of Construction. Bob is the author
of “Strategic Program Management” published by the Construction Management Association
of America (CMAA) and more recently a companion work entitled “Topics in Strategic Program
Management.” Contact: Bob.Prieto@fluor.com .
Jorge E. Tarazona B. Civil Engineering at Universidad Nacional de Colombia. Postgraduate
studies in Systems Engineering (European Systems Research Institute, Geneva, Switzerland),
Project Management (Information Systems Management Institute, New York, USA and other
IBM Education Centers) and Management (several Education Centers). Professional
Experience in Civil Engineering, Systems Engineering, Management and Project Management
as Engineer, Manager, Advisor and Consultant. University Professor in Graduate and
Postgraduate Programs and Dean of Systems Engineering. Founder and Participant in several
Graduate and Postgraduate Programs in Project Management Education. Over 30 years of
experience in Project Management and Project Management Education. Co-author of the
book “Papel y Perfiles del Ingeniero de Sistemas en Colombia,” and author of a variety of
articles. Lecturer in several Project Management Congresses. Member of Colombia PMI
Chapter. Contact: jetarazona@cable.net.co
28
Appendix B
Illustrative List of Business Process and
Project/Program/Portfolio
Digital Management Systems
29
Appendix C
Project life cycle models and references:
generic and for various project categories.
Project Categories:
Each having similar life cycle phases and one Life Cycle Models and References
unique project management process
Generic Project Models: many project Belanger 1998, pp 62-72: Generic, Waterfall,
categories. Parallel-Work, Evolutionary Models.
Morris 1994, pp 245-248: Standard, Waterfall,
Cyclical, Spiral Models.
1. Administrative/Management Projects See generic models above.
2. Aerospace/Defense Projects DOD 5000: Defense Acquisition System
2.1 Systems acquisition NASA Space Flight Program and Project
2.2 Space vehicle Management Handbook, p.20.
http://nodis3.gsfc.nasa.gov/OCE_docs/OCE_8.pdf
3. Communication Systems Projects See generic models above.
4. Event Projects See generic models above.
5. Facilities Projects See generic models above.
5.1 Facility decommissioning
5.2 Facility demolition
5.3 Facility maintenance and modification
5.4 Facility design/procurement/construction
Civil
Environmental
Industrial
Commercial
Residential
6. Information Systems (Software) Projects Desaulniers and Anderson 2001: Predictive
(Waterfall, Prototyping, RAD, Incremental Build,
Spiral) and Adaptive (ASD, XP, SCRUM) Models.
Highsmith 2009 Agile Project Management:
Creating Innovative Products
Lewin 2002, p 47: “V” Software Development
Model; p 50: Formula-IT Development Model.
7. International Development Projects World Bank Institute 2002, Module 1.
8. Product and Service Development Projects Cooper and Kleinschmidt 1993: Stage-Gate ®
8.1 Industrial product Process Model
8.2 Consumer product Kezsbom & Edward 2001, pp 108: Stage/Gate
8.3 Pharmaceutical product Product Development Model.
8.4 Service (financial, other) Thamhain 2000: Phase-Gate Process Model.
Murphy 1989: Pharmaceutical Model.
9. Research and Development Projects Eskelin 2002, p 46: Technical Acquisition: Basic
9.1 Environmental Model, Phased Model, Multi-Solution Model.
9.2 Industrial
9.3 Economic development
9.4 Medical
9.5 Scientific
30
References
th
APM Body of Knowledge, 5 edition, 2006. http://www.apm.org.uk/BOK.asp .
rd
Archibald, Russell D., Managing High-Technology Programs and Projects, 3 ed 2003, NY: Wiley.
_________________, “Life Cycle Models For High-Technology Projects – Applying Systems Thinking To Managing Projects,”
4th International Project Management Seminar, PMI-SP Chapter, December 9-10 2004, Sao Paulo Brazil (download at
http://russarchibald.com/recent-papers-presentations/other-pm-subjects/.)
_________________, “The Purposes and Methods of Practical Project Categorization,” International Project/Program
Management Workshop 5, ESC Lille – Lille Graduate School of Management , Lille, France, August 22 to 26, 2005 [modified
May 28 2007] (download at http://russarchibald.com/recent-papers-presentations/categorizing-projects/ .)
_________________, “Aspects of the Future of Innovative Projects Management.” Second International Conference on
Management of Innovation and Projects: A Vision of the Future of Innovation and Project Management in Brazil and the
World. Sponsored by the University of Sao Paulo’s Center of Competence in Strategic Management of Knowledge and
Innovation (GECIN), and the USP FUNDACE Business School, 30-31 May and 1 June, 2011, Sao Paulo, Brazil.
Download at http://russarchibald.com/recent-papers-presentations/innovation-projec-manage/
Cooper, Robert G., and Elko J. Kleinschmidt, “Stage-Gate Systems for New Product Success” Marketing Management, 1, no. 4
(1993): 20-29. See www.prod-dev.com .
Delanger, Thomas C., “Choosing the Project Lyfe Cycle.” Field Guide to Project Management, edited by David I. Cleland. New
York: Wiley, 1998, 61.71.
Desaulniers, Douglas H., and Robert J. Anderson, “Matching Software Development Life Cycles to the Project Environment,”
Proceedings of the Project Management Institute Annual Seminars & Symposium, Nov. 1-10, 2001. Nashville, TN. Newtown
Square, PA: Project Management Institute.
Di Filippo, Ivano, “Quando Inizia un Progetto? La Teoria del ‘Critical Buffering’ Theory,” *“When Does a Project Start: ‘Critical
Buffering’ Theory”+, IL PROJECT MANAGER Magazine, No. 8, 2011. Download at
http://www.francoangeli.it/riviste/5Scheda_rivista.aspx?IDArticolo=43784
Eskelin, Allen. “Managing Technical Acquisition Project Life Cycles.” PM Network (March 2009).
Highsmith, Jim, Agile Project Management: Creating Innovative Products, 2009. Addison-Wesley.
Jones, Milton H., “The Case for Front End Loading (FEL) and Constructability Reviews,” Greater New Orleans Chapter, Project
Management Institute, Professional Development Day, 15 October 2004
Kerzner, Harold, Project Management: A Systems Approach to Planning, Scheduling and Controlling; 11th
edition, John Wiley and Sons Publishers, Hoboken, 2013; pp. 427-430. To be released in March, 2013.Lewin,
Marsha D., Better Software Project Management—A Primer for Success. New York: John Wiley & Sons, 2002.
OGC (Office of Government Commerce), Managing Successful Projects with PRINCE2, 2003. Available at http://www.best-
management-practice.com/ .
Ketzsbom, Deborah S. and Katherine A. Edward, The New Dynamic Project Management—Winning Through Competitive
Advantage. New York: Wiley-Interscience, 2001.
World Bank Institute, Knowledge Products and Outreach Division. Managing the Implementation of Development Projects, A
Resource Kit on CD-ROM for Instructors and Practitioners, 2002. The World Bank, Room J-2-105, Washington DC 20433 USA.
31
Morris, Peter W.G., Managing the Front-End: how project managers shape business strategy and
manage project definition, PMI 2005 Global Congress Proceedings – Edinburgh, Scotland.
Download at http://www.indeco.co.uk/filestore/Morris-ManagingtheFront-End2005.pdf
Murphy, Patrice L. “Pharmaceutical Project Management: Is It Different?” Project Management Journal September 1989.
Newtown Square, PA: Project Management Institute.
th
PMIa, Guide to the Project Management Body of Knowledge, 4 ed, Newtown Square, PA: Project Management Institute,
2008. http://www.pmi.org/PMBOK-Guide-and-Standards.aspx .
nd
PMIb, The Standard for Program Management, 2 Ed, 2008.
nd
PMIc, The Standard for Portfolio Management, 2 Ed, 2008.
Tarazona, Jorge, “Algunas Verdades Sobre La Gerencia Moderna de Proyectos (GMDP)”, Primer Congresso de Gerencia de
Proyectos, PMI Bogotá Chapter, Nov. 1-2, 2012.
Thamhain, Hans J., “Accelerating Product Developments via Phase-Gate Processes.” Proceedings of the Project Management
Institute Annual Seminars & Symposium, Houston, Texas. September 7-16, 2000. Newtown Square, PA: Project Management
Institute.
Tikkanen, Henrikki, Jaakko Kujala, and Karlos Artto, “The marketing strategy of a project-based firm: The Four Portfolios
Framework,” Industrial Marketing Management 36 (2007) 194–205.
Turner, Rodney J., Martina Huemann, Frank T. Anbari, Christophe N. Bredillet, Perspectives on Projects. NY: Routledge, 2010.
32
About the Authors
Russell D. Archibald: PhD (Hon) ESC-Lille (Fr), MSc (U of Texas) & BS (U of Missouri)
Mechanical Engineering, PMP, Fellow PMI and Honorary Fellow APM/IPMA (member of the
Board of IPMA/INTERNET 1974-83), held engineering and executive positions in aerospace,
petroleum, telecommunications, and automotive industries in the USA, France, Mexico and
Venezuela (1948-1982). Russ also had 9 years of active duty as a pilot officer with the U.S.
Army Air Corps (1943-46) and the U. S. Air Force (1951-58.) Since 1982 he has consulted to
companies, agencies and development banks in 16 countries on 4 continents, and has
taught project management principles and practices to thousands of managers and
specialists around the world. He is the author of Managing High-Technology Programs and
Projects, 3rd Edition 2003, also published in Russian, Italian, and Chinese, plus other books (in English, Italian,
Japanese, and Hungarian) and many papers on project management. Web site: http://russarchibald.com Contact:
Russell_archibald@yahoo.com
Ivano Di Filippo: Team leader of Genial Software, a high performance expert team; ISIPM
PM certified, Member of Professional Italian Project Manager list held by ISIPM. Ivano
has over 20 years of experience as a consultant and project manager in business
information systems development. During three years of study with the medical faculty
at La Sapienza University in Rome he developed a strong interest in subjects concerning
human behavior and human mental processes, and has continued over many years to
cultivate and develop this interest by applying the cognitive psychological theories as an
important key to success in the numerous projects he has directed. Contemporarily he
studied computer science to become a web site programmer and IT programmer as
applied in project management. Ivano has 25 years with Radiotaxi 3570 Company, Rome, Italy, (the largest
Radiotaxi company in Europe and perhaps the world) and at present he is in charge of human resources in its
Operations Control room. In addition to the operations control personnel he daily interacts with company
customers as well as the company members/taxi drivers who number over 3,500. Ivano is the author of “When
Does a Project Start? The Critical Buffering Theory” in the ISIPM Magazine Il Project Manager, published by Franco
Angeli (see References.) ISIPM Project Managers Professional list: http://www.isipm.org/albo-
professionale/catalog?search=Di+Filippo Web site: www.genialsoftware.it Contact:
Ivano.difilippo@genialsoftware.it
33
Chapter 7: The Project Life Cycle
The project manager and project team have one shared goal: to carry out the work of the
project for the purpose of meeting the project's objectives. Every project has beginnings, a
middle period during which activities move the project toward completion, and an ending (either
successful or unsuccessful). A standard project typically has the following four major phases
(each with its own agenda of tasks and issues): initiation, planning, implementation, and closure.
Taken together, these phases represent the path a project takes from the beginning to its end and
are generally referred to as the project life cycle .
7.1 Initiation Phase
During the first of these phases, the initiation phase, the project objective or need is
identified; this can be a business problem or opportunity. An appropriate response to the need is
documented in a business case with recommended solution options. A feasibility study is
conducted to investigate whether each option addresses the project objective and a final
recommended solution is determined. Issues of feasibility ("can we do the project?") and
justification ("should we do the project?") are addressed.
Once the recommended solution is approved, a project is initiated to deliver the approved
solution and a project manager is appointed. The major deliverables and the participating work
groups are identified and the project team begins to take shape. Approval is then sought by the
project manager to move on the detailed planning phase.
7.2 Planning Phase
The next phase, the planning phase, is where the project solution is further developed in
as much detail as possible and you plan the steps necessary to meet the project's objective. In this
step, the team identifies all of the work to be done. The project's tasks and resource requirements
are identified, along with the strategy for producing them. This is also referred to as scope
management. A project plan is created outlining the activities, tasks, dependencies and
timeframes. The project manager coordinates the preparation of a project budget; by providing
cost estimates for the labor, equipment and materials costs. The budget is used to monitor and
control cost expenditures during project implementation.
Once the project team has identified the work, prepared the schedule and estimated the
costs, the three fundamental components of the planning process are complete. This is an
excellent time to identify and try to deal with anything that might pose a threat to the successful
completion of the project. This is called risk management. In risk management, "high-threat"
potential problems are identified along with the action that is to be taken on each high threat
potential problem, either to reduce the probability that the problem will occur or to reduce the
impact on the project if it does occur. This is also a good time to identify all project stakeholders,
and to establish a communication plan describing the information needed and the delivery
method to be used to keep the stakeholders informed.
Finally, you will want to document a quality plan; providing quality targets, assurance,
and control measures along with an acceptance plan; listing the criteria to be met to gain
Page 51 of 135
customer acceptance. At this point, the project would have been planned in detail and is ready to
be executed.
7.3 Implementation Phase
During the third phase, the implementation phase, the project plan is put into motion and
performs the work of the project. It is important to maintain control and communicate as needed
during implementation. Progress is continuously monitored and appropriate adjustments are
made and recorded as variances from the original plan. In any project a project manager will
spend most of their time in this step. During project implementation, people are carrying out the
tasks and progress information is being reported through regular team meetings. The project
manager uses this information to maintain control over the direction of the project by measuring
the performance of the project activities comparing the results with the project plan and takes
corrective action as needed. The first course of action should always be to bring the project back
on course, i.e., to return it to the original plan. If that cannot happen, the team should record
variations from the original plan and record and publish modifications to the plan. Throughout
this step, project sponsors and other key stakeholders should be kept informed of project status
according to the agreed upon frequency and format. The plan should be updated and published
on a regular basis.
Status reports should always emphasize the anticipated end point in terms of cost,
schedule and quality of deliverables. Each project deliverable produced should be reviewed for
quality and measured against the acceptance criteria. Once all of the deliverables have been
produced and the customer has accepted the final solution, the project is ready for closure.
7.4 Closing phase
During the final closure, or completion phase, the emphasis is on releasing the final
deliverables to the customer, handing over project documentation to the business, terminating
supplier contracts, releasing project resources and communicating the closure of the project to all
stakeholders. The last remaining step is to conduct lessons learned studies; to examine what went
well and what didn't. Through this type of analysis the wisdom of experience is transferred back
to the project organization, which will help future project teams.
Page 52 of 135
Chapter 2
The Life Cycle of a Project
Once one has a clear vision for a research topic, the next step is to develop
a project, planning the outlines of the work that will be needed to reach the
desired goals and outcomes. Another class of research-related project for
which planning is critical is in the development of research infrastructure,
such as the commissioning of major equipment.
Once funding has been secured, detailed planning for the project needs
to start in earnest, taking into account the resources available over the
time frame of funding. If, for example, new staff have to be recruited, it
helps to have made the necessary preparations so that the human resources
processes can be set in train as soon as funding is available.
There are well-developed tools to aid project management, and these can
be beneficial in a research context. It takes some effort to learn how to use
the tools and to set them up, but the return is a much clearer understanding
of dependencies, and the critical points of interaction between the different
components of a project.
19
The Life Cycle of a Project
20
2.1 Developing a new project
21
The Life Cycle of a Project
the research case more convincing. You still have to ‘sell’ the importance
and need for the scientific component in order to secure the funding.
The proposal has to conform to the rules of the funding agency, and
this will place restrictions on the nature of acceptable budget items and
allowable time frames. It may be necessary to put forward only part of
a broad research program to stay within the bounds of what might be
supported. In this case, prior planning should make the order of program
components clear.
It is also important to keep track of the funding policy of the agencies to
which submission is being made. Where funded amounts are regularly
much less than requests, extra effort or proposals may be needed for a
project to proceed in full.
• Project funded
In these days of high competition for research funding, it is likely that
multiple proposal submissions are needed to secure funding. Where
feedback is supplied it is critical that this be incorporated into the
proposal, and the implications for the overall project plan understood.
When funding is secured, the requirements are to bring the project into
action to achieve the research goals. The nature of what can be achieved
will be dictated by the level of funding, and the research plan must be
revisited for implementation.
• Working project plan
Now the project is about to start, the project plan needs to be revisited in
the light of the prevailing circumstances, particularly the available level
of funding. It may be necessary to reduce the scope of the work from
what was desired, to accommodate a shorter time period, or less money.
Advance planning makes such decisions easier, if not more palatable.
It is useful to retain the original project plan for reference, but now the
time line and resources need to be reworked to form the basis for the way
ahead.
Over the course of a project, external and internal circumstances can
change, and so the plan may well need to be updated during the course
of the work. Effective research management needs to recognise how the
project is developing, and remain flexible to secure the best outcomes.
• Reporting, publications and presentations
Keep note of any reporting requirements and build these into the
working time line. Early in the project it is worth sketching out the
expected presentations at conferences etc., and which members of the
research group will be responsible. Presentation material can frequently
form a good base for the preparation of publications.
The final report on a funded project generally requires a summary of
what has been achieved. It is worthwhile to look back on the project plan
22
2.1 Developing a new project
at this stage and reflect on how far the forward planning matched with
actual progress. This step will aid the development of the next project.
• Lessons
Often you will find that the research has developed different aspects
than expected at the beginning, and rather than answering the questions
posed, you have opened up a new group of issues. This is part of the
excitement of research; the outcomes can be unexpected. It is important
to not force rigid adherence to a plan, except where funding is tied to
specific outcomes, but to adapt to circumstances.
The experience from one project then feeds into the creation of the next,
23
The Life Cycle of a Project
and what has been learnt from tracking the progress of a project will help
improve the next plan.
We can summarise the stages of the research project between concept and
completion in the form of a flow chart, as shown in Figure 2.1.
Exercise 2-1:
Prepare an outline project plan for your current project that summarises
goals and expectations together with the time frame for the major elements.
24
2.2 Building a research proposal
create a short informal proposal with the aim of summarising the aims of
the project and the way in which it will be tackled. This informal proposal
material will be found to be valuable as a summary of initial thinking,
and as a means of developing a project plan with appropriate organisation
of activity. Even if external funding does not have to be sought, there
will be a need to achieve the project goals. Such material provides a
succinct representation of the project, which is valuable when planning
future directions
The way in which these elements are represented in the research proposal
will depend on the requirements of the funding scheme. Often length
restrictions are imposed on the various sections of the proposal and so brief,
but clear, exposition is at a premium.
In addition, information will be sought on the scientific record of the
potential participants, including such items as employment history and
publications. In some cases the applicant makes a separate statement about
the way in which their research experience benefits the project; in others
this will form part of the scientific component.
Alongside the scientific and personal elements, the proposed budget will
have to be presented, with justification for the various elements. This
budget needs to include both the components requested from the funding
agency, and funding available from other sources. Normally the budget
information is available to reviewers, but in some cases may be in a
separate document that is considered only when the science review has
been completed.
Increasingly, proponents are expected to point to the way in which the
work proposed can provide broader societal and economic impacts. In
25
The Life Cycle of a Project
26
2.2 Building a research proposal
results of the review processes are then moderated by a panel. The panel
may then be involved in the funding and budget decisions, but in some
cases these are made separately based on a ranking list prepared by a panel.
27
The Life Cycle of a Project
28
2.3 Submitting a proposal
29
The Life Cycle of a Project
Scientific justification
This is the main component of the proposal where a clear research goal
and plan have to be expressed. It is here that the effort expended in
developing a working plan for a research topic will be repaid. If the concept
of the work has already been well developed with a clear expression of
questions, hypotheses, and outcomes, then this can be built directly into the
justification for the proposed work. This section is normally subject to fixed
length limits and may also have prescribed structure. For example, Box 2.1
shows the required headings for the Australian Research Council (ARC)
Discovery Scheme for 2013, together with the class of material that should
appear in each section. This list gives a good indication of the topics that
should be addressed in proposals, even where a more free form structure is
allowed.
Budgets
The way in which budgetary information is handled varies markedly
between schemes. Sometimes the budget is incorporated with the research
plan, but frequently it is in a separate section. A standard budget form
may be required or entries made in an electronic spreadsheet. Where
30
2.3 Submitting a proposal
The guidelines for the Starting Grants of the European Research Council
provide a useful summary of expectations with respect to the expression
of the objectives of the project and necessary background, as well as the
project plan:
31
The Life Cycle of a Project
Note that it is expected that the project plan be dynamic, and therefore able
to adjust to the nature of earlier results. It is not a weakness to anticipate
critical points in the work schema, and to have alternative modes of attack
depending on outcomes.
32
2.4 Proposal review
33
The Life Cycle of a Project
34
2.4 Proposal review
Exercise 2-2:
Prepare a personal profile in the style required by your preferred funding
agency. In some cases this may constitute a simple curriculum vitae, but
others will have a more complex structure; e.g., including your best 10
papers with reasons for the choice.
Exercise 2-3:
Obtain a copy of a submitted proposal in a field different to your own and
prepare a review based on the appropriate criteria for your preferred funding
scheme, with both numerical scores and written comments (use a 1-5 scale,
with 5 best).
This exercise is most effective if you can exchange and critique proposals
with colleagues from another field.
35
The Life Cycle of a Project
36
2.6 Project completion
Whatever the future state, you still have obligations to fulfil on the
current project. Commonly a final report has to be rendered to the
funding agency detailing the work achieved, the research outputs such as
publications, and data management. This is the stage at which you will
be trying to exploit the work achieved through conference presentations
and publications with a broader overview. Good record keeping through
the project, and thorough metadata attached to experimental results or
simulation procedures, will aid the process of producing these major
outputs.
The other step at the end of a project is the finalisation of financial
accounts, so that expenditure is fully justified. Since financial reporting
may well take a different path through an institution than the handling
of research reports, you will have to ensure that necessary communication
occurs. Many people’s experience indicates that this is not something you
can take for granted.
37
See discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/254423929
Article
CITATIONS READS
6 794
2 authors:
Some of the authors of this publication are also working on these related projects:
Electric load scheduling with a novel dynamic pricing scheme View project
All content following this page was uploaded by Goutam Dutta on 06 May 2015.
Debasis Sarkar
Goutam Dutta
The main objective of the working paper series of the IIMA is to help faculty members,
research staff and doctoral students to speedily share their research findings with professional
colleagues and test their research findings at the pre-publication stage. IIMA is committed to
maintain academic freedom. The opinion(s), view(s) and conclusion(s) expressed in the
working paper are those of the authors and not that of IIMA.
Abstract
In this paper, we discuss a method of measurement of project risk, based on the expected
value method (EVM). Project risk management primarily comprises cost and schedule
uncertainties and risks associated with each activity of the project network. We have
identified the major risk sources and quantified the risks in terms of likelihood, impact
and severity in a complex infrastructure project for the construction of an underground
corridor for metro railways. A case study of the underground metro corridor in the
capital city of an emerging economic nation of South Asia has been considered for this
research work. The methodology for this work was the response from the experts
associated and involved in this and other similar projects in metro rail. The risk analysis
for the determination of risk cost, risk time, expected cost and expected time of the
project has been carried out by the expected value method. Based on this study we find
that the project cost overrun and time overrun can be about 22.5 % and 23.4 %
respectively, if we use the expected value method.
1
Associate Professor, CEPT University, Ahmedabad
2
Professor, Indian Institute of Management, Ahmedabad. Email: goutam@iimahd.ernet.in
1. Introduction
The major activities in underground corridor construction consist of feasibility studies, design,
traffic diversion, utility diversion, survey works, shoulder piling and king piling works, timber
lagging works, soil and rock excavation, construction decks, steel struts, rock anchors, sub-
floor drainage, waterproofing, permanent structure works, mechanical and electrical
installations, backfilling and restoration works. We have developed a questionnaire survey
and personally interviewed experts from the underground corridor project. In this process, we
have identified the risks at various phases of the project starting from the feasibility phase to
the completion of the project. Then we have used the expected value method (EVM) to
compute the effect of risky sources in terms of their impact and severity and also the overall
effect on the project time and cost.
This paper is organized as follows. In section two, we discuss the review of related literature.
In section three, we narrate the case study. In section four we discuss the methodology, which
is based on the work of Roetzheim (1988) and Nicholas (2007). In section five we analyze the
case by applying the EVM model to the underground metro construction project. We have
also demonstrated the application of the Monte Carlo simulation on the risk management
methodology to predict the expected time and cost of the project. Finally, in section six we
discuss the conclusion and scope for future research.
2. Literature survey
Risk can be defined as a measure of the probability, severity and exposure to all hazards for
an activity (Jannadi and Almishari, 2003). For an infrastructure project there is always a
chance that things will not turn out exactly as planned. Thus project risk pertains to the
probability of uncertainties of the technical, schedule and cost outcomes.
Williams, Walker and Dorofee (1997) worked on developing methods by which risk
management could be put into practice. Their methods were based on software intensive
programs (SEI) along with which specific road maps were designed. These could guide and
help identify various risk management methods which could be easily put into practice.
Complex projects like the construction of an underground corridor for metro rail operations
involve risks in all the phases of the project starting from the feasibility phase to the
operational phase. These risks have a direct impact on the project schedule, cost and
performance. Reilly (2005), Reilly and Brown (2004), Sinfield and Einstein (1998) carried out
their research on underground tunnel projects. Reilly and Brown (2004) state that
infrastructure underground projects are inherently complex projects with many variables
including uncertain and variable ground conditions. As per Reilly (2005), for a complex
infrastructure project like underground construction, it is very important to identify the risk
events in the early phases of the project. A proper risk mitigation plan, if developed for
identified risks, would ensure better and smoother achievement of project goals within the
specified time, cost and quality parameters. Further, it would also ensure better construction
safety throughout the execution and operational phase of the project.
Mulholand and Christan (1999) explain that due to the complexity and dynamic environments
of construction projects, certain circumstances are created which result in a high degree of
uncertainty and risk. Often these risks are compounded by demanding time constraints. Dey
(2001) developed an Integrated Project Management Model for the Indian petroleum industry
where he incorporated risk management into the conventional project management model and
cited it as an integral component of project management. But Dey (2001) carried out the risk
analysis by finding out the respective likelihoods of the identified risks which were found to
have a summation of 1 for the respective work packages on a local percentage (LP) basis. The
summation of the likelihoods of all the concerned work packages was found to be equal to 1
on a global percentage (GP) basis. Nehru and Vaid (2003) carried out the risk analysis with
similar concepts. As per Roetzheim (1988) as quoted by Nicholas (2007), the likelihood of the
identified risks can have a value ranging from 0 to 1, which indicates a 0% or a 100% chance
of occurrence. But the weightage associated with all risk sources for a work package / activity
is always equal to 1. The product of the likelihood and the respective weightages is equal to
the cumulative likelihood factor (CLF).
Dey and Ogunlana (2002) describe that conventional project management techniques are not
always sufficient to ensure time, cost and quality achievement of a large scale construction
project, which may be mainly due to changes in scope and design, changes in government
policies and regulations, unforeseen inflation, underestimation and improper estimation. Such
projects which are exposed to such risks and uncertainties can be effectively managed with
the application of risk management throughout the projects’ life cycle. Dey (2002) developed
a tool for risk analysis, also through the analytic hierarchy process (AHP) which is a multiple
attribute decision making technique and decision tree approach. Rahman and Kumaraswamy
(2002) carried out their research on joint risk management (JRM). Moreover, they generally
preferred to assign reduced risks from either one or both contrasting parties to JRM, rather
than shifting more risks to the other party. This is indicative of the fact that more collaborative
effort and team based work can reduce the risk component of a project. Jannadi and Almishari
(2003) developed a risk assessor model (RAM) for assessing the risk associated with a
particular activity and tried to find out a justification factor for the proposed remedial
measure for risk mitigation. Ward and Chapman (2003) in their research work made an
argument indicating that all current project risk management processes induce a restricted
focus on the management of project uncertainty. Zoysa and Russel (2003) developed a
knowledge based approach for risk management. According to them effective risk
management is a function in the successful planning and execution of large infrastructure
projects.
3. Case study
The project considered for analysis is the construction of an underground corridor for metro
rail operations in the capital city of an emerging economic nation in South Asia. Phase-I of
the project is about 65 kms with 59 stations. The estimated capital cost of Phase-I is about
INR 105 billion. The project under study for this research work is a part of Phase I. The scope
of work is the design and construction of a 6.6 km underground metro corridor with six
underground stations and a twin tunnel system. The underground stations are referred to as S1,
S2,…. S6. Here S6 is the terminal station equipped with an over-run tunnel (where an up train
can be converted to a down train). The client is a public sector company floated jointly by the
State and Central Government. The principal contractor is a Joint Venture (JV) of three
foreign contractors and two domestic contractors. The type of contract is a Design Build
Turnkey (DBT) where the principal contractor is required to design the underground corridor
and execute the project. The project cost for the execution of 6.6 kms is about INR 18 billion.
The contract period is about five years (exclusively for execution). The feasibility phase of the
project is an additional five years. The activity chart of the sample stretch under analysis
consisting of the tunnel connecting two stations S5 and S6, S6 station box and the over-run
tunnel succeeding S6 station box is provided in Table 1. The corresponding network diagram
is given in Figure 1. Some additional project details are furnished in Appendix 1.
Table 1: Major Activities and their Time Estimates in the Underground
Corridor Construction Project (Terminal Station S6)
Activity Description Immediate Duration
Predecessors (Days) ES EF LS LF
A Feasibility studies - 1875 0 1875 0 1875
B Design A 295 1875 2170 1985 2280
C Technology selection A 90 1875 1965 1875 1965
D Traffic diversion B,E 475 2280 2755 2280 2755
E Utility diversion C 315 1965 2280 1965 2280
F Survey works B,E 290 2280 2570 2821 3111
G Shoulder / King piles D 356 2755 3111 2755 3111
H Timber lagging C 240 1965 2205 2871 3111
I Soil excavation G,F,H 330 3111 3411 3111 3441
J Rock excavation L,R 165 2655 2820 3276 3441
K Fabrication and erection of C 170 1965 2135 2941 3111
construction decks
L Fabrication and erection of steel struts C 690 1965 2655 2421 3111
M Rock anchor installation N,O 285 2280 2565 3156 3441
N Shotcreting & rock bolting L,R 120 2655 2775 2871 2991
O Subfloor drainage Q 170 2110 2280 2821 2991
P Water proofing I,K,J,M 120 3441 3561 3441 3561
Q Diaphragm wall construction C 145 1965 2110 2604 2749
R Top down construction Q 122 2110 2232 2749 2871
S Permanent structure N,O 570 2280 2850 2991 3561
T Mechanical / Electrical installations & P,S 225 3561 3786 3561 3786
services
U Backfilling & restoration works N,O 225 2280 2505 3561 3786
ES: Early Start; EF: Early Finish; LS: Late Start; LF: Late Finish
4. METHODOLOGY
Base time estimate (BTE) of the project is the estimated basic project duration determined by
critical path method of the project network. Similarly, the estimated basic cost of project
determined by the cost for each activity is termed as the base cost estimate (BCE). The BTE
and BCE data of all the major activities of the project have been obtained as per the detailed
construction drawings, method statement and specifications for the works collected from the
project. The corresponding corrective time (CT) or the time required to correct an activity in
case of a failure due to one or more risk sources for each activity and their corresponding
corrective cost (CC) have been estimated based on the personal experiences of the first author
and have been tabulated. An activity may have several risk sources each having its own
likelihood of occurrence. The value of likelihood should range between 0 through 1. The
likelihood of failure (Lij) defined above, of the identified risk sources of each activity were
obtained through a questionnaire survey. The target respondents were experts and
professionals involved in and associated with the project under analysis and also other similar
projects. The corresponding weightage (Wij) of each activity has also been obtained from the
feedback of the questionnaire survey circulated among experts. The summation of the
weightages should be equal to 1.
M
The weightages can be based on local priority (LP) where the weightages of all the sub-
activities of a particular activity equal 1. Also, weightages can be based on global priority
(GP) where the weightages of all the activities of the project equal 1. The mean of all the
responses should desirably be considered for analysis. Inconsistent responses can be modified
using a second round questionnaire survey using the Delphi technique. The next step is to
compute the risk cost (RC) and risk time (RT) of the activities of the project. RC and RT for
an activity can be obtained from the following relationship:
Risk Cost for activity j (RC)j = (CC)j x Lj for all j. …… (2)
Risk Time for activity j (RT)j = (CT)j x Lj for all j …… (3)
The total risk time for an activity is the summation of the risk time of all the sub activities
along the critical path.
The likelihood (Lij) of all risk sources for each activity j can be combined and expressed as a
single composite likelihood factor (CLF)j. The weightages (Wij) of the risk sources of the
activities are multiplied with their respective likelihoods to obtain the CLF for the activity.
The relationship of computing the CLF as a weighted average is given below:
M
M
0 ≤ Lij ≤ 1 and ∑ Wij = 1 for all j
i =1
The impact of a risk can be expressed in terms of the effect caused by the risk to the time and
cost of an activity. This time impact and cost impact can be considered as the risk time and
risk cost of the activity. A similar computation as that of likelihood can be done for obtaining
a single combined composite impact factor (CIF) by considering the weighted average as per
the relationship given below:
M
0 ≤ Iij ≤ 1 and ∑W
i=1
ij = 1 for all j.
Risk consequence or severity can be expressed as a function of risk likelihood and risk
impact. Thus the numerical value will range from 0 to 1. This severity can also be expressed
in terms of qualitative rating as “no severity” for value 0 and “extremely high severity” for
value 1. The numerical value of the Risk Severity (RS) is obtained from the below mentioned
relationship:
Risk Consequence / Severity (RS)j = Lj x Ij for all j ….. (6)
The risk consequence derived from this equation measures how serious the risk is to project
performance. Small values represent unimportant risks that might be ignored and large values
represent important risks that need to be treated.
The expected cost (EC)j and expected time (ET)j for each project activity and subsequently
the computation of the expected project cost and time was carried out from the concept of
the expected value (EV) of a decision tree analysis.
Expected value (EV) = probability of occurrence (p) [higher payoff] + (1-p) [lower payoff].
BTEj + CTj
Lj BCEj + CCj
Lj CTCT
BCEj BTEj
(1-Lj) (1-Lj)
5. CASE ANALYSIS
The sample stretch under analysis consists of a 530 metre(m) cut and cover tunnel connecting
station S5 and S6, a 290m S6 station box and a 180m cut and cover over run tunnel adjoining
the S6 station box. S6 station being the terminal station, the down trains towards this station
after leaving station S5 will travel through the 530m cut and cover tunnel and enter the
platforms of the terminal station S6. After the commuters vacate the train at this terminal
station, this down train will travel through the 180m over run tunnel and will be converted
into an up line train which will travel from station S6 to S1.
The activities of the sample stretch under analysis consist of the installation and erection of
temporary supporting and retaining structures to enable construction by cut and cover
technology and for the construction of permanent structures like tunnels and station boxes
which are RCC single boxes / twin boxes for tunnels and RCC boxes with intermediate
concourse slab for station boxes.
We have considered some basic assumptions during the analysis. These assumptions are (i)
the maximum cost overrun permissible is 25 % of the basic cost estimate beyond which the
project becomes less feasible and (ii) the maximum permissible time overrun for
infrastructure projects is about 30% of the base time estimate, beyond which the feasibility of
the project reduces.
The common risk sources identified for all the activities A …. U as per Table 1 and Figure 1
are listed in Table 3 and a detailed description of the same is furnished in Appendix 2
The risks identified under each activity have been listed and a detailed questionnaire
consisting of all the identified risks as per the classification stated above has been framed.
This questionnaire was circulated amongst 67 experts having adequate experience in
underground construction projects or similar infrastructure projects. These experts were
required to respond with respect to the likelihood of occurrence and the weightages associated
with each risk based on their experience. The methodology for receiving the filled up
questionnaires from the respondents was through personal approach, telephonic conversation,
e-mails and post. The experts were Designers, Consultants, Deputy Project Leaders, Project
Managers, Deputy Project Managers, CEOs, Managing Directors, Area Managers, people in
charge of Quality assurance / Quality control, and Safety, Senior Engineers and Project
Engineers of the principal contractor of the above project, the client organization, the
consulting organization, major sub-contractors of the above project and other ongoing metro
rail projects within the country. Of around 67 experts, 45 had responded to this study and the
mean of all the responses of respective risk likelihoods and their associated weightages in the
related activities have been considered. The inconsistent responses were revised by
conducting a second round questionnaire survey using the Delphi technique.
A sample of a part of a filled up questionnaire consisting of the likelihood of risks and the
weightage associated with the identified risks for the feasibility project risk (FPR) is presented
in Appendix 3. The value of likelihood (Lij) varies from 0 to 1 and the sum of the weightages
(Wij) on local priority (LP) basis is 1 (0.121+0.185+0.155+0.295+0.075+0.169). The
M
corresponding Composite Likelihood Factor (CLF)j = ∑
i =1
Lij Wij for all j (j = 1…. N) =
Similar tables have been formulated for pre-execution project risk (PEPR 1 and PEPR2) and
execution project risk (EPR 1 to EPR 18).
The network diagrams consisting of the major activities of the project have been drawn and
their activity times (early start, early finish, late start and late finish) have been calculated by
forward and backward pass and then their critical path has been tracked out. The duration
along the critical path is the longest duration path and is considered as the duration of the
project. The BCE and BTE of each activity and sub-activity of the project have been
calculated as per the actual site data. The corrective cost and time for each activity have been
assumed as a certain percentage (25% to 75%) of BCE and BTE respectively depending upon
the severity and casualty caused by that risk.
Each activity of the project as presented in figure 1 has been analyzed at the sub-activity level
for computation of RC, RT, EC, ET and risk severity. The detailed analysis for computation
of risk cost and time for all the activities of the project is presented in Table 4.
Base
Corrective Risk Base Corr- Expected
Cost Risk EC % ET %
Cost Cost Time ective Cost Expected
Estimate Time Higher Higher
Activity (CLF)j (CC)j (RC)j Estimate Time (EC)j Time
(BCE)j (RT)j than than
INR. INR (BTE)j (CT)j INR (ET)j
INR Days BCE BTE
Million Million Days Days Million Days
Million
A 0.348 240 60 20.88 1875 1130 393.24 260.88 2268.24 8.7 20.97
B 0.356 110 32 11.392 295 245 87.22 121.392 382.22 10.36 29.57
C 0.27 40 10 2.7 90 85 22.95 42.7 112.95 6.75 25.5
D 0.319 50 11.9 3.7961 475 355 113.25 53.7961 588.25 7.59 23.84
E 0.262 100 82.4 21.5888 315 267 69.95 121.5888 384.95 21.59 22.21
F 0.186 10 8.66 1.61076 290 247 45.94 11.61076 335.94 16.11 15.84
G 0.28 220 176.465 49.4102 356 356 99.68 269.4102 455.68 22.46 28
H 0.252 20 15.975 4.0257 240 180 45.36 24.0257 285.36 20.13 18.9
I 0.377 150 122 45.994 330 205 77.29 195.994 407.29 30.66 23.42
J 0.419 80 56 23.464 165 140 58.66 103.464 223.66 29.33 35.55
K 0.398 120 108 42.984 170 113 44.97 162.984 214.97 35.82 26.46
L 0.367 300 245 89.915 690 485 178 389.915 868 29.97 25.8
M 0.345 50 49.2 16.974 285 250 86.25 66.974 371.25 33.95 30.26
N 0.343 80 70.3 24.1129 260 185 63.46 104.1129 323.46 30.14 24.41
O 0.306 60 58 17.748 170 130 39.78 77.748 209.78 29.58 23.4
P 0.384 120 83.2 31.9488 120 95 36.48 151.9488 156.48 26.62 30.4
Q 0.278 60 59.2 16.4576 145 115 31.97 76.4576 176.97 27.43 22.05
R 0.227 80 77.2 17.5244 122 88 19.98 97.5244 141.98 21.91 16.37
S 0.223 800 596.5 133.0195 570 415 92.55 933.0195 662.55 16.63 16.24
T 0.398 300 217.7 86.6446 225 180 71.64 386.6446 296.64 28.88 31.84
U 0.354 250 189.3 67.0122 225 163 57.7 317.0122 282.7 26.8 25.65
3240 2329 729.20256 3786 884.47 3969.2026 4670.47 22.51 23.36
Note: Base time estimate and Risk time is considered as the time estimate along the critical path
(refer Figure 1)
As per Figure 1 which represents the critical path diagram of the entire project of the
underground corridor construction, and Table 4, for activity A (feasibility studies) the CLF is
0.348 as obtained from the feedback of the questionnaire survey (refer appendix 2). The base
cost estimate (BCE)j for the activity feasibility studies (A) is INR 240 Million, the corrective
cost (CC)j is INR 60 Million (assumed in consultation with experts); the base time estimate
(BTE)j is 1875 days; the corrective time (CT)j is 1130 days (assumed in consultation with
experts).
As per equations (2) and (3), Risk cost (RC)j = 0.348 x 60 x 106 = INR 20.88 x 106; Risk time
(RT)j = 0.348 x 1130 days = 393.24 days. Thus as per equations (7) and (8), the expected cost
(EC)j = BCEj + RCj = INR 260.88 Million, expected time (ET)j = BTEj + RTj = 2268.24
days.
A similar computation has been carried out for activities B, C, D….. and U (refer Table 4).
Henceforth, the expected cost (EC)project of the entire project of underground corridor
construction has been calculated as follows:
U
Expected Cost (EC)Project = ∑
j =A
ECj
Table 5: Project Expected Cost and Time Analysis [Based on Questionnaire Survey]
Base Cost Risk Cost Base Time Risk Time Expected Cost Expected
Estimate (INR Estimate (Days) (INR Time
(INR Million) (Days) Million) (Days)
Milion)
Thus as per the analysis, the EC of the project is 22.51 % higher than the BCE of the project.
The ET of the project is 23.36 % higher than the BTE. As per the basic assumptions
considered for risk management analysis the cost overrun should not exceed 25% of the
estimated base cost and the time overrun should not be more than 30% of the estimated base
time. Exceeding these limits would increase the chances of the project becoming less feasible.
The risk management analysis predicts that the expected cost of the project is 22.51% higher
than the estimated base cost. This situation is highly alarming as it is the upper limit of the
permissible cost overrun. It requires meticulous planning and proper risk mitigation measures
to enhance the probability of success of the project. The expected time predicted from the
analysis is 23.36% higher than the estimated base time which is close to the upper limit of the
permissible time overrun. Thus it is essential to judiciously follow the risk mitigation
measures to ensure that the project is completed within the scheduled time frame.
Risk severity can be computed from equation (6). The product of the likelihood and impact of
a risk can be considered as the severity of that risk. This concept can be extended for multiple
risk sources in a work package, the likelihood and impact of which can be expressed in terms
of CLFj and CIFj respectively. Thus for the underground corridor construction project, the risk
severity of each major activity of the project is computed as presented in Table 6.
The scale for the classification of the risk severity is expressed as
Severity Classification
0.00 – 0.02 V. Low
0.03 – 0.05 Low
0.06 – 0.15 Medium
0.16 – 0.20 High
0.21 – 1.00 V. High
Table 7: Risk Severity Analysis of Total Project using the Concept of Composite
Likelihood Factor (CLF) and Composite Impact Factor (CIF)
The risk severity analysis has also been carried out by PERT analysis and the outcome of both
the EVM and PERT analysis in terms of the severity of the major activities of the project is
presented in Table 8
Table 8: Outcome of Risk Severity analysis by Expected Value and PERT
V. High High Medium Low
Design Technology selection Traffic diversion Top down Survey Backfilling & Nil
Utility diversion Soldier construction Timber lagging Restoration
Piles King Piles Mechanical & Electrical
Soil / Rock excavation Works, Permanent Structure
Diaphragm wall
Steel struts
Rock anchors
Shotcreting and rock bolting
We apply the Monte Carlo simulation to predict the outcome of the expected time (ET) and
expected cost (EC) of all the possible paths of activities as represented in the network diagram
of the project (figure 1). The Monte Carlo simulation also takes into account the effects of the
near critical paths becoming critical. By carrying out a detailed path analysis of the project
network diagram, we observed that the path A-C-E-D-G-I-P-T has the longest duration of
3786 days. Hence this path is considered as the critical path of the project network (refer
figure 1). The corresponding cost for the completion of activities along this path is INR 1220
Million. It is also observed that the probability of the successful completion of the project
within the stipulated time and cost frame is only 4% (0.625 x 0.730 x 0.738 x 0.681 x 0.720 x
0.623 x 0.616 x 0.602 = 0.040). Path A-B-D-G-I-P-T is a near critical path with a probability
of about 4.8% for successful completion within the stipulated time and cost frame. There are
chances of this path becoming critical.
The application of the Monte Carlo simulation to the above path analysis resulted in the
following outcome:
Path Cost
Path Activity / Node duration (Rs. Crores)
(days)
1 A-B-D-G-I-P-T 3676.17 119.28
2 A-C-E-D-G-I-P-T 3785.98 122.28
3 A-C-E-F-I-P-T 3244.88 96.17
4 A-C-H-I-P-T 2879.88 87.11
5 A-C-K-P-T 2479.67 82.09
6 A-C-L-J-P-T 3164.79 108.19
7 A-C-Q-R-J-P-T 2741.60 92.20
8 A-C-Q-O-S-T 3074.89 150.10
9 A-C-Q-O-U 2504.95 65.07
From the above analysis we observed that path 2 (A-C-E-D-G-I-P-T) has the longest duration of
3785.98 days and remains critical. The corresponding cost for the completion of all the
activities along the critical path is INR 1222.8 Million. The probability of the successful
completion of path 2 or the critical path within the scheduled time is 50%. The probability of
the successful completion of the near critical path or path 1 within the scheduled time is
84.13% (Z = 1.009, P = 0.8413). Also the probability of the successful completion of all the
paths within the scheduled time is 42.05% (P = 0.8413 x 0.5 x 1 x 1 x 1 x 1 x 1 x 1 x 1 =
0.4205)
Carrying out about 10,000 runs of the Monte Carlo simulation, the EC was found to have a
value of INR 3532.9 Million and the ET of the project was found to be 4351.12 days.
Proposed Risk Management Model for the Underground Corridor Construction for
Metro Rail
The generalized risk management model for the underground corridor construction for the
metro rail is proposed on the basis of the detailed analysis carried out. This model can be
effectively implemented in the ongoing and upcoming metro rail projects across the nation.
As a part of the formulation of risk mitigation strategies, the following risk response planning
can be adapted by the project authority: (i) risk transfer, (ii) risk sharing (iii) risk reduction
(iv) risk contingency planning and (v) risk mitigation through insurance.
6. CONCLUSION
Project risk management which primarily comprises schedule and cost uncertainties and risks
should be essentially carried out for complex urban infrastructure projects such as the
construction of an underground corridor for metro rail operations. In the current research
work we found that the number of major and minor risks involved during the construction of
the project, from the feasibility to the completion of the execution, are large, and if not treated
or mitigated properly, the probability of successful completion of the project within the
stipulated time and cost frame will reduce. This will have a direct impact on the efficiency
and profitability of the organization.
As per the analysis carried out by EVM, based on the expert questionnaire survey, the
expected project cost for the sample stretch under analysis (530 m tunnel from station S5 to
S6, S6 station box and 180 m over-run tunnel) is about 22.51% higher than the base cost
estimate of the project. According to the basic assumptions made for the analytical procedure
adopted, the maximum permissible cost overrun for the project is 25%. Thus if proper project
risk management is not carried out by the authority, the project may result in a cost and time
overrun which will ultimately reduce the feasibility of the successful completion of the
project. The expected project time as obtained by the analysis is about 23.36% higher than the
base time estimate of the project, the maximum permissible time overrun as per the basic
assumptions being 30% of the base time estimate. This value is also quite alarming making
the concerned authority feel the need for carrying out proper risk management for such
complex infrastructure projects.
Hence considering the results of all the analyses carried out in this research work, it can be
concluded that for complex infrastructure projects like that of an underground corridor
construction, based on EVM, about INR 0.82 Million extra per day per station would be
incurred if proper risk management is not followed to mitigate the anticipated risks. Thus for
six underground stations for this 6.6 km underground metro corridor package approximately
INR 4.92 Million extra per day will have to be incurred by the project authorities. A major
limitation of the model adopted for analysis is that the entire model being probabilistic, the
outcome of the analysis is largely dependent on the opinion of the likelihood and weightages
of the identified risks obtained from the expert questionnaire survey. Also any sort of
misinformation provided will result in erroneous results. Although at present, a very nominal
percentage of identified risks can be insured under the existing “Contractors All Risk Policy”,
the potentiality of insurance and the means of making insurance a strong risk mitigation tool
for the construction industry provide scope for future research.
The proposed risk management model will definitely benefit the ongoing metro corridor
works and about 20 future anticipated metro projects in cities across the nation under study.
As the nation under study is an emerging economy, there are proposals for several metro rail
construction projects likely to come up in the next two decades. This study can be used as an
aid to plan for the quantitative risk management for these projects. An integrated decision
support system for underground corridor metro rail projects can also be developed based on
the risk management model. As the concept is generic, we can extend the concept to several
other types of complex infrastructure projects like highways, oil and gas refineries, airports,
bridges, nuclear, thermal and hydro power plants and other forms of mass rapid transit system
(MRTS) projects. The potentiality of insurance as a risk mitigation tool should also be
explored.
REFERENCES
Dey , P.K. (2001) “Integrated Project Management in Indian Petroleum Industry” NICMAR
Journal of Construction Management, Vol. XVI, pp. 1 – 34.
Dey, P.K. (2002) “Project Risk Management: A Combined Analytic Hierarchy Process and
Decision Tree Approach” Cost Accounting, Vol. 44, pp. 13 – 26.
Dey, P.K. and Ogunlana, S.O. (2002) “Risk based Decision Support System for Effective
Implementation of Projects” International Journal of Risk Assessment & Management Vol. 3,
pp. 189 – 204.
Nicholas, J.M. (2007) Project Management for Business and Technology: Principles and
Practice, Second edition, Pearson Prentice Hall, New Delhi.
Rahman, M.M. and Kumaraswamy, M.M. (2002) “Risk Management Trends in the
Construction Industry: Moving towards Joint Risk Management” Engineering Construction &
Architectural Management, Vol. 9(2), pp.131-151.
Reilly, J. and Brown, J. (2004) “Managing and Control of Cost and Risk for Tunneling and
Infrastructure Projects” Proceedings of International Tunneling Conference, Singapore,
pp.703 -712.
Reilly, J.J. (2005) “Cost Estimating and Risk Management for Underground Projects”
Proceedings of International Tunnelling Conference, Istanbul.
Roetzheim.W. (1988) Structured Computer Project Management, Prentice Hall, New Jersy.
Sinfield, J.V.and Einstein, H.H. (1998) “Tunnel Construction Costs for Tube
Transportation Systems” Journal of Construction Engineering & Management, Vol. 124(1),
pp.48 – 57.
Ward, S. and Chapman, C. (2003) “ Transforming Project Risk Management into Project
Uncertainty Management” International Journal of Project Management, Vol. 21(2), pp.97 –
105.
Williams, R.C., Walker, A.J. and Dorofee, A.J. (1997) “Putting Risk Management into
Practice” IEEE Software Vol. 3, pp.75 –81
Zoysa, S.D. and Russel, A.D. (2003) “Knowledge Based Risk Identification in Infrastructure
Projects” Canadian Journal of Civil Engineering, Vol.30 (3), pp.511 – 522.
Weightage Impact
Likelihood
Risk Description (LP) (Iij)
(Lij)
(Wij)
Delay in submission of preliminary feasibility report 0.65
0.15 0.029
Delay in approval for carrying out detailed feasibility study 0.75
0.20 0.030
Delay in preparation and submission of detailed project report 0.85
0.20 0.018
(DPR)
Delay in approval of DPR 0.90
0.30 0.044
Total
CLF = 0.027
0.121
CIF = 0.096
Political interference
0.55 0.013 0.9
Delay in finalizing temporary rehabilation schemes
0.4 0.055 0.85
Public interference for changing the alignment
0.25 0.055 0.9
Interference of environmental activists
0.4 0.012 0.9
Delay due to interdepartmental issues
0.35 0.03 0.9
Delay in construction of diversion roads for existing traffic
0.2 0.014 0.85
Problems with the physical possession of land
0.65 0.116 0.95
Total:
CLF = 0.136
0.295
CIF = 0.264
FPR 5: Financial Closure Risks
● Systems Theory
● Contingency View
Open versus closed systems. According to Ludwig von
Bertlanffy, there are two basic types of systems: closed systems
and open systems. Closed system are not influenced by and do
not interact with their environments. Open systems interact with
their environment. All organizations are open systems, although
the degree of interaction may vary.
Synergy. Synergy means that the whole is greater the sum of its
parts. Synergy is an important concept for managers in that it
reinforces the need to work together in a cooperative fashion.
Each part has some role to perform so that the whole can
accomplish its purpose.
Exhibit 2.5, p. 58
Contingency View of Management
On the next page is an example of a gantt chart. The first column allows you to record the task that needs to be
completed. You then shade the box in on that row which corresponds with when you plan to complete the task. You
can assign responsibility for given tasks by recording who will deliver them in the owner column and record any
additional notes which may be useful in the notes column. This allows you to see the whole project at a glance and see
what should be happening when. You may wish to add additional columns, for example stakeholders, like the example.
You can
download a
blank
template from
this module
Gantt Charts
RESOURCE ALLOCATION METHODS
Assumptions
available requires some limiting assumptions to
Ease of demonstrating the allocation methods
The rest of the chapter depends entirely on the
keep attention on the heart of the problem. allowed. 'This means once an activitv
assumptions noted here. First, splitting activities will not be
1s placed in the schedule, assume it will be worked on
continuously until it is finished; hence, an
and then finished. Second, the level of
activity cannot be started, stopped for a period of time,
resources used for an activity cannot be changed.
These limiting assumptions do not exist in
to deal With the reality of
practice, but simplify learning. It is easy for new project managers
meet them on the job.
splitting activities and changing the level of resources when they
Design
Layout& 2 Bh
scarify
1 Bh
Walkways
1 Bh
Lighting
Irrigation Bh
Fence&
walls 2 Bh
Planting 3 Bh
2 4 6 8 10 12 14 16 18 20 22 24 26 28 30
1 Bh
1 Bh
Number of2
backhoes
2 Bh 2 Bh 3 Bh
required
1 Bh
4 6 8 10 12 14 16 18 20 22 24 26 28 30
Smoothed 1 Bh
number of
backhoes
required Bh 1 Bh 2 Bh 3 Bh
2
1 Bh
10 12 14 16 18 20 22 24 26 28 30
2 4 6 8
the project also increases because slack reduction can create more critical
activities delaying
activities
and/or near-critical activities. Pushing leveling too far for a perfectly level resource
Resource-Constrained Projects
When the number of people and/or equipment is not adequate to meet peak demand requirements
and it is impossible to obtain more, the project manager faces a resource-constrained problem
Something has to give. The trick is to prioritize and allocate resources to minimize project delay
without exceeding the resource limit or altering the technical network relationships.
The resource scheduling problem is a large combinatorial one. This means even a modest-size
solutions. A
project network with only a few resource types might have several thousand feasible
few researchers have demonstrated optimum mathematical solutions to the resource allocation
problem but only for small networks and very few resource types (Arrow and Hurowicz, 19[
Talbot and Patterson, 1979; Woodworth and Shanahan, 1988). The massive data requirements 1or
larger problems make pure mathematical solutions (e.g., linear programming) impractIca
alternative approach to the problem has been the use of heuristics (rules of thumb) to solve large
for may
combinatorial problems. These practical decision or priority rules have been in place
years.
Heuristics do not always yield an optimal schedule, but they are very capable of yieldng
rent
good schedule for very complex networks with many types of resources. The efficiency or u ever,
rules and combinations of rules has been well documented (Pascoe, 1965; Fendly, 1968). How
because each project is unique, it is wise to test several sets of heuristics on a network to detau
today
the priority allocation rules that minimize project delay. The computer software avala0 t. A
makes it very easy for the project manager to create a good resource schedule for the proj
e not
which activities are allocated resources and which activities are delayed when resources a
adequate.
Cheduling Resources and sts 429
Period Action
6-7 Activities 2, 5, and 6 are eligible with slack of -2, 2, and 0, respectively.
Load activity 2 into schedule (rule 1).
Because activity 6 has 0 slack, it is the next eligible activity.
Load activity 6 into schedule (rule 1).
The programmer limit of 3 is reached.
1.
Update: ES 7, slack
activity 5.
=
Delay
1-8 Limit is reached. No programmers available.
0.
Delay activity 5. Update: ES 8 , slack
=
10-11 Delay
Activity 5 is eligible.
Load activity 5 into schedule.
(Note: Activity 6 does not have slack because there are no programmers avalable- 3 maximum.)
11-12 No eligible activities.
12-13 Activity 7 is eligible.
Load activity 7 into schedule.
430 Project Management
22 8
4 6 10 6 5 8
2 1P2
8 2 10 10 7 12
1P
o 2P 0 02P0
o22 246 6 6 10o 10 212
0 1P 0
Legend
2 4 4 6 4 10
ES ID EF
6 1P 6 sL RES SL
RI2 10 LS DUR LF
5 1P 2
6 10 2
6 6 1P 4 6 10
7 1P 2 10 12
Total resource load 2P 2P 5P 5P 4P 4P 4P 4P 1P 1P 1P
1P
Resource-constrained schedule through period 2-3
ID RES DUR ES LF SL O 1
2 4 5 6 7 8 9 10 11 12 13 14
1 2P 2 02 o2 2
2P 6 10
-
|3 2P 6 0
22
41P 2 2 10 6
5 1P 2 6 10 2
6 1P 4 6 100
7
1P 2
10 12 0
Total resource load 2P 2P 3P 3P 2P 2P
Resource available 3P 3P 3P
3P 3P
3P 3P 3P 3P 3P 3P 3P
o 2
2 6 5236 012N210
A-2
3 2P 4 2 6 0
22
1P 2 2 10 6
10 2
5 1P2|6
6 1P 4 6 10
1P
1P 22 ON 3
12 142|
Total resource load 2P 2P 3P 3P2P 2P
Resource available 3P 3P 3P 3P 3P 3P 3P 3P 3P 3P 3P 3P
33 6 0 2P
42 22 22
41P2 2 6 2 SLSL SL
678 O210| x X1
55 1P
22 9 10 12 2
6 1P4 6 10 0
7 1P 2
12 14 -2
Total resource load 2P 2P 3P 3P 2P 2P 3P 3P 3P 3P 3P 3P1P 1P
Resource available 3P 3P 3P 3P 3P 3P 3P 3P 3P 3P 3P | 3P 3P 3P
o 2P
e12 10 5 12
0 1P 0
Introduction
Editor's Note: We liked so much of this book that we asked for the author's permission to quote
extensively from the whole of Jason Westland's Chapter 1. This is because it succinctly describes what
follows in detail in the remainder of the book. However, in pursuing our regular book review structure,
we placed his text under corresponding headings. Since the quotations are so extensive, we have not
followed our normal practice of indenting quoted paragraphs. However, the references are identified in
the footnotes.
As Jason says:
"Welcome to The Project Management Life Cycle. This book describes the Methodl23® Project
Management Methodology (MPMM)1 and provides a practical approach to managing projects. Every
phase, activity and task in the project life cycle is described here in detail to help you manage staff,
customers and suppliers efficiently. By reading this book, you will gain the knowledge and confidence
required to properly initiate a project, create detailed project plans, build high quality deliverables,
monitor and control delivery and close projects effectively.
"Not only will you learn how to successfully complete projects from end to end, but you will also be
armed with a suite of tools and templates to allow you to create project deliverables quickly and easily.
More than 150 charts, tables and diagrams are included in this book to help explain the steps needed to
undertake a project. Each table is full of real life examples to provide you with the knowledge needed to
complete project activities faster than before."2
Book Structure
The book structure is very simple, yet it covers a lot of ground in only 237 pages. Jason explains it as
follows.
"As there are four phases within the project life cycle, there are four main chapters in this book. Each of
these chapters describes a particular project life cycle phase in detail, by providing the activities and
tasks required to complete the phase in its entirety. In Chapter 2 you will learn how to initiate projects
by developing a business case, undertaking a feasibility study, establishing the terms of reference,
appointing the team and setting up a project office.
"Every step required to build a comprehensive suite of project plans is provided in Chapter 3. This
includes the activities required to create a project plan, resource plan, financial plan, quality plan, risk
plan, acceptance plan, communications plan and procurement plan. The entire tender process is also
defined, allowing you to create a suite of tender documentation to help you select a preferred supplier
and create a supplier contract.
"The most complex phase in the project life cycle (project execution) is made simple in Chapter 4 with a
step by step guide to the nine critical management processes: time management, cost management,
quality management, change management, risk management, issue management, procurement
management, acceptance management and communications management.
"Finally in Chapter 5, you will be shown how to formally close a project by creating a project closure
report and undertaking a post implementation review. So sit back, relax and discover the vital steps
needed to manage a project through the four critical phases of the project life cycle: initiation, planning,
execution and closure."4
Jason says:
"The first phase of a project is the initiation phase. During this phase a business problem or opportunity
is identified and a business case providing various solution options is defined. Next, a feasibility study is
conducted to investigate whether each option addresses the business problem and a final recommended
solution is then put forward. Once the recommended solution is approved, a project is initiated to deliver
the approved solution. Terms of reference are completed outlining the objectives, scope and structure of
the new project, and a project manager is appointed. The project manager begins recruiting a project
team and establishes a project office environment. Approval is then sought to move into the detailed
planning phase." 5
"Within the initiation phase, the business problem or opportunity is identified, a solution is defined, a
project is formed and a project team is appointed to build and deliver the solution to the customer.
Figure 1.3 shows the activities undertaken during the initiation phase:
"Develop a business case: The trigger to initiating a project is identifying a business problem or
opportunity to be addressed. A business case is created to define the problem or opportunity in detail and
identify a preferred solution for implementation. The business case includes:
• A detailed description of the problem or opportunity;
"An identified project sponsor then approves the business case and the required funding is allocated to
proceed with a feasibility study.
"Undertake a feasibility study: At any stage during or after the creation of a business case, a formal
feasibility study may be commissioned. The purpose of a feasibility study is to assess the likelihood of
each alternative solution option achieving the benefits outlined in the business case. The feasibility study
will also investigate whether the forecast costs are reasonable, the solution is achievable, the risks are
acceptable and the identified issues are avoidable.
"Establish the terms of reference: After the business case and feasibility study have been approved, a
new project is formed. At this point, terms of reference are created. The terms of reference define the
vision, objectives, scope and deliverables for the new project. They also describe the organization
structure; and activities, resources and funding required to undertake the project. Any risks, issues,
planning assumptions and constraints are also identified.
"Appoint the project team: The project team are now ready to be appointed. Although a project
manager may be appointed at any stage during the life of the project, the manager will ideally be
appointed prior to recruiting the project team. The project manager creates a detailed job description for
each role in the project team, and recruits people into each role based on their relevant skills and
experience
"Set up a project office: The project office is the physical environment within which the team is based.
Although it is usual to have one central project office, it is possible to have a virtual project office with
project team members located around the world. A project office environment should include:
• Equipment, such as office furniture, computer equipment, stationery and materials;
• Communications infrastructure, such as telephones, computer network, e mail, Internet access,
file storage, database storage and backup facilities;
• Documentation, such as a project methodology, standards, processes, forms and registers;
• Tools, such as accounting, project planning and risk modeling software.
"Perform a phase review: At the end of the initiation phase, perform a phase review. This is basically a
checkpoint to ensure that the project has achieved its objectives as planned." 6
Jason continues:
"Once the scope of the project has been defined in the terms of reference, the project enters the planning
phase. This involves creating a:
• Project plan outlining the activities, tasks, dependencies and timeframes;
• Resource plan listing the labor, equipment and materials required;
• Financial plan identifying the labor, equipment and materials costs;
• Quality plan providing quality targets, assurance and control measures;
• Risk plan highlighting potential risks and actions to be taken to mitigate those risks;
"At this point the project will have been planned in some detail and is ready to he executed." 7
"By now, the project costs and benefits have been documented, the objectives and scope have been
defined, the project team has been appointed and a formal project office environment established. It is
now time to undertake detailed planning to ensure that the activities performed during the execution
phase of the project are properly sequenced, resourced, executed and controlled. The activities shown in
Figure 3 are undertaken.
"Create a project plan: The first step in the project planning phase is to document the project plan. A
'work breakdown structure' (WBS) is identified which includes a hierarchical set of phases, activities
and tasks to be undertaken to complete the project. After the WBS has been agreed, an assessment of the
level of effort required to undertake each activity and task is made. The activities and tasks are then
sequenced, resources are allocated and a detailed project schedule is formed. This project plan is the key
tool used by the project manager to assess the progress of the project throughout the project life cycle.
"Create a resource plan: Immediately after the project plan is formed, the level of resource required to
undertake each of the activities and tasks listed within the project plan will need to be allocated.
Although generic resource may have already been allocated in the project plan, a detailed resource plan
is required to identify the:
• Type of resource required, such as labor, equipment and materials;
• Quantity of each type of resource required;
• Roles, responsibilities and skill sets of all human resource required;
• Specifications of all equipment resource required;
• Items and quantities of material resource required.
"A schedule is assembled for each type of resource so that the project manager can review the resource
allocation at each stage in the project.
"Create a financial plan: A financial plan is created to identify the total quantity of money required to
undertake each phase in the project (in other words, the budget). The total cost of labor, equipment and
materials is calculated and an expense schedule is defined which enables the project manager to measure
the forecast spend versus the actual spend throughout the project. Detailed financial planning is an
extremely important activity within the project, as the customer will expect the final solution to have
been delivered within the allocated budget.
"Not only is it important to review the quality of the deliverables produced by the project, it is also
important to review the quality of the management processes that produced them. A quality plan will
summarize each of the management processes undertaken during the project, including time, cost,
quality, change, risk, issue, procurement, acceptance and communications management.
"Create a risk plan: The next step is to document all foreseeable project risks within a risk plan. This
plan also identifies the actions required to prevent each risk from occurring, as well as reduce the impact
of the risk should it eventuate. Developing a clear risk plan is an important activity within the planning
phase, as it is necessary to mitigate all critical project risks prior to entering the execution phase of the
project.
"Create an acceptance plan: To deliver the project successfully, you will need to gain full acceptance
from the customer that the deliverables produced by the project meet or exceed requirements. An
acceptance plan is created to help achieve this, by clarifying the completion criteria for each deliverable
and providing a schedule of acceptance reviews. These reviews provide the customer with the
opportunity to assess each deliverable and provide formal acceptance that it meets the requirements as
originally stated.
"Create a communications plan: Prior to the execution phase, it is also necessary to identify how each
of the stakeholders will be kept informed of the progress of the project. The communications plan
identifies the types of information to be distributed to stakeholders, the methods of distributing the
information, the frequency of distribution, and responsibilities of each person in the project team for
distributing the information.
"Create a procurement plan: The last planning activity within the planning phase is to identify the
elements of the project to be acquired from external suppliers. The procurement plan provides a detailed
description of the products (that is, goods and services) to be acquired from suppliers, the justification
for acquiring each product externally as opposed to from within the business, and the schedule for
product delivery. It also describes the process for the selection of a preferred supplier (the tender
process), and the ordering and delivery of the products (the procurement process).
"Contract the suppliers: Although external suppliers may be appointed at any stage of the project, it is
usual to appoint suppliers after the project plans have been documented but prior to the execution phase
of the project. Only at this point will the project manager have a clear idea of the role of suppliers and
the expectations for their delivery. A formal tender process is undertaken to identify a short list of
capable suppliers and select a preferred supplier to initiate contractual discussions with. The tender
process involves creating a statement of work, a request for information and request for proposal
"Perform a phase review: At the end of the planning phase, a phase review is performed. This is a
checkpoint to ensure that the project has achieved its objectives as planned."8
In much of the literature, and in training programs, project management is all about project planning
while project execution gets short shrift. This is not the case in Jason's book. As Jason explains:
"This phase involves implementing the plans created during the project planning phase. While each plan
is being executed, a series of management processes are undertaken to monitor and control the
deliverables being output by the project. This includes identifying change, risks and issues, reviewing
deliverable quality and measuring each deliverable produced against the acceptance criteria. Once all of
the deliverables have been produced and the customer has accepted the final solution, the project is
ready for closure. The activities of this phase are shown in Figure 4."9
"The execution phase is typically the longest phase of the project in terms of duration. It is the phase
within which the deliverables are physically constructed and presented to the customer for acceptance.
"Build the deliverables: This phase involves physically constructing each deliverable for acceptance by
the customer. The activities undertaken to construct each deliverable will vary depending on the type of
project being undertaken. Activities may be undertaken in a 'waterfall' fashion, where each activity is
completed in sequence until the final deliverable is produced, or in an 'iterative' fashion, where iterations
of each deliverable are constructed until the deliverable meets the requirements of the customer.
Regardless of the method used to construct each deliverable, careful monitoring and control processes
should be employed to ensure that the quality of the final deliverable meets the acceptance criteria set by
the customer.
"Monitor and control: While the project team are physically producing each deliverable, the project
manager implements a series of management processes to monitor and control the activities being
undertaken by the project team. An overview of each management process follows.
"Time Management: Time management is the process of recording and controlling time spent by staff
on the project. As time is a scarce resource within projects, each team member should record time spent
undertaking project activities on a timesheet form. This will enable the project manager to control the
amount of time spent undertaking each activity within the project. A timesheet register is also
completed, providing a summary of the time spent on the project in total so that the project plan can
always be kept fully up to date.
"Cost management: Cost management is the process by which costs/expenses incurred on the project
are formally identified, approved and paid. Expense forms are completed for each set of related project
expenses such as labor, equipment and materials costs. Expense forms are approved by the project
manager and recorded within an expense register for auditing purposes.
"Quality management: Quality is defined as the extent to which the final deliverable conforms to the
customer requirements. Quality management is the process by which quality is assured and controlled
for the project, using quality assurance and quality control techniques. Quality reviews are undertaken
frequently and the results recorded on a quality review form.
"Change management: Change management is the process by which changes to the project scope,
deliverables, timescales or resources are formally requested, evaluated and approved prior to
implementation. A core aspect of the project manager's role is to manage change within the project. This
is achieved by understanding the business and system drivers requiring the change, identifying the costs
and benefits of adopting the change, and formulating a structured plan for implementing the change. To
formally request a change to the project, a change form is completed. The status of all active change
forms should he recorded within a change register.
"Risk management: Risk management is the process by which risks to the project are formally
identified, quantified and managed. A project risk may be identified at any stage of the project by
completing a risk form and recording the relevant risk details within the risk register.
"Issue management: Issue management is the method by which issues currently affecting the ability of
the project to produce the required deliverable are formally managed. After an issue form has been
"Acceptance management: Acceptance management is the process of gaining customer acceptance for
deliverables produced by the project. Acceptance forms are used to enable project staff to request
acceptance for a deliverable, once complete. Each acceptance form identifies the acceptance criteria,
review methods and results of the acceptance reviews undertaken.
"Perform a phase review: At the end of the execution phase, a phase review is performed. This is a
checkpoint to ensure that the project has achieved its objectives as planned."10
Jason concludes:
"Project closure involves releasing the final deliverables to the customer, handing over project
documentation to the business, terminating supplier contracts, releasing project resources and
communicating the closure of the project to all stakeholders. The last remaining step is to undertake a
post implementation review to quantify the level of project success and identify any lessons learnt for
future projects."11
"Following the acceptance of all project deliverables by the customer, the project will have met its
objectives and be ready for closure. Project closure is the last phase in the project life cycle, and must be
conducted formally so that the business benefits delivered by the project are fully realized by the
customer. The activities outlined in Figure 5 are undertaken.
"Perform project closure: Project closure, or 'close out', essentially involves winding up the project.
This includes:
• Determining whether all of the project completion criteria have been met;
• Identifying any outstanding project activities, risks or issues;
• Handing over all project deliverables and documentation to the customer;
• Canceling supplier contracts and releasing project resources to the business;
• Communicating the closure of the project to all stakeholders and interested parties.
"A project closure report is documented and submitted to the customer and/or project sponsor for
"Review project completion: The final activity within a project is the review of its success by an
independent party. Success is determined by how well it performed against the defined objectives and
conformed to the management processes outlined in the planning phase. To determine how well it
performed, the following types of questions are answered:
• Did it result in the benefits defined in the business case?
• Did it achieve the objectives outlined in the terms of reference?
• Did it operate within the scope of the terms of reference? 0 Did the deliverables meet the criteria
defined in the quality plan?
• Was it delivered within the schedule outlined in the project plan?
• Was it delivered within the budget outlined in the financial plan?
"To determine how well the project conformed, an assessment is made of the level of conformity to the
management processes outlined in the quality plan. These results, as well as a list of the key
achievements and lessons learnt, are documented within a post-implementation review and presented to
the customer and/or project sponsor for approval."
Note how each phase described in the preceding pages ends with a Stage Gate or Phase Review. A
Phase review is defined in the book's Glossary as: "A checkpoint at the end of each project phase to
ensure that a project has achieved its stated objectives and deliverables as planned" (for that phase).12
Downside
Do we have any criticisms? Well, yes, just a few. First, as we have suggested many times elsewhere, we
think that Figure 1, showing the four phases of the project life cycle is a perfect illustration of why the
"project life cycle" should not be called "cycle" but called "span" instead. The figure shows the project
phases going round in circles but never seems to produce a final output anywhere. That might be good
news for a continuous quality improvement model, but it is not an ideal depiction of a project. And,
before anyone jumps in and points out that "iteration" is a key element of information technology, our
answer is: True, but the iterations only take place in the project execution phase and the iterations are
progressive!
We feel strongly that for any but the smallest of projects, the results of the planning phase should be
summarized into a Project (Execution) Charter. The approval of this Charter by the project's sponsor or
senior management then provides the project manager with the updated authority to expend resources on
the remaining phases and in accordance with the planned modus operandi. If this corporate management
control strategy is adopted, then we thing that the creation of the detailed plans described as part of the
planning phase, should in fact be included as the first stage in Project Execution.
Finally, we think that the Project Closure phase could have a little more beef to it. Here, the very success
of a project depends heavily on how well the product is "transferred to the care, custody and control" of
the users. That means careful and appropriate marketing, training and support. This sequence is crucial
to the success of any project.
Summary
This book describes Jason Westland's preferred project management methodology that is encapsulated
in his proprietary product Method123®.13 The book caters for many types of project, including IT,
finance, telecommunications and administrative projects. It is written in plain text and, as Jason
observes:
"I have adopted industry standard terminology that can be understood by any reader with
a rudimentary knowledge of project management. I have not adopted the complicated
acronym-based terminology that is prevalent throughout industry. As such, you will not
read about undertaking a PERT (project evaluation review technique) or CPA (critical
path analysis), but you will read about how to create practical plans for managing time,
cost and quality within a project. This book explains the project life cycle without the
fluff."14
Amen to that! So, this book is simple, straightforward and detailed, and it includes over 100 tables and
examples that you can use as templates for your project. But you will have to read the book for those
details.
R. Max Wideman
Fellow, PMI
1
See http://www.method123.com/
2
Westland, J., The Project Management Life Cycle, Kogan Page, London, 2006, p1, available from Amazon On
Line Shopping http://www.amazon.com
3
Ibid, p4
4
Ibid, pp1-2
5
Ibid, pp3-4
6
Ibid, pp5-7
7
Ibid, p4-5
8
Ibid, pp7-10
9
Ibid, p5
10
Ibid, p10-13
11
Ibid, p5
12
Ibid, p225
13
See http://www.method123.com/
14
Westland, pp xvi-xvii
DR SAMYADIP CHAKRABORTY
SESSION :1 & 2
Objectives
• To provide participants with:
• An awareness of the importance of applying good practice
Project Management in projects of any size.
• Projects such as these are unparalleled not only in terms of technical difficulty and
organizational complexity, but also in terms of the requirements circumscribing them.
• In ancient times, project requirements were more flexible. If the Pharaohs needed more
workers, then more slaves or more of the general population were conscripted.
• If builders ran out of funding during construction of a Renaissance cathedral, the work was
stopped until more funds could be raised (one reason why some cathedrals took decades
or centuries to complete).
• If a king ran out of money while building a palace, he simply raised taxes. In other cases
where additional money could not be raised, more workers could not be found, or the
project could not be delayed, then the scale of effort or the quality of workmanship was
simply reduced to accommodate the constraints.
• In the Manhattan and Pathfinder projects, the requirements were not so flexible. First, both
projects were subject to severe time constraints. Manhattan, undertaken during World War
II, required developing the atomic bomb in the shortest time possible to end the war. For
Pathfinder, the mission team was challenged with developing and landing a vehicle on Mars
in less than 3 years’ time and on a $150 million budget.
Exercise 1
• Write down three attributes of a good Project Manager
Project Manager Role
• A Good Project Manager
• Takes ownership of the whole project
• Is proactive not reactive
• Adequately plans the project
• Is Authoritative (NOT Authoritarian)
• Is Decisive
• Is a Good Communicator
• Manages by data and facts not uniformed optimism
• Leads by example
• Has sound Judgement
• Is a Motivator
• Is Diplomatic
• Can Delegate
Stakeholder Engagement
Stakeholder
“A person or group of people who have a vested interest in
the success of an organization and the environment in
which the organization operates”
Exercise 2
• Write down three typical project stakeholders
Major aspects to be optimized
• Cost
• Time
• Quality
Typical Stakeholders
• Sponsor
• Funding Body
• Customer
• Suppliers
• End User
• HSE/Environmental Agency
• Maintenance Team
• Neighbours/Community/Shareholders
• Fusion Community
• Interfaces
Stakeholder Engagement process
• Identify Stakeholders
• Assess needs
• Define actions
• Establish communication channels
• Gather feedback
• Monitor and review
Key Points in Project Set-up and Definition
§ Labor
§ Materials
§ Subcontractors
§ Travel
§ …
Copyright © 2010 Pearson Education, Inc. Publishing as Prentice Hall 8-29
Types of Costs
Non-recurring
Expedited
Recurring
Variable
Normal
Indirect
Direct
Fixed
Costs
Direct Labor X X X X
Building Lease X X X X
Expedite X X X X
Material X X X X
ü Lack of definition
ü Specification changes
ü External factors
Cost variance
negative zero
Schedule
variance
ACWP
Progress report
Day 1 Day 2 Day 3 Day 4 Day 5 Day 6
A 18 60% 8 87% 4 100%
B 16 53% 10 87% 4 100%
C 14 47% 10 80% 0 80% 0 80%
D 12 40% 6 60% 6 80%
E 16 53% 8 80%
F 12 40%
G
H
I
J
BCWS 15000 30000 45000 60000 75000 90000
BCWP 9000 21000 35100 48000 59000 72000
ACWP 10200 22800 37000 50400 62800 75600
Calculate the variances for day 6
Schedule variance in cost terms = BCWP – BCWS
72000 – 90000 = -18000
09/10/2021
Project Risk
• Likelihood of an event
• Impact of event on project
• Market conditions
• Labor availability
• Competitors actions
• Government regulations
• Interest rates
• Customer needs & behavior
• Supplier relations
• Weather
RISK IDENTIFICATION
Risk Identification Techniques
• Analogy
• Checklist
• WBS Analysis
• Process flow diagram
• Brain storming (Fish Bone)
• Delphi technique
• Interviewing
Risk Checklist
Cause and Effect Diagram (Ishikawa and fishbone)
Product
Delivered
Late
• No.: R44
• Rank: 1
• Risk: New customer
• Description: We have never done a project for this organization before and don’t know
too much about them. One of our company’s strengths is building good customer
relationships, which often leads to further projects with that customer. We might have
trouble working with this customer because they are new to us.
• Category: People risk
• Etc.
2. Risk Assessment
• Scenario analysis for event probability and impact
• Risk assessment matrix
• Failure Mode and Effects Analysis (FMEA)
• Probability analysis
• Decision trees, NPV, and PERT
• Semiquantitative scenario analysis
Risk Assessment
• Risk likelihood
• Composite Likelihood Factor (CLF)
• Risk Impact
• Risk Impact: Composite impact Factor (CIF)
• Risk Consequence:
• Risk Consequence Rating: RCR = CLF + CIF – CLF(CIF)
CLF
Impact Scales of a Risk & Major Project Objectives
(Examples for negative impacts only) for CIF
Probability and Impact Matrix
• Define Probability Scale & Impact Scale
7–105
Contingency Planning
• Contingency Plan
• An alternative plan that will be used if a possible foreseen risk event actually
occurs.
• A plan of actions that will reduce or mitigate the negative impact
(consequences) of a risk event.
• Risks of Not Having a Contingency Plan
• Having no plan may slow managerial response.
• Decisions made under pressure can be potentially dangerous and costly.
7–106