Project Closing From POME by Gautam Koppala VT

1
Kanaka maha lakshmi Thalli
Be bold when you loose and be calm when you

win.
"Changing the Face" can change nothing.

POME’
POME’07
But "Facing the Change" can change everything.
1
2
2
KANAKA MAHA LAKSHMI THALLI
THIS BOOK IS DEDICATED TO THE ALMIGHTY, WHO
ALWAYS SHOWERS HER BLESSINGS ON HER
CHILDREN.
3
2007, POME, Gautam_Koppala, All Rights Reserved
PROJECTS AND OPERATIONS
MANAGEMENT EXPOSED
(POME)
Part “PROJECT CLOSING”
A COLLECTION AMELIORATED BY
GAUTAM KOPPALA V.T.
4
5
6
6
You are the only person who can revolutionise your life.
You are the only person who can influence your happiness,
your realisation and your success.
You are the only person who can help yourself.
Your life does not change, when your boss changes,
when your friends change, when your parents change,
when your partner changes, when your company changes.
Your life changes when YOU change,
when you go beyond your limiting beliefs,
when you realize that you are the only one responsible for your life.

Copyright © 2007 POME
All rights reserved. No part of this product may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopy, recording, broadcasting, or by any information storage
or retrieval system, without permission in writing from the author Gautam Koppala.
All knowledge in POME book is service marks and/or trademarks of the author Gautam Koppala.
Except as otherwise specified, names, marks, logos and the like used in the educational/teaching
content of these materials are intended to be, and to the best of Licensor’s [Gautam Koppala’s]
knowledge and belief are, fictitious. None of the names, marks, or logos used herein is intended to
depict any past or present individual or entity, or any trademark, service mark, or other protectable
mark of any individual or entity. Any likeness, similarity or sameness between any name, mark, or
logo used herein by Licensor and the name, mark, or logo of any individual or entity, past or present,
is merely coincidental and unintentional. Any such names, marks, and logos used in the
educational/teaching content of these materials are used only to provide examples for purposes of
teaching the educational content of the materials, and are in no way intended to be used in any
trademark sense or manner.
The names of actual past or present individuals, entities, trademarks, service marks, logos and the like
(other than those of Licensor used in the educational/teaching content of these materials are used only
to provide examples (including in some instances actual case studies based upon factual events or
circumstances involving the individuals, entities, marks, or logos) for purposes of teaching the
educational content of the materials. Any such names, marks, and logos used in the
educational/teaching content of these materials are intended and used solely for the purpose of
providing examples and case studies, and are in no way intended to be used in any trademark sense
or manner.
8
VITA: FROM THE AUTHOR:
Academically, I am a cum laude graduate with a Bachelor of Technology degree in Electrical and
Electronics Engineering (B-Tech E.E.E.) and a post graduate in Masters in Human Resources
Management (M.H.R.M.) and Masters of Foreign Trade (M.F.T.), all from India.
My engineering completed in a remote village in India, Srikakulam, and it’s been a long journey from
there, and journey still continues….I feel this book demonstrates my ability to maintain dedication,
motivation and enthusiasm for a project management over a long period of time. I believe that in
combination with my extensive broad-based operations work experience along with my drive,
9
resourcefulness and determination would make this book, an excellent opportunity for any
juvenile/experienced one in Projects industry.
I started my career as a small time engineer and gradually still developing in the Operations Domain.
With over nine years of Professional Experience, am a well-rounded functional Manager with excellent,
documented record of accomplishment and success in the electronic Security and Building Systems
Technology Field.
The reason behind writing this book, is that when am new to this field, I don’t have any one to say,
what is all about the projects, what to do, and when to do? Hence, the detailed information that I
gained through the ages, thought to put in an orderly fashion, so that it would be vitally milked by
future successful managers, avoiding the time lags.
Highlights of my background include Supply chain, Commercial with a magnificent experience in
Project and Operations management, technically oriented towards Automation and Security Systems in
Industrial and Building sectors.
My success in the past has stemmed from my strong commitment and sense of professionalism. I keep
high standards for my work and am known for my persistent nature and ability to follow through.
If this book facilitates you in getting adjusted and grow in this domain. I would feel really successful.
GAUTAM KOPPALA VT
10
POME Contents
Faces of Failure in Project: .................................................................................................. 13
Planning Project Close Out: ................................................................................................. 37
Project Close out ................................................................................................................. 44
Handing over from Projects to Services/ Facilities/ Maintenance: ...................................... 65
Project Success: Found in the Eye of the Beholder .............................................................. 83
Project Operations Documentation Templates:.................................................................... 89
Project Gating for Success and Project Reviews: ............................................................... 174
11
FACES OF
FAILURE IN
PROJECTS
12
Faces of Failure in Project:
Previously we stated that success might be a cube rather than a point. If we stay within the cube but
miss the point, is that a failure? Probably not! The true definition of failure is when the final results are
not what were expected, even though the original expectations may or may not have been reasonable.
Sometimes customers and even internal executives set performance targets that are totally unrealistic
in hopes of achieving 80–90 percent. For simplicity's sake, let us define failure as unmet expectations.
With unmeetable expectations, failure is virtually assured since we have defined failure as unmet
expectations. This is called a planning failure and is the difference between what was planned and
what was, in fact, achieved. The second component of failure is poor performance or actual failure.
This is the difference between what was achievable and what was actually accomplished.
Today, most project management practitioners focus on the planning failure term. If this term can be
compressed or even eliminated, then the magnitude of the actual failure, should it occur, would be
diminished. A good project management methodology helps to reduce this term. We now believe that
the existence of this term is largely due to the project manager's inability to perform effective risk
management. In the 1980s, we believed that the failure of a project was largely a quantitative failure
due to:
Ineffective planning
Ineffective scheduling
Ineffective estimating
Ineffective cost control
Project objectives being "moving targets"
During the 1990s, we changed our view of failure from being quantitatively oriented to qualitatively
oriented. A failure in the 1990s was largely attributed to:
Poor morale
Poor motivation
Poor human relations
Poor productivity
No employee commitment
No functional commitment
Delays in problem solving
Too many unresolved policy issues
13
Conflicting priorities between executives, line managers, and project managers
Although these quantitative and qualitative approaches still hold true to some degree, today we
believe that the major component of planning failure is inappropriate or inadequate risk management,
or having a project management methodology that does not provide any guidance for risk
management.
Sometimes, the risk management component of failure is not readily identified. For example, look at
the below Figure. The actual performance delivered by the contractor was significantly less than the
customer's expectations. Is the difference due to poor technical ability or a combination of technical
inability and poor risk management? Today we believe that it is a combination.
Figure: Risk planning.
When a project is completed, companies perform a lessons-learned review. Sometimes lessons learned
are inappropriately labeled and the true reason for the risk event is not known. The below Figure
illustrates the relationship between the marketing personnel and technical personnel when undertaking
a project to develop a new product. If the project is completed with actual performance being less than
customer expectations, is it because of poor risk management by the technical assessment and
forecasting personnel or poor marketing risk assessment? The relationship between marketing and
technical risk management is not always clear.
14
Figure: Mitigation strategies available.
The above Figure also shows that opportunities for trade-offs( Time, Cost, Quality, Performance)
diminish as we get further downstream on the project. There are numerous opportunities for trade-offs
prior to establishing the final objectives for the project. In other words, if the project fails, it may be
because of the timing when the risks were analyzed.
15
Business Case Form Sample Matrix:
Please complete the form below and submit it to your project sponsor.
Background to the project (PLEASE KEEP BRIEF)
General aims(s)
16
Initial Risks
Expected Outcomes
Benefits of running with this project
Initial estimates of cost and time
£:
Time:
Outcome of the business case
Decision from (x x)
17
Date
18
Project Definition Form [or PID]
Project Title: Put here a very brief Sponsor: Insert actual sponsor name
title
State below the link with the corporate agenda – the actual wording please.
Put here the actual words in the corporate agenda – showing the link with this project
Project Background: The background to the project. Enough information to inform the
reader.
Project Benefits: An outline of what the benefits are to the organisation, individuals or
stakeholders in delivering the project
Project Objectives: The specific objectives for the project. NOTE: the objectives can be
one line or more detailed text.
Project Deliverables: What you will be delivering at the end of the project. NOTE: these are
the what you will have at the end of the project, e.g. a report, a
building, improved service levels etc.
19
This project will include: This project will not include:
This section defines the boundaries of the Planning details should not be included at this stage.
project.
Success Criteria: How you will measure the success of the project. NOTE: the success
criteria must be measurable.
Constraints: Examples here can be specific (a skill which the project team must
have) resources, or a legal deadline – NOTE: only include time and
money if you can quantify them.
Key Assumptions: The assumptions you are making in putting this document together.
Project Manager: Who fulfils this role and what they do.
Project Sponsor: Who fulfils this role and what they do.
20
Project Who fulfils these Project Team
Board/Steering roles and what they Members:
Group Members: do. NOTE: may not
be appropriate for
all projects

Budget
Resource Costs: Other Costs:
Total costs (attach a breakdown of the overall budget)
• VAT*– Some projects may have important VAT issues. Have you spoken to accountancy to
discuss these?
• Other Taxes issues
Start Date: Completion Date:
Signature of Project Date:
Manager:
Approval from Sponsor: Date:
21
For your organisation, you will need to liaise with your Finance people in order to develop
financial information that will inform project delivery. The data on this form in relation to
finance needs to be fine tuned to your organisational and project management needs
22
Project Reporting Form Sample Matrix:
Project Title: Number:
Project Sponsor: Project Manager:
Progress Report Report No.
RAG Status*: RED / AMBER / GREEN
Headlines
Tasks, Milestones, Outcomes delivered this period Completion dates
Tasks, Milestones, Outcomes Comments Plan Actual
Major Risks and Issues Include an assessment of the impact and any actions taken
Recommendations and Requests for Decisions or Support
Tasks, Milestones, Outcomes scheduled for next Completion dates
23
period
Tasks, Milestones, Outcomes Comments Plan Forecast
* RED "Major concern - escalate to the next level” Slippage greater than 10% of remaining
time or budget, or quality severely compromised. Corrective Action not in place, or
not effective. Unlikely to deliver on time to budget or quality requirements
AMBER "Minor concern – being actively managed” Slippage less than 10% of remaining time
or budget, or quality impact is minor. Remedial plan in place.
GREEN "Normal level of attention” No material slippage. No additional attention needed
24
Highlight/Progress Report
Project Name: PROJECT NAME
Reporting Period: Project Manager: Project Sponsor:
Project
RAG Status R 0
Prepared by: Date Prepared: Phase:
Project Description: Project End Date: dd/mm/yyyy
Key Deliverables for next reporting

Key Deliverables Completed this period Key Deliverables Outstanding this period
period
Deliver Delivery
y Date Date
Risk Management Issue Management Change Management
Log No Risk Action/Status Log No Issue Action/Status Req No Details Approve
25

Financial Statement
Capital Revenue External
Foreca Rema
Source Budget Actual Remaining Forecast Source Budget Actual Remaining st Source Budget Actual ining Forecas
0 0 0
26

27
Change Control Sheet Sample Matrix:
Project Title Project Number
Project Manager
CHANGE REQUEST
Originator Date of request Change request no.
Phone: allocated by Change
Controller
Items to be changed Reference(s)
Description of change (reasons for change, benefits, date required)
Estimated cost and time to implement (quotation attached? Yes No )
Priority / Constraints (impact on other deliverables, implications of not proceeding, risks)
CHANGE EVALUATION
What is affected Work required (resources, costs, dates)
Related change requests
Name of evaluator Date evaluated Signature
CHANGE APPROVAL
Accepted Rejected Name Signed Date
Deferred
Comments
CHANGE IMPLEMENTATION
Asset Implementer Date Signature
completed
Change Control Log Sample Matrix:
Project Manager
Chang Description of change Date Date Date Date
e received evaluate approved complete
numbe d d
r
Actual V Planned Sample Matrix:
Activity Planned Actual Difference Planned Actual Difference
Time Time
Cost Cost
28
29
Project Management - Check Sheet Amend this Check Sheet to suit your project
A: SET UP - INITIATION Y N COMMENTS 5 Have you identified the critical path for the
project?
6 Have you developed a communications

1 Developed the business case?
plan and included its component parts into
2 Is a full options appraisal necessary?
the Gantt charts?
3 Is the project in line with the strategic
7 Are you continuing to carry out risk
plan?
analysis throughout the project?
4 Has the project received sign off by
8 Are quality standards high? How do you
sponsor or project board?
know?
B: SET UP - DEFINITION
D: DELIVERY
1 Has a PID or project definition form been

1 Have you identified the appropriate type of
completed?
control – loose versus tight?
2 Are roles explicit and documented?
2 Project reporting – are you clear who
3 Are levels of authority clear? reports what and to whom and how?
4 Have you carried out a stakeholder 3 Do you have a clear procedure for
analysis and planned accordingly? managing change?
5 Have you assessed risks and put a plan 4 Have you developed a planned versus
into action to monitor them? actual schedule? How up to date is it?
6 Are you clear what is driving the project 5 Tolerance – have you an agreed tolerance
Quality, Cost or Time (1 only) figure?
7 Have clear project review procedures 6 Variations – are these quickly flagged?
been established?
8 Has planning started for a start up

E: CLOSEDOWN AND REVIEW
workshop (or series of workshops)?
9 Team selection - have you got the correct

1 Post project review has been planned?
mix of skills and professional experience?
2 Learning identified?
3 Is the project still delivering the benefits

C: DELIVERY PLANNING
intended?
4 Is there a case for abandoning the project

1 Have you broken the project down into its
– off schedule or delivered a significant
component parts – work breakdown
part of it?
2 How accurate are your estimates? If a low
5 End of project review reports are produced
percentages then recalculate.
and circulated?
3 Have you developed a milestone chart or
produced a Gantt chart?
4 Have you developed an overall project

budget? Have you sought advice from
financial experts
30

Site handover Format:
31
32
33
Training and Development
Hands on Training be provided to the customer team for Understanding of Engineering Drawings,
Product Knowledge, Installation, Testing, Labelling and Administration, Relocation and Maintenance
34
POME Prescribe:
About Personal organization:
Nothing beats being organized. Keep an organized filing system, for instance, even something as
simple as storing documents chronologically will go a long way in saving you time and stress
when you need to locate information.
Keep a daily journal where you jot down the day’s highlights. Then, set aside an hour on Friday/
Saturday night/evening to analyze your week. What did you do wrong? What did you do right?
What will you do differently the next time in a similar situation? This practice will help you grow
professionally and personally in the long run.
Make daily lists and cross things off. Keep a personal scorecard and grade yourself weekly.
Buy a Daily Planner; now actually use it.
35
PLANNING
PROJECT CLOSE
OUT
36
Planning Project Close Out:
All projects must come to an end, one way or another. While some projects may come to an untimely
end through cancellation, most projects reach their planned conclusion. Projects are designed to produce
a specific unique outcome, and when that outcome is delivered, the project should end. This "end" can
be a process in and of itself, normally referred to as project closure.
Depending on the nature and complexity of the project, closure can consist of any or all of the following
elements:
• Final testing of project deliverables as needed.
• Formal acceptance of project deliverables based on pre-defined acceptance criteria.
• Formal production turnover. (the transfer of project deliverables to operational status).
• Review and analysis of non-critical "open issues".
• End-user training (covering deliverables usage and maintenance as needed).
• Operational and administrative training (for production/operations staff).
• Deliverables documentation (end-user and operational).
• Resource re-allocation or release (to transfer project staff to other projects, back to operations,
or to release outsourced resources).
• Post project performance reviews (lessons learned analysis).
• Project team and staff performance reviews.
• Vendor performance reviews.
• Release of final payments to vendors or contractors.
• Formal closure event planning, to include staff recognition and to mark outstanding project
achievement.
Planning for Closure:
To a large extent, project closure planning takes place before the project begins. To properly plan any
project, you have to envision the end-game …. how and when will your project end? As such, the
following closure issues should be addressed as you initially define and structure your project.
37
38
39

Acceptance Criteria:
Acceptance criteria should define the form and function of specific project deliverables, establishing end-
user expectations and requirements, and forming the basis by which project deliverables are accepted or
rejected. Once acceptance criteria are defined, they form a "contract" under which the project is
performed, setting expectations and creating consensus. As such, acceptance criteria should not be
changed once a project is underway unless a formal change process is applied. Without acceptance
criteria, true project closure cannot be obtained, as there may be no specific measurement for
completion. As acceptance criteria are planned, the following questions should be considered.....
• How will acceptance criteria be identified?
• How will acceptance criteria be finalized?
• Who must be involved in acceptance criteria definition and final approval?
• How can acceptance criteria be controlled to ensure consistency and to avoid unnecessary
changes?
Closure Kick-off (timing of closure activities):
As any project is defined and structured, you will need to identify the point at which project closure
activities can begin. Typically, project closure activities should begin when project deliverables are near
completion. Overall, the goal is to ensure that valuable time is not wasted. Once a project nears
completion, transition should begin immediately in order to maintain momentum and to ensure that
sufficient resources are available to move on to the next project.
Transition (Turnover) Needs:
Depending on the type of project at hand, transition needs will vary. As you plan closure activities, you
should consider specific transition/turnover requirements. Typically, transition/turnover activities relate
to the status of project deliverables. When a deliverable is under development, the project team is in
control. Once a deliverable is ready for production, ownership must be transitioned to end-users and
operations staff so that the deliverable can be used and maintained. Turnover planning can involve end-
user training, operations training and the preparation of procedural and technical documentation....
• What types of turnover activities will be required?
• How much time should be allocated to turnover?
• How and when will formal turnover take place?
• Who must approve and accept turnover?
Resources, Roles and Responsibilities:
40
As project closure is planned, resource requirements, including roles and responsibilities must be
considered. As you go through the closure planning process, think through the following questions…..
• What types of resources will be required for project closure activities (considering activity
requirements, tasks, skills and responsibilities)?
• Who will be involved in the closure process (including management and end-users)?
• As the project draws to a close, how will project team members be reassigned to other projects?
• Who will be involved in the post project review process (to analyze project results &
performance)?
Communication:
Communication is essential to smooth project closure and transition. In order to ensure that all parties
are informed and in synch with closure activities, you will need to take appropriate steps to keep
information flowing as needed, and on a timely basis. As you plan "closure communication" you should
consider the following questions....
• Will you have closure planning meetings (how many and how often)?
• What types of documentation will be required to ensure effective project closure?
• How will you best communicate the closure activity schedule, considering meeting requirements,
training sessions, and staff transition information.
• How will formal project closure be acknowledged and recognized?
As you can see, closure activities will vary according to project needs and circumstances, but the overall
goal is constant – to ensure that your project ends with success. To that end, project closure should be
recognized as a formal project process, and should be included as an independent phase in any project
plan, no matter how limited actual closure activities may be.
Entering the Closure Phase:
• Recognize that the closure kick-off point has arrived and activate your closure plan.
• Schedule formal closure activities.
• Communicate the schedule to all interested parties.
• Identify and document all remaining open issues, if any, and determine which issues must be
closed in order to obtain formal project acceptance. If needed, you can form a post-project clean-
up team to handle minor issues that do not prevent deliverables acceptance.
• Complete all required closure activities as needed, including production turnover, training, staff
re-allocation, and documentation.
• Obtain formal project acceptance from customers and management.
• Celebrate project completion with staff and end-users.
41
• Complete staff performance reviews.
• Complete the post project review process and document the results.
Concluded Note:
Once the post project review is completed, your project will likely come to an official end. Certain minor
issues may linger, and the project review process may raise new issues that must be addressed in the
future. These ongoing issues can be dealt with by the project manager, or by a post-project clean-up
team, if needed. But, from an organizational perspective, formal closure activities will bring the project
to an end, freeing staff and financial resources for the next project likely waiting in the wings.
In the busy project environment, projects occur at a fast and furious pace, and, at times, it may seem
as if one project just flows into the next. But it is important to take the time to acknowledge actual
project completion. Project closure is a sign of success and achievement, and should be treated as such.
In this way, you can ensure that all your projects go out with a bang, and not a whimper.
42
PROJECT
CLOSE OUT
43
Project Close out
Fig: Advanced Project Management – Project life cycle
A project is operationally complete when the last financed inputs have been provided and the
related activities have been completed. Through the Project Board, the implementing partner
promptly notifies the finance office when this has been done..
Project Financial completion
A project is financially completed when, It is operationally completed or has been cancelled;
Projects should be financially completed not more than 12 months after being operationally
completed or after the date of cancellation. Between operational and financial closure, the
Implementing Partner is required to identify and settle all financial obligations and prepare a final
expenditure report. No adjustments can be made to a financially completed project.
Final Project Review
A final project review will be conducted during the final quarter of the project duration. Its
purpose is to assess the performance and success of the project. It should look at sustainability of
the results, including the contribution to related outcomes (and the status of these outcomes) and
capacity development. It will also review lessons learned and recommendations that might
44
improve design and implementation of other projects. Like the Annual Review, the final project
review is driven by the Project Board and may involve other stakeholders as required. The final
project review is distinguished from an evaluation because the latter is an external assessment,
while the former is a self assessment exercise. The findings from the review can be used to
inform the evaluation and vice versa.
Transfer or Disposal of Assets
Assets may be transferred to for project activities managed by a recipient institution at any time
during the life of a project.
Learning & Knowledge Management
Project lessons learned should be actively captured to ensure ongoing learning and adaptation
within the organisation. Based on the Lessons Learned Log created and updated in previous
processes, a final Lessons Learned Report should be prepared at the end of the project to foster
the learning process. In addition, in order to promote knowledge sharing, ideas, experiences and
lessons deriving from the project should be shared with colleagues on the Practice Knowledge
Networks (e.g. answer a referral, participate in an e-discussion or peer review/assist, contribute
to the development of a knowledge product).
Acceptance Certificates:
1. PAC: Preliminary Acceptance Certificate: Certificate, issued by the client after completing of
the Project.
2. FAC: Final Acceptance Certificate: Acceptance certificate by the Client, after completion of
the warranty.
Subject User Training
To meet contractual obligations and to ensure that the end user/s of the facility are
Purpose adequately informed on the use of the installed equipment / systems to be able to assume
responsibility for day to day operation
To prepare and deliver end user training in accordance with contract and customer
Scope
requirements
45
STEP WHO NOTES
Scope Definition Document, Training Plan template, Training module library,
INPUT -
Training certificate template, Technical Training department
Project Confirm training allowance
Engineer / Check the project scope documents & proposal with the Project
1
Project Manager to determine the project allowance / intention regarding
Manager training.
Project Confirm customer expectations / needs
2
Engineer / The contract document or specification will often define specific
46
Project customer's original expectations regarding training requirements.
Manager Meet or discuss with the customer to establish their current
expectations.
Obtain PM approval to training scope
Project
In the event the project training allowance is less than the current
Engineer /
3 customer expectation, review the current customer expectation
Project
with the Project Manager and obtain PM approval before
Manager
committing to an increased scope.
Develop training plan
Develop a proposed training plan / agenda to meet the agreed
Project
training needs & operational constraints. Wherever practicable,
4 Engineer /
base the training plan on use of pre-existing training material so as
Trainer
to minimise the amount of development time required.
Project
Review & approve training plan
Engineer /
5 Review the training plan with the PM & Customer to obtain
Project
approval before proceeding
Manager
Develop training manual / material
Develop the training material in accordance with the agreed plan.
The training material may include one or more of the following:
Project • Training presentation / trainer notes
6 Engineer / • Training manual / trainee notes
Trainer • Trainee assessment questionnaire or test
• Training Certificates of Achievement - The CAD Centre can produce
'official' Company customer training certificates.
7 Project Approve training manual
47
Engineer / Often, our contract customer will wish to review & approve the
Project training material prior to delivery of the training to the end users.
Manager
Schedule training
• Schedule the training according to trainer, trainee and system resource
availability.
• Make arrangements for provision of required resources e.g. printed
Project manuals, presentation material, data projectors etc.
8
Engineer • Ensure that trainee details are confirmed and captured in a Training
Attendance Register. Copy the final attendance register to the trainer.
• Send each trainee confirmation of their enrolment and details of the
training date, location and any materials or equipment they are required
to bring to the training.
Conduct training
• Ensure the Training Attendance Register is signed by all trainees so there
is an official record of all persons attending the training course.
• If practicable, a trainee assessment questionnaire should be completed
Project
by each trainee to confirm achievement of basic training objectives.
9 Engineer /
• Where practicable, a Training Feedback & Evaluation form should be
Trainer
completed by each trainee at the conclusion of each training session.
This provides the trainees an opportunity to comment on the quality of
the training experience and for Company to improve future training
sessions.
Issue training certificates
It is important to issue training certificates at or shortly after the
Project
10 completion of training so as to:
Engineer
• Raise awareness of the value of the training delivered
• Give the trainees recognition for their effort and a record for personal
48
development files
• Avoid any future dispute over who was or was not trained
Lessons learned
Project Review the training evaluation feedback to identify lessons for
11
Engineer future training sessions and to identify opportunities for additional
or ongoing training offerings.
Training Plan, Training Manual, Customers Trained, Training Certificates issued,
OUTPUT -
Lessons learned
Subject O&M Manuals
To provide the system Operation & Maintenance Manuals for the end user and service
Purpose
department
Scope All projects where O&M Manuals are required as part of the scope
STEP WHO STEP NOTES
INPUT - O&M Manual template, Product data sheets, As-Built records, CAD Centre
The engineering department must have the facility to assist with the
production of Operation and Maintenance manuals for projects. They
Project can create professional looking CDs containing PDFs of the as-built
1
Engineer data for a project to your requirements. They can also produce paper
versions if requested.
Approved Operation & Maintenance Manuals provided to the end user and service
OUTPUT -
department
Subject As-Built Records
Purpose To prepare the final 'as-built' records for the project
49
Accurate 'as-built' information is vital for future servicing and maintenance of the system and
Scope
is required for the Project to Service handover.
STEP WHO STEP NOTES
Working documents (mark-ups), change control regiater, installation verification
INPUT -
records, test & commissioning records
Collate As-Built mark-ups & change information
During the installation & commissioning of the works as-built mark-
ups to working documents, changes, variations & ammendments will
most likely have been made. Collate all such information and
validate that all known differences between the actual site
Project installation / configuration and the design documentation are
1
Engineer identified.
Check the Change Control Register to ensure that the impact of all
identified, authorised changes have been taken into account on the
working documents & mark-ups. Where necessary, refer back to the
relevant change owner or verifier to complete any missing mark-up
information.
Revise all documentation to final As-Built status
Update all engineering documentation to include changes made
during the installation & commissioning phase so that there is an
accurate record of the final as-built design & configuration of the
delivered systems. Where necessary, refer to the Engineering Plan
to identify the appropriate person/s nominated responsibility for
Project delivery / update / verification of each of the engineering outputs.
2
Engineer
As-built information would typically contain:
• System Architecture / Block diagrams / schematics
• Functional Specifications / Descriptions
• Points lists / Wiring Schedules
• Equipment Location drawings / floor plans / cable routes
• Equipment schedules
50
• Wiring / termination diagrams
• Assembly & manufacture drawings
• Software configuration manual / design
• Controller software
• Software configuration tables / design
• Head end software & graphics
When each design output is updated with the As-built information,
the revision of the output should be incremented to "As-built"
status.
Validate as-built documents
Project • Validate that the required changes have been correctly made.
3
Engineer • The project Document Control Register shall be updated accordingly as the
master list of as-built information.
Design documents updated & validated to "as-built" status, document register
OUTPUT -
updated
Project Closeout Report Illustarion Template
Project Closeout Report
Project Name:
Date: DD Mmmm 20yy
GAUTAM KOPPALA ORG
Project Manager:
Approver: signature
Approver Name & Title
Project No: Project
Size:
Project Review
Manager: Date:
Reviewers: XXXXX
51
The following are suggested sections for the Project Closeout Report:
Summary of the Project from Sales Handing over to The Project Completion
XXXXXX
Observations: XXXXXX
Purpose of Closeout Report
Describe the purpose of the Closeout Report using the following guidelines:
The closeout report insures that personnel, contract, administrative, and financial issues are resolved,
that documents are archived, and lessons learned are captured.
Scope of Work
• Task/services/ Deliverables to be delivered –system works completed
Certificate issued and validated by Customer ( Yes/ No)–
Payment
• Billings submitted & still outstanding
- Invoice number
- Any retentions
Bank Guarantees
XXXXX
Costs
• Costs still to come
- Honeywell hardware – hardware complete( Yes/ No)
- outside purchase – purchases completed ( Yes/ No)
- sub-contract services – invoices received ( Yes/ No)
- Work man hours – Completed ( Yes/ No).
• Customer claim risk –
- bank charges
- rise and fall
- exchange rate
52
- Liquidity Damage’s
Documentation
• As built drawings completed or not( Yes/ No)
• Final issue of functional specification - ( Yes/ No)
• Manuals – O&M submitted ( Yes/ No)
- User
- Technical
- Maintenance
Administrative Closure
Were the objectives of the project met?
Review the project objectives and indicate if the objectives were met. If there were deviations from the
baseline objectives and the final product, describe those here.
Revenue
• Billings to be submitted – all monthly invoices submitted, not included unapproved variations.
• Scope variations to be negotiated and billed – Completed ( Yes/ No).
• Rise & fall to be negotiated and billed - Completed ( Yes/ No).
• Prolongation to be negotiated and billed – Completed ( Yes/ No).
• Exchange rate to be negotiated and billed – Completed ( Yes/ No).
• Other revenue to be negotiated and billed – time delays charges- Completed ( Yes/ No).
• Earned revenue charges incurred – Completed ( Yes/ No).
Warranty
• Terms agreed – as per “Warranty Dates”
• Period agreed – (Yes/ No).
• Scope agreed – (Yes/ No).
• Contacts nominated - no
• Outstanding claims agreed - no
• Customer advised of warranty start and contact details
Service/ Facility Handover
• Documentation – O/M in progress
• Training arranged – Service staff did not attend training at customer site
53
• Job status advised – (Yes/ No).
• User facility orientation - (Yes/ No).
Performance
• Scope delivered ( Yes/ No)
• Objectives
- customer satisfaction score –(1-10)
- gross margin – negative/ Positive
- revenue – total expected revenue reached or not
- internal & external quality audit results – ( Yes/ No)
• Schedule –
• Quality delivered ( Yes/ No)–
• Forecasting accuracy (%) –
Archiving Project Artifacts
Describe how project documents will be collected and archived for future reference. Documentation to
consider:
▲ Financial records
▲ Cost and schedule performance reports and records
▲ Quality data
▲ Correspondence
▲ Meeting Notes
▲ Status Reports
▲ Issue and Action Log
▲ Risk Log
▲ Contract Files
▲ Change Requests
▲ Technical documents
▲ Acceptance records
Lessons Learned
54
Conduct a lessons learned session to discuss and capture the performance (e.g., what worked well,
what didn’t work well) from start to finish on the project. Capturing and incorporating lessons learned
on future projects are among the most important ways in which an organization gathers information to
institutionalize repeatable processes and avoid repeated mistakes.
• Scope management
• Schedule management
• Finance management
• Quality management
• Risk management
• Human Resource management
• Procurement management
• Communications management
• Integration management
• Other Methodologies
• Case Analysis
• Legal Management
Plans for Post Implementation Review (PIR)
Describe the plan to conduct the Post Implementation Review (PIR).
Final Customer Acceptance
Describe the achievement of final customer acceptance. Describe the final meeting with customer, who
attended and what disciplines were represented (finance, contracts, quality, etc.) Discuss the
documents signed. If open issues remain discuss the plan for their resolution.
Financial Records
Discuss the review of invoices, purchase orders, and final cost reporting. Describe where the final cost
records are archived.
• Outstanding variations to be booked – yes, after approval only
• Reconcile revenue - Completed (Yes/ No).
• Check accuracy of forecast costs – negative margin expected early on.
• Consider closing the job – Completed (Yes/ No).
Final Project Performance Report
55
Summarize the project’s scope management, schedule performance, cost performance, quality
achievements and a review of the risk containment performance. Discuss the reasons for cost or
schedule variances.
Contract Closure
Resolution of Contract Open Issues
Describe any open contract issues and the plans to obtain closure to the issues.
Collection and Audit of Contract Documents
Contract closure is essentially a collection and audit of the contract documentation. Documentation to
be collected includes but is not limited to:
▲ Original contracts
▲ Contract changes
▲ Schedules
▲ Performance reports
Describe the plan and actions for closing any contracts and associated tasks.
Demobilisation
• Surplus hardware and facilities sold or sent to warehouse/ factory – (Yes/ No).
• Records archived -(Yes/ No).
• Staff reassigned – (Yes/ No).
• Staff recognised & rewarded - (Yes/ No).
• Advise Customer Advocate that the project is complete – (Yes/ No).
Job File
• Rationalise document - Completed (Yes/ No).
• Delete unnecessary documents – Completed (Yes/ No).
• As built drawings in file - Completed (Yes/ No).
• Finalise functional specification - Completed (Yes/ No).
• Label all files - Completed (Yes/ No).
RECORD OF AMENDMENTS
56
Version Author Date Comments
Draft 1. Based on template created for
1.0 7/25/09
Project Closure
Closing a Project in perspective of finance
Typical sequence of events for financial and economic analysis of a project
Procedures
Ref Task Atlas Action Notes
[who] Points
01 Prepare final Project Executive When
Review report Snapshot: completion is
[Project Manager] Annual Review approaching,
Report covering the Project
the entire duration Manager must
of the project prepare a final
Project Review
Report.
This is a report
from the
project team to
the Project
Board and the
Outcome Board,
using the same
format than the
Progress Report
available in the
Executive
Snapshot. As
such, it does
offer a coherent
and structured
57
assessment of
progress based
on the chain of
results initially
defined in the
Resources and
Results
Framework
(RRF). It may
be
supplemented
by additional
narrative to
meet specific
reporting needs
of stakeholders,
especially
bilateral
donors.
As an annex, a
LessonsLearned
report should
also be
prepared,
summaring the
information
captured in the
Lessons
Learned log
throughout the
implementation
of the project.
2A Conduct final project Key documentation Using the final
review produced for the Project Review
[Project Board] review should be Report, the
uploaded in Atlas. Lessons
Project Learned Report
and other
documentation
as appropriate,
the Project
Board should
assess in this
meeting the
performance
and success of
the project, and
its contribution
to related
outcomes.
Topics during
the review shall
58
include:
Activity
deliverables
quality
Achievements
of last year
targets
Overall project
performance
Progress on
capacity
development
strategies
Outstanding
activities
Lessons
Learned
Use of
remaining
budget, if any
Effective date
of project
closure
Transitioning of
responsibilities
to national
counterparts
Hand-over of
assets
2B Commission project Evaluation report Mandatory only
evaluation, prepare a to be uploaded in when required
management Atlas if required. by partnership
response to protocols (such
evaluation and as GEF) and
discuss and share within the
findings and context of the
recommendations for Country
learning Programme
[Project Manager] Evaluation Plan.
Management
responses to
evaluations are
required to all
evaluations.
They should be
developed in
consultation
with key
59
stakeholders
and progress
made in
committed
actions need to
be tracked in
the Evaluation
Resources
Centre (ERC)
03 Identify follow-on None To ensure
actions follow-up on
[Project Manager] other aspects
discussed in the
final review
meeting, the
Project Manager
should update
the Lessons
Learned Report
to include a
brief record of
decisions and
conclusions
related to
follow-up
actions. This
updated report
should be
submitted to
the Project
Board and the
Outcome Board
in order to
update the
Country
Programme
Evaluation Plan
as required. It
could also be
shared with
stakeholders,
relevant
partners or
networks.
04 Notify operational None The project is
completion of the operationally
project completed
[Project Manager, when the last
Project Board] financed inputs
have been
provided and
60
related
activities
completed. The
Project Manager
should notify
the Project
Board, who in
turn should
notify the
Outcome Board
about the
operational
completion of
the project.
05 Operationally close Project Based on the
the project Project Status set Project Board
[Project Assurance] to “C” decision to
close the
Award Profile project, project
Status set to status in Atlas
“Closed” will be set to
“Operationally
Closed”. No
further financial
commitment
can be made
from that point
on.
06 Transfer project None Project assets,
assets and files documents,
[Project Manager] files, (if not
already
transferred)
should be
transferred to
the national
beneficiaries or
national
representatives
at this time.
07 Prepare and submit None A final financial
final financial report report is
[Project Manager] prepared by the
Project Manager
and submitted
to finance in
order to record
the
expenditures
61
made during
the last period.
08 Ensure that all Record Based on the
financial transactions expenditures as financial reports
are in Atlas per Financial received and
[Project Assurance, Report using AP recorded
Project Support] vouchers prepares the
final and submit
it to the Project
Board.
09 Review and sign final none The final report
report must be
[UNDP Programme reviewed by the
Manager, Project Board,
Implementing then signed by
Partner] finance and
Implementing
Partner,
confirming final
project financial
accounts and
expenditures.
The final
replaces the
previously
defined
procedure
known as Final
Revision.
10 Ensure project Project Closure of any
accounts are closed Project Status set project-based
[Project Assurance] to “F” financial
accounts or
funds. Once
confirmed,
project status
will be set to
“Financially
Closed”. No
further financial
transactions
can be made.
Step Who Steps/Notes
62
Upon completion of the project, it is important that
Project Manager / any Bank Guarantees issued by Project
1
Engineer Organization are requested to be returned as they
pose potential Liability.
Project Manager / Outstanding Bank Guarantees can attract a Finance
2
Engineer Charge which is charged directly to the project.
63
HADIG OVER FROM
PROJECTS TO SERVICES/
FACILITIES/
MAITEACE
64
Handing over from Projects to Services/ Facilities/ Maintenance:
1. Invite Service to Step Who Description Output

attend
Commissioning
1 Invite Service
Project
Manager to attend
2. Agree date for
commissioning
handover
2. Agree date for
Project
Manager/ Handover
Service meeting.
Sales
3. Does All relevant
the service NO
documents
team accept
the project need to be
handover? ready for the
meeting.
yes
3 Does the
4. Complete service team
Solutions to Service accept the
Handover Checklist project
and minute the handover?
meeting
If NO – go back
5. Service Sales to to step 2
establish customer
needs. If YES – go to
step 4
65

4 Complete the
Project
Manager Solutions to
5. Service Sales to
Service
establish customer Handover
needs. Checklist and
minute the
meeting.
6. Customer
decides on
5. Service Sales
standard or Service
extended warranty Sales to establish
or service contract customer
needs:
Is the
7.Does the
customer have
customer to
an account set be offered 1/
up? standard
warranty,
2/extended
warranty or
3/service
8. Set up contract.
customer account
6. Customer
Customer
decides on
9. Inform customer standard
of contract details warranty,
and call out
procedure
extended
warranty or
service
contract.
66

Note: if the
customer
requires
service over
and above
standard
warranty start
service sales
process.
7. Does the
customer
have an
account set
up?
If yes – go to
step 9
If no – go to
step 8
8. Set up
Service
Admin customer
account in
financial
system and
service
management
system
9. Inform
Service
67

Admin/FSL customer of
contract
details and
call out
procedure.
Provide the
customer with
a start-up
pack
containing
GCCC
numbers, Call
out and
dispatch
process,
details of
warranty
obligations
(call out
times,
response
times, PM
included or
excluded
,etc..).
68

Projects to Service Handover Checklist
1. PROJECT INFORMATION (Filled out by PM)
Project Name :
Project No :
Site Address :
Initial Order Sales Date :

Variation Order sales Date:
Acceptance Date :
Warranty End Date :
Initial Contract Amount (€) :
Closing Contract Amount (€) :
Account Manager / Sales Engineer
:
Project Manager / Engineer :
Site Engineer / Technician :
Ontime Delivery :
Notes
:
2. CUSTOMER AND SUBCONTRACTOR INFORMATION (Filled out by PM)
Direct Customer (Company) :

Address :
Contact Person :
Title :
Tel/Fax :
69

GSM :
e-mail :
End User (Company) :

Address :
Contact Person :
Title :
Tel/Fax :
GSM :
e-mail :
General Contractor :
Electr. Subcontractor :
Mech. Subcontractor :
Consultant :
Project Execution Team
Subcontractor :
Address :
Contact Person :
Title :
Tel/Fax :
GSM :
e-mail :
Notes
:
3. SYSTEM INFORMATION (Filled out by PM)
Main System Type :

Other systems 1 :
Other systems 2 :
70

Other systems 3 :
Other systems 4 :
Systems Installed :
Notes
:
4. HEALTH SAFETY & ENVIROMENT (Filled out by PM)
OHSE Classification :
Hazard and Risk assessment :
Site safetyplan :
Notes
:
5. SITE VISIT INFORMATION (Filled out by FSL)
Site Visit Date with FSL :

Customer Contact Person(s)
Visited :
Site Survey with FSL Done :
Full operatonal Overview :
71

Notes
:
6. DOCUMENT CHECKLIST (Checked by FSM)

* : must be submitted during handover or within 30 days after handover ** : handover critical item (if missing project cannot be handed over)
No Document Description Hardcopy Softcopy
Project agreement Contract signed with customer including complete
(contract or PO) CAP and Booking package **
3rd party agreements Contract(s) signed with 3rd party suppliers
(if any) including complete RFA and approval package, **
PO forms
Change/Variation Orders (if Additional purchases done by customer or HW

any) after the main contract **
Sales Handover Sales to solution handover form signed by Sales
Protocol Engineer, Sales Leader, PM and SSDL, including *
last agreed proposals and Page-1
Project Closing Project completion form signed by PM and SSDL,

Protocol including actuals vs estimates **
Service Contract Signed or In case service contract was signed together with
Proposal the main contract or service contract proposal
(if any) submitted
Acceptance Protocol Protocol signed by authorized customer rep
accepting Project Execution Teams system and **
documentation
Deficiency List List of system deficiencies fixed during
(if any) system acceptance, signed by PM and
customer rep, including name of owners and
deadlines
72

*
Training Protocol Training date(s) and topics, names, titles and

signatures of attendees and trainer **
Submittal Protocols Software Installation CD's, Software/PC licenses,
As-Built documents, User manuals, Equipment *
delivery protocols etc. signed by authorized
customer rep
SLA Software license agreement signed by

customer *
Meeting Notes, Site Visit Decisions taken during the progress of the project
Reports (initially not found or not described in detail in the *
main contract)
Test Protocols System installation, cabling and functional test

forms signed by authorized customer rep *
Project critical information which is usually not
Password Page found in other documents i.e.: **
* Software, hardware versions
* Software passwords (Power-On, Operating
Systems.), IP addresses etc.
* PC's (Server, station, printer), supplied by
Project Execution Team or not?
* other important subjects about the project which
may be useful for service team (i.e. critical 3rd
party products information)
System Summary Brief description of system and general operation,

As-Built system components, locations and serving areas * *
73

Scenario Detailed (system by system) principles of
As-Built operation approved by the customer * *
Riser, Block Diagram Riser diagram showing system structure, LAN
As-Built (Server, stations), controllers, field equipment and * *
(if any) integration with other systems
Large Scale Project Drawings Floor or site plans showing cable routes, system
(ACAD)As-Built locations etc. (i.e. fire detector locations and *
cabling)
Principal Schematics Flow diagrams

As-Built ** **
Equipment List List of field components, and others
As-Built ** **
Point and Field Equipment
Summary ** **
As-Built
Cable Lists Indicating cable marking, connection terminals

As-Built ** **
Equipment Installation / Wiring Detailed installation and/or wiring details for field
Details equipment (for example: pressure sensor *
(if any) installation drawing)
User Manuals In local and/or English language

(if any) *
74

Project Related Correspondence Interoffice and external correspondence
*
Complete Project Backup Backup CD including program , central software
As-Built and all other files related with the project. **
Equipment Datasheets Technical datasheets of the devices used in the

project, especially 3rd party. *
Authorization Authorization no, version, system no, database
Number Sheets size and options sold. **
Customer Satisfaction Survey Customer feedback about overall HW
(VOC) performance
Special Tools or Training
requirements
Misc. Items ie keys, logbooks, points of interest, job
pecularities or items to note by PM or FSL.
Letter to Customer Informing that project is now under service team
incl Warranty Letter responsibility, including service contact details *
(of the Project Execution Team and its Start and end date of warranty terms, detailed
subcontractors) description of warranty conditions and spare
support.
Missing Items : Owner Deadline

1
2
3
4
5
6
7
8
9
75

10
Notes
: All open actions should be resolved within 30 days after handover.
7. PROJECT HANDOVER (PM, FSL and approval)
Handover Date :
Project Binders Location :
Project Backup :
Project Data :
Project Manager :
signature
Field Service/ Facility Manager :
signature
Solution&Service Delivery
Leader(s) :
signature(s)
76

The warranty represents the process from the final acceptance by the customer including the hand-
over of the installed base to the point, where the warranty will expire.
The checklist for site handing over / customer acceptance is as below:
The project account (respectively the warranty accounts, if available) must be closed by the end of the
warranty period and after the final acceptance certificate is signed by the customer. This ensures that
all warranty costs can be charged to the applicable project account. The Project Controlling monitors;
• The total project costs, including possible warranty costs.
• The invoicing and cash collection of the final payments, following the contract.
If required, further costs as of unsatisfying performance of the delivered solution or system occurring
after the project account was closed (after the warranty period), a specific claim order respectively
variation order must be opened.
Service:
The service phase follows after the project execution phase. Immediately after the final acceptance by
the customer, the technical hand-over of the solution from the Project Manager to the Service
Department takes place. This hand-over is to be confirmed with a protocol.
A specific Service Cost Account has to be opened for all the three different service types:
• Maintenance Contracts: all costs and revenues of each individual contract have to be booked into
an individual account. The revenues have to be recognized linearly.
• Time and Material Order (on call): all costs and revenues of each individual order have to be
booked into an individual account.
• Migration and Retrofit Orders: all costs and revenues of each individual order have to be booked
into an individual account. The bigger orders are executed like a project by a specific project
manager.
If possible and with regard to a lifecycle controlling, it would be useful to have a link between the
service account and the initial project account.
77
In cases where the service costs are frozen by the customer while signing the contract the service
order should be booked in the system and copy of the contract should be marked to the concerned
service person in regions.
Cash Sale Invoicing for service calls:
It is to ensure correct process if followed when invoicing cash sale customers and to define the Inputs,
responsibilities and information flow to achieve accuracy invoicing
Note # Who Details
1 Service The job will be logged via Service call
and forwarded to a Technician to
complete work. Service PMIS will
obtain the PO upfront if the job is
during business hours. If the job is
after business hours and a PO cannot
be obtained we need written
confirmation to proceed with the job
from the customer – email will do.
2 Technician Technician will attend site and cost
the job. If job is under x amount,
suppose here it is $5,000 the
technician can commence work. If job
estimate exceeds $5,000 they need
to advise their Team Leader that job
exceeds the specified amount. In the
event that the job exceeds the $5K
limit the Team Leader will need to
give his approval for the job to
commence.
Technician completes necessary
paperwork and obtains PO if not
78
obtained by Service PMIS. The
paperwork is submitted when they
next attend the office.
3 SBU Team Check the paperwork for accuracy
Leader and completeness. This will also
ensure that Credit approval has been
obtained for jobs exceeding $5,000.
If credit approval is not given they
will contact the customer for an
upfront payment prior to work
commencing.
If they need to obtain credit approval
they need to submit an email. The
application will be assessed within
two working days.
Assuming all is in order they will then
approve the paperwork and forward
to the Branch Administrator.
4 Branch The Branch Administrator will raise
Administrator the invoice and makes it final in ERP
on the branch cash sale account.
They then forward a copy of invoice
to the customer.
The invoice must show the customer
contact details, which include;
1. Who requested the work
2. Contact phone number
3. PO number
4. Billing address
79
5. Site address where work was
carried out
The paperwork scanned into ERP and
filed.
Credit will assess all credit requests
exceeding $5K within two working
days.
Credit monitors and reviews cash sale
accounts on a weekly basis. Any final
invoices appearing on the cash sale
accounts will be followed up for
collection per the Credit SLA.
Once payment is received cash
Credit receipting process will apply.
5
Department Credit will review the SBU branch
cash sale accounts monthly with the
branch manager and administrator to
ensure that jobs and customers are in
line with this process. This should
occur by the 2nd week of every
month.
This is to ensure that repeat cash sale
customers are converted to trade AR
accounts.
If there have been more than two
spots jobs for a customer within the
Risk
6 same month then a new credit
Management
account should be established in for
the customer in accordance with the
80
Credit SLA.
This should be picked up in the
monthly review with the branch
manager.
There should be only one cash sale
account per branch per SBU. For
example, there will be one cash sale
account for PROJECT Sydney and one
for PROJECT Newcastle.
This will help control and monitor
credit limits, cash sales, and invoicing
and cash application. This will also
reduce administration costs.
81
PROJECT SUCCESS:
FOUND IN THE
EYE OF THE
BEHOLDER
82
Project Success: Found in the Eye of the Beholder
Thanks POME, I got
my basics straight!!!!
Am going to win
Was your last project a success? The answer may very well depend upon who is asked, and their
particular definition of success. As a project manager, (or someone who finds themselves managing
projects), you may expect that if you complete a project on time, within budget, and your end-result
works, that you will have achieved success. This seems logical, but it not always true.
Consider this example.....
83
A project is completed on time, the end-result works, and the budget was met, but the project team
had to work extra hours and every weekend for two months because the project schedule was overly
aggressive and the project plan did not properly account for problems. Was this project a success....?
The answer is likely something along the lines of "it depends", "yes, but...." or "not in every respect".
In any event, it would be difficult to view this project as a success on all counts. As this example
shows, project success cannot be viewed from a single perspective. Your end-users may not even
know or care that your project was not planned well as long as the end-result works. But to your
burnt-out project team, that same project could hardly be called a success. And, this is not only an
important issue of the moment. If the project team is burnt-out, the next project manager who must
rely on that same team for future successes may have real cause for concern. As this one example
illustrates, your ability to consider a project a "success" will go well beyond immediate budgets and
deliverables.
Considering that success can be so subjective, it is wise to not limit yourself to a single definition.
Instead, the creative, but realistic project manager should promote a different concept.... that projects
can be successful on many levels, and that a failure on any particular level is not necessarily
determinative of overall success, or failure.
WORKING TOWARDS PROJECT SUCCESS.....
The true definition of project success arises from multiple perspectives, and will vary from project to
project. Any examination of success should not begin at the end of a project, but at the very start.
Success begins with consensus amongst all project participants and stakeholders ..... what will it take
to make this project a success?
The answer to this question will form your success criteria - the agreement between all parties as to
the meaning of "success" for a given project. Success criteria should be defined from the start as a
basis for project initiation - along with goals, deliverables, scope and requirements. It is an important
project element .... you need to know what you are working towards, and you also need to know that
everyone is on the same page "success-wise".
Any useful definition of success criteria should account for variations in perspectives and dimensions.
To that end, success criteria can be viewed from three distinct points of view ....
• Deliverables Success - relating to the end-result of the project (products or services), including
issues of quality and fulfillment of requirements.
• Procedural Success - relating to the way the project was organized, structured and managed,
including timeliness, cost control, effectiveness of the project plan, and adherence to
established project management standards.
• Staff Success - relating to the "human resource" elements of the project, including resource
utilization, staff perspectives, interactions and team relationships.
84
These three categories set the stage for the definition of workable success criteria, but underlying
specifics will probably vary according to the project at hand. For that reason, success criteria should
be created for each and every project encountered, and should be tailored to suit individual project
circumstances. Above all, success criteria should be simple and attainable. And, once defined, they
should also be ranked according to priority.
The issue of priority may seem a bit illogical, after all, your overall goal should be for success on all
levels, right......? We can all agree on that goal, but unfortunately, even the best of intentions run up
against unexpected problems now and then. If hard choices have to made in the midst of a project,
success criteria priorities can provide a basis for sacrifice ..... For example, if your project participants
have established the quality of deliverables as a priority over timeliness, you will have some clue as to
how to react should project delays occur.
The following list provides an illustration of the use of multi-dimensional project success criteria:
• Project deliverables are to be delivered according to requirements and specifications.
(Deliverables Success)
• The project is to completed with no more than 10% schedule overruns. (Procedural Success)
• Project expenditures are not to exceed the estimated budget by more than 10%. (Procedural
Success)
• The project management process is to be followed without exception unless authorized by the
Project Director. (Procedural Success)
• Project change requests shall not be allowed to interfere with project schedule or budget.
(Procedural Success)
• Project staff resources are to be utilized effectively, and will acquire new skills as a result of the
project. (Staff Success)
• Project overtime shall not exceed estimations by more than 5%. (Staff Success)
EVALUATING SUCCESS.....
At the end of a project, success criteria can be used as basis for evaluating project performance. And,
if you looked at success from a single perspective, you would miss important indicators for future
performance improvements. As we have previously discussed, projects can fail or succeed on any
number of elements, and can still be considered a success if overall priorities and objectives are met.
But that does not mean that there is no further room for improvement. As you go through your post-
project review, you can use your success criteria as a benchmark for evaluating overall project
performance....
• Were success criteria met?
85
• If the answer is yes, how was that accomplished, and how can we ensure that our successes
are repeated?
• If the answer is no, why did we fail to meet our success criteria?
• Which criteria did we fail to meet?
• Why did each failure occur?
• Were the success criteria realistic and attainable?
• What improvements can be made in the future to the way we plan deliverables, execute
projects or utilize project staff resources?
Concluded Note:
Success is the obvious goal of every project .... but it should not be an unspoken goal, nor should it be
taken for granted. If you take the time to consider success from multiple perspectives, you will make
future project successes more likely and easier to attain.
POME LIGHTER VEI:
86
87
OTHER PROJECT
OPERATIONS
DOCUMENT
TEMPLATES
88
Project Operations Documentation Templates:
The forms as appropriate. Please note, completing the forms is an aid to help you deliver your
projects, not an end in itself.
These project management templates have been produced for open distribution to anyone. Please feel
free to pass them onto friends or colleagues. The forms have been used by professional staff at all
levels – staff who have to deliver projects. Some of these projects are small quick delivery (less than a
month), others large long term projects which cost significant sums of money.
We would be delighted to hear how you used these forms and how useful they were in supporting the
delivery of your project.
89
Defining Project Responsibilities Sample Matrix:
PERSONNEL
TASKS/ACTIVITIES
90

Stakeholder Analysis Sample Matrix:
The purpose of stakeholder analysis is to inform the project manager and sponsor who should contribute to the project, where barriers might
be, and the actions that need to be taken prior to detailed project planning.
Stakeholder Their interest or What the project needs Perceived attitudes Actions to take
from them and/or risks
requirement from the
project
91

92

Milestone Chart Sample Matrix:
Main milestones/phases shown on higher chart, and sub-milestones for each phase on charts below
TIME [in suitable units -days, weeks, months, etc.]
MILESTONES Responsibility
93

94

Sub Milestone Report Sample Matrix:
Project:
Date of Milestone meeting/discussion:
Deliverables due Due R/A/G Action to take to bring deliverable or task back on schedule
date *
95

* R = Red flags [off plan - describe in detail: quality, cost, time]
96

A = Amber [is almost off schedule or will definitely be off schedule NOTE: you may need to agree the precise definition before
use]
G = Green flags [to plan or better - show savings]
97

Variation Form Sample Matrix:
Activity Description Date to Revised Reason for delay. Effect on project

name /No. be est.
Q/C/T? Explain
delivered
Q/C/T
98

Note: Q: Quality; C: Cost; T: Time
Signed: Project Sponsor
Project Manager
Date
99

100

The Risk Management Process:
Risk Analysis Sample Matrix:
Score as follows, for Likelihood and Impact: High = 3, Medium = 2, Low = 1
Nature of Likelihood Impact Likelihood Actions required and who will
Risk or take responsibility to manage
High/ High/ x Impact
Uncertainty the risk
Medium/ Medium/ [Score]
Low Low
101
Business Case Form Sample Matrix:
Please complete the form below and submit it to your project sponsor.
Background to the project (PLEASE KEEP BRIEF)
General aims(s)
102
Initial Risks
Expected Outcomes
Benefits of running with this project
Initial estimates of cost and time
£:
Time:
Outcome of the business case
Decision from (x x)
103
Date
104
Project Definition Form [or PID]
Project Title: Put here a very brief Sponsor: Insert actual sponsor name
title
State below the link with the corporate agenda – the actual wording please.
Put here the actual words in the corporate agenda – showing the link with this project
Project Background: The background to the project. Enough information to inform the
reader.
Project Benefits: An outline of what the benefits are to the organisation, individuals or
stakeholders in delivering the project
Project Objectives: The specific objectives for the project. NOTE: the objectives can be
one line or more detailed text.
Project Deliverables: What you will be delivering at the end of the project. NOTE: these are
the what you will have at the end of the project, e.g. a report, a
building, improved service levels etc.
105
This project will include: This project will not include:
This section defines the boundaries of the Planning details should not be included at this stage.
project.
Success Criteria: How you will measure the success of the project. NOTE: the success
criteria must be measurable.
Constraints: Examples here can be specific (a skill which the project team must
have) resources, or a legal deadline – NOTE: only include time and
money if you can quantify them.
Key Assumptions: The assumptions you are making in putting this document together.
Project Manager: Who fulfils this role and what they do.
Project Sponsor: Who fulfils this role and what they do.
106
Project Who fulfils these Project Team
Board/Steering roles and what they Members:
Group Members: do. NOTE: may not
be appropriate for
all projects

Budget
Resource Costs: Other Costs:
Total costs (attach a breakdown of the overall budget)
• VAT*– Some projects may have important VAT issues. Have you spoken to accountancy to
discuss these?
• Other Taxes issues
Start Date: Completion Date:
Signature of Project Date:
Manager:
Approval from Sponsor: Date:
107
For your organisation, you will need to liaise with your Finance people in order to develop
financial information that will inform project delivery. The data on this form in relation to
finance needs to be fine tuned to your organisational and project management needs
108
Project Reporting Form Sample Matrix:
Project Title: Number:
Project Sponsor: Project Manager:
Progress Report Report No.
RAG Status*: RED / AMBER / GREEN
Headlines
Tasks, Milestones, Outcomes delivered this period Completion dates
Tasks, Milestones, Outcomes Comments Plan Actual
Major Risks and Issues Include an assessment of the impact and any actions taken
Recommendations and Requests for Decisions or Support
Tasks, Milestones, Outcomes scheduled for next Completion dates
109
period
Tasks, Milestones, Outcomes Comments Plan Forecast
* RED "Major concern - escalate to the next level” Slippage greater than 10% of remaining
time or budget, or quality severely compromised. Corrective Action not in place, or
not effective. Unlikely to deliver on time to budget or quality requirements
AMBER "Minor concern – being actively managed” Slippage less than 10% of remaining time
or budget, or quality impact is minor. Remedial plan in place.
GREEN "Normal level of attention” No material slippage. No additional attention needed
110
Highlight/Progress Report
Project Name: PROJECT NAME
Reporting Period: Project Manager: Project Sponsor:
Project
RAG Status R 0
Prepared by: Date Prepared: Phase:
Project Description: Project End Date: dd/mm/yyyy
Key Deliverables for next reporting

Key Deliverables Completed this period Key Deliverables Outstanding this period
period
Deliver Delivery
y Date Date
Risk Management Issue Management Change Management
Log No Risk Action/Status Log No Issue Action/Status Req No Details Approve
111

Financial Statement
Capital Revenue External
Foreca Rema
Source Budget Actual Remaining Forecast Source Budget Actual Remaining st Source Budget Actual ining Forecas
0 0 0
112

Change Control Sheet Sample Matrix:
Project Manager
CHANGE REQUEST
Originator Date of request Change request no.
Phone: allocated by Change
Controller
Items to be changed Reference(s)
Description of change (reasons for change, benefits, date required)
Estimated cost and time to implement (quotation attached? Yes No )
Priority / Constraints (impact on other deliverables, implications of not proceeding, risks)
CHANGE EVALUATION
What is affected Work required (resources, costs, dates)
Related change requests
Name of evaluator Date evaluated Signature
CHANGE APPROVAL
Accepted Rejected Name Signed Date
Deferred
Comments
CHANGE IMPLEMENTATION
Asset Implementer Date Signature
completed
Change Control Log Sample Matrix:
Project Manager
Chang Description of change Date Date Date Date
e received evaluate approved complete
numbe d d
r
Actual V Planned Sample Matrix:
Activity Planned Actual Difference Planned Actual Difference
Time Time
Cost Cost
114
Project Management - Check Sheet Amend this Check Sheet to suit your project
A: SET UP - INITIATION Y N COMMENTS 13 Have you identified the critical path for the
project?
14 Have you developed a communications

5 Developed the business case?
plan and included its component parts into
6 Is a full options appraisal necessary?
the Gantt charts?
7 Is the project in line with the strategic
15 Are you continuing to carry out risk
plan?
analysis throughout the project?
8 Has the project received sign off by
16 Are quality standards high? How do you
sponsor or project board?
know?
B: SET UP - DEFINITION
D: DELIVERY
10 Has a PID or project definition form been

7 Have you identified the appropriate type of
completed?
control – loose versus tight?
11 Are roles explicit and documented?
8 Project reporting – are you clear who
12 Are levels of authority clear? reports what and to whom and how?
13 Have you carried out a stakeholder 9 Do you have a clear procedure for
analysis and planned accordingly? managing change?
14 Have you assessed risks and put a plan 10 Have you developed a planned versus
into action to monitor them? actual schedule? How up to date is it?
15 Are you clear what is driving the project 11 Tolerance – have you an agreed tolerance
Quality, Cost or Time (1 only) figure?

16 Have clear project review procedures 12 Variations – are these quickly flagged?
been established?
17 Has planning started for a start up

E: CLOSEDOWN AND REVIEW
workshop (or series of workshops)?
18 Team selection - have you got the correct

6 Post project review has been planned?
mix of skills and professional experience?
7 Learning identified?
8 Is the project still delivering the benefits

C: DELIVERY PLANNING
intended?
9 Is there a case for abandoning the project

9 Have you broken the project down into its
– off schedule or delivered a significant
component parts – work breakdown
part of it?
10 How accurate are your estimates? If a low
10 End of project review reports are produced
percentages then recalculate.
and circulated?
11 Have you developed a milestone chart or
produced a Gantt chart?
12 Have you developed an overall project
budget? Have you sought advice from

financial experts
116

Organization Radar Plot Template
Project Name: Prepared By: Date:
1. This tool is intended to help the organization determine how ready it is for the agile project
management environment. The weights that have been assigned to each characteristic have
been determined from industry best practices. The compatibility indicator value is derived by
multiplying the ranking provided by you with the weight of that characteristic divided by 100
(Value = Rate x Weight/100).
2. The radar plots are designed with 0 as the benchmark. So the farther away from the center
(or 0) a score is, the more comfortable you and your customers are in an agile environment.
3. To use the tool, all that is required is for you to answer the questions in the Organization
Worksheet. The tool will calculate the compatibility level and plot a radar graph.
4. The ratings are 0 through 5. Please keep the ratings to whole numbers.
0: Not at all
1: Minimal
2: Somewhat
3: Average
4: Above Average
5: Competitive Advantage
5. To calculate the Compatibility Indicator manually, total up all the numbers in the Value
column and round up to the nearest whole number.
6. To plot the Radar Graph manually, start at the center and place a dot on the line that
corresponds to the rating of the respective characteristic. Continue this for all the
characteristics. Once all the ratings for the characteristics have been plotted, start with the top
dot (12:00 position) and connect the dots in a clockwise fashion. Once the dots have been
connected, shade the inner portion of the radar shape.
118
Organization Radar Plot Worksheet
Rating Value
Organization Question
Weight Description Scale Value = Rating x
Characteristics Number
(0-5) Weight/100
Degree to which the organization values innovation
Innovative 23.0 1 and creativity over organizational stability 0 0.0
Degree to which the organization can make
independent, product-related decisions without
Independent 21.0 2 consulting other organizations 0 0.0
Organization's willingness to accept and work with
Risk Tolerance 13.0 3 uncertainty 0 0.0
Organization's ability to allocate resources full time to
Resource Allocation 10.0 4 one project rather than assign to multiple projects 0 0.0
Organization's ability to understand and embrace
multiple approaches to documentation and measuring
Flexibility 15.0 5 project progress 0 0.0
Degree to which the organization is able to partner
Customer Focus 18.0 6 with their customers 0 0.0
Organization Compatibility Indicator 0

The ratings are 0 through 5. Please keep the ratings to whole numbers.
0: Not at all
1: Minimal
2: Somewhat
3: Average
4: Above Average
Organization Radar Graph
NOTE: The higher the score the better it is for an agile environment.
Explanation for the Organization Compatibility Indicator:
5 = Organization is highly supportive of an agile environment
4 = Organization is interested in supporting agile projects, but needs proof
3 = Organization is exploring the possibility of agile projects
2 = Organization supports agile development if it doesn't interfere with the current
delivery of projects
1 = Organization allows agile development "under the radar"
0 = Organization does not support agile development
Summary Radar Plot Template
1. This tool is intended to help the project team determine the overall propensity for supporting
an agile environment. The weights that have been assigned to each characteristic have been
determined from industry best practices. The compatibility indicator value is derived by
multiplying the compatibility indicator from the respective assessments provided by you with
the weight of that characteristic divided by 100 (Value = Compatibility Indicator x Weight/100).
2. The radar plots are designed with 0 as the benchmark. So the farther away from the center
(or 0) a score is, the more compatible your organization is with the agile environment.
3. To use the tool, enter in the compatibility indicators from the previous worksheets into the
Summary Worksheet. The tool will calculate the overall compatibility indicator level and plot a
radar graph.
121
0: Not at all
1: Minimal
2: Somewhat
3: Average
4: Above Average
Summary Radar Plot Worksheet
Compatibility
Indicator Value
Organization Question (Insert Value = Compatibility
Weight Description
Characteristics Number Score from Indicator x
Respective Weight/100
Assessment)
Degree to which the
organization supports an agile
Organization 25.0 1 environment 0 0.0
Degree to which the team is
Team Readiness 25.0 2 ready for an agile environment 0 0.0
Degree to which project
managers will be successful in
Project Manager 25.0 3 an agile environment 0 0.0
122
Degree to which the
stakeholder supports an agile
Stakeholder 25.0 4 environment 0 0.0
Summary Compatibility
Indicator 0
Summary Radar Graph
Explanation for the Summary Compatibility Indicator:
5 = Organization is highly supportive of an agile environment
123
4 = Organization is interested in supporting agile projects, but needs proof
3 = Organization is exploring the possibility of agile projects
2 = Organization supports agile development if it doesn't interfere with the current
delivery of projects
1 = Organization allows agile development "under the radar"
0 = Organization does not support agile development
Team Radar Plot Template
1. This tool is intended to help the project team determine their level of proficiency for working
in an agile environment. The weights that have been assigned to each characteristic have been
determined from industry best practices. The compatibility indicator value is derived by
multiplying the ranking provided by you with the weight of that characteristic divided by 100
(Value = Rate x Weight/100).
2. The radar plots are designed with 0 as the benchmark. So the farther away from 0 a score is
from the center, the more compatible your team is with the agile environment.
3. To use the tool, all that is required is for you to answer the questions in the Team
Worksheet. The tool will calculate the compatibility level and plot a radar graph.
0: Not at all
1: Minimal
2: Somewhat
3: Average
4: Above Average
124
Team Radar Plot Worksheet
Rating Value
Team Question
Weight Description Scale Value = Rating x
Characteristic Number
(0–5) Weight/100
Team members' ability to make
Autonomy 15.3 1 independent decisions 0 0.0
Team members' commitment and
capability to collaborate and work as
Cohesiveness 18.0 2 a group 0 0.0
Degree to which the team members
Co-location 12.7 3 can communicate in person 0 0.0
Degree to which the customer is
Customer willing and able to become a team
Participation 23.3 4 member 0 0.0
Team members' ability to problem
Creativity 20.7 5 solve and come up with new ideas 0 0.0
Team members' knowledge and
experience with the application area
and the tools for creating the project
Skill Level 10.0 6 result 0 0.0
Team Readiness Compatibility
Indicator 0
125
The ratings are 0 through 5. Please keep the ratings to whole numbers.
0: Not at all
1: Minimal
2: Somewhat
3: Average
4: Above Average
Team Radar Graph
Explanation for the Team Compatibility Indicator:
5 = Team has all the characteristics to be successful in an agile environment
126
4 = Team has many of the key characteristics to be successful in an agile
environment
3 = Team will need to change some aspects of their style to be successful
2 = Team will need guidance to be successful in an agile project
1 = Team will find it difficult to work on an agile project
0 = Team does not have the requisite skills or demeanor to work on an agile project
TOOL
Analyzing Patterns of Participation (1)
Directions: To analyze patterns of communication and participation among team members, complete this chart for
approximately 10–15 minutes in the middle of the meeting. Draw an arrow between team members (in the
direction of the communication) each time communication occurs. The completed chart will show you patterns of
communication among team members, graphically displaying which lines of communication are open, which are
closed, which may be over or under used.
10. _________ 1. __________
9. __________ 2. __________
8. __________ 3. __________
7. __________ 4. __________
6. __________ 5. __________
127
Notes:
TOOL
Directions: To analyze influence and patterns of participation among team members, complete this chart for
approximately 10–15 minutes in the middle of the meeting. Place a tic mark in the Spoke column each time a team
member initiates a communication thread. Place a tic mark in the Responded To column each time someone
responds to the team member. The completed chart will show you patterns of influence such as team members
who contribute frequently but are ignored, and team members who have a great deal of influence and are
responded to frequently.
Team Member Spoke Responded To
1.
2.
3.
4.
5.
6.
128
Team Member Spoke Responded To
7.
8.
9.
10.
Notes:
TOOL
Directions: To analyze team behaviors and patterns of participation among team members, complete this chart for
approximately 10–15 minutes in the middle of the meeting. Place a tic mark in the appropriate column each time a
team member exhibits each type of behavior. The completed chart helps the leader and the team members
understand the types of contributions the team members are making.
Team Member Task Encouraging Self-Oriented
11.
12.
13.
129
Team Member Task Encouraging Self-Oriented
14.
15.
16.
17.
18.
19.
20.
Notes:
TOOL
Communication Plan—With Program Extensions
Program Name Program Ref. No. Prepared By (print) Preparer’s
Initials
Customer Contact Contact’s Phone Date
Prepared
130
1.0 Communication plan overview
1.1 Document intent
1.2 Document intended audience
1.3 Document change procedures
2.0 Goals and objectives of the plan
3.0 Program and project communication standards
3.1 sms use and response
3.2 Cell phone use and response
3.3 Voice mail response
3.4 E-mail response
4.0 Teams and team members
4.1 Team name
4.2 Team objectives
4.3 Team leader
4.4 Team members and roles
5.0 Levels of information and communication
5.1 Customer status reporting standards
5.2 Program team status and issue reporting standards
6.0 Executive and other stakeholder reports
6.1 Standard report layouts
6.2 Sources of report information
7.0 Executive meetings
7.1 Meeting schedule
7.2 Meeting agenda
8.0 Summary reports (content and distribution)
131
8.1 Standard summary report layout
8.2 Frequency
8.3 Recipients
9.0 Cost reports (content and distribution)
9.1 Standard cost report layout
9.2 Frequency
9.3 Recipients
10.0 Deliverable reports (content and distribution)
10.1 Standard deliverable report layout
10.2 Frequency
10.3 Recipients
11.0 Detailed communication process
11.1 Issue communication
11.2 Change request communication
11.3 Scope change communication
11.4 Reprioritization assessment communication
12.0 Communication tools
12.1 Use of e-mail (What communicated? When used?)
12.2 Use of teleconferences (What communicated? When used?)
12.3 Use of in-person meetings (What communicated? When used?)
13.0 Tool formats
13.1 Statement of work structure
13.2 Project plan formats
13.3 Task assignment worksheets
14.0 Standard meetings
14.1 Agendas
132
14.2 Attendees
14.3 Attendance policy, decision-making policies
15.0 Ad hoc meeting processes
15.1 When called
15.2 How communicated
15.3 Attendance policy, decision-making policies
133
16.0 Web page or generally available program information repository
16.1 Address
16.2 Update frequency
16.3 Update policies, document control
17.0 Team building events
18.0 Mentoring processes
18.1 Mentor listing
18.2 Mentor and mentee goals
18.3 Mentor and mentee meeting log
19.0 Conflict management process
20.0 Sign-off processes (for customer authorization and so on)
21.0 Issues resolution
21.1 Process
21.2 Meetings, agenda
21.3 Logs
22.0 Program glossary of terms
23.0 Process for assigning work items to senior managers or sponsors
PROGRAM EXTENSIONS
24.0 Program change logs—strategic alterations
25.0 Strategic alignment verification/meetings/status
25.1 Process
25.3 Logs
26.0 Vendor management communication
134
26.1 Process
26.3 Logs
27.0 Process models analysis
27.1 Documentation standards
27.2 Meetings
27.3 Verification and sign-off
28.0 Market research
28.1 Process
28.3 Logs
29.0 Business (organization) function specific change planning and reviews
30.0 Executive status reports
31.0 Executive steering committee
31.1 Process
31.3 Logs
32.0 Program objective
32.1 Business strategies
32.2 Customers
32.3 Internal drivers
32.4 External drivers
TOOL
135
Organizational Change Assessment
Initials
Prepared
Rank 1– Multiplie
Requirements 5 r Score Remarks
Staffing levels 1
Number of teams
Number of vendor organizations
Number of vendor personnel
Number of internal departments
represented
Mission changes 3
Number of organizations (divisions,
units) affected
Number of new products or customer
relationships
Competitive environment 3
New product turnaround time
“Leap-frog” risk
Market changes 3
Viability of product
Product demand issues
Product supply issues
Raw material issues
136
Process changes 1
Number of process changes
Number of new processes
Business metrics changes 1
Number of new metrics
Number of changed metrics
Business change complexity 3
Number of new processes
Number of new interactions
Number of new customer support
processes
Number of new products or services
137
Technical complexity 2
Number of new interfaces
Number of new technologies
Number of platforms involved in
solution
E-business elements
Cost of initiative 1
Percentage of sponsoring unit’s
budget
Overall $$
Power shifts within the organization as result 2
of deliverables
New managers
Responsibility changes or “shifts”
TOTAL SCORE
Rank. On a scale of 1–5 score each area (where the subelements describe characteristics of changes in that area)
relative to other projects/programs or initiatives in your organization. A score of “3” means the area is equal to
most of the initiatives in our environment, “1” means it is much less significant, and “5” means it is substantially
more significant.
Multiplier. Multiply your rank for each area by this number to get the Score for each area. This multiplier is
intended to help prioritize these benefits and costs for the organization. The multiplier itself can and should be
changed to reflect the priorities of the sponsoring organization.
Sum the scores in the column to determine the Total Score for the assessment and compare the result to the table
below.
50 points or less—Typical business change
Between 50-75 points—Significant business change
138
76 points or greater—Substantial business change
The score will determine your implementation strategy.
TOOL
Program/Initiative Prioritization Scoring Tool
Initials
Prepared
Program Benefit/Motivation Score
Financial Implications
Overall cost savings—1 point per $50,000 forecast
Overall revenue generation—1 point per $50,000 forecast
Each of the above can receive up to 20 points
Position Against Competitors
Positions even with competitors—1 point
Positions ahead of competitors 1–6 months—3 points
Positions ahead of competitors 6 months or more—10 points
Marketplace Perception
Positive press for 1 month—1 point
139
Positive press for 1–6 months—2 points
Positive press for 6 months or more—3 points
(Opposite applies—negative points for less than favorable
press)
Compliance Issues
Closes compliance issue—20 points
“Step towards” compliance—3 points
Political Objectives
Positive advancement—possible revenue—10 points
Positive advancement—good standing with decision maker—5
points
(Opposite applies—negative points for less then favorable political
consequence)
Total Score
TOOL
Program Reprioritization Steps Checklist
Initials
Prepared
140
Condition: Resource Shortages
Research the resource needs across each project in the program
Determine the impact on the critical path and the “cross project links”
Determine cost of contracting skill, including appropriate training and acclamation
Calculate return on investment (ROI) for the program based on cost differences
Estimate the impact of delaying program completion and recalculate ROI
Condition: Senior Management Changes
Ensure that the current senior management perspective is reflected in program status
Update the stakeholder values table with the new manager
Present program merits and how the program will meet the items in the stakeholder values table
Listen carefully for impressions, priorities, and other items of interest to the new manager
Weigh the benefits and costs of any program changes that might apply
Change any communication plans as appropriate
Condition: Reorganization
Work with sponsors (or sponsors’ replacements) to understand responsibilities
Review and revise stakeholder identification and analysis process; recreate as needed
Create new stakeholder values tables for each new major stakeholder
Press on with the program while you perform these steps
Reestablish signature authority and sources of funding
Condition: Mission Changes or Alterations
Approach sponsors and obtain their impressions about the future of the program
Assess benefits and consequences of making any necessary changes to the program
Prepare new stakeholder values tables and status reports that are mindful of new mission
Obtain the sign-offs required to proceed, including new funding agreements, and requirements
Communicate changes to all stakeholders and team members
Condition: Stock or Valuation Change
Approach sponsors and obtain their impressions about the future of the program
Assess benefits and consequences of making necessary changes to the program
Prepare new status reports and review them with major stakeholders
TOOL
141
Project Link Tracking Tool
Initials
Prepared
Project From/To Link Owner— Description Strategic
Type Responsible for objective
Managing supported
Link Types
• Task-level—Dependencies between tasks that reside in different project plans
• Event—A link that causes some action to be taken in other projects as a result of an event
• Action—A risk mitigation action that needs to be cascaded across projects in the program
• Resource-level—Actions across projects taken due to delayed or early resource availability
142
Sample Project Link Tracking Tool
Initials
Prepared
Project From/To Link Owner— Description Strategic
Type Responsible for objective
Managing supported
Construction/Infrastructure Task PM, Construction Riser supports built Best in class
level project and tested; alert from
infrastructure that construction
cabling can be start to “in-
started business”
operation
Link Types
• Task-level—Dependencies between tasks that reside in different project plans
• Event—A link that causes some action to be taken in other projects as a result of an event
• Action—A risk mitigation action that needs to be cascaded across projects in the program
143
• Resource-level—Actions across projects taken due to delayed or early resource availability
TOOL
Question List for Project Plan Evaluation/Approval
Project Name Project Ref. No. Prepared By (print) Preparer’s
Initials
Prepared
N/
Requirements Yes No A Remarks
1. Were the requirements developed by
knowledgeable customers?
2. Has a gap analysis been conducted to evaluate
completeness of the requirements?
3. What is the confidence level that the
requirements are accurate and complete?
4. Are the requirements built with appropriate
flexibility to handle change at the program
level?
5. Are performance expectations included as part
of the requirements? Are they achievable?
6. Are the performance levels requested
achievable without planned technology
advances?
7. Are the priority and flexibility of the triple
144
constraints known and agreed to by the
customer? Are they in synch with the program
at large?
N/
Project Plan Elements Yes No A Remarks
1. Does adequate time exist to develop
deliverables without broad assumptions?
2. Will knowledgeable customer personnel be
accessible to participate in the project?
3. Are those customer resources committed by
name in the project plan?
4. Is the correct balance of in-house and vendor
resources presented as part of the project
plan?
5. Is an appropriate amount of project
management incorporated into the plan?
6. Are appropriate interproject relationships
established and appropriate links added to the
plan?
7. Are those links reflected in any referenced
project plan?
8. Have all SOWs in the project undergone the
appropriate reviews at the project and
program level?
9. Are appropriate teaming, mentoring, and
training elements included in the plan at the
project and program level?
10. Are project estimates derived using
dependable sources and methods?
Project Plan Elements (continued) N/ Remarks
Yes No A
145
11. Are there dependencies in the project that
involve the customer? Are those dependencies
significant?
12. Has the customer reviewed all dependencies
and agreed to them?
13. Have key personnel from other organizations
and vendors been committed to the project by
name?
14. Are any project assumptions included in the
project plan documented, reviewed, and
agreed to by the customer?
15. Has a project glossary been created and
reviewed by team members and the customer?
16. Are the program metrics incorporated into the
project and is the administration in place to
collect and evaluate them?
17. Who will be judging project integrity from the
customer environment, and is their agenda
understood?
18. Is the appropriate support structure in place,
or does the project plan account for building
support for deliverables as a result of this
project?
N/
Deliverables Yes No A Remarks
1. Is appropriate risk built in for new technology
or new solutions to produce deliverables?
2. Is the solution considered straightforward or of
medium or high complexity? Is this
documented with appropriate contingency?
3. Does the solution consist of entirely standard
146
components or will customization be needed?
If so, is it planned in detail?
4. Does an appropriate environment exist to test
the solution? If not, are plans adequate to
create that environment?
5. Has the customer’s infrastructure been
evaluated to determine the effects the project
may have on the environment?
N/
Implementation Yes No A Remarks
1. Is appropriate testing included in the project
plan? Is the customer community included?
2. Are the testing and completion criteria
documented and agreed to?
3. Does the customer understand the level of
training that must occur for the solution to be
effective? Is that training in the project plan?
4. Does a deliverable acceptance plan exist? If
not, is it part of the plan and is there adequate
time to react to the results of the analysis it
yields?
5. Does the project plan include appropriate
installation and transition plans?
147
Implementation (continued) N/
Yes No A Remarks
6. How could customer environment changes
affect the project and the program?
7. Will the customer have critical or confidential
data involved in the installation? Will that
restrict the project team or vendors during
installation?
8. Have the people who are responsible for
customer infrastructure management ever
been involved in an installation of this type?
9. Have appropriate test cases been created to
test the deliverables? Has the customer
created or approved them?
10. Are backup or back-out plans included in any
installation plans?
TOOL
Stakeholder Values Table
Program/Project Name Program/Project Ref. No. Prepared By (print) Preparer’s
Initials
Prepared
Stakeholder name:
Metric Types
148
Stakeholder
Values
(Priority Order)
149
Tool
Stakeholder Values Table—Sample
Stakeholder name Tom Manufacturer
Metric Types
Stakeholder Average time Manufacturing Average duration—design
value (priority for vehicle cost per vehicle change request
order) build accommodated in
manufacturing
Manufacturing Reduce by 1 day
production rate
increase
Decreased $3000 less per
manufacturing vehicle
cost
Ability to Interim cost 30 days
accommodate increase <= 5%
design changes
150
Action Plan
Name Date
What? Who? When? Where? How? Why? Done

What? Who? When? Where? How? Why? Done
152

Analysis Risk Checklist
Project Name Project Reference Prepared By (print) Preparer’s
Number Initials
Customer Contact Contact’s Phone # Date
Prepared
With the help of the Analysis team, the business analyst needs to identify all possible risks
that could affect the Analysis phase. As you create estimates from the work breakdown
structure (WBS), ask yourself the following questions:
1. What is the risk?
Creep in product vision and scope
Pressure to limit analysis so that development can begin
Quality of requirements elicitation and documentation
Highly innovative products with few or no precedents
Glossing over nonfunctional requirements, such as performance, usability, and
speed
Stakeholder agreement on requirements
Assuming legacy system is a good requirements baseline
Solutions presented as requirements
Comments:
2. Are there issues that might cause serious problems in terms of—
Vision or scope creep
Cost
Schedule
Resources (management, the customer, the Analysis team, HR, material resources)
Comments:
© ESI
3. Do you foresee any concerns during the Analysis in terms of—
Safety
Security
Compliance with regulatory agencies, codes, or guidelines
Data ownership
Compatibility or technologies
Comments:
4. Can any part of the Analysis damage—
The reputation of sponsoring organization
The customer’s reputation
The relationship with existing vendors or business partners
Future opportunities
Existing organizational infrastructure
Comments:
5. What is the worst external catastrophe that would directly affect this project?
6. Are there any little problems that could have a lasting negative impact on the
organization, even though they do not create major conflict?
7. What are the impacts of each risk (low, medium, high)?
8. What are some possible risk triggers?
9. How do you plan to respond to each listed situation (for threats: avoid, transfer,
mitigate, or accept; for opportunities: accept, enhance, exploit, or share).
10. How would you rate the project’s chances of success? Why?
© ESI
• Assessing Preferred Learning Styles
In situations where you are using either a Direct or an Advise coaching style, you’re helping
another person learn how to do something better. But not everyone learns the same way.
Wherever possible, factor in what you know about the other person’s preferred learning
style in how you delegate work. Listed below are the most common learning styles.
The learning Means… So the coach should…
style…
Hear The auditory learner prefers to Take the time to carefully explain
learn by listening to instruction both expectations and recommended
or ideas approaches for completing the
assignment
See The visual learner prefers to Provide plenty of examples of how
learn by seeing a the completed assignment should
demonstration or example look
Try The kinesthetic or tactile Create opportunities for the person to
learner prefers to learn by practice completing elements of the
physically trying or doing assignment in the coach’s presence
Discuss The verbal learner prefers to Ask questions to encourage the
learn through conversation and person to reflect on the assignment
dialogue and to express his or her questions
or ideas
© ESI
1.Assessing the Performance Level of Others
Job/Position Title: ________ Time in Job/Position: ______
Name: _________________
Tasks Performance Level Evidence of Performance
Level
© ESI
1.Audience Analysis
Prepared by Date
© ESI
As a Group or as Concerns/Issues Solutions
an Individual
1. Who (for example, 1.
position, 2.
communication style,
3.
or other identifiers)
(as needed)
2. Current knowledge
3. Required
knowledge
1.Basic Requirements Checklist
Project Name Project Ref. No. Prepared By (print) Preparer’s
Initials
Prepared
© ESI
Authority
Who’s in charge here (who’s the PM)?
Who is in charge of the project manager?
Market
What’s the anticipated price?
What consumer market is targeted?
What are the customer benefits?
Who is the competition?
What competitive advantage does it present?
How does it differ from other similar products?
What research has been done on the product and its customer base?
Are there existing market surveys?
What is the intended market?
What are the advertising plans?
What is the market entry strategy?
Could it be used in other market segments?
What is the appropriate sales channel? Distribution methodology?
Are there discount plans?
Have you conducted a trademark search?
Is this the only product of its kind?
Why hasn’t the product been introduced before?
Why are you interested in the market you’ve selected?
Why did you select this product?
What will people love? Talk about?
What do you want people to experience in using this?
What is the perceived benefit of this product?
What is the value added for the consumer?
What’s motivating you in this market?
What’s the next step in the market strategy?
Are there market alliances or partnerships?
Is there legal liability? To what degree?
© ESI
Do we share liability with any partners?
Have you conducted a patent search?
What’s the planning schedule?
What’s the development schedule?
What’s the volume for the initial rollout?
What is the rollout schedule?
What’s the anticipated production life?
What production facilities are available?
What is the organization’s conventional product or service life cycle?
How much of our manufacturing capacity will this consume?
Where will it be manufactured?
What internal resources are available?
Are there supporting vendors and subcontractors?
Is engineering staff available for modifications?
Budget
What’s the budget?
What’s the cost to build?
What’s the anticipated price to the consumer?
What’s the volume?
Capability
What does it do?
How does it work?
Does it use any breakthrough technologies?
How is it used?
How can it be misused?
Are there any uses that might be dangerous to children? Adults? Pets?
Is it safe? (For everyone? Heart patients?)
How easy should it be to use?
Is the product oriented primarily or exclusively for right- or left-handed people?
Does it have varying levels of capability based on the usage environment?
Are there specific products that can or cannot be used with it?
© ESI
How does it function?
Has it been tested? Will it be? How?
Is there a prototype?
How will it be built?
Are there specific environmental requirements?
Can the product be recycled?
Is it single-location-oriented, or is it portable?
Are there supplemental products to support it?
Are there peripherals?
Can it be used in conjunction with other products developed by us?
Can it be used in conjunction with other products developed by other firms?
Are upgrades available?
Will it be compatible with the upgrades?
Will there be more than one model? What other models are there?
Are repair parts available?
Can it be repaired by the “average” user?
What repair cycle will be used to implement repairs?
What are the storage requirements?
Appearance, Capacity, and Functionality
What does it look like? (Draw it for me!)
What color?
What size? What dimensions?
What weight?
Does it have adjustable capabilities? (Speed? Physical action?)
Will all the products be identical?
What’s it made of?
How is it constructed?
What are the key components?
How will those components operate and interact?
Can we use those components in other products or services?
Do we already produce any of those components?
© ESI
Can this product serve as an upgrade for existing products?
How will they integrate?
Will the components be readily available?
What are their dimensions?
What are their construction materials?
What are its mandatory performance capabilities?
Is it powered?
By what source?
Are there alternative sources?
Does it have a limited life span? What is it?
Regulation
Does it meet regulatory requirements?
Does it meet industry requirements?
Does it meet UL requirements? (Should it?)
What’s the life span on the power source?
What customer criteria must the power source meet?
Are there limitations on the decibels the unit can produce?
Are there limitations on the vibration levels of the unit?
Will the power capabilities be within manageable levels for the “average” user?
Support
Is there computer support?
Is any programming required either before production or by the user?
Training
Will auxiliary training be required?
How much training is required?
Documentation
Is supporting documentation required?
What types of documentation?
Are formats required for that documentation?
Will the documentation be developed in any languages besides English?
© ESI
Storage and Retrieval
What are the storage requirements?
How will the product be packaged?
Are there additional products you want sharing the limelight with this one?
If so, how will they help you achieve your vision?
How will delivery be accomplished?
Maintenance
How will this product/system/service be maintained?
What warranties will it carry?
What service networks are required?
What off-the-shelf support is available? Will be available?
Are there disposal issues?
How will it be recycled?
• Budget Analysis Checklist
DOCUMENT PREPARATION INFORMATION
PROJECT NAME PREPARED BY SIGNATURE DATE DOCUMENT ID
(PRINT) PREPAR
ED
CUSTOMER INFORMATION
CUSTOMER CONTACT CUSTOMER
ACCOUNT
WHAT TO LOOK FOR IN A BUDGET YOU PREPARED
Yes No Notes
© ESI
Are all elements accounted for?
Do the estimates look legitimate?
Do the numbers add up?
Does the amount of effort appear
reasonable for the time period
given?
Are there contingencies planned
for? How much of the budget is
set aside for contingencies?
© ESI
ANALYZING BUDGETS GIVEN TO YOU
Yes No Notes
Are all elements accounted for?
Do the estimates look legitimate?
Do the numbers add up?
Does the amount of effort appear
reasonable for the time period
given?
Are there contingencies planned
for? How much of the budget is
set aside for contingencies?
Who owns the decision when and
if more financial resources are
needed?
What is the change process?
What are the priorities within the
budget?
© ESI
© ESI
• Budget Template
Division/Program:
FY:
1st Estimate 2nd Estimate Actual Approved Amount of Percentage of
Amount Budget Variance Variance
Operating Income
Sales
Donations
Savings
Loans
Total Operating Income
Operating Expenses
Personnel
Salaries
Wages
Benefits
Travel and Per Diem
Airfare
Mileage
Lodging
Meals
Purchases
© ESI
Equipment
Materials
Subcontractors
Overhead
Utilities
Rent
Insurance
Total Operating Expenses
Operating Gain/Loss
Contingency reserves
Net Gain/Loss
© ESI
Site handover Format:
© ESI
© ESI
Training and Development
Hands on Training be provided to the customer team for Understanding of Engineering Drawings,
Product Knowledge, Installation, Testing, Labelling and Administration, Relocation and Maintenance
POME Prescribe:
About Personal organization:
© ESI
Nothing beats being organized. Keep an organized filing system, for instance, even something
as simple as storing documents chronologically will go a long way in saving you time and stress
when you need to locate information.
Keep a daily journal where you jot down the day’s highlights. Then, set aside an hour on
Friday/ Saturday night/evening to analyze your week. What did you do wrong? What did you do
right? What will you do differently the next time in a similar situation? This practice will help
you grow professionally and personally in the long run.
Make daily lists and cross things off. Keep a personal scorecard and grade yourself weekly.
Buy a Daily Planner; now actually use it.
POME LIGHTER VEI:
© ESI
PROJECT GATIG FOR
SUCCESS AD
PROJECT REVIEWS
© ESI
Project Gating for Success and Project Reviews:
As stated in the previous section, the implementation of POME methodology requires active
management-level involvement and oversight. To further address this requirement Project Gating and
Project Reviews are required as part of the methodology.
Regular reviews should be scheduled by management to insure proper performance and management
in the areas identified in the implementation phase of the methodology. Large complex projects
require more in depth reviews vs. small non-complex projects which may only require basic
performance indicator reviews.
For projects that are small in size and not complex, reviews may be conducted by the Program or
Regional Project Leader directly with the Project Manager in one on one session or as part of
staff/group review sessions. In either of these cases formal meeting agendas/minutes may not be
required, or summary review notations and actions may be used to record the review activities.
Summary notations may include project performance indicators, progress indicators, and financial
indicators, a brief summary paragraph of the project scope, a summary of the current issues and
projected completion schedule. Actions will be recorded and tracked as part of the specific project
records.
© ESI
For projects that are large by dollar volume and/or technically complex or high risk in nature more
formal reviews shall be conducted. These reviews will at minimum be conducted by management
periodically during the project life cycle, and may include more extensive gating reviews and/or
executive management reviews as described below. These reviews or gating sessions will be
documented using the standard gating or review tools or regional review documentation, rather than
standard meeting agendas/minutes. Actions will be recorded and tracked as part of the specific project
records.
Project reviews will be conducted, attended, and acknowledged/signed off per the following matrix:
Acknowledgement of the project reviews may be accomplished by distribution of the review notations
via e-mail.. Acknowledgement of the review notations is complete with the distribution of the review
notations unless corrections or objections are raised.
Executive Project Reviews:
An Executive Review is a review where members of Project Operations and Regional management
teams scrutinize business and Projects risks associated with a selected project. Business risks for
example can come from financial issues, deviation from our prescribed methodologies, the type of
contract (T&M, target price, fixed fee), resource constraints, leadership issues, quality/client
satisfaction issues or safety issues. The goal is to sample a minimum of 25% of the backlog contract
value as reflected by current PoC Revenue. Executive reviews may be conducted in place of quarterly
reviews
The criteria for selecting a project or program that will be placed on the list for Executive Review
during a fiscal quarter is described below. The following selection criteria are in order of precedent for
selection of projects to be reviewed.
1. Projects that have any Cost, Schedule or Technically not possible setup, in the Project Balanced
© ESI
Score Card (PBS).
2. Projects that have greater order values.
3. Projects that were reviewed in the previous quarter with follow up actions assigned.
4. Projects that have had an PoC adjustment in the last two quarters.
5. Projects that in the view of management have inherent risk issues.
6. Minimum of one project from each business area or program
7. Project being managed by a project manager who has not been involved in an Executive Review in
the prior 2 quarters.
Attendees shall include:
PMC Director - Mandatory
PCO Regional Manager (if applicable) – Mandatory
Program or Regional PMC Manager – Mandatory
Regional Finance Manager – Mandatory
Local Finance Manager – Mandatory
Project Manager – Mandatory
Project PCO Lead (if applicable) - Mandatory
Global Finance Manager – Optional
Regional Representative – Optional
GPO V.P. – Optional
Regional Contract Manager – Optional
In addition, the following Statements of Representation should be acknowledged (signed off) by the
Functional Groups as follows:
• Project Management
Concurrence with the project Revenue, Margin and Percentage of Complete (PoC) confidence of +/-
X% and that the business strategy and project management methodology being employed on the
project ensure effective project management.
• Project Controls
Concurrence with the project POC confidence of +/- X% and that the project control processes and
tools being employed on the project effectively track project performance, facilitate project control and
accurately forecast the project estimate to complete.
• Finance
© ESI
Concurrence with the project Revenue, Margin and PoC confidence of +/- X% and that the financial
processes and tools being employed by the business effectively track project financial performance,
facilitate project financial control and accurately forecast the project revenue and gross margin.
Manage Project Variance:
Managing the costs, schedule, and resources is one of the most important functions that the project
manager performs. These three key performance measurements are critical elements in keeping the
project under control. The key facets of performance measurement are the requirements to integrate
the management of cost, schedule, and resource use, with the technical aspects of a project and to
provide information relating these data in a coherent, systematic fashion, using a recognized
management approach.
Using PMIS information and applying the "earned value" concept, the project manager is able to
determine cost and schedule variances and take corrective action to ensure that the project stays on
track. The "earned value" concept, which is based on the central theory of performance measurement,
embodies the principle that obtaining an accurate measure of how a project is progressing requires an
objective assessment of work performed. When compared with project expenditures, this assessment
of work performed provides a true variance against cost and replaces the more traditional technique
that compares expenditures with spend plans. In essence, it recognizes the basic premise that funds
can be spent and hours of work can be logged that is disproportionate to the work being done.
Resource use is also a key indicator of project performance. The project manager must periodically
evaluate resource use and determine where and when to apply corrective actions such as resource
reallocation.
This process is carried out primarily during the Implementation Phase but also in the project Closeout
Phase.
Project Status Reporting and Project Review:
A key component of effective project control is the review of project status and the timely
communication of such to the project team, management, and the customer. At the start of the
project, the project manager establishes the frequency and content of status reports, as well as the
project review process, which is meant not only to track project progress, but also to solicit
management and customer support in resolving problems. These processes must be well defined in the
communication and documentation plans. A tool must be provided to assist the project manager with
his or her reporting duties to management in conjunction with effective tracking and control of projects
in PMIS..
The project manager must also establish a routine for collecting project report information, which is
necessary for tracking, controlling, and managing project performance. Such recurring events may
take place weekly or monthly and are as defined in the communication plan.
© ESI
Measuring Work Effort:
The project work effort is the expenditure of human resources' time on project tasks. The level of
effort refers to how many people are working on the project (also referred to as project head count).
Because some resources may be working on more than one project at a time, it is necessary to track
their individual effort as it relates to the project at hand. The process of measuring project work effort
includes the following activities:
Project resources report actual hours worked on a specific work package. This information is
reported weekly on the time sheet and entered into the labor system by the project administrator or
the individual contributor. It is recommended that project administration staff (project manager,
project administrator, and others working on the project but not on specific work packages) also
submit weekly time sheets charging their time to project administration, so that all costs associated
with the project are captured.
The project manager receives a weekly labor tracking report containing numerous data fields. This
report provides the information necessary to evaluate, at the work package level, the hours expended
to date, PoC, efficiency factor, and other important elements that will help the project manager to
assess work progress on the project.
Contracted professionals or vendors performing specific time-constrained project work also provide
accurate reporting of hours worked so that their time can be included in the calculation.
Earned Value Analysis Method:
Earned value analysis was introduced by the Department of Defense in 1960 as a methodology for
project managers to evaluate project progress. It is now used in some form by every agency as a
performance measurement tool. Simply stated earned value is defined as the amount of planned work
that has been accomplished to date or the value that has been earned by the project so far.
The key aspect of performance measurement is to integrate the management of cost, schedule, and
technical performance of a project and to provide information relating these data in a coherent and
systematic fashion, using a management-recognized base. It assumes that early warning is the key to
averting disastrous consequences.
The theory behind performance measurement is that to obtain an accurate measure of how a project is
progressing, an objective assessment of work performed must be developed. When compared with
project expenditures, this assessment of work performed provides a true variance against cost and
replaces the more traditional technique that compares expenditures with spend plans.
The key elements of earned value analysis are the BCWP, BCWS, and ACWP. These terms are
described in the following table:
© ESI
Budgeted Cost of Work Performed (BCWP)
BCWP is the term used for work accomplished. It is a numerical representation of the value, in
dollars, of the work completed. BCWP is also known as earned value because the value associated
with a particular work package is earned when the task is completed. It is important that the
BCWP be an accurate and timely measure of the completion status of a particular effort. If a work
package is 50 percent completed, then the BCWP should be 50 percent of the total budget for that
work package.
Budgeted Cost of Work Scheduled (BCWS)
BCWS is a numerical representation of scheduled work. Although similar to a time-phased budget
or spend plan, BCWS has two significant differences: it is directly related to a period of time when
a specific segment of work is scheduled, rather than when expenditures are booked, and it always
relates to the overall planned budget for a given scope of work, as opposed to functional or
corporate budgets. Because BCWS should be based on the schedule for when the work is to be
performed, it is not only time phased but also work phased.
Actual Cost of Work Performed (ACWP)
ACWP represents the actual costs incurred (direct and indirect) related to a specific work package
or the sum of all of the work packages performed during a specific period (usually from project
start to date). These costs should reconcile with the supplier's incurred cost ledgers, which are
regularly audited by the customer in the case of cost-plus contracts.
The most important variances that can occur on a project are schedule and cost variances. The
following table describes these variances and the process for calculating them using the earned value
analysis method:
Schedule Variance (SV)
SV is calculated by subtracting the budgeted cost of work scheduled from the budgeted cost of
work performed:
SV = BCWP – BCWS
SV provides an indication of whether work is being accomplished on schedule. Although an
excellent indicator of the status of work in progress, SV is not a time measurement tool. It
provides a measurement of the degree of variance from the original plan, in terms of monetary
© ESI
units. It is the difference between the value of the work actually performed and the value of the
work scheduled to be performed.
Cost Variance (CV)
CV is calculated by subtracting the actual cost of work performed from the budgeted cost of work
performed:
CV = BCWP – ACWP
CV represents the difference between what was expected to be spent for the work that was
performed (cost estimate) and what was actually spent. It is a clear indication of past cost
performance. CV is not based on a spending plan, thus avoiding the common problem of assuming
that the project is on target simply because the resources consumed during a given time period
match the resources planned for that period. Because it is not tied directly to schedule
performance, it does not suffer the same shortcomings as cumulative cost curves. Those curves do
not reflect the value of the work being accomplished.
The project manager can use earned value analysis data to determine the level of effort and cost
needed to restore any project variances. Earned value analysis provides several additional
mathematical formulas that the project manager can use to track and control project schedule and
budget. This information is presented in the following table:
Budget at Completion (BAC)
BAC is the estimated total cost of the project, or a work package, when completed. When
combined with project contingency or management reserve funds, BAC equals the total project
budget.
Estimate to Complete (ETC)
ETC is an estimate of how much more money this project will require.
Estimate at Completion (EAC); Latest Revised Estimate (LRE)
EAC or LRE, consists of the current measured cost plus the estimated remaining cost. EAC should
be calculated consistently from period to period with consideration given to factors such as
performance to date, anticipated risks, and work volume. Because of the importance of this
estimate, it is recommended that it be calculated and reported monthly. The formulas for EAC are
© ESI
as follows:
EAC = ACWP + ETC
or
EAC = BAC/CPI
Cost Performance Index (CPI)
The cost performance index is a numeric representation of how effective the project has been to
date in terms of cost. CPI is calculated as follows:
CPI = BCWP/ACWP
The cost performance index is often used to predict the magnitude of possible cost overrun using
the following formula:
Original Cost Estimate/CPI = Projected Cost at Completion
Schedule Performance Index (SPI)
SPI has the same functionality as CPI, except that SPI measures schedule instead of cost. SPI
provides information on schedule performance at any given point during the project. SPI is
calculated as follows:
SPI = BCWP/BCWS
Percent Complete
Percent complete is an estimate, expressed as a percent, of the amount of work that has been
completed on an activity, a group of activities, or on the project as a whole, regardless of the
amount expended to achieve that much work. It can be calculated as follows:
Percent Complete = BCWP/BAC
Percent Spent
© ESI
Percent spent is an important tool to the project manager seeking information on the percent of
budget expended to date or on the difference between percent complete and percent spent. If the
project is running on time and within budget, percent spent and percent complete should be
identical. If percent spent is significantly more than the percent complete, the project manager will
need to identify the cause and take corrective action, if necessary, to prevent a project overrun on
cost. Percent spent is calculated as follows:
Percent Spent = ACWP/BAC
Variance at Completion (VAC)
VAC is the difference between BAC and EAC. VAC is an early flag indicating how far off the project
will be. It represents the predicted cost position (over or under budget) when all work is
completed. Comparing VAC to CV is an easy way to determine whether things are expected to get
better or worse. VAC is calculated as follows:
VAC = BAC – EAC
Earned value analysis provides a valuable tool for the project manager to use in evaluating project
performance. Awareness of the earned value, SV, and CV is important throughout the project life
cycle. CPI, SPI, and VAC are more accurate and, thus, useful in the later stages of the project. EAC or
LRE should be calculated and reported monthly, although they too become more meaningful as the
project matures. Percent complete and percent spent information is valid and useful throughout the
project.
Taking Cost Control Actions:
Earned value analysis of cost variances can be performed by the project manager concurrently with
the weekly project review. This review will enable the project manager to identify variances from the
initial estimates; classify them as routine, minor, or major (according to the established threshold);
and take necessary corrective action. The following table describes possible corrective actions for cost
variances:
Labor Cost Higher Than Planned
Look for incorrect reporting on time sheets or incorrect charges through PMIS. Make corrections,
if necessary.
Look at resource use. Are resources being fully used? Are all of the resources needed? Make
adjustments in use of resources, if appropriate.
© ESI
Look at the scope of work. Has the scope of work changed? If so, was the cost baseline updated?
Was the estimate a poor one? Make appropriate adjustments, re-estimate, and submit information
to management for review and possible resolution.
Material Cost Higher Than Planned
Is more material being used than initially estimated? If so, did this situation occur as a result of
approved changes? If so, was the baseline updated? Update the baseline, if appropriate.
Is the cost/unit higher than planned? If so, why? Can another source or supplier be used? Get
Procurement involved.
Look at the material consumption versus the schedule. Is it possible that the material
requirements are as planned but are being consumed ahead of schedule? Re-estimate total material
requirements.
Subcontractor/ Vendor Cost to Date Higher Than Planned
Review contractor's invoices and compare to milestones and invoice schedule. Is the
subcontractor ahead of schedule? Are there incorrect invoices? If so, correct them.
Has the subcontractor/vendor scope of work changed? If so, was the cost baseline updated?
Update the baseline, if appropriate.
Miscellaneous Cost Higher Than Planned
Pre approve travel; review and approve all travel expenses.
Review and approve invoices.
Review and approve supplier requisitions.
Expected Overall Project Cost Overrun, with Inability to Correct
Is the overrun a result of poor estimates? Or is it a result of uncontrollable events? Can cost
overrun be passed to the customer? Escalate the issue to senior management.
Make necessary adjustments to the baseline, if required, as approved by management.
Project review meetings are necessary to show that progress is being made on a project. There are
three types of review meetings:
Project team review meetings
© ESI
Executive management review meetings
Customer project review meetings
Most projects have weekly, bimonthly, or monthly meetings in order to keep the project manager and
his team informed about the project's status. These meetings are flexible and should be called only if
they will benefit the team.
Executive management has the right to require monthly status review meetings. However, if the
project manager believes that other meeting dates are better (because they occur at a point where
progress can be identified), then he should request them.
Customer review meetings are often the most critical and most inflexibly scheduled. Project managers
must allow time to prepare handouts and literature well in advance of the meeting.
POME Prescribe:
About Communication:
Clear, open communication is a prerequisite for a healthy, result-oriented work environment.
Keep them posted: A lack of information is a fertile ground for rumor, gossip and insecurity. Keep the team in
the loop about information concerning and affecting them.
When in doubt, ask: Don’t refrain from asking “stupid” questions – they may save miscommunication and
misunderstandings, resulting in saved time and money!
It is bad policy to wait till your team members find out important information concerning them from other
sources. That information should come from you.
Ask questions and listen to suggestions.
Feedback: Provide it often and ask for it. Keep an open mind. (Tip: Don’t expect all feedback to be pleasant
and positive.)
Listen: It’s always important to listen, but even more so in tough times. Listen for undertones.
Be Open: While you should not be a dumping ground for grievances, you SHOULD be accessible enough for
team members to openly discuss concerns or delays. (Tip: If you are not open, you'll find out about the
concern or delay later in the game when there is less time to fix it.)
Touch Base: One-on-one and in meetings, meet up with your team members (or family members). (Sitting in
front of the television with the family does not count as touching base!)
© ESI
“There is only one person
who is capable to set limits
to your growth:
It is YOU, ONLY YOU.”
© ESI
186
© 2007, POME, Gautam_Koppala, All Rights Reserved
WE CAME, WE SAW, WE
COQUERED, AD WE
RULE
187
Any Questions?
Comments? For
better
improvement
Contact:
georgegautam@gmail.com
00918912550564
188
189
Heated gold becomes ornament. Beaten copper becomes
wires. Depleted
stone becomes statue. So the more pain you get in life you
become more valuable.
But year's later collection of

mistakes is called experience,
which leads to success.
190

Project Closing From POME by Gautam Koppala VT

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Project Closing From POME by Gautam Koppala VT

Hochgeladen von

Copyright:

Verfügbare Formate

1

Kanaka maha lakshmi Thalli

Be bold when you loose and be calm when you

"Changing the Face" can change nothing.

2007, POME, Gautam_Koppala, All Rights Reserved

Project Name: PROJECT NAME

Reporting Period: Project Manager: Project Sponsor:

Project Description: Project End Date: dd/mm/yyyy

Key Deliverables for next reporting

Risk Management Issue Management Change Management

Log No Risk Action/Status Log No Issue Action/Status Req No Details Approve

2007, POME, Gautam_Koppala, All Rights Reserved

Capital Revenue External

2007, POME, Gautam_Koppala, All Rights Reserved

6 Have you developed a communications

1 Has a PID or project definition form been

8 Has planning started for a start up

9 Team selection - have you got the correct

3 Is the project still delivering the benefits

4 Is there a case for abandoning the project

4 Have you developed an overall project

2007, POME, Gautam_Koppala, All Rights Reserved

2007, POME, Gautam_Koppala, All Rights Reserved

1. Invite Service to Step Who Description Output

2007, POME, Gautam_Koppala, All Rights Reserved

2007, POME, Gautam_Koppala, All Rights Reserved

2007, POME, Gautam_Koppala, All Rights Reserved

2007, POME, Gautam_Koppala, All Rights Reserved

1. PROJECT INFORMATION (Filled out by PM)

Initial Order Sales Date :

2. CUSTOMER AND SUBCONTRACTOR INFORMATION (Filled out by PM)

Direct Customer (Company) :

2007, POME, Gautam_Koppala, All Rights Reserved

End User (Company) :

3. SYSTEM INFORMATION (Filled out by PM)

Main System Type :

2007, POME, Gautam_Koppala, All Rights Reserved

4. HEALTH SAFETY & ENVIROMENT (Filled out by PM)

5. SITE VISIT INFORMATION (Filled out by FSL)

Site Visit Date with FSL :

2007, POME, Gautam_Koppala, All Rights Reserved

6. DOCUMENT CHECKLIST (Checked by FSM)

Change/Variation Orders (if Additional purchases done by customer or HW

Project Closing Project completion form signed by PM and SSDL,

2007, POME, Gautam_Koppala, All Rights Reserved

Training Protocol Training date(s) and topics, names, titles and

SLA Software license agreement signed by

Test Protocols System installation, cabling and functional test

System Summary Brief description of system and general operation,

2007, POME, Gautam_Koppala, All Rights Reserved

Principal Schematics Flow diagrams

Cable Lists Indicating cable marking, connection terminals

User Manuals In local and/or English language

2007, POME, Gautam_Koppala, All Rights Reserved

Equipment Datasheets Technical datasheets of the devices used in the

Missing Items : Owner Deadline

2007, POME, Gautam_Koppala, All Rights Reserved

7. PROJECT HANDOVER (PM, FSL and approval)

2007, POME, Gautam_Koppala, All Rights Reserved

2007, POME, Gautam_Koppala, All Rights Reserved

2007, POME, Gautam_Koppala, All Rights Reserved

2007, POME, Gautam_Koppala, All Rights Reserved

TIME [in suitable units -days, weeks, months, etc.]