Business Case ESSENTIALS PROJECT MANAGEMENT … · The PRINCE2 approach to the Business Case. 3. Business Case content. 4. Essential elements. 5. Credibility, practical value and

© PMO South Africa (Pty) Ltd 2012/189587/07

Business Case ESSENTIALS

PROJECT MANAGEMENT FUNDAMENTALS


1. What is a Business Case?

2. The PRINCE2 approach to the Business Case.

3. Business Case content.

4. Essential elements.

5. Credibility, practical value and accuracy.

6. Costs and benefits.

7. Making assumptions.

8. Estimating costs.

9. Estimating benefits.

10. Financial value for non-financial objectives.

11. Calculating return on investment and other financial metrics.

12. Sensitivity analysis.

13. Risk analysis.

14. Practical.

Business Case Essentials

<#>


Project Management Fundamentals

1. What is a project?

2. What is Project Management?

3. The project lifecycle.

4. Time, cost, quality, scope, benefit, risk.

5. Stages & phases.

6. Initiating, delivering, closing.

7. Monitoring & reporting progress.

8. Project Management & the Business Case.

<#>


Strategy

• What is strategy:

– It is a high level plan to achieve one or more goals under conditions of uncertainty.

– It becomes ever necessary when it is known or suspected that there are insufficient resources to achieve these goals.

– It is also about attaining and maintaining a position of advantage over adversaries through the successive exploitation of known or emergent possibilities rather than committing to any specific fixed plan designed at the outset.

• What is agile strategy: Chess.

• Why strategy?

• Strategy process:

– Vision, mission, objectives, goals, deliverables, projects, tasks, sub-tasks.

• Delivering on strategy:

– Sub-tasks, tasks, projects, deliverables, goals, objectives, mission, vision.

• Where does the Business Case fit in?

• What happens if market conditions and/or strategy changes?

– What happens to the Business Case or project?

<#>


Portfolio and Programme Management

• Project Portfolio Management:

– is the centralised management of processes, methods, and technologies used by project managers and project management offices (PMOs) to analyse and collectively manage a group of current or proposed projects based on keycharacteristics.

– The objectives of PPM are to determine the optimal resource mix for delivery and to schedule activities to best achieve an organisation’s operational and financial goals while honouring constraints imposed by customers, strategic objectives or external real-world factors.

• Programme Management:

– is the process of managing several related projects, often with the intention of improving an organisation's performance.

– In practice and in its aims it is often closely related to systems engineering and industrial engineering.

• Why Portfolio Management?

• Why Programme Management?

• Where does the Business Case fit in?

• What happens if a portfolio/programme is not being successful?

<#>


Programme Environment

• Programme will define standards to be used when developing the Business Case.

• Project Business Case will be aggregated into Programme Business Case.

• Likely to be reduced in content:

– Details of budget.

– List of benefits and tolerance.

– State how the project is contributing to the programme.

• Could be produced and maintained by the programme .

• Could exist before the project is initiated.

• Benefits will be defined, tracked and managed by the programme.

• Benefits Review Plan will be part of the programmes Benefits Realisation Plan.

<#>


Project Sponsor

• What is a project sponsor?

• Why a project sponsor?

• Who represents your business case for approval?

• Who is accountable for the business benefits/success or failure of the business or project.

• Who is responsible for the project:

– Time.

– Cost.

– Scope: Specification, Quality and Risk.

– Business benefits/ROI.

– CSF’s (Critical Success Factors).

• What is the difference between:

– A projects time, cost and scope.

– Business case benefits measurement (Roles).

• When does business measurement occur?

<#>


PMO (Project Management Office)

• What is a PMO?

• Why a PMO?

• What does a PMO do?

• Business case scorecard.

• Resourcing.

• Business case quality approval.

• Business case monitoring.

• Project approval.

• Project monitoring.

• Project closure.

• Projects/business case benefits measurement and control.

<#>


Balanced ScorecardProgramme Management

<#>

© PMO South Africa (Pty) Ltd 2012/189587/07 <#>





Project Life Cycle


What is a Business Case?

• What is a Business Case?

• Examples of a Business Case.

• What is a good Business Case?

• What is a bad Business Case?

• Basic requirements questions:

– Can you approve?

– Can you deliver it?

– Can you control?

– Can you measure its success?

– Business Cases can range from comprehensive and highly structured, as required by formal project management methodologies, to informal and brief.

<#>


Why Do Business Cases Vary?

•Does size, complexity or risk make a difference to a Business Case?

•Does the experience, knowledge and qualifications of those approving make a difference to a Business Case?

•Good or bad – either way?

<#>


What is a Business Case?

• The justification for an organisational activity (project) which typically contains costs, benefits, risks and timescales and against which continuing viability is tested.

• A business case defines the delivery of one or more business products by the project/temporary organisation that was created for that very purpose.

• PRINCE2 ensures that participants focus on the viability of the project in relation to its business case objectives rather than simply seeing the completion of the project as an end in itself.

• The business case gets the planned project costs and timescales, and identifies the major control points, such as management stages and milestone from the project plan.

• Control of progress ensures that the project remains viable against its approved business case.

• Ensure that the project remains focussed on the corporate or programme objectives set, and remains justified in accordance with its business case as response to the receipt of a highlight report.

• PRINCE2 recommends determining the options for recovery and assessing them against the business case when escalating issues and risks.

• The business case needs to reflect the changes in the project’s external environment as well as the nature and timing of the project’s products because projects must have continued business justification (i.e. the project board is ordinarily only authorised to continue while the project remains viable).


What is a Business Case?Continued

• The Executive is responsible for updating the business case.

• How to update the business case:

– Check whether risk tolerances need to be redefined.

– Update the benefits review plan with the results from any benefits reviews undertaken during the stage.

– Examine and review:

Benefits review plan.

Impact of approved changes.

Project risk file and key risks.

Issue register.

Project plan to see whether the final implementation date of the project has changed.

Project plan to see whether the cost of delivering the project’s products has changed.

The corporate/programme environment into which the project’s products will be delivered.

Whether any benefits reviews are required.

– Revise the business case.

– Update the risk and issue registers as necessary.



• A project may not start with a pre-defined business case because the specification is

driven by the business case.

• PRINCE2 handles the evolving paradigm as the business case represents a best and

agreed forecast at a particular point in a project’s lifecycle which will evolve as the

project moves from discovery to implementation.

– The outline business case:

Developed pre-project.

Has wide-range forecast of desired outcomes.

– Detailed business case:

Updated mid-project.

Has a narrower forecast.

– As the project progresses the set of products, required to provide the desired

outcomes, also evolve.



• Evolving business case value:

– Enables organisation to make an investment commitment that is

commensurate with the expected benefits and risks forecast at the time in

the project’s evolution.

– Provides the basis for the control and impact assessment of requested

changes as a result of the “contestable and open to negotiation throughout

the project’s life” aspects of modern projects.



• Presents the optimum mix of information used to judge whether the project is and remains desirable, viable and achievable and therefore worthwhile investing in.

• In PRINCE2 the business case provides the vital test of the viability of the project (is the investment in this project still worthwhile).

• It is not static because the viability question is on-going, should be actively maintained throughout the life of the project, it should be continually updated with current information on costs, risks and benefits.

• Types of business case is determined by the type of project (compulsory, not for profit, evolving, customer/supplier, multi-organisation) because this will determine the type of measure being used (i.e. return on investment or other non-financial benefits).

• At various stages in the project, the business case should be reviewed to ensure that:

– The justification is still valid.

– The project will deliver the solution to the business need.

• The result of a review may be the termination or amendment of the project.

• The business case may also be subject to amendment if the review concludes that the business need has abated or changed, this will have a knock on effect on the project.


Reasons for creating a business case

• Business cases are created to help decision-makers ensure that:

– The proposed initiative will have value and relative priority compared to alternative initiatives.

– The firm has the capability to deliver the benefits.

– The firm’s dedicated resources are working on the highest value opportunities.

– Projects with inter-dependencies are undertaken in the optimum sequence.

– The performance of initiatives is monitored objectively based on the objectives and expected benefits laid out in the business case.

– The business case must demonstrate that:

• The issues have been thought through.

• The full benefits will be realized on time.

• Any technical aspects have been thoroughly evaluated.

• Cost and track and measure their achievement.


What is R.A.C.I. ?

• Who is:

– Responsible.

– Accountable.

– Consulted.

– Informed.

• Why is R.A.C.I. so important?

<#>

© PMO South Africa (Pty) Ltd 2012/189587/07 22

Who Is Responsible For Preparing TheOutline Business Case?

Producer – Responsible for product’s productionReviewer – Ideally independent of productionApprover – Confirmsapproval

Product Action Co

rpo

rate

/Pro

gram

me

Exe

cuti

ve

Sen

ior

Sup

plie

r

Pro

ject

Man

age

r

Pro

ject

Man

age

r

Pro

ject

Ass

ura

nce

Pro

ject

Su

pp

ort

Pro

du

ctD

esc

rip

tio

n a

vaila

ble

Outline Business Case Create A P R R R R A2

Project Product Description

Create (A) (A) (A) P RA21

Daily Log Update P A7


Why a Business Case

•Budgeting/strategy.

•Approval.

•Control.

•Measurement.

•Market demand.

•Organisational need.

•Customer request.

•Technological advance.

•Legal requirement.

•Ecological impacts.

•Social need.

•Problem.

<#>


Types of Business Case

• Profit project:

– ROI/break even.

• Compulsory project:

– Government legislation.

• Not-for-profit project (balanced scorecard):

1. Financial.

2. Customer.

3. Internal business processes.

4. Learning.

• Evolving project.

• Customer/supplier project.

• Multi-organisation project.

• Investment project.

• Non-core project.

<#>


Business Case Trigger Points

• Vision Mission Objectives Goals Deliverables Projects Tasks Sub-tasks.

• Capital Projection and Budgets.

• Project Plan.

• Technical Specification.

• Measurement of success of a project:

– Time, cost, scope, quality, risks, benefits.

– Outputs.

– Customer satisfaction.

– User satisfaction.

– Business benefits.

– Return on investment (ROI) or business reason.

– Business case.

• Measurement of success of business:

– Projects.

– Business case.

– Portfolio and/or programme.

– Capital budgets.

– Strategy.

<#>


Essential Elements of the Business Case

The components of a business case may change depending on the template or methodology used, but the essential elements will remain the same:

• Executive Summary:

– Enables decision makers to very quickly understand the essence of the business case.

– It should include all main points made in the business case.

– Including all the recommendations.

– Should be a stand-alone part of the document.

– The detail is located in the business case itself.

– An effective executive summary will capture the interest of the decision maker.

– They will want to know more and be quickly interested in the project or initiative.

– It should be used to ‘sell’ the project or initiative to the person reading it.

– This section is placed at the beginning of your business case.

– Should be the last section to be written.

– Ensure that you have a very clear understanding of what is included in your business case when you summarise it.

<#>


Essential Elements of the Business CaseContinued

• Objectives & Scope:

– Provides direction at the beginning of the document about what the project will achieve if the business case is supported.

– Should be brief, concise and set the scene for the business case.

– Objectives should be phrased in terms of how supporting the business case will improve an aspect of agency business or assist the agency to meet its strategic objectives.

• Options.

• Cost-benefit analysis.

• Risk assessment.

• Recommendation.

<#>


Business Case Size

• Experience.

• Standards.

• History.

• Complexity.

• Time.

• Cost.

• Scope:

– Specification.

– Quality.

– Risks.

<#>


Business Case Content

• Summary:

– What, when, why, duration, time, cost, risk, specification, quality.

• What?

• Why?

• ROI (Return on investment).

• CSF’s (Critical success factors).

• Strategy.

• Portfolio.

• Programme.

• Duration:

– Start.

– End.

• Time:

– Man Hours.

• Cost.

<#>


Business Case ContentContinued

• Scope:

– Specification.

– Quality.

– Standards.

– Governance.

• Risks.

• Motivation or Summary Description.

• Business Description.

• Technical Description.

• Project Sponsor.

• RACI:

<#>

– Who is Responsible.

– Who is Accountable.

– Who to Communicate to.

– Who to Inform.

– Customer.

– Project Sponsor.

– Signatories on Specification.

– Signatories on Project Close.



• Objectives & Scope:

– Provides direction at the beginning of the document about what the project will achieve if the business case is supported.

– Should be brief, concise and set the scene for the business case.

– Objectives should be phrased in terms of how supporting the business case will improve an aspect of agency business or assist the agency to meet its strategic objectives.

• Options.

• Cost-benefit analysis

• Risk assessment.

• Recommendation.

• Priority.

• Options:

– A why?

– B why?

– C why?

<#>



• Business Case Quality.

• Requires further detail or motivation.

• Department.

• Division.

• Area.

• Business Benefits.

• Business Dis-benefits.

• Benefit measurement, over what time.

• Constraints:

– Schedule.

– Resources.

– Budget.

– Staffing.

– Technical.

– Other.

<#>



• Phases/Stages.

• High level project plan.

• Accuracy of business case.

• Proof.

• Attachments.

• History.

• What will happen if we do not do it?

• Reference:

– Origins.

– Background.

– Current state.

• Context:

– Opportunities.

• Quotes.

• Photos.

<#>


Business Case Scorecard / Checklist

<#>

Headings

Summary:(what, when, why, duration, time, cost, risk, specification, quality)

What.

Why.

ROI (Return on investment).

CSF’s (Critical success factors).

Strategy.

Portfolio.

Programme.

Duration:

Start.

End.

Time:

Man Hours.

Cost.

Headings

Scope:

Specification.

Quality.

Standards.

Governance.

Risks.

Motivation or Summary Description.

Business Description.

Technical Description.

Project Sponsor.

RACI:

Who is Responsible.

Who is Accountable.

Who to Communicate to.

Who to Inform.


Business Case Scorecard / ChecklistContinued

Headings

Objectives & Scope:

Provides direction at the beginning of the document about what the project will achieve if the business case is supported.

Should be brief, concise and set the scene for the business case.

Objectives should be phrased in terms of how supporting the business case will improve an aspect of agency business or assist the agency to meet its strategic objectives.

Options.

Cost-benefit analysis.

Risk assessment.

Recommendation.

Priority.

Options:

Why A?

Why B?

Why C?


Business Case Scorecard / ChecklistContinued

Headings

Business case quality.

Requires further detail or motivation.

Department.

Division.

Area.

Business benefits.

Business dis-benefits.

Benefit measurement, over what time.

Constraints:

Schedule.

Resources.

Budget.

Staffing.

Technical.

Other.

Headings

Phases/stages.

High level project plan.

Accuracy of business case.

Proof.

Attachments.

History.

What will happen if we do not do it?

Reference:

Origins.

Background.

Current state.

Context:

Opportunities.

Quotes.

Photos.


Business Case Budget Approval Template

<#>

BusinessCase

NameReason Type Cost Duration Time

Major Risks

Description Approved

Approved,but requiring

further information

Date Approved

Approved By


Examples of Business Cases

1. New Post Office.

2. Fix up the current PMO (Project Management Office).

3. Software Project.

4. New Boardroom.

5. Nuclear Power Station.

<#>


Capex – Liberty Properties

• Is this a good example?

• Has it covered the business case key points?

<#>


Capex


Capex

CAPITAL ITEMS 2012

MIDLANDS MALL

APPROVED MANDATE DATE DATE DATE DATE DATE TENDER SAVINGS/ PO NUMBER

AS NO. MANDATE MANDATE SITE RFQ TENDER FIGURE OVERSPEND

CAPITAL LOADED ON WORKFLOW MEETING CLOSED ADJUDICATION

SAP APPROVED

TECHNICAL

JULY

R 127 500 Replacement of compressors for HPI units AP/003-CST-260-TEC-001 X 10025652 20/02/2012 21/02/2012 17/05/2012 18/06/2012 ? 81 969R R 45 531 4500083604

R 2 473 414 IT revitalization AP/003-CST-260-TEC-002 X 10025653 20/02/2012 28/02/2012 N/A 15/03/2012

AP/002-CST-260-TEC-001

R 7 400 000 Install new pay on foot parking system R6 500 000 AP/003-CST-260-TEC-003 X }10025648 20/02/2012 21/02/2012 08/03/2012 16/03/2012

Install parking manipulators R900 000 }

AP/001-CT-260-OPS-006 / AP/002-CST-260-OPS-008

AP/001-CST-260-OPS-004 / AP/002-CST-260-OPS-007

AUGUST

R 2 000 000 Installation of BMS - carryover from 2011 AP/003-CST-260-TEC-004 X 10025661 20/02/2012 21/02/2012 12/03/2012 19/03/2012 11/04/2012

AP/002-CST-260-TEC-002

SEPTEMBER

R 1 300 000 Separation of power factor correction AP/003-CST-260-TEC-005 X 10025640 20/02/2012 01/03/2012 07/03/2012 20/03/2012 22/03/2012 1 281 700R 18 300R 4500083442

OCTOBER

R 88 000 Upgrade of Extractors in Transformer Rooms 1 and 3 AP/003-CST-260-TEC-006 X 10028354 2012/05/08 15/05/2012

R 55 000 New extraction system for Transformer Room 2 AP/003-CST-260-TEC-007 X SAVINGS

NOVEMBER

R 2 172 111 IT systems upgrades AP/003-CST-260-TEC-008 X

Office network equipment & switches R131 443 }10025701 21/02/2012 21/02/2012 09/03/2012 16/03/2012

UPS (2 units) R192 668 }

Upgrade headcount system to be IP based R70 000 10025702 21/02/2012 28/02/2012 N/A 26/03/2012

Upgrade fire detection panels to be IP based R90 000 10025703 21/02/2012 21/02/2012 12/03/2012 20/03/2012 11/04/2012 89 000R 1 000R 4500083602

Tenant monitoring R1 292 648 10025661 20/02/2012 21/02/2012 12/03/2012 19/03/2012 11/04/2012

Contingency at 10% R177 676

Travelling & accomodation R40 000

Project cost at 10% R177 676

R 15 616 025 Total

OPERATIONS

JUNE

R 80 000 Trolley bays in 6 Parking areas (6 bays) AP/003-CST-260-OPS-001 X 10025638 20/02/2012 22/02/2012 02/03/2012 08/03/2012 22/03/2012 72 000R 8 000R

R 1 305 257 Relocation of security control room AP/003-CST-260-OPS-002 X

AP/002-CST-260-OPS-003

R 1 385 257 Total

BUILDING SERVICES

JULY

R 139 118 Entrance paving, bollard and curbs (carry over from 2010) AP/003-CST-260-BDS-001 X

AP/002-CST-260-BDS-006

R 17 956 233 Garden food court cover AP/003-CST-260-BDS-002 X

AP/002-CST-260-BDS-007

R 596 070 New coastal regional office AP/003-CST-260-BDS-003 X

AP/002-CST-260-BDS-004

R 1 118 000 Construction of new public toilets AP/003-CST-260-BDS-004 X

AP/002-CST-260-BDS-012

R 360 000 3x Kiosks for non-gla income AP/003-CST-260-BDS-005 X SAVINGS

SEPTEMBER

Waterproofing to Phase 2 Roof back flashings and smoke vents, AP/003-CST-260-BDS-006 X }10025782 23/02/2012 28/02/2012 08/03/2012 20/03/2012

total overhaul of 3 shield skylights and waterproofing shield to South }10025783 23/02/2012 28/02/2012 08/03/2012 20/03/2012 11/04/2012

facing high level glazing above food court (Round 1) New Mandate

R 1 500 000 Waterproofing to Phase 2 Roof back flashings and smoke vents, AP/003-CST-260-BDS-006 10030117 25/06/2012

total overhaul of 3 shield skylights and waterproofing shield to South

facing high level glazing above food court (Round 2)

OCTOBER

R 2 300 000 Thermostatic roof coating AP/003-CST-260-BDS-007 X N/A N/A N/A N/A N/A N/A N/A N/A

DECEMBER

R 2 000 000 New Christmas decor for the Midlands Mall AP/003-CST-260-BDS-008 X 10025654 20/02/2012 21/02/2012 05/04/2012

R 25 969 421 Total

R 42 970 703 Total for Midlands Mall approved and bonded


Bubble Chart

• What key points does one need to do a Bubble Chart?

• One test key points available on the previous Capex.

<#>


Business Case

– Desirable: Optimum mixture of risk/cost/benefit.

– Viable: Project capable of delivering the product.

– Achievable: Product can provide the benefit.

• The Business Case is LIVE! Constantly updated and maintained with the best know information to assess ongoing viability of the project.

“The purpose of the Business Case theme is to establish mechanisms to judge whether the project is (and remains) desirable, viable and achievable as a means to support decision making in its (continued) investment.”

<#>


Outputs, Outcomes and Benefits

• Output: Specialist product (Tangible/Intangible).

• Outcome: Result of the change derived from using the output.

• Benefit: Measurable improvement resulting from the outcome.

• Dis-benefit: An outcome perceived as negative by one or more stakeholders.

A major building supplies wholesaler erected additionaloutdoor storage sheds to curb theft at a cost of R600,000.The project was a success and theft from the outdoorarea reduced by 80% resulting in an increase in monthlyprofits of R20,000. Building maintenance costs rose by10% annually costing an additional R120,000 butinsurance premiums dropped by R2500 per month.

<#>


Outputs, Outcomes and BenefitsContinued

also cause

Project

outputs

Business

changes

Side-effects and

consequences

Dis-benefit

create

realize

further

measured in

helps achieve

one or more

Desired

outcomes

Strategic

objectives

Benefit

enable

result in

<#>


Business Case

• Executive summary.

• Reasons.

• Business options.

• Expected benefits.

• Expected dis-benefits.

• Timescale.

• Costs.

• Investment appraisal.

• Major risks.

The Outline Business Case is produced in the Starting Up a Project process. It is later refined and the Detailed Business Case developed in the Initiating a Project process. It continues to be maintained and verified throughout the remainder of the project.

<#>


Confirmbenefits

Verifyupdated

Business Case

Verifyoutline

Business Case

Verifydetailed

Business Case

DevelopBusiness Case

MaintainBusiness Case

Pre-project

Initiationstage

Subsequent delivery stage(s) Final delivery stage Post-project

Confirmbenefits

Confirmbenefits

47

Development Path of the Business Case


Benefits Review Plan

• Scope of the benefits review plan.

• Who is accountable for benefit delivery.

• How to measure benefit achievement.

• What resources will be required for the review.

• Baseline measures of performance.

• How product performance will be reviewed.

The Benefits Review Plan is developed during the Initiating a Project process, updated at each stage boundary and is passed on to corporate or programme management when the project is closed.

<#>


Detailed Business Case ContentPRINCE2

• An executive summary.

• Reasons:

– Why is the project required.

– Should be linked to organisational context.

– Should explain how the project will enable the achievement of corporate strategies and objectives.

– Reasons will be defined in the project mandate, if not seek clarification.

If there is no project mandate, then what?

• Three basic business options concerning any investment:

Do nothing – this is always the starting option, the basis for quantifying the other options.

Do the minimum.

Do something.

• The difference between “Do the minimum” and “Do something” is the benefit that the investment will buy.

• Analysis of 3 options will provide enough information to decide between the 3 options (i.e. which presents the best value for the organisation).

<#>


Detailed Business Case ContentPRINCE2 - Continued

• For this level of investment, are the anticipated benefits more desirable, viable and achievable than the other options available?

• Business case of the chosen option should be assessed for desirability, viability and achievability on a continual basis.

• Any new risks and/or changes may make one of the other options more justifiable.

• Expected benefits:

– Business case should list each benefit that is claimed would be achieved by the project’s outcome (for the selected business option).

– Define the current status of each benefit in quantifiable terms, in order to assess measurable improvements after the project has been completed.

– Business case defines how and when the measurement of the improvements can be made.

– Benefits can be financial or non-financial/cashable or non-cashable.

<#>



Expected benefits (Continued).

– Benefits should be:

Aligned to corporate objectives and strategy.

Mapped form the outputs and outcomes provided by the project.

Quantified (with tolerance) i.e. budget.

Measurable.

Assigned.

– Clear responsibility for benefits, collectively and individually:

Senior user is responsible for the set of benefits within their respective areas.

Responsibility for individual benefits should be assigned to an appropriate person – ideally someone within the group of users affected by that benefit.

– The list of expected benefits will influence the set of products that the project will provide:

Products that do not directly or indirectly enable the sought-after benefits to be achieved should not be included in the project.

Mapping products to outcomes and to benefits aids decision making in the planning and control of the project (based on the impact of the realisation of the expected benefits).

<#>



Expected benefits (Continued).

– Benefits should be expressed in tangible ways wherever possible.

– Senior user or executive can define many benefits as intangible.

– It is worthwhile to try to express “intangible” benefits measurable terms.

– Quantification of benefits enables benefits tolerance to be set and measurability of the benefits ensures that they can be proven.

– If benefits cannot be proven then it cannot be determined if a project:

Has been a success.

Has provided value for money.

Should be (or have been) initiated.

– Verify expected benefits:

Sensitivity analysis.

Define three views of the achievement of the benefits.

Build an allowance into the costs for estimating inaccuracies, changes and risks.

<#>



• Expected dis-benefits:

– This is an outcome perceived as negative by one or more stakeholders.

– Actual consequences of an activity (a risk has some uncertainty about whether it will materialise).

• Timescale:

– Corporate and/or programme management will wish to know:

Over what period the project costs will be incurred.

Over what period the cost/benefits analysis will be based.

When the organisation can expect to accrue benefits.

What the earliest/latest feasible start date is.

What the earliest/latest feasible completion date is.

• Costs:

– Business case should summarise costs derived from the project plan together with the assumptions upon which they are based.

– Costs should also include details of the on-going operations and maintenance costs and funding arrangements.

<#>



• Investment appraisal:

– Comparison between the development, operations and maintenance costs with the value of benefits over a period of time.

– Over a fixed period of a number of years or the useful life of the products.

– Prescribed accounting rules for how the investment will be appraised may be defined by the commissioning authority.

– Should cover both project costs (to produce the required products and the project management costs) and on-going operations and maintenance costs.

• Major risks:

– Project board needs to understand the set of risks that may either reduce/enhance the benefits or reduce/increase the cost.

– In order to judge business justification.

– Business case should include a summary of the aggregated risk (in the form of a summary risk profile).

– Should highlight the major risks that will have an effect on the business objectives and benefits (covers both the project delivery and the on-going operations and maintenance).

<#>


Typical Business Case Topics

• Executive summary:

– Highlights the key points in the business case.

– Includes important benefits and return on investment.

• Business opportunity:

– Describes the motivation for the project.

– Includes a definition, a statement of scope and a discussion of objectives that the project will help the organisation achieve.

• Alternatives:

– The business case analyses the alternatives to a proposed project.

– All business cases involves at least 2 alternatives:

Doing a project.

Not doing a project.

<#>


Typical Business Case TopicsContinued

• Benefits:

– Benefits provide three types of business value:

Increased revenue.

Reduced costs.

Strategic advantage.

– Quantifying benefits that provide strategic advantage may make the difference between business case success and failure.

• Costs:

– Typical costs include:

Equipment (purchase and maintenance).

Labour (training and operation).

Overhead cost.

• Recommendations:

– Summarise the main points of a business case and offer suggestions on how to proceed with the project.

<#>



• Financial analysis:

– Compares benefits to costs.

– Analyses the value of a project as an investment.

– May include a cash flow statement, return on investment, net present value, internal rate of return and payback period.

• Assumptions:

– Events that a business case assumes will happen.

– Critical assumptions must occur for a project to succeed.

• Sensitivity analysis:

– Evaluates the probability that a project cam be implemented successfully.

– Evaluates the risks involved in undertaking the project.

Risks may also result from not undertaking the project.

• Project description:

– Provide information for Project Board to decide whether the project is viable and worth doing.

• Implementation plan:

– Business case is meaningless unless project cannot be implemented successfully.

<#>



• Constraints:

– Limitations that may impact the success of a project.

– Including:

Schedule.

Resource.

Budget.

Staffing.

Technical.

Other.

• Market analysis:

– Examines changes in business environment that impact the success of a project.

Technological innovations and shifts in customer demographics.

• Organisational considerations:

– Examine how a project impacts an organisation.

– Project success might depend on management support and employee acceptance.

<#>


Typical Business Case ContentsPRINCE2

Varies from industry to industry and from project to project.

• Reasons:

– Why the project is required.

– How the project will enable the treatment of corporate strategies and objectives.

– Generally, reasons will either be to reduce pain or to increase gain of some sort.

• Business Options:

– 3 basic PRINCE2 business case options:

Do nothing - is always the starting point reference for quantifying the other options.

Do the minimum.

Do something.

Whichever option is now selected in the business case:

Should show the best level of investment for the best realized benefits.

Is more viable and achievable than the other options.

<#>


Typical Business Case ContentsPRINCE2 - Continued


– Based on the selected option.

– A list of each business case benefit that could be achieved by the project’s outcome.

– Defines how and when the measurement of these improvements can be made.

– Some benefits will be measured by financial metrics and others by non-financial metrics.

– Each benefit should be tied back through the products and outcomes that will provide them.

– Should be measurable and stated within a tolerance.

– Should be clearly stated in the business case where these benefits will be achieved.

– The PRINCE2 senior user is responsible for identifying the business case benefits in the first place.

– Will be held to account by corporate or programme management that these benefits are eventually realised.


– The outcome is seen as negative, and is usually the result of a side effect or consequence.

– Should be measurable in the same way as benefits including the use of tolerance.

<#>



• Timescale:

– Extracted from the PRINCE2 project plan.

– Includes other time-frames:

Project time-frame.

Time-frame that cost/benefits analysis will be based upon.

Time when benefits will be accrued.

Earliest/latest feasible start and completion dates.

• Costs:

– Summarised from the PRINCE2 project plan along with their assumptions.

– Should also include details of on-going operational and maintenance costs.

– Should also include the funding arrangements.

<#>



• Investment appraisal:

– Depending on the industry or organisation, then different techniques will be used for business case investment appraisal.

– Normally compares the development, operations and maintenance costs against the value of the benefits over a period of time.

– Techniques that may be used within a PRINCE2 business case most often used include:

Return on investment.

Payback period.

Discounted cash flow.

Net present value.

Sensitivity analysis.

• Major risks:

– In order for the business case to make a balanced business justification.

– Consider and include the risks.

– These should be balanced against the benefits and costs.

– Include a summary of the aggregated risks.

– Mention specifically those that will have an effect on the business objectives and benefits.

<#>


Contents of the Final Business Case

• Executive Summary:

– 3 pages for small projects, a maximum of 5 pages for complex projects.

– Write it as if this is the only part of the document that will be read.

– Should cover all the issues that a decision maker will need to know about.

– Outline of the proposal and the business concept.

– Summary analysis of the options and alternatives considered.

– Details of the preferred option.

– Use text, graphics and tables of critical numbers to present the key arguments and findings to decision makers.

– Cover all high-level issues that would be covered in an Executive Director’s briefing.

– Clear, succinct summary of the service delivery requirement to be addressed:

• Project objectives.

• Options considered.

• Summary of evaluation of options.

• Project readiness.

• Budget and funding implications.

• Project risks and risk management strategies.

• Project profile model.

• Gateway (or other) reviews.

• Performance measures.

• Next steps in progressing project.

<#>


Calculating Financial Metrics

• Return On Investment (ROI):

– Profits or savings resulting from investments (this is the same as net benefits if benefits were only financial).

ROI% = (Benefits – Cost)

Cost

• Payback Period (PBP):

– Calculating the period of time required for the ROI to ‘repay’ the sum of the original investment.

• Net present value (NPV):

– The total value of discounted future cash inflows less the initial investment.

– Based on the ‘time value of money’, how much is the project worth right now minus the cost of the project.

NPV = PV – Cost Of Project

– Ex: if inflation is at 6% the value of money halves approximately every 12years.

– If a project is forecasting a SZL500’000 benefit to materialise in year 12, then it is only worth ZSL250’000 in today’s money.

<#>


Calculating Financial MetricsContinued

• Present Value (PV):

– Based on the ‘time value of money’, how much is the project worth right now.

• Benefit Cost Ratio (BCR):

– This ratio compares the benefits to the costs of different options.

>1 benefits are greater than costs.

<1 costs are greater than benefits.

=1 benefits and costs are the same.

• Economic Value Added (EVA):

– How much value has a project truly created for its shareholders.

EVA = After Tax Profits – Capital Invested in project x Cost Of Capital

• Internal Rate of Return (IRR):

– Project’s returns expressed as an interest rate.

• Return on Invested Capital (ROIC):

– How an organisation uses the money invested in a project and it is expressed as a percentage.

ROIC = Net Income (after tax) from Project

Total Capital Invested in the Project

<#>


Detailed CostsPRINCE2

• The project has to be affordable and though we may start out with a particular budget in mind there will be many factors which can lead to overspending and perhaps some opportunities to cut costs.

• Cost tolerance:

– The permissible deviation on a plan’s cost that is allowed before the deviation needs to be escalated to the next level of management. Cost tolerance is documented in the respective plan.

• Plus or minus an amount of time on the planned budget.

• The business case should summarise the costs derived from the project plan together with the assumptions upon which they are based. The costs should also include details of the on-going operations and maintenance costs and their funding arrangements.

• Through-life costs:

– Analysing the total cost of implementation and any incremental operations and maintenance costs.

• Full project costs can only be estimated once the quality criteria for the products and the quality management activities which have to be included in the project’s plans have been established.

• Project plan provides the business case with planned project costs.

<#>


Detailed CostsPRINCE2 - Continued

• The budget should include:

– Costs of the activities to develop and verify the specialist products, and the cost of the project management activities.

– Risk budget (optional).

– Change budget (optional).

– Cost tolerance.

• In order to refine the business case, the outline business case (produced during Starting up a project) must be updated to reflect the estimated time and costs as determined by the Project Plan.

– PRINCE2 recommends that the detailed business case be created using the additional detail gained, namely:

Costs and timescales as calculated in the project plan.

Major risks that affect the viability and achievability of the project (from the Risk Register).

Benefits to be gained.

Tolerances allowed for each of the benefits.

<#>



• 2 of the actions recommended by PRINCE2 when authorising new work packages or authorising amendments to existing ones:

– Examine the stage plan for the current management stage in order to understand the:

Products to be produced.

Cost and effort that the work is expected to consume.

Tolerances available.

– Define each work package to be authorised (or amended):

Obtain the relevant product descriptions for inclusion in the work package.

Define the techniques processes and procedures to be used.

Define the development interfaces to be maintained.

Define the operational and maintenance interfaces to be maintained.

Define the configuration management requirements.

Define the joint agreements on effort, cost, start and end dates, key milestones and tolerances.

Define any constraints that may apply.

Define the reporting, problem handling and escalation arrangements.

Define the approval method.

Provide relevant references.

<#>



• One of the actions recommended by PRINCE2 when updating the business case:

– Examine and review, amongst other elements, the project plan to see whether the cost of delivering the project’s products has changed, which may affect the cost/benefit analysis.

• When a project closes project costs should no longer be incurred.

• Project-level time and cost tolerances will be defined by the programme.

• The customer’s business case covers the benefits to that customer in contrast to its whole-life costs and risks. The costs should include:

– The internal costs (of customer projects resources, and on-going operations and maintenance resources).

– The external costs (of suppliers’ goods and services).

• Cost of conducting the gateway reviews should be included in the Project Plan and Stage Plans.

• One of the actions recommended by Prince 2 when planning the initiation stage:

– Identify any constraints on time and costs for the initiation stage.

<#>


Project Cost Management Overview

• Estimate costs:

The process of developing an approximation of the monetary resources needed to complete project activities.

• Determine budget:

The process of aggregating the estimated costs of individual activities or work packages to establish an authorised cost baseline.

• Control costs:

The process of monitoring the status of the project to update the project budget and managing changes to the cost baseline.

<#>


Estimate Costs:Inputs, Tools & Techniques and Outputs

• Scope Baseline

• Risk Register

• Organisational Process Assets

• Enterprise Environmental Factors

• Project Schedule

• Human Resource Plan

Create WBS

DevelopSchedule

Enterprise/Organisation

Identify Risks

DevelopHuman

ResourcePlan

EstimateCost

ProjectDocuments

PlanProcurement

Identify Risks

• Project Document Updates

Determine Budget

• Activity Cost Estimates

• Basis of Estimates


Estimate Costs: Tools & Techniques

• Expert judgment:

– Cost estimates are influenced by numerous variables such as labour rates, material costs, inflation, risk factors and other variables.

• Analogous estimating:

– Uses values of parameters or measures of scale, from a previous, similar project as the basis for estimating the same parameter or measure for a current project.

• Parametric estimating:

– Uses a statistical relationship between historical data and other variables to calculate an estimate for activity parameters such as cost, budget and duration.

• Three-point estimates:

– The accuracy of single-point activity cost estimates can be improved by considering estimation uncertainty and risk.

– Most Likely.

– Optimistic.

– Pessimistic.

<#>


Estimate Costs: Tools & TechniquesContinued

• Reserve analysis:

– Cost estimates may include contingency reserves (sometimes called contingency allowance) to account for cost uncertainty.

• Cost of quality:

– Assumptions about costs of quality may be used to prepare the activity cost estimate.

• Project management estimating software:

– Project management cost estimating software applications, computerised spread sheets, simulation and statistical tools are becoming more widely accepted to assist with cost estimating.

• Vendor bid analysis:

– Cost estimating methods may include analysis of what the project should cost, based on the responsive bids from qualified vendors.

• Bottom-up estimating:

– This method is used to estimate one component of work.

<#>


Estimating Costs - Techniques

• Historical data/information.

• Experience.

• Top-down Estimating:

– Good overall estimate arrived at for the plan (by whatever means).

– Subdivided through the levels of the product breakdown structure.

– Apportion the effort accordingly.

• Bottom-up Estimating:

– Each individual piece of work is estimated on its own merit.

– These are then summed together to find the estimated efforts for the various summary level activities and overall plan.

• Top-down and bottom-up approach:

– An overall estimate is calculated for the plan.

– Individual estimates are then calculated or drawn from previous plans.

– To represent the relative weights of the tasks.

– The overall estimate is then apportioned across the various summary and detailed-level tasks.

– Using the bottom-up figures as weights.

<#>


Estimating Costs – TechniquesContinued

• Comparative Estimating:

– Historical data built up over time by an organisation regarding projects that it has undertaken (previous experience or lessons learned).

– This data may be useful to reference it for similar projects and apply that data to estimates.

• Parametric Estimating:

– Basing estimates on measured / empirical data where possible.

• Single-point Estimating:

– Sample data is used to calculate a single value which serves as a “best guess” for the duration of an activity.

• Three-point Estimating:

– Ask appropriately skilled resources for their best-case, most likely and worst-case estimates.

– Project manager should choose the weighted average of these three estimates.

• Delphi Technique:

– Relies on obtaining group input for ideas and problem solving without requiring face-to-face participation.

– Uses a series of questionnaires interspersed with information summaries and feedback from preceding responses to achieve an estimate.

<#>


Preparing Cost Estimates

• Decide how much time and resources are required to carry out a piece of work to acceptable standards of performance.

• How:

Identify the type of resource required.

Specific skills may be required depending on the type and complexity of the plan.

Requirements may include non-human resources.

Estimating the effort required for each activity by resource type.

At this point estimates will be approximate and therefore provisional.

• Estimating does not guarantee accuracy.

• When applied it provides an overall view of cost and time required to complete the plan.

• Estimates change as more information is collected about the project.

• Estimates should be challenged – the same work under the same conditions can be estimated differently by various estimators or by the same estimator at different times.

<#>


Rules for Estimating Costs

• Assume that resources will only be productive for 80% of their time.

• Resources working on multiple projects take longer to complete tasks because of time lost switching between them.

• People are generally optimistic and often underestimate how long tasks will take.

• Make use of other people’s experiences and your own.

• Ensure that the person responsible for creating the product is also responsible for creating the effort estimates.

• Always build in provision for problem solving, meetings and other unexpected events.

• Cost each activity rather than trying to cost the plan as a whole.

• Communicate any assumptions, exclusions or constraints you have to the user(s).

<#>


Financial Value for Non-Financial Objectives

• Objectives:

– Something towards which work is to be directed.

– A strategic position to be attained.

– A purpose to be achieved.

– A result to be obtained.

– A product to be produced.

– A possibility for positive changes.

– Contrast with threat.

<#>


Detailed BenefitsPRINCE2

• The measurable improvement resulting from an outcome perceived as an advantage by one or more stakeholders.

• Benefits Review Plan: A plan that defines how and when a measurement of the achievement of the project’s benefits can be made. If the project is being managed within a programme, this information may be created and maintained at the programme level.

• Benefits tolerance: The permissible deviation in the expected benefit that is allowed before the deviation needs to be escalated to the next level of management. Benefits tolerance is documented in the business case.

– Once benefits have been quantified the benefits’ tolerance can be set.

– The measurability of the benefits ensures that they can be proven.

• Perhaps most often overlooked is the question: Why are we doing this? The project manager has to have a clear understanding of the purpose of the project as an investment and make sure that what the project delivers is consistent with achieving the desired return.

• Benefits of a project are often only realised after project closure.

• Link from projects’ outputs to outcomes and benefits should be clearly identified and made visible to those involved – this is the original purpose of the project.

<#>


Detailed BenefitsPRINCE2 - Continued


– Each benefit should be listed in the business case.

– Current status of each benefit should be defined in quantifiable terms in order to assess the measurable improvements after the project has been completed.

– Financial or non-financial.

– Benefits should be:

Aligned to corporate objectives and strategy.

Mapped from the outputs and outcomes provided by the project.

Quantified (with tolerance).

Measurable.

Assigned.

– Successful benefit realisation will be dependent on clear responsibility assignment.

– Expected benefits influence the set of products that the project will provide.

– Mapping products to outcomes and subsequently to benefits will aid decision making in the planning and control of the project.

– Always expressed in tangible ways.

<#>



Expected benefits (continued).

– Always attempt to express seemingly intangible benefits in measurable ways.

– Benefits that cannot be proven makes it impossible to judge whether the project:

Has been a success.

Has provided value for money.

Should be / have been initiated.

– Verifying expected benefits:

Sensitivity analysis – determine whether or not the business case is heavily dependent on a specific benefit.

Define 3 views of the achievement of benefits – what is really expected, what is the best-case scenario and what is the worst-case scenario. This reveals whether benefit expectations are reasonable or overoptimistic.

– Once benefits have been defined, activities to establish and collect measures should be described in the benefits review plan.


– An outcome perceived as negative by one or more stakeholders.

– An actual consequence of an activity.

<#>



• Net benefits:

– Analysing the total value of the benefits less the cost of implementation and on-going operation calculated over a defined period.

• Project closure activities include:

– Planning post-project benefits reviews to take place for those benefits that can only be assessed after the products have been in use.

– Thus after the project has closed.

• Create the detailed business case by updating the outline business case with the following additional detail:

– The costs and timescale as calculated in the project plan.

– The major risks that affect the viability and achievability of the project (from the Risk Register).

– The benefits to be gained.

– The tolerances allowed for each of the benefits.

<#>



• Confirming benefits:

– Identify the benefits.

– Select objective measures that reliably prove the benefits.

– Collect the baseline measures (from which the improvements will be quantified).

– Decide how, when and by whom the benefit measure will be collected.

<#>


Benefit Measurement MethodsComparative Approach

• Murder board (a panel of people who try to shoot down a new project idea).

• Peer review.

• Scoring models.

• Economic models:

– Present value.

– Net present value.

– Internal rate of return.

– Payback period.

– Benefit-cost ratio.

<#>


Benefit Measurement MethodsComparative ApproachEconomic Models (Continued)

– Present Value:

The value today of future cash flows: PV = FV / (1 + r)n

– Net Present Value:

Present value of the total benefits (income or revenue) minus the costs over many time periods (a positive value indicates a good investment and the greater the value the better the investment).

– Internal Rate of Return:

The “interest” rate at which the project inflows (revenues) and project outflows (costs) are equal (the greater the value the more desirable the project).

– Payback Period:

The length of time it takes to recover your investment in the project before you start accumulating profit (the shorter the payback period the more desirable the project).

– Benefit-Cost Ratio:

Relates to costing projects and to determining what work should be done. This ratio compares the benefits to the costs of different options.

If this ratio is greater than 1 it means that the benefits are greater than the costs, if this ratio is less than 1 it means that the costs are greater than the benefits and if this ration is equal to 1 it means that the benefits and the costs are the same.

<#>


Tangible and Intangible Benefits

• Tangible (Hard) Benefits:

– H1 Production of material, software, services, processes, etc.

– H2 Improved collaboration.

– H3 Improved awareness of the ideas, concepts, materials, etc. within the institution, the sector and other wider areas e.g. government or the general public.

– H4 Improved skills and attitudes of users, project team, institution staff, stakeholders and staff in sector.

• Intangible (Soft) Benefits:

– S1 Catalyst for change both in institution and wider.

– S2 Impact on professional or governmental views, actions or policies.

– S3 Improvement of image, standing or effectiveness of the funding body of the project.

– S4 Improvement of image, standing or effectiveness of the institution.

– S5 Improvement of image, standing or effectiveness of the project team.

<#>


Detailed Business Case Approach

• The business case must first be:

– Developed, meaning it contains the right information.

– Verified, meaning that the project is still worthwhile.

– Maintained, meaning that the business case is updated with actual costs and benefits for both current and forecast time-frames.

– Confirmed, meaning assessing whether the benefits have been, or will be realised.

• The project board executive is responsible for the business case.

• The development of the business case as above may be delegated to the project manager or someone else with appropriate finance knowledge and skills including the business assurance role if the executive has delegated their responsibilities.

• The business case will be reviewed:

– At the end of the starting up a project process.

– At the end of the initiating a project process.

• The business case will form part of the evidence the project board uses to decide what to do next.

• During a stage and as part of any impact assessment for issues or risks, the business case should be checked to see what the impact may be.


Detailed Business Case ApproachContinued

• At the end of each stage the project manager will update the business case based on the next stage plan, and also update the project plan, this will be presented to the project board for them to decide what to do next.

• The investment appraisal section of the business case provides the project with information to verify that it justifies the authorization and continuation of the project.

• The senior user is responsible for specifying the benefits within the business case and will be held accountable by corporate or programme management for the eventual realisation of the forecast benefits.

• The benefits review plan is created from the detailed business case during the initiation stage, and this will be updated at the end of each stage as part of the evidence for the project board to consider as to whether to proceed or not. The project’s benefits review plan defines the scope, timing and responsibility of a number of reviews for the expected benefits.

• The benefits that can be measured during a project should be included in each end stage report.



• The business case in PRINCE2 is the document against which all decisions are ultimately made.

• It provides the decision makers (project board) in the project with a clear picture of what the project is set to deliver, how much it is all going to cost, how long it will take, and an analysis of when the expected benefits will come on stream.

• So why is this any different to any other project that we already undertake? For example at home; if we are considering enlarging our living accommodation we first of all have to gain a common understanding of why we need to do it, to have good REASONS. Once that is agreed and decided there are several options that may be available to us:

– We could “do nothing”.

– We could move to a larger house.

– We could build an extension on side of the existing house.

– We could grow into the loft.

– We could adapt the existing room layout.

• Each of these OPTIONS would of course have different costs and timescales attached to them, but we would consider them all, and decide which of them could be discounted and capture why that decision was made. We may be left with a couple of alternatives which need further investigation, but eventually we come to a decision on the way forward, and that is our chosen OPTION.



• The business case is developed at the beginning of the project:

– Getting the right information upon which decisions can be made.

– Executive is responsible for ensuring that the business case written and approved.

– This task may be delegated (to a business analyst or project manager).

– It is essential to ensure that, whoever is assigned the task of developing the business case has the appropriate business skills required.

– Alternatively the project board should consider using project assurance to assist with the development of the business case.

– The outline business case is:

Derived from the project mandate.

Developed pre-project in the starting up a project process.

To gain approval by the project board in the directing a project process to initiate the project.

Outline business case stands until the project has been planned in detail.

Outline business case is based on approximate costs and timescales.



– The detailed business case is derived from the:

Outline business case.

Project plan (costs, timescale, products).

Risk register.

– Throughout the project life cycle the business case will be developed over and over again.

– Initial justification is needed to proceed with the project.

– Better understanding of the costs and timescales may:

Increase/decrease the desirability, viability and achievability of the project.

Change the project approach.

Lead to some re-planning.



• The business case is maintained throughout the life of the project:

– The business case is updated with actual costs and benefits and current forecasts for costs and benefits.

– The business case drives all decision making:

Ensures that the project remains justified and that the business objectives and benefits being sought can be realised.

The business case should be reviewed:

At the end of the starting up a project process by the project board.

At the end of the initiating a project process by the project board.

As part of any impact assessment by the project manager.

In tandem with an exception plan by the project board.

At the end of each stage by the project manager.

At the end of each stage by the project board.

During the final stage by the project manager.

As part of the benefits review.



– The Executive is responsible for assuring the project’s stakeholders that the project remains desirable, viable and achievable at all times, using end stage assessments and project assurance.

– Investment appraisal section of the business case provides information to verify that the business case justifies the authorisation or continuation of the project.

• The business case is formally verified by the project board at each key decision point (i.e. end stage assessments).

– Assess whether the project is still worthwhile.



• The business case is confirmed throughout the period that the benefits accrue:

– Assess whether the intended benefits have been/will be realised.

– This will most likely take place post-project.

– Approach to confirming benefits:

Identify the benefits.

Select objective measures that reliably prove the benefits.

Collect the baseline measures (from which the improvements will be quantified).

Decide how, when and by whom the benefit measure will be collected.

– Senior users must specify the benefits and are held accountable for demonstrating to corporate/programme management that the forecast benefits that formed the basis of project approval are in fact realised.

– Commitment beyond the life of the project is necessary, since many benefits will not be realised until after it has closed and once the project closes, the temporary organisation is disbanded along with the framework (including funding and resources) needed to carry out any measurement activities.

PRINCE2 defines a benefit review plan. It will use the detailed business case to define the scope, timing and responsibility of a number of reviews based on the timing and nature of the expected benefits.



– The Executive is responsible for ensuring that benefit reviews are planned and executed.

Exceptions:

Projects in a programme environment:

o Benefits review plan may be produced and executed by the programme.

o Coordinating the realisation of benefits of its projects is one of the roles of a programme.

If the corporate organisation has a centre of excellence or some form of performance monitoring unit:

o It may take the responsibility for measuring benefits of all projects within the organisation.

Post-project measurement activities:

o Responsibility will transfer from the executive to corporate/programme management as the project closes.

o As the reviews will need to be funded and resourced.



– Benefits review plan:

First created by the project manager.

In the initiation stage.

Submitted to the project board for approval.

When seeking project authorisation.

If corporate or programme management are to manage or participate in the benefits reviews project board may need to seek approval from corporate or programme management.

It is updated towards the end of each stage with actual benefits achieved.

A revised plan is created for any remaining reviews whether within or beyond the life of the project.

PRINCE2 recommends that the benefits review plan is kept separate from the project plan and stage plans.

– Benefits that can be measured during the life of a project should be reported by the project manager in the end stage report.

– Any other benefits should be re-examined and their forecast updated as part of the managing a stage boundary process.



– Post-project benefits review involves:

Corporate or programme management.

The senior user being held to account.

Asking senior users to provide evidence of how the individual benefits allocated to them have been gained in comparison to those benefits promised to justify the cost and risk of the project when it was authorised.

Review of performance of project’s products in operational use.

Identifying whether there have been any side-effects (beneficial/adverse) that may provide useful lessons for other projects.

• The business case is at the centre of any impact assessment of risks, issues and changes.

– How will this risk, issue or change affect the viability of the business case and the business objectives and benefits being sought?


Credibility, Practical Value and Accuracyof the Board

• Credibility:

– of Project Board members within the corporate organisation will affect their ability to direct the project.

• Accuracy:

– Means that the measured value is very close to the true value. A very accurate measure is not necessarily precise.

– Project Management team must determine appropriate levels of accuracy and precision.

– Level of accuracy.

Activity cost estimates will adhere to a rounding of the data to a prescribed precision, based on the scope of the activities and magnitude of the project, and may include an amount for contingencies.

– Precision means the values of repeated measurements are clustered and have little scatter. A very accurate measurement is not necessarily precise.

• If business cases are weak:

– What effect will this have on strategy?

– How much time will be spent reviewing and approving business cases/projects?

– What effect will it have on the company?

<#>


Risk Breakdown Structure

Risks

Internal Risks

Functionality too limited Technology

Integration Problems with

backend systems

Data Centre Unable to Support

Protocol Problems

Selected Technology Unproven

Functionality Manager's

Resistance to Project

External Risks

Shifts in customer

needs

Trading partners won't

adopt

Competition first to market


Risk AnalysisPMP

• Risk: A risk is any unknown on the project. Risks may be positive or negative.

• An uncertain event or set of events, should it occur, will have an effect on the achievement of objectives. A risk is measured by a combination of the probability of a perceived threat or opportunity occurring, and the magnitude of its impact on objectives.

• Risk Acceptance: the decision to deal with the risk if and when it occurs, when risk acceptance is employed, no additional planning or steps will be taken before the risk event occurs.

• Risk avoidance: Taking steps to eliminate the project risk.

• Risk Breakdown Structure: A graphical chart showing risks organised into categories, this organisation will vary from project to project.

• Risk Database: the risk database contains all information on identified risks throughout the life of the project. The risk database will be used by future projects to assist in risk analysis.

• Risk Enhancement: A risk management strategy for making a positive uncertainty even better for the project.

• Risk Exploitation: a risk management strategy for making a positive uncertainty more likely to occur.

• Risk management plan: the component of the project plan that shows how subsequent risk processes and activities will be performed.

<#>


Risk AnalysisPMP – Continued

• Risk mitigation: looking to decrease either the likelihood of an identified risk’s occurrence, or its impact on the project if it does occur.

• Risk register: the document containing all identified risks relevant to the project. the risk register, which is a component of the project plan, contains information about each risk and is updated throughout the project.

• Risk transference: the risk response technique of shifting the risk to another entity, usually a subcontractor of a vendor specialising in that type of risk. Firm fixed price contracts would be one type of risk transference, as would be purchasing an insurance policy that protected the project.

• Risk actionee: a nominated owner of an action to address a risk. Some actions may not be within the remit of the risk owner to control explicitly; in that situation there should be a nominated owner of the action to address the risk. They will need to keep the risk owner informed of the situation.

• Risk appetite: an organisation’s unique attitude towards risk taking that in turn dictates the amount of risk that it considers is acceptable.

• Risk estimation: the estimation of probability and impact of an individual risk, taking into account predetermined standards, target risk levels, interdependencies and other relevant factors.

<#>



• Risk evaluation: the process of understanding the net effect of the identified threats and opportunities on an activity when aggregated together.

• Risk management: the systematic application of principles, approaches and processes to the tasks of identifying and assessing risks, and then planning and implementing risk responses.

• Risk management strategy: a strategy describing the goals of applying risk management, as well as the procedure that will be adopted, roles and responsibilities, risk tolerances, the timing of risk management interventions, the tools and techniques that will be used, and the reporting requirements.

• Risk owner: a named individual who is responsible for the management, monitoring and control of all aspects of a particular risk assigned to them, including the implementation of the selected responses to address the threats or to maximise the opportunities.

• Risk profile: a description of the types of risk that are faced by an organisation and its exposure to those risks.

• Risk response: actions that may be taken to bring a situation t a level where exposure to risk is acceptable to the organisation.

<#>



• Risk tolerance: the threshold levels of risk exposure which, when exceeded, will trigger an Exception Report to bring the situation to the attention of the Project Board. Risk tolerances could include limits on the plan’s aggregated risks, or limits on any individual threat. Risk tolerance is documented in the Risk Management Strategy.

• Risk Tolerance Line: A line drawn on the summary risk profile. Risks that appear above this line cannot be accepted (lived with) without referring them to a higher authority.

• Analyse the risk: this is a planning activity that will run parallel with other steps because risks may be identified at any point in the creation or revision of a plan.

– Examine each resource and activity for potential risk content.

– Identified risks should be entered in the risk register.

<#>


Threat and Opportunity Responses

Threat Responses0 Opportunity Responses

Avoid Exploit

Reduce (probability and/or impact)

EnhanceFall back (reduces impact only)

Transfer (reduces impact only, and often only the financial impact)

Share

Accept Reject


Probability Impact GridP

rob

abili

ty

0.9Very High71-90%

0.045 0.09 0.18 0.36 0.72

0.7High

51-70%0.035 0.07 0.14 0.28 0.56

0.5Medium31-50%

0.025 0.05 0.10 0.20 0.40

0.3Low

11-30%0.015 0.03 0.06 0.12 0.24

0.1Very low

Up to 10%0.005 0.01 0.02 0.04 0.08

Very low Low Medium High Very high

0.05 0.1 0.2 0.4 0.8

Impact


Identify Risks: Inputs and Outputs

Inputs

Risk Management Plan

Activity Cost Estimates

Activity Duration Estimates

Scope Baseline

Stakeholder Register

Cost Management Plan

Schedule Management Plan

Quality Management Plan

Project Documents

Enterprise Environmental Factors

Organisational Process Assets

Outputs

Risk Register


Perform Qualitative Risks Analysis

Inputs

Risk Register


Project Scope Statement


Outputs

Risk Register Updates

The process of prioritising risks for further analysis or action by assessing and combining their probability of

occurrence and impact


Perform Qualitative Risk AnalysisData Flow Diagram

Define Scope

Enterprise /

Organisation

Plan Risk

Management

Perform

Qualitative

Risk Analysis

Identify Risks

Risk Management Plan Risk Register

Project

Scope

Statement

Organisational

Process Assets

Risk

Register

Updates


Perform Quantitative Risks Analysis

Inputs

Risk Register


Cost Management Plan

Schedule Management Plan


Outputs


The process of numerically analysing the effect of identified risks on overall project objectives


Perform Quantitative Risk Analysis:Inputs, Tools & Techniques and Outputs

Project Time Management

Enterprise / Organisation

Plan Risk Management

Perform Quantitative Risk Analysis

Identify Risks

Risk Management Plan Risk Register



Project Cost Management

Schedule Management

Plan

Cost Management

Plan


Plan Risk Responses

Inputs

Risk Register


Outputs


Risk-related Contract Decisions

Project Management Plan Updates

Project Document Updates


Risk Calculation

Probability x Impact = % risk

Calculation: Risk Response: Issue Response:


The Purpose and Objective of Initiating

• Purpose of process is to establish solid foundations for the project, enabling the organisation to understand the work that needs to be done to deliver the project’s products before committing to a significant spend.

• Objective of process is to ensure a common understanding of:

– The reasons for doing the project, benefits expected and associated risks.

– Scope of what is to be done and products to be delivered.

– How and when project’s products will be delivered and at what cost.

– Who is to be involved in the project decision making.

– How the quality required will be achieved.

– How baselines will be established and controlled.

– How risks, issues and changes will be identified, assessed and controlled.

– How progress will be monitored and controlled.

– Who needs information, in what format at what time.

– How the corporate project management method will be tailored to suit the project.

<#>


The Context and Activities of Initiating

• Context:

– Foundation.

– Allows project board to decide whether the project is properly aligned with corporate objectives to authorise it continuation.

– If there is a commercial relationship between the customer and supplier all activities within the initiating a project process need further consideration.

– The project manager will be creating the suite of management products required for the level of control specified by the project board.

• Activities:

– Prepare the risk management strategy.

– Prepare the configuration management strategy.

– Prepare the quality management strategy.

– Prepare the communication management strategy.

– Set up the project controls.

– Create the project plan.

– Refine the business case.

– Assemble the project initiation documentation.

<#>


The Purpose and Objective of Delivering

• Purpose is to control the link between the project manager and the team managers by placing formal requirements on accepting, executing and delivering project work.

– The team manager’s role is to coordinate an area of work that will deliver one or more of the project’s products.

• Objective is to ensure:

– Work allocated to team is authorised and agreed.

– Team managers, team members and suppliers are clear as to what is to be produced, expected effort, cost or timescales.

– The planned project is delivered to expectations and within tolerance.

– Accurate progress information is provided to the project manager at an agreed frequency to ensure that expectations are managed.

<#>


The Context and Activities of Delivering

• Context:

– The team manager ensures delivery by:

Accepting and checking authorised work packages form Project manager.

Ensuring that interfaces identified in the work packages are maintained.

Creating a team plan for the work packages being assigned.

Ensuring that development is in accordance with any development methods specified in the work package.

Demonstrating that each product meets its quality criteria.

Obtaining approval for completed products from the authorities identified in the product description.

Delivering the products to the project manager in accordance with any procedures specified in the work package.

• Activities:

– Accept a work package.

– Execute a work package.

– Deliver a work package.

<#>


The Purpose and Objective of Closing

• Purpose is to provide a fixed point at which acceptance for the project product is confirmed and to organise that objectives set out in the original project initiation documentation have been achieved.

• Objective is to:

– Verify user acceptance of the project’s products.

– Ensure that the host site is able to support the products when the project is disbanded.

– Review the performance of the project against its baselines.

– Assess any benefits that have already been realised, update the forecast of the remaining benefits and plan for a review of those unrealised benefits.

– Ensure that provision has been made to address all open issues and risks, with follow-on action recommendations.

<#>


The Context and Activities of Closing

• Context:

– PRINCE2 projects are finite.

– A clear end to a project:

• More successful.

• Provides opportunity to ensure that all unachieved goals and objectives are identified so that they can be addressed in the future.

• Transfer ownership of the products to the customer and terminates the responsibility of the project management team.

– Closure activities should be planned as part of stage plan for final management stage.

– Project board may want to trigger premature project closure of the project under some circumstances.

• Activities:

– Prepare planned closure.

– Prepare premature closure.

– Hand over products.

– Evaluate the project.

– Recommend project closure.

<#>


Making AssumptionsPRINCE2

• A statement that is taken as being true for the purposes of planning, but which could change later.

• An assumption is made where some facts are not yet known or decided.

• An assumption is usually reserved for matters of such significance that, if they change or turn out not to be true, there will need to be considerable re-planning.

<#>


Making AssumptionsPMBoK

• Assumptions are factors that, for planning purposes, are considered to be true, real or certain without proof or demonstration.

• The constraints and assumptions from the project scope statement are considered when estimating the activity durations.

– Examples of assumptions include:

• Existing conditions.

• Availability of information.

• Length of the reporting periods.

– Examples of constraints include:

• Available skilled resources.

• Contract terms and requirements.

• Assumptions analysis:

– Every project and identified project risk is conceived and developed based on a set of hypotheses, scenarios, or assumptions.

– Assumptions analysis explores the validity of assumptions as they apply to the project.

– It identifies risks to the project from inaccuracy, instability, inconsistency or incompleteness of assumptions.

<#>


Making AssumptionsContinued

• Constraints and assumptions:

– Constraints are factors that limit the team’s options such as limits on resources, budget, schedule and scope.

– Assumptions are things that are assumed to be true but that may not be true.

– Constraints and assumptions are recorded in the project scope statement.

– Constraints and assumptions are inputs to many project management processes.

– Identified and then managed.

– Sponsor, team and other stakeholders can identify constraints and assumptions and review them for validity throughout the life of the project.

– If the constraints change or the assumptions are proven wrong the project management plan may need to change.

– Assumptions analysis is part of the risk management process.

• Historical records can be used to validate assumptions.

• An assumption is anything that is considered to be true while planning.

• Assumptions should always be documented and validated, and they are often closely linked to constraints.

<#>


Portfolio, Programme and ProjectManagement Interactions

Highest Level Portfolio

Higher Level Programs

Lower Level Programs

Projects

Projects

Projects

Higher Level Programs

Projects Lower Level Programs

Projects

Lower Level Portfolio

• Strategies & priorities• Progressive elaboration• Governance• Disposition on requested

changes• Impacts from changes in

other portfolios, programs or projects







• Performance reports• Change requests with impact

on other portfolios, programs or projects






PRINCE2 Processes

Directing

Managing

Delivering

Pre-projectInitiation stage

Subsequent delivery stage(s)

Final delivery stage

Starting up a

project

Directing a project

Managing a stage

boundary

Managing a stage

boundary

Closing a

project

Initiating a project

Controlling a stage

Controlling a stage

Managing product delivery

Managing product delivery


Project Boundaries

Project Initiator / Sponsor

Project Inputs

Initiating Processes

Closing Processes

Executing Processes

Planning Processes

Project Deliverables

Project Records

End Users

Process Assets

Project Boundaries

Monitoring & Controlling Processes


Project Life Cycle and Organisation

Other Stakeholders

Portfolio Manager

Program Manager

Project Management

Office

Sponsor

Project Management

Team Project Manager

Other Project Team

Members

Operations Management

Functional Managers

Sellers / Business Partners

Customers / Users

Project Team

The Project

Project Stakeholders


Business Case Approval Process

What is your Business Case approval process?


The business case development and approval process

• The development and approval process should be designed to be:

– Adaptable - tailored to the size and risk of the proposal.

– Consistent - the same basic business issues are addressed by every project.

– Business oriented - concerned with the business capabilities and impact, not a technical focus.

– Comprehensive - includes all factors relevant to a complete evaluation.

– Understandable - content is relevant & logical, demanding yet simple to complete & evaluate.

– Measurable - all key aspects can be quantified in order to track and measure achievement.

– Transparent - key elements can be justified directly.

– Accountable - clear accountabilities & commitments for benefit delivery & cost management.

• Development of the business case should not be mechanical.

• The process of developing a business case involves:

– Financial decomposition.

– Opportunity identification.

– Opportunity qualification.

– Benefit validation.

– Finalization of the business case.


What a Business case is not / should not be

• No stories

• No long winded paragraphs (Must be in point form)

• As short as possible to give the information

• Get to the point! (Must sell the project)

• Must not be vague

• Must not be one of the other project documents

– Specification

– Project Plan


Project management fundamentals


The Project Manager’s PowerBy Organisation Type

Functional Weak Matrix

Balanced Matrix

Strong Matrix

Projectized

Less formal

authority

More formal

authorityFunctional Manager Stronger

Power Shared

Between Project and Functional Manager

Project Manager Stronger


What Is A Project Manager?

• The person assigned by the performing organisation to achieve the project objectives.

• Characteristics of a project manager:

– Knowledge – what the project manager knows about project management.

– Performance – what the project manager is able to do or accomplish while applying their project management knowledge.

– Personal – how the project manager behaves when performing the project or related activity. Personal effectiveness encompasses attitudes, core personality characteristics and leadership – the ability to guide the project team while achieving project objectives and balancing the project constraints.

• The project manager must address every process to determine the level of implementation for each process for each project. If a project has more than one phase, the same level of rigor should be applied to processes within each phase of the project.

• The role of the person ultimately responsible for the project. The project manager has the authority to spend project budget and to assign project resources in order to realise the project’s goals.


What Is A Project Manager?Continued

• The Project Manager is:

– Formally empowered to use organisational resources.

– In control of the project.

– Authorised to spend the project’s budget.

– Authorised to make decisions for the project.

• Management skills:

– Leading.

– Communicating.

– Negotiating.

– Problem solving.

– Influencing.

• Competencies:

– Planning.

– Time management.

– People management.

– Problem solving.

– Attention to detail.

– Communication.

– Negotiation.

– Conflict management.



• Project manager controls:

– Authorisations.

– Progress updates.

– Exceptions and changes.

• Four levels of management:

– Corporate or programme management.

– Directing.

– Managing.

– Delivering.



• Responsibilities:

– Prepare the following baseline management products, in conjunction with any project assurance roles and agree them with the project board:

Project brief, including project product description.

Benefits review plan.

Project initiation documentation.

Stage/exception plans and their product descriptions.

Work packages.

– Prepare the following reports:

Issue reports.

End stage reports.

Lessons reports.

Exception reports.

End project reports.

– Maintain the following records:

Issue register.

Risk register.

Daily log.

Lessons log.



– Liaise with corporate or programme management.

– Liaise with any external suppliers or account managers.

– Lead and motivate the project management team.

– Ensure that behavioural expectations of team members are established.

– Manage the information flows between the directing and delivering levels of the project.

– Manage the production of the required products, taking responsibility for overall progress and use of resources and initiating corrective action where necessary.

– Establish and manage the project’s procedures.

– Establish and manage the project controls.

– Authorise work packages.

– Advise the project board of any deviations from the plan.

– Unless appointed to another person(s), perform the team manager role.

– Unless appointed to another person(s), perform the project support role.

– Implement the configuration management strategy.

– Ensure project personnel comply with the configuration management strategy.

– Schedule configuration audits.


What Is A Project?

• A temporary organisation that is created for the purpose of delivering one or more business products according to an agreed business case.

• A temporary endeavour with a beginning and an end which creates a unique product, service or result.

• A time-limited undertaking to deliver a unique product, service or outcome.

• Unique means that it has never been performed by this organisation before.

• Projects do not include on-going operations, although they do need to consider them upfront.

• A temporary (finite) group of related tasks undertaken to create a unique product, service or result.

• The project ends when the objectives have been achieved or when the project is terminated because its objectives will not or cannot be met, or when the need for the project no longer exists.

• Organisational influences on project management.

• Organisational cultures and styles.


What Is A Project?Continued

• Organisational structure:

– Functional organisation.

– Weak matrix organisation.

– Balanced matrix organisation.

– Strong matrix organisation.

– Projectised organisation (i.e. the entire company is organised by projects).

– Composite organisation.

• Organisational process assets:

– Processes and procedures.

– Corporate knowledge base.

• Projects and strategic planning.

• Projects are often used to achieve an organisation’s strategic plan.

• Projects are usually authorised because of one or more of the following strategic considerations:

– Market demand.

– Strategic opportunity/business need.

– Customer request.

– Technological advance.

– Legal requirements.


What Is Project Management?

• The application of knowledge, skills, tools and techniques to project activities to meet the project requirements.

• Project management processes:

– Initiating.

– Planning.

– Executing.

– Monitoring and controlling.

– Closing.

• Managing a project typically includes:

– Identifying requirements.

– Addressing the various needs, concerns and expectations of the stakeholders as the project is planned and carried out.

– Balancing the competing project constraints including, but not limited to:

Scope.

Quality.

Schedule.

Budget.

Resources.

Risk.


What Is Project Management?Continued

• Project management office: is an organisational body or entity assigned various responsibilities related to the centralised and coordinated management of those projects under its domain. The responsibilities of a PMO can range from providing project management support functions to actually being responsible for the direct management of a project.

• Primary function: To support project managers in a variety of ways.

• Project processes performed by the project team:

– Project management processes.

– Product-oriented processes.


Project Life Cycle


Impact of Variable Based on Project Time

Stakeholder influence, risk and uncertainty

Deg

ree

Project Time

High

Low

Cost of changes


Typical Cost and Staffing LevelsAcross the Project Life Cycle

Starting the

project

Organising and

preparing

Closing the

project

Carrying out the workC

ost

an

d S

taff

ing

leve

l

Project Charter

Project Management Plan

Accepted Deliverables

Archived Project

Documents

Project Management Outputs

Cost and Staffing level


Project Life Cycle


• What is a stage?

• Why have a stage?

– Control.

– Measurement.

Stage


Stages/Steps/Phases

• Stage/Step/Phase 1:

Proposal.

Business case.

Feature pack.

Scope of work.


Solution design.

Analysis.

Requirements.


Planning.


Execution.


System testing (internal).


Implementation.

UAT (user acceptance testing).


Go live.

Hand over to support.


Customer hand over.

Snag fixing.

Training & support.


Close.

Lessons learnt.

Project audit.


Benefits measurement.

Customer satisfaction.


Project Life Cycle


Project Management Process Groups

Enter Phase / Start Project

Initiating Processes

Planning Processes

Executing Processes

Monitoring & Controlling Processes

Closing Processes

Exit Phase / End Project


Project Life CycleTheory

• A collection of project phases.

• Usually following in sequence.

• Sometimes overlapping.

• The names and numbers are determined by:

– The management and control needs of the organisation or organisations involved in the project (i.e. the unique aspects of the organisation).

– The nature of the project itself.

– The area of application.

– The technology and/or industry engaged in the project.

• Can be documented with a methodology.

• Provides basic framework for managing the project.

• Characteristics: See slides.


Project Life CycleTheory – Continued

• Product vs Project Life Cycle Relationships:

– Product life cycle:

Collection of product phases.

Usually following in sequence.

Never overlaps.

Determined by:

Manufacturing and control needs of the organisation.

Last phase is the product’s retirement phase.

– Expected result of a project is related to a product:

Development of a new product – this becomes a project.

Adding new functions or features to a product – this becomes a project.

Develop a new model of the product – this becomes a project.

– If all projects related to one product are overseen by a higher authority it could increase likelihood of success.



• Project Phases:

– Divisions within a project where extra control is needed.

– To effectively manage the completion of a major deliverable.

– Element of the project life cycle.

– Not a project management process group.

– Characteristics:

Close of a phase ends with some transfer or handoff of the work product produced as the phase deliverable.

The work has a distinct focus that differs from any other phase.

The primary deliverable or objective of the phase requires an extra degree of control to be successfully achieved.

– Differ in duration or length.



– Project governance across the life cycle:

Provides a comprehensive, consistent method to control the project and ensure its success.

Phase structure provides formal basis for control.

A phase is formally closed off with a review of the deliverables to determine completeness and acceptance.

Closing off of one phase does not include automatic authorisation for the next phase.

– Phase-to-phase relationships:

Sequential relationship.

Overlapping relationship.

Iterative relationship.

• Projects vs. operational work:

– Shared characteristics:

Performed by individuals.

Limited by constraints, including resource constraints.

Planned, executed, monitored and controlled.

Performed to achieve organisational objectives or strategic plans.



– Operations:

Are on-going.

Produce repetitive products, services or results.

Sustains the organisation over time.

Does not terminate when the current objectives are met.

Operations department interacts with the project team to achieve project goals.

– Examples of when project deliverables are integrated into the future business practices of the operations department:

• Developing a new product or service that is added to an organisation’s product line to be marketed and sold.

• Installing products or services that will require on-going support.

• Internal projects that will affect the structure, staffing levels or culture of an organisation.

• Developing, acquiring and enhancing an operational department’s information system.



• Stakeholders:

– Persons of organisations (customers, sponsors, the performing organisation, the public) who are actively involved in the project or whose interests may be positively or negatively affected by the performance or completion of the project.

– May also influence the project, deliverables, project team members.

– Project team must identify both internal and external stakeholders.

– Project manager must manage the influence of various stakeholders.

• Table: Organisational Influences on Projects.

Project

Characteristics

Organisation

Structure Functional

MatrixProjectized

Weak Balanced Strong

Project Manager’s AuthorityLittle or

NoneLimited

Low to

Moderate

Moderate to

HighHigh to Almost Total

Resource AvailabilityLittle or

NoneLimited

Low to

Moderate

Moderate to

HighHigh to Almost Total

Who controls the project

budget

Functional

Manager

Functional

ManagerMixed

Project

ManagerProject Manager

Project Manager’s Role Part-Time Part-Time Full-Time Full-Time Full-Time

Project Management

Administrative StaffPart-Time Part-Time Part-Time Full-Time Full-Time


Project Documents

• Business case.

• Project charter.

• Project plan.

• Project schedule.

• Technical specification.


QualityIn

itia

l pro

ject

pla

nn

ing

Qu

alit

y p

lan

nin

g

Fin

al p

roje

ct

man

agem

ent

pla

n

app

rova

l

Do

wo

rk

Qu

alit

y as

sura

nce

Qu

alit

y co

ntr

ol

Quality is improved:

Processes are followed.

Changes are made.

Good practices are shared with the organisation.

Problems are found in advance.

The project management plan and project documents are updated.

Inte

grat

ed c

han

ge

con

tro

l

Do

wo

rk f

ollo

win

g th

e n

ew p

lan

Rep

eat

qu

alit

y as

sura

nce

an

d q

ual

ity

con

tro

l


Plan Quality Inputs,Tools & Techniques and Outputs

Inputs:

Scope baseline.

Stakeholder register.

Cost performance baseline.

Schedule baseline.

Risk register.

Enterprise environmental factors.

Organisational process assets.

Tools & Techniques:

Cost-benefit analysis.

Cost of quality.

Control charts.

Benchmarking.

Design of experiments.

Statistical sampling.

Flowcharting.

Proprietary quality management methodologies.

Additional quality planning tools.

Outputs:

Quality management plan.

Quality metrics.

Quality checklists.

Process improvement plan.

Project document updates.


• Perform quality assurance:

– Are we using the standards?

– Can we improve the standards?

– Quality assurance tools and techniques:

Plan quality and perform quality control tools and techniques.

Quality audits.

Process analysis.

Outputs of perform quality assurance.

Quality


QualityContinued

• Perform quality control:

– The process of ensuring a certain level of quality in a product or service. It looks for products or services that do not meet the standards of quality.

– Control means measure.

– Mutual exclusivity.

– Probability.

– Normal distribution.

– Statistical independence.

– Standard deviation (Sigma).

– 3 or 6 Sigma.

– Seven basic tools of quality:

Cause and effect diagram.

Flowchart.

Histogram.

Pareto chart.

Run chart.

Scatter diagram.

Control chart.


• Plan quality – outputs:

– Quality management plan.

– Quality metrics.

– Quality checklists.

– Process improvement plan:

Process boundaries.

Process configuration.

Process metrics.

Targets for improved performance.

– Project document updates.

QualityContinued


QualityContinued

• Quality audit:

– A structured, independent review to determine whether project activities comply with organisational and project policies, processes and procedures.

• Quality:

– The totality of features an inherent or assigned characteristics of a product, person, process, service and/or system that bears on its ability to show that it meets expectations or satisfies stated needs, requirements or specifications.

• Quality criteria:

– A description of the quality specification that the product must meet, and the quality measurements that will be applied by those inspecting the finished product.

• Quality inspection:

– A systematic, structured assessment of a product carried out by two or more carefully selected people (the review team) in a planned, documented and organised fashion.

• Quality management:

– The coordinated activities to direct and control an organisation with regard to quality.


QualityContinued

• Quality management strategy:

– A strategy defining the quality techniques and standards to be applied, and the various responsibilities for achieving the required quality levels, during a project.

• Quality management system:

– The complete set of quality standards, procedures and responsibilities for a site or organisation.

• Quality records:

– Evidence kept to demonstrate that the required quality assurance and quality control activities have been carried out.

• Quality register:

– Contains summary details of all planned and completed quality activities.


• Risk response strategies (risk mitigation strategies):

– Response strategies for threats:

Avoid.

Mitigate.

Transfer.

– Response strategies for opportunities:

Exploit.

Enhance.

Share.

• Risk reassessment:

– Risk management plan and risk register must be reviewed periodically and adjusted as required.

• Risk audits:

– Arranged by project manager.

– Result is the identification of lessons learned for the project.

– This serves as evidence of how seriously risk should be taken on a project.

Risk


RiskContinued

• Risk factors:

– The probability that it will occur.

– The range of possible outcomes.

– Expected timing in the project life cycle.

– The anticipated frequency of risk events from that source.

• Risk averse:

– Someone who does not want to take risks.

• Risk tolerances:

– The areas of risk that are acceptable or unacceptable.

• Risk thresholds:

– The point at which a risk becomes unacceptable.

• Six sequential risk management processes:

– Plan risk management.

– Identify risks.

– Perform qualitative risk management.

– Perform quantitative risk management.

– Plan risk responses.

– Monitor and control risk responses.


• Plan risk management – outputs:

– Risk management plan:

Methodology.

Roles and responsibilities.

Budgeting.

Timing.

Risk categories.

Definitions of probability and impact.

Stakeholder tolerances.

Reporting formats.

Tracking.

– Risk categories:

External.

Internal.

Technical.

Unforeseeable.

– Causes of risks:

The customer.

Lack of project management effort.

Lack of knowledge of project management.

The customer’s customers.

Suppliers.

Resistance to change.

Cultural differences.

– Sources of risks:

Schedule.

Cost.

Quality.

Scope.

Resources.

Customer/stakeholder satisfaction.

Risk Outputs


Risk OutputsContinued

– Types of risk:

Business risk.

Pure (insurable) risk.

– Identify risks:

Documentation reviews.

Information gathering techniques:

Brainstorming.

Delphi technique.

Interviewing.

Root cause analysis.

SWOT analysis:

Strengths.

Weaknesses.

Opportunities.

Threats.

Checklist analysis.

Assumptions analysis.

Diagramming techniques.

– Risk register:

List of risks.

List of potential responses.

Root cause of risks.

Updated risk categories.


• Plan Risk responses:

– Do something to eliminate the threats before they happen.

– Do something to make sure the opportunities happen.

– Decrease the probability and/or impact of threats or increase the probability and/or impact of opportunities.

– For the remaining threats that cannot be eliminated:

Do something if the risk happens (contingency plans).

Do something if contingency plans are not effective (fall back plans).

– Outputs of Plan Risk Responses:

Project management plan updates.


Risk register updates:

Residual risks.

Contingency plans.

Risk response owners.

Secondary risks.

Risk triggers.

Contracts.

Fall back plans.

Reserves (contingency).

Risk Response


RiskContinued

• Outputs of monitor and control risks:

– Risk register updates.

– Change requests.

– Project management plan updates.

– Project document updates.

– Organisational process assets updates.

• Risk categorisation:

– What will we find if we regroup the risks by categories?

– What will we find if we regroup the risks by work packages?

• Risk urgency assessment:

– Qualitative risk analysis includes noting risks that should move more quickly through the process than others.


• Time:

– Plus or minus an amount of time on the target completion dates.

• Timescale:

– Corporate and/or programme management will wish to know:

Over what period the project costs will be incurred.

Over what period the cost/benefits analysis will be based.

When the organisation can expect to accrue benefits.

What the earliest/latest feasible start date is.

What the earliest/latest feasible completion date is.

Time (Duration)


• Scope baseline:

– The agreed-upon project scope statement, work breakdown structure and work breakdown structure dictionary.

• Verify scope:

– This process involves frequent, planned-in meetings with the customer or sponsor to gain formal acceptance of deliverables during monitoring and control.

• Control scope:

– Involves measuring project & product scope performance & managing scope baseline changes.

• Scope:

– For a plan, the sum total of its products and the extent of their requirements.

– Described by the product breakdown structure for the plan and associated product descriptions.

• Scope tolerance:

– The permissible deviation in a plan’s scope that is allowed before the deviation needs to be escalated to the next level of management.

– Documented in the respective plan in the form of a note or reference to the product breakdown structure for that plan.

Scope


Scope is the “what”:

• Technical specification.

• Risks.

• Quality.

Control & measure during the project:

• Time (hours).

• Duration (start & end).

• Cost (amount).

• Scope (what):

– Technical specifications and others:

• Architectural.

• Design diagrams.

– Risk.

– Quality.

Time (Hours)

Cost (Amount) Scope (What)

What Is Scope?


Control Scope Inputs,Tools & Techniques and Outputs

Inputs:

Project management plan.

Work performance information.

Requirements documentation.

Requirements traceability matrix.

Organisational process assets.

Tools & Techniques:

Variance analysis.

Outputs:

Work performance measurements.

Organisational process assets updates.

Change requests

Project management plan updates.



• A PRINCE2 project is planned, monitored and controlled on a stage-to-stage basis.

• Management stages provide senior management with control points at major intervals throughout the project.

• Breaking the project into a number of stages enables the extent of senior management control over projects to be varied according to the business priority, risk and complexity involved.

• Planning can only be done to a level that of detail that is manageable and foreseeable.

• PRINCE2 requires that there be a minimum of 2 management stages:

– 1 initiation stage.

– 1 or more further management stages.

• Management products assisting the project manager in establishing baselines for progress control:

– Project plan.

– Stage plans.

These form the basis of the day-to-day control of the stage.

– Exception plan.

Stages and Phases


Plan the next stage: Activity Summary


Plan the next stage: Responsibilities


Stages and PhasesContinued

• Report stage end:

– The results of a stage should be reported back to the project board.

– So that progress is clearly visible to the project management team.

• Use of management stages:

– Partitions of the project with management decision points.

– A collection of activities and products whose delivery is managed as a unit.

– Management stages:

Provide review and decision points.

Give the ability to ensure that key decisions are made prior to the detailed work needed to implement them.

Allow clarification of what the impact will be of an identified external influence.

Facilitate the management by exception principle.

– The project board authorises one management stage of the project at a time.



• Number of stages:

– Flexible.

– Depends on the scale and risk of the project.

– Defining management stages is a balancing act:

How far ahead in the project is it sensible to plan.

Where the key decision points need to be on the project.

The amount of risk within a project.

Too many short management stages.

How confident the project board and project manager are in proceeding.

• Length of stages:

– PRINCE2 does not define.

– Greater risk, uncertainty or complexity = shorter stage.

– Depends on point within the project life cycle:

The planning horizon at any point in time.

The technical stages within the project.

Alignment with programme activities.

The level of risk.



• Technical stages:

– Group work by set of techniques used/products created.

– Often overlap.

• Boundary of two types of stages (management and technical) will coincide often.

• Authorise a stage or exception plan:

– Stage should only start when the project board says it should.

– If an exception has occurred during the stage the project board may request that the project manager produces an exception plan for project board approval.

– Only exceptions to stage plans or project plans need to be escalated for approval.

– The project board may appoint project assurance to undertake some of the reviewing and assessing actions.



• Plan the next stage:

– Stage plan for next management stage is produced when the current stage is near an end.

– If the next stage is the final stage, the plan should include closure activities.

– Project manager must consult with:

Project board.

Project assurance.

Team managers.

Other stakeholders.

– Recommended by PRINCE2:

Review the components of the project initiation documentation.

Produce the stage plan for the next stage.

Create or update configuration item records for products in the next stage.

Update the issue register and risk register.

Update the quality register for planned quality management activities.



• Review the stage status:

– Objective is to maintain an accurate and current picture of progress on the work being carried out and the status of resources.

– How frequently this happens is defined in the stage plan.

– Recommended by PRINCE2:

Review progress for the stage.

Based on the analysis, decide whether any actions are required.

Revise the risk register and issue register as necessary.

Update the stage plan if the aggregated assessment changes any forecasts.

If ownership of any of the products is to be transferred to the customer as part of a phased handover.

Consider whether to review lessons now or wait until a later review of stage status or when approaching a stage end.

If the end of the current stage is near, prepare for the next phase.

If the end of the final stage is near, prepare to close the project.


Need for scope change found during Control Scope

Potential impact to scope found in Control Cost, Control Schedule, etc.

Perform Integrated Change Control – accept or reject the change

Return to Control Scope to process the approved change

Change Control Process


Project Name:Select the name carefully; it will be used to refer to the project for the life of the effort. Use language that people outside

the project can understand.

Project Description:Describe the essential elements of the project in a few paragraphs. Include information about the current situation and

what will be different when the project is complete. Focus on the value of the changes to the organization.

Objectives:Create a bulleted list of the most critical objectives of the project. Do not simply repeat items from the description. List

critical goals and final results.

Criticality:

Choose a size category of low, medium, or high. Provide information about the urgency and the benefits of the project, to

explain the selected rating. Consider the criticality based on the broadest view of the organization, not the narrow needs

of a particular group.

High Level Scope: Describe any project deliverables that are known at this stage.

High Level Timeline:Indicate a rough timeline as to when you foreseen the project commencing and completing. If you have details on phases

please include these here.

Summary Budget:Provide some indication of estimated budget required to execute the project. These should include labour (permanent

and/or temporary), hardware, software or any other fees.

Risk of doing: Note any project risks to the business. These should include organisational, environmental and/or external risks.

Risk of not doing:In converse are there any business risks of not doing the project. These should include organisational, environmental

and/or external risks.

Project Charter Approval

Title Name/s Sign-Off Date

Submitted By

Reviewed By

Project Sponsor

Executive Committee

Approval Feedback

Include any additional notes or requirements from the Approval Committee above. E.g. There may be

a need for a business case before the project can commence etc.

Project Charter Summery


• Business case.


• Project communication.

• High level technical description.

• High level technical specification.

• Quality.

• Risks.

• Bill of materials (BOM).

• Contact list.

• Major milestones.

• Penalties.

• Conditions.

• Rules.

• Excluded/exclusion.

• SLA (service level agreements).

• Guarantees and warrantees.

• Contingency fee or percentage (%) allowed.

Project Plan


Project PlanBusiness Case Headings

• Motivation.

• Project objective.

• RACI (responsible, accountable, consulted, informed).

• Project major milestone dates.

• Pricing.

• Critical success factors.

• Current equipment.

• Envisaged bill of materials (BOM).

• Project process.

• To be submitted with the proposal.

• To be submitted and approved before onsite implementation (after order number is received).

• To be submitted on handover.

• References.

• Rules.

• Meetings.

• Working hours.

• Other areas to be covered in the proposal.

• Suppliers.

• Supplier valuation criteria.

• Sign-off.


Project Process: 43 Step ProcessSteps 1-11

1. Budget approved (business motivation). Approved by centre, head office heads of department and executives.

2. Capex approved but requires further detail. What further detail is needed, why it was not approved and questions to gain clarification answered, “requires further motivation” should never be used, open ended.

3. Capex approved (business case/project charter). Approved by centre and relevant heads of department.

4. Identify project stakeholders.

5. Obtain Liberty governance, procedures, architecture and methodology.

6. High level design and layout.

7. Technical specification approved. Approved by centre and specialists assigned by heads of department, specifications should not be approved by executives or business unit managers but by the centre and specialists who understand the specifications.

8. Brand evaluation.

9. Product evaluation.

10. Supplier evaluation.

11. Mandate paperwork complete.



12. Mandate loaded.

13. Project approved/received by procurement.

14. Tender issued.

15. Tender adjudication/choosing a supplier.

16. Order number issued to supplier.

17. Project kick-off meeting.

18. Equipment lead time, project documentation and pre-implementation meetings.

19. Detailed project plan approved.

20. Detailed bill of materials/quantities approved.

21. Detailed schematic diagram approved.

22. Detailed layouts and designs approved.



23. ATP approved (acceptance test procedure).

24. Training schedule and plan approved.

25. Equipment on-site.

26. Training manual approved.

27. Administrator manual and passwords approved.

28. On-site implementation.

29. Constant monitoring of the project against detailed project plan, bill of materials, layouts and designs, specification and tender documents.

30. Constant updating of project progress, risks / issues and project changes.

31. Constant checking and ensuring the project is delivered against all criteria, keeping project on track and ensuring maximum business value is delivered.

32. Testing and training.

33. As built diagrams, layouts and schematics approved.



34. Go live.

35. Hand over documentation accepted and sign-off.

36. Outstanding actions/deliverables list cleared and signed-off.

37. Final bug fixes complete and signed-off.

38. Lessons learnt submitted.

39. Project sign-off close.

40. Project audit.

41. Final payment.

42. SLA signed (service level agreement).

43. Handover to stakeholders and operations.



• Outstanding list/issues/problems.

• Risk list.

• Weekly report.

• Monthly report.

• Change log.

• Audit report.

• Project checklist.

• Documents:

– Business case.

– Project charter.

– Project plan.

– Project schedule.

– Technical specification.

– Project presentation.

– Project update presentation.

Lists/Reports


Project Indicators/robots/colours/percentages


Project Methodologies/Framework/Processes

• PRINCE2.

• PMP/PMBoK.

• Waterfall.

• SDLC.

• Agile.

• Scrum.

• Why different methodologies?

• Why the risk?


Driving a Project

Project managers have “Teeth”.


Project Meetings

• Why have project meetings?

• What to cover in a project meeting?

• How long should a project meeting be?

• Project minutes of checklist/to do list?

• Meeting VS divide and conquer.

• Meeting VS telephone VS email.


Appointing the Project Manager

1. Business Case.

2. Sponsor.

3. Negotiating your responsibilities.

4. Negotiate time, cost, scope, risk, quality if not correct.


Project Planning

• What is project planning?

• What is a WBS (work breakdown structure)?

• What is a project schedule?

• How to plan a project (make tea).

• Fail to Plan, Plan to Fail.


Project Dashboard


Project Progress Report

IT Stabilisation Project Sharepoint Portal Reporting Requirements

Requirements Information

Title *IT Stabilisation Project - Nelson Mandela Square

Programme ManagerYvonne Hefer

Project ManagerBurgher Nortje

Project StatusGreen

Report Date *01-Jul-10

Project Phase *Phase 2

Actual Start Date28-Jun-10

Scheduled Completion Date 20-Nov-10

Summary Progress Statement *

The network infrastructure and the Sandton City influences the daily operation. In some cases it seems that personal are constantly busy fighting fires.Detailed Progress Statement

The Pre-Stabilisation process has been completed and areas have been identified that the teams can start with. As part of the next stage, the Interconnect team will focus on

removing the old cameras in the parking and back passages. Once this has been completed, the focus will shift to removing the old cabels from the parking areas.

There where 3 major network related issues at the centre this month. The first was the replacement of a faulty switsh that caused network infrastructure failures. The second was

servers that went down in the main server room that caused camera failures. And the 3rd was a Telkom error that caused a problem with the admin buildings opperations.Overall Project Status Rating *

GreenPlanning/Schedule Status Rating *

GreenPlanning/Schedule Status Comment

The focus has been on Sandton City thus far. As soon as they have removed the critical cameras, will work commence at NMSQFinancial Status Rating *

AmberFinancial Status Comment

Amber rating at this stage as the parking at NSMQ might need to be upgrade as Centre Management is uncvertain if they want to upgrade the system in this year. If not, the system

needs to be stabilisedProcurement/Tender Status Rating *

N/AProcurement/Tender Status Comment

No new Equipment requiredQuality Rating *

N/AQuality Rating Comment

Work to commenceMajor Issues/Risks

Issue: The Interconnect team has not had the oppertunity to gain access to the roofes as yet, to obtain the ceverity of the cabels in the roof. My concer is that even though SC is in a

serious state, that NSMQ is not far from the same.Next Month Actions/Tasks

Remove all redundant equipment, and cables. Ensure to keep the working equipment for Midlands. Gain access to the ceilings to determine what the current state of the ceilings are.


Project Timesheet

Saturday

Task

1 7:00 - AM

2 7:30 - AM

3 8:00 - AM

4 8:30 - AM

5 9:00 - AM

6 9:30 - AM

7 10:00 - AM

8 10:30 - AM

9 11:00 - AM

10 11:30 - AM

11 12:00 - AM

12 12:30 - PM

13 1:00 - PM

14 1:30 - PM

15 2:00 - PM

16 2:30 - PM

17 3:00 - PM

18 3:30 - PM

19 4:00 - PM

20 4:30 - PM

21 5:00 - PM

22 5:30 - PM

23 6:00 - PM

24 6:30 - PM

25 7:00 - PM

26 7:30 - PM

27 8:00 - PM

28 8:30 - PM

29 9:00 - PM

30 9:30 - PM

Total Hours: 10:00 - PM

Name:

Date:

Planned Tasks Tick if applicable

Sat Sun Mon

Ho

urs

Co

mp

lete

d

Pla

nn

ed

Ho

urs

to

Co

mp

leti

on

Assigned By

Company Name:

Pri

ori

ty

Customer

Bil

lab

le

Task

Task

bro

ugh

t

forw

ard

Time

Company Name:

Name: Date:

% C

om

ple

te

Tota

l H

ou

rsTue Wed Thu Fri


Project Detailed Timesheet

Saturday Sunday Monday Tuesday Wednesday Thursday Friday

Task Task Task Task Task Task Task

7:00 - AM

7:30 - AM

8:00 - AM

8:30 - AM

9:00 - AM

9:30 - AM

10:00 - AM

10:30 - AM

11:00 - AM

11:30 - AM

12:00 - AM

12:30 - PM

1:00 - PM

1:30 - PM

2:00 - PM

2:30 - PM

3:00 - PM

3:30 - PM

4:00 - PM

4:30 - PM

5:00 - PM

5:30 - PM

6:00 - PM

6:30 - PM

7:00 - PM

7:30 - PM

8:00 - PM Week 1:

8:30 - PM Week 2:

9:00 - PM Week 3:

9:30 - PM Week 4:

10:00 - PM Week 5:

Total: Total:

3. Planned new tasks for next week:

5. Issues / Problems AND

6. Value added / achieved for the business for the week:

10. Monthly Summary of hours

Planned

Time

Un

pla

nn

ed

Un

pla

nn

ed

8. Quality of work:

Un

pla

nn

ed

Un

pla

nn

ed

Company Name:

Name: Date:

Un

pla

nn

ed

Un

pla

nn

ed

Un

pla

nn

ed

Doing the right thing, at the right time, right the first time as efficiently as possible

Think, Plan, Prioritise, Communicate (where am I heading / going to do (What, Where, Why, How)), Action, Progress Update, Assess (change direction if necessary), Deliver,

Lessons Learnt, Communicate (what I have achieved / done)

1. Expenses for the week:

Company Name:


Project Timesheet Report

Amount

Hours

Week 1:

Week 2:

Week 3:

Week 4:

Week 5:

Total:

3. Planned new tasks for next week: 4.Time wasted for the week (hours) (stop, start, continue):

5. Issues / Problems AND Solutions Implemented

6. Value added / achieved for the business for the week: 7. Productivity for the week (Effectiveness / Efficiency / Initiative):

Date:

10. Monthly Summary of hours

Planned Actual Billable Non-BillableSigned by:

Date:

Approved by:

8. Quality of work: 9. Notes

Date:

Doing the right thing, at the right time, right the first time as efficiently as possible

Think, Plan, Prioritise, Communicate (where am I heading / going to do (What, Where, Why, How)), Action, Progress Update, Assess (change direction if necessary), Deliver,

Lessons Learnt, Communicate (what I have achieved / done)

1. Expenses for the week: 2. Deliverables achieved for the week:

Company Name: Name:


Project Marketing

• Why market your project?

• When to market your project.

• Who to market to.

• How to market your project.

• Change management.

• Project communication.


Project Audit Checklist








Project System / Software

• What is project software?

• What is portfolio software?

• Software systems:

– MS Project.

– EPM.

– Sciforma.

– Delivery Pipeline (Cloud/Internet based).

• What is project collaboration or project workspace?


Project Workspace


Project Workspace


Project Timesheet


Project Schedule


Project Schedule


How To Kick Off A Project

•Business case.

•Presentation.

•High level plan.

•Pre-buy in & pre-sales/marketing.

•No surprises.

•Pre-marketing.

•The kick off meeting (RAC only) VS the kick off presentation (anybody) (full RACI).