Project - Programme - Portfolio Management - View On Reporting

Juni 03-23-05
2011
project – programme – portfolio management – view on reporting
Presented by Jan Biets
Jan_biets@hotmail.com +32(0)477 32 90 11 Mechelen - Belgium

page 1 • view on reporting
Project management – view on reporting
• What is the purpose:

– Increase success rate of -strategically- projects;
– Decrease failure rate of -strategically- projects
– Improve - visual- reporting data;
– Improve baseline information to take decision upon;
– Improve communication, also to ‘non project management’-skilled
audience , i.e. top management;
– Increase effort in strategically supportive projects; define metrics
for measuring progress/success/quality of balanced scorecards;
– Order (go / kill ) strategically important projects;
• Very often lack of right information to be used by stakeholders to have a
clear understanding of the project status, progress , and ‘forecast’.
• Reason to take drastic, but un-rightful decisions, which can endanger
outcome of organisation’s strategy;
note:
•It is not the author’s intention to be aligned with whatever existing
methodology, nor framework;
•‘projects’– in this presentation, ‘projects’ can mean
projects, programme, or portfolio
Project management – view on reporting Juni 2011 page 2 • View on Reporting

• it does not matter who takes up the initiative to implement ‘View on

Reporting’:
– Project manager
– PMO
– (executive) Management
– Stakeholder(-s)
– Project board ( steering committee )
– Or other
Abbreviations:
PMO - project management office

• Remarkable observations (after + 20 years of professional project

experiences):
– Quality of project planning is very poor.
– Project planning is a specialty!
– Reporting and PM-‘understanding’ is very poor;
– Risk management:
• less loss of effort;
• Less loss of time;
• Less loss of money;
• Less loss of missed deadlines;
• Less loss of window opportunities;
• Improve awareness of ECV of project;
– Aligning (more) all initiatives (programmes, projects):
• Compose a roadmap with all required investment data
Abbreviations:
ECV - expected commercial value

• Improving the planning quality;

• Reducing the risks, or at least identify the potential risk for organisation’s
strategy;
• Improving the resource capacity management (aligning);
• Improving the reporting (aligning);
• Improving alignment of projects & master plan;
• Aligning ‘initiatives’ / projects according the pre-set strategy, thus avoiding
loss of effort , focus, money and business opportunities (window of
opportunity);

• Inform all stakeholders (e.g. operations, management, team leads, pm’s,

business, PMO,…);
• Obtain better mutual understanding of ‘needs’:
– business leads the projects, IT is a service provider!;
• Planning:
– approach & policy;
– naming conventions, other;
– capacity (specialised staff)
– quality;
– tool;
• Project process flow
– use of PM-tool, or ‘manual’- processes?;
• Information / instructions:
– written instructions, information, education;
• And lots of “Good-willing”.

• Reports , on progress, risks, resources (next skills);

• Updated project planning;
• Alignment of programmes / projects;
• Alignment of planning approach:
– Planning policy,
– Avoid typical errors of planning;
• Alignment of reports, EVA (earned value analysis), finance;
• Improvement of Business & ICT project performances.
• Aligning all kind of efforts , to enable the strategy , market position;
– Harvesting all initiatives, projects
– Based on business case , (financials, and strategic fit/match, ROI ,
‘what if we not?”-assessment (reference to balanced scorecard
‘product selection’);
– Compose order of importance (necessity of good outcome per project

Project management – view on reporting : SET UP BSC
•Measuring is knowing;
•Define what information is required to be able to assess your project on
‘total project quality management’?;
•A ‘best’ tool is Balanced Scorecards (Kaplan/Norton);
•Good defined BSC allows a in-depth view on the projects, thus:

•Increasing organisation’s benefits of outcome of project (application);
•Increasing lessons learned for other project initiatives; your
organisation will improve project-ability behaviours;
•Decreasing failure rates of projects, and consequently , negative
impact on organisation’s strategy;
Abbreviations:
BSC - Balanced Scorecards (Kaplan & Norton)

Balanced Scorecards: IT Strategic Measures
OBJECTIVES (suggestions):
• IT mission goals
– Percent mission improvements (cost, time, quality) attributable to IT
solutions and services
– Percent planned IT benefits projected v. realised
• Portfolio analysis and management
– Percent IT portfolio reviewed and disposed
– Percent old applications retired
– Percent applications retirement plan achieved
– Percent reusable of core application modules
– Percent new IT investment v. total spending
• Financial and investment performance
– Percent and cost of services provided in-house v. industry standard
– IT budget as a percent of operational budget and compared to
industry average
– Net present value, internal rate of return, return on investment, return
on net assets
• IT resource usage
– Percent consolidated/shared resources across units
– Percent cross-unit shared databases and applications
– Percent hardware/software with interoperability capabilities
Balanced Scorecard: satisfying needs ‘Customers”
OBJECTIVES:
• Customer partnership and involvement

– Percent projects using integrated project teams
– Percent joint IT customer/supplier service-level agreements
• Customer satisfaction
– Percent customers satisfied with IT product delivery
– Percent customers satisfied with IT problem resolution
– Percent customers satisfied with IT maintenance and support
– Percent customers satisfied with IT training
– Percent products launched on time
– Percent service-level agreements met
• Business process support
– Percent IT solutions supporting process improvement projects
– Percent users covered by training to use new IT solutions
– Percent new users able to use applications unaided after initial
training

Balanced Scorecard: IT internal business performance
OBJECTIVES:
• Applications development and maintenance
– Number of function points delivered per labour hour
– Number of defects per 100 function points at user acceptance
– Number of critical defects per 100 function points in production
– Percent decrease in application software failures, problems
– Mean time to resolve critical defects
– Cycle time for development
• Project performance
– Percent projects on time, on budget
– Percent projects meeting functionality requirements
– Percent projects using standard methodology for systems analysis and design
• Infrastructure availability
– Percent computer availability
– Percent communications availability
– Percent applications availability
– On-line system availability
• Enterprise architecture standards compliance
– Number of variations from standards detected by review and audit per year
– Percent increase in systems using architecture
– Percent staff trained in relevant standards

Balanced Scorecard: addressing innovation and learning
OBJECTIVES:
• Workforce competency and development
– Percent staff trained in use of new technologies and techniques
– Percent staff professionally certified
– Percent IT management staff trained in management skills
– Percent IT budget devoted to training and staff
• Advanced technology Use
– Percent employees skilled in advanced technology applications
– Number of dollars available to support advanced technology skill
development
• Methodology currency
– Currency of application development methods used
– Percent employees skilled in advanced application development
methods
– Percent projects developed using recognized methods and tools
• Employee satisfaction and retention
– Percent employee satisfaction with the capability of the
– existing technical and operating environment to support mission
– Percent employee turnover by function

view on reporting – some interesting PM criteria
criteria that constantly emerge (1/2) :
• There is a lot of –valuable - information available when executing

a project, but some interesting data has to be excavated, you
have to know where to find it, and what to do with;
– Time:
• Schedule (overall, per phase;)
• Schedule performance index [SPI]
– Finance
• How are we going against budget;
• Cost performance index [CPI];
• Earned value analysis [EVA/-M];
• Return on investment [ROI];
• Net present value [NPV];
• Expected commercial value [ECV];
Abbreviations:
SPI - schedule performance index
CPI - cost performance index

view on reporting – some interesting PM criteria
criteria that constantly emerge (2/2) :
• There is a lot of –valuable - information available when executing

a project, but some interesting data has to be excavated, and you
have to know where to find it;
– Resources
• How much time are we spending on the project,
• How many resources we need (globally, per IT department,
roles);
• Do we use the available resources;
– Scope: Is the scope [creep] in line with expectations (?)/ (!);
– Quality (total quality project management – TQPM)
• Is the plan realistically built-up;
• Number of issues reported;
• Are we reviewing and fixing quality problems;
note:
An organisation with project tradition, has advantages when building
up a project minded attitude and a benchmark data-warehouse to
assess the projects and improve the project’s success rate, thus
organisation’s strategy outcome.
view on reporting - TIME
Time: How are we going against schedule;

– Progress on schedule;
– Number of tasks late started;
– Number of tasks overdue (not closed);
– Number of open tasks;
– Metrics & status : traffic light

– Define : (these are default values)
• number : 1 – 2 : orange
• number : 2+ : red
– Explain reason:
• E.g. technology, resources, errors, training, management

view on reporting – Finance & COST
Cost: How are we going against budget schedule

– Earned value management (and assessment)
– Progress on schedule (€);
– Cash flow;
– ROI , pay-back time;
– ECV;
– Metrics & status : traffic light

– % : orange
– %+ : red
– Define reason to understand

Abbreviations:
ECV - expected commercial value
ROI - return on investment
NPV - net present value
view on reporting – SCHEDULE : SPI
“How is schedule against schedule”
• Indication for quality of

schedule / planning
delta CPI %
CPI & SPI
delta SPI %
10
SPI = BCWP / BCWS
5
variance CPI
• Metrics & status : 0
-25 -15 -5 5 15 25
SPI value should be 1 -5
SPI <1 means project is behind

-10
schedule
-15
variance SPI
index of 1.0 or greater is on/above target and considered satisfactory
• Define reason (e.g. over-/ Note:

under-estimated tasks, wrong
Figure is a combined graphic, both CPI and SPI
schedule techniques,
Abbreviations:
SPI - schedule performance index
BCWP - budgeted cost of work performed
BCWS - budgeted cost of work scheduled
view on reporting – EVA - COST : CPI
“How is cost against cost”
• The CPI shows the ratio of budgeted (or baseline) costs of work performed
to actual costs of work performed, up to the project status date or today's
date. delta CPI %
CPI & SPI
CPI = BCWP / ACWP delta SPI %
10
5
• Metrics & status :
variance CPI
0
CPI value should be 1 -25 -15 -5 5 15 25
Variances: -5
CPI < 1 means project is over -10
budget
-15
variance SPI
• identify reason(-s) (e.g. over-/ under-estimated costs, wrong cost

expenditure techniques,
Abbreviations:
EVA - earned value analysis
CPI - cost performance index
ACWP - actual cost of work performed
view on reporting – EVA - COST & SCHEDULE
“How is cost against cost”
• The CSI shows the ratio of budgeted (or baseline) costs of work performed
to actual costs of work performed, up to the project status date or today's
date. delta CPI %
CPI & SPI
CSI = CPI x SPI delta SPI %
10
5
• Metrics & status :
variance CPI
0
CSI value should be 1 -25 -15 -5 5 15 25
-5
-10
-15
variance SPI
Variances:
CSI <> 1 means project is less likely to be ‘recoverable’
Abbreviations:
EVA - earned value analysis
CSI - cost schedule index
ACWP - actual cost of work performed
view on reporting – budget milestones (or phases)
Every milestone (or phase) has a budget

(baseline), vs actual budget (€ , man-days)
Milestones budget tracking

3000 100%
90%
2500
Rationale: 80%
70%
•quality check of budget planning; 2000
60%
% variance
ManDays
Explanation: 1500 97% 50%
•close follow up of milestone planned manhrs 40%

1000
budget, planned (baseline) vs spent mandhrs 30%
actuals variance 20%
500
•A possible understanding why 10%
0% 0% 9%
(when) project budget has 0 0%
deviations vs baseline Initiate Define Design Build Implement Close
Phase / Milestone
•Explanation: a prognosis of total
budget spent (at completion) note:
phases - typical naming by Prince 2

view on reporting – budget man-days vs man-days
Baseline planned man-days vs actual man-days
p ro je c t p ro g re ss : m a nd a ys
10
numb e r sta ff
5 p ro je c t p ro g re ss : m a nd a ys
10
0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
re po rting c yc le 5
%
baseline (abs)
0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
Rationale: baseline (abs)
actual (abs)
re po rting c yc le
•quality check of planning: most realistic plannings have a specific wave-profile:

•Explanation: unrealistic growth (variations) of staff on project
•A possible understanding why project has deviations vs baseline
•Explanation: planned resources vs actual resources
•Identifies reason of ‘late’ of project : not enough man-hours ‘produced’
•Reason of deviations have to be identified and explained
view on reporting – budget man-days vs man-days
Baseline planned man-days vs actual man-days
10
Planned (Man Hrs / week)

450
num b e r sta ff
400
5
350
Planned (Man Hrs)
300
Manhrs Week
250
0
200
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
150 baseline (abs) re po rting c yc le
100
50
0
33
36
39
51
11
14
26
29
32
50
42
45
48
2
5
8
17
20
23
35
38
41
44
47
Rationale:
•quality check of planning: most realistic plannings have a specific wave-profile:
•Explanation: unrealistic growth (variations) of staff on project
•A possible understanding why project has deviations vs baseline
•Explanation: planned resources vs actual resources
•Identifies reason of ‘late’ of project : not enough man-hours ‘produced’
•Reason of deviations have to be identified and explained
view on reporting – budget milestones (or phases)
Baseline budget (€ or man-days) vs actual value (cumulated , %)
project progress : mandays (cumulative)
100
90
80
70
60
%
50
40
30
20
10
0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
baseline
re po rting c yc le
actual
Rationale:
Tracking of progress (man-days, % complete, €, and other) vs baseline
Explanation: visual follow up, easy to understand, and to communicate;
A possible understanding why project has deviations vs baseline
Explanation: using other tools, understand why project has deviations

Metric – cost / schedule variance trends
Cost / schedule variance trends

Metric – total quality project management: open tasks
Follow up the planned activities vs the actual started activities;
Follow up open / non finished tasks, time that these tasks stays un-finished/ open;
activities started
Description:
• Activities too early started (according baseline
actual this w eek
schedule);
activities 0 5 10 15 20 25
• Activities started, prior to closing predecessor started
tasks;
• Activities started but unfinished (stays “open”/
<100% work complete)
Open tasks
Graphical view on number of tasks
started on time, late, or still open 10
after due date (according
planning) 8
Rationale: # open tasks (late)

6
closed (ETC=0)
quality check of project open (0<actuals>100%)
progress and project 4 not started (late)
management
2
Explanation:
0
typically, in a troubled project, mrt/11 apr/11 mei/11 jun/11 jul/11 aug/11 sep/11 okt/11
tasks start, without finishing re po rting c yc le
predecessor / prior tasks;

Metric – EVA : budget at completion
project progress : budget [€] & mandays
250 10
baseline [€]
200 actual [€]
baseline budget
150 baseline [md]

actuals [md]
5
reserved budget
100
50
0 0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
re po rting c yc le
Rationale:
•Visual quality status check of project progress (man-days and €)
•Explanation: in an eye blink, a status report to communicate;
•A projection of estimated budget at completion is available;
•Additionally, contingency (both € and man-days) can be added on chart;
and if used, it can be shown as a decreasing line.

TQPM – staffing management
pm
developper staff: capacity vs scheduled
business analyst
tester
1500 representative
business
developper (scheduled)
business analyst (scheduled)
tester (scheduled)
business representative (scheduled)
pm (scheduled)
1000
monthly hours
500
0
jan/00 jan/00 jan/00 jan/00 jan/00 jan/00 jan/00 jan/00
Rationale: re p o rting c yc le
•quality check of resources planning

•Explanation: based on available resources , vs assigned resources; the number
of ‘man-days’ available and the number of man-days assigned , and planned. This
should be done per role or function; “too many/ not enough staff (specific role) for
a certain project , or certain timeframe”
•Resources management:
•When well managed, in combination of the project plans (and roadmap) an early
warning system for hiring / firing staff;
•Upfront check if sufficient resources according the scheduled needs.
TQPM – staffing management (per role / function)
staff: capacity vs scheduled
1500
Level:
•Project
1000
monthly hours
•Programme
•portfolio
500
0
mrt/11 apr/11 mei/11 jun/11 jul/11 aug/11 sep/11 okt/11
re p o rting c y c le
Rationale:
Resources planning:
•Explanation: based on pipeline (projection) a clear view on expected variances on
resources (function) for the next phases (in time).
•Better ‘serieux’ of overall planning;
•Better ratio on successful outcome of project (assigned staff) , and outcome of
programme / strategy;
•Better understanding of cashflow (actual fiscal year) , cash reservation (for next fiscal
year);

TQPM – meeting functional requirements
What is the scope of the project?!
What is quality / success rate of the project?
What is to be assessed during the project review meetings/process?
Rationale:
An important project quality success indication is the number of met requirements.
This can be:
Functional requirements , tangible and intangible, operations, up-time , availability, mean time between failures,
matching with technology policy, …
•Define clear user requirements

•Identify , quantify , ‘name it ! ‘
•List requirements;
•Build metrics;
•Test or assess during review meetings;
•Report;
•Validate the met requirements versus the requirements defined;
•Prioritise the application / project outcome;
•PDCA;
•Set up improvement project.

TPQM – meeting competency models
What is the applied or to be technology of the project / organisation?!
What is the competency level of our staff / organisation?
How measuring? Certificates rate? Number of staff certificated?
Rationale:
An important organisation’s quality success indication is the number of skilled / trained staff to meet the required
technology skills ?
This can be:
Technology, skills, tangible or intangible, …
•Define clear skills requirements (technology, other skills), based on defined strategy;
•Identify , quantify , ‘name it ! ‘
•List requirements;
•Build metrics;
•Test or assess during review meetings;
•Report;
•Validate the met requirements versus the requirements defined;
•Prioritise the training initiatives (or hire the required skills);
•PDCA;
•Set up improvement programme.

view on reporting – ‘Logic’ - diagram
logic planning composition
Rationale:
•quality check of planning
Critical Path method (elapsed time)
Explanation:
•optimising or reducing elapsed time
by logically flow of milestones.
Abbreviations:
CPM – Critical Path Method
FQT – final qualification testing
FAT – factory acceptance test
POC – proof of concept
Metrics: progress (cumulative)
• Schedule: How is actual against baseline (cumulative)

• Metrics & status : indication how actuals are evolving against baseline ;
• % variance (+ / - )
project progress : mandays (cumulative)
100
90
80
70
60
%
50
%
40
behind
30
20
# cycles late
10
0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
baseline
re po rting c yc le
actual
Period late or early;
Indication of % deviation, or better, time of deviation (ahead or late vs
baseline schedule);
Use other diagrams to examine reason (e.g. over-/ under-estimated tasks,
insufficient # staff,…


10
# manday / reporting cycle 5
0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
baseline (abs)
re po rting c yc le
actual (abs)
‘late’ due to insufficient # of man-days ‘produced’.
Use other diagrams to examine reason : lack of staff staff (not assigned ,
illness,…)


p ro je c t p ro g re ss : 'd e ve lo p m e nt' - m a nd a ys
10
# manday / reporting cycle 5
0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
baseline (abs)
re po rting c yc le
actuals 'development' staff
‘late’ due to insufficient # of man-days ‘produced’ : development staff.
illness,…)


staff: capacity vs scheduled
300 8
7
250
6
200
monthly hours
5
development (planned work)
150 4
development (assigned staff - max
3
100 manhours)
development actuals (manhours/week)
2
50 developpment ( # assigned staff)
1
0 0
mrt/11 apr/11 mei/11 jun/11 jul/11 aug/11 sep/11 okt/11
re p o rting c yc le
• 3 given data involved: work to be done (scheduled), # available/assigned

resources, realised work by the assigned resources (actuals)= NEED TO
BE BALANCED
• ‘late’ due to insufficient # of man-days ‘produced’ : development staff.
• Use other diagrams to examine reason : lack of staff staff (not assigned ,
illness,…)


p ro je c t p ro g re ss : 'func tio na l a na lyst' - m a nd a ys
10
# manday / reporting cycle

5
0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
baseline (abs)
re po rting c yc le
actuals 'functional analyst' staff
‘late’ due to insufficient # of mandays ‘produced’ : functional analyst.
illness,…)

p ro je c t p ro g re ss : ma nd a y s
• Schedule: How is actual
against baseline (cumulative) 100
90
• Metrics & status : indication 80

70
how actuals are evolving 60
against baseline ; 50
%
40
• % variance (+ / - ) 30
20
• Period late or early; 10 baseline
0 actual
– Indication of % 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
deviation, or better, time re po rting c yc le
of deviation (ahead or
late vs schedule);
• Use other diagrams to examine reason (e.g. over-/ under-estimated tasks,
wrong schedule techniques, EVA
Rationale:
•quality check of project progress and project management
•Explanation: typically, in a troubled project, tasks start, without finishing
predecessor / prior tasks;
•Reporting of progress to ‘all’ stakeholders , eventually with coloured ‘deliverables’;

TQPM – Finance / ROI
Rationale:
•Quality check of project ROI
•Important to be defined in ‘project charter’ (financial feasibility).
•Calculating the ROI , based on assumptions when defining the project charter
(project investments , and operational costs (maintenance, and evolving
maintenance) [forecast cash flows]
Re turn o n Inve stm e nt (2011 - 2014)
4000000
cost & benefit prognosis
3000000
2000000
costs (assued)
1000000
benefits (assumed)
0
initial 2011 2011 2012 2012 2013 2013 2014 2014
- Q2 - Q4 - Q2 - Q4 - Q2 - Q4 - Q2 - Q4
Project / Application Life Cycle

TQPM – Finance / ROI
Rationale:
•quality check of project ROI
•Could be of importance when ‘re-assessing’ the desirability of the project outcome , by
the stakeholder(-s). Stop of go decision
Re turn o n Inve stm e nt (2011 - 2014)
4000000
cost & benefit prognosis
3000000
2000000
costs (assued)
1000000
benefits (assumed)
benefits (actual)
0 costs (actual)
initial 2011 2011 2012 2012 2013 2013 (benefits
Lineair 2014(actual))
2014
- Q2 - Q4 - Q2 - Q4 - Q2 Lineair (costs (actual)) - Q4
- Q4 - Q2
-1000000
Project / Application Life Cycle

TQPM – Metrics: Finance / NPV
scoreboard using NPV to rank and prioritise project selection
project PV Development Commercialisation NPV Ranking decision

(present cost cost (net based on
value of present NPV
future value)
earnings)
alpha 30 3 5 22 4 hold
beta 64 5 2 57 2 go
gamma 9 2 1 6 5 hold
delta 3 1 0,5 1,5 6 hold
echo 50 5 3 42 3 hold
foxtrot 66 10 2 58 1 go

TQPM – Metrics: Finance / NPV
scoreboard ranking projects according to the NPV-based productivity index
project NPV development Productivity index = Sum of decision
cost development
NPV / development
cost costs
beta 57 5 11,4 5 hold
echo 42 5 8,4 10 hold
alpha 22 3 7,3 13 hold
Limit reached*
foxtrot 58 10 5,8 23 drop
gamma 6 2 3 25 drop
delta 1,5 1 1,5 26 drop
* : productivity index is used to rank projects until out of resources (€ 15 m) in development costs is reached.
* : value of the portfolio is NPV = € 121m from these 3 projects.

TQPM – Metrics: Finance / ECV – determining the expected commercial value of a
project
Abbreviations:
ECV – Expected Commercial Value

TQPM – Metrics: Finance / ECV - Determination of Expected Commercial Value (ECV)
of Project – Use Decision Tree Analysis
Commercial
Success
€ PV
Technical Pcs
Yes
Success Launch
Pts
€C
No
€ ECV Development Yes
€D Commercial
No
Failure
Technical Failure
ECV = [(PV x Pcs - C ) x Pts- D]
€ ECV = expected Commercial Value of project

P ts = probability of technical success
P cs = probability of commercial success (given technical success)
€D = development costs remaining in the project
€C = commercialisation (launch) costs (if not into project budget)
€ PV = present value of project’s future earnings (discounted to today)

METRICS : overall budget versus spent versus spent ‘reserved-’budget
Planned
Planned &
& Forecast
Forecast HRS
HRS
1950
1950
1750
1750
1550
1550
1350
1350
1150
1150
950
950
750
750
550
550
350
350
150
150
project progress : budget [€] & mandays W

Weeeeks
ks
Baseline
Baseline Forecas
Fo recastt Actual
Actual
100
80
60
%
40
20
baseline [€]
0
actual [md]
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
baseline budget
re po rting c yc le
baseline [md]

METRICS : financial - EVA
What?
• Measure of project progress;
• Forecast completion date and final cost;
• Provide schedule and budget variances:
• By integrating 3 measurements, EVA provides consistent, numerical

indicator with which you can evaluate and compare projects.
Key:
• Where are we on schedule?
• Where are we on budget?
• Where are we on work accomplished?
Abbreviations:
EVA – Earned Value Analysis

How?
• It compares the ‘planned’ amount of work with what has actually been
completed, to determine if COST , SCHEDULE, and WORK ACCOMPLISHED
are progressing as planned
• Work is ‘EARNED’ as it is … 100% completed
EVA gives a uniform unit of measure: € or man-days

EVA provides an ‘EARLY WARNING” for prompt corrective actions
Example:
30% time spent
30% € spent
Equals 30% work performed ?
Not necessarily !
Abbreviations:

Abbreviations:
BCWS – budgeted cost of work performed
planned cost of the total amount of work scheduled
to be performed by milestone date
ACWP – actual cost of work performed
cost incurred to accomplish the work that has bee done to
date
BCWP – budgeted cost of work performed
planned (not actual) cost to complete the work that has
been done

Some more abbreviations:

SV - Schedule Variance (BCWP – BCWS)
comparison of amount of work performed during a given
period of time to what was scheduled to be performed
Negative variance means that the project is behind
schedule
CV – Cost Variance (BCWP – ACWP)

comparison of the budgeted cost of work performed with
actual cost
negative variance means that the project is over budget
Example:
Schedule Variance = BCWP – BCWS
Cost Variance = BCWP - ACWP
Total Quality Project Management : schedule sanity check
“How realistic is the schedule”
Indication for quality of p ro je c t p ro g re ss : m a nd a ys
schedule; 10
• Slope is sinusoidal:
• Increase and decrease of
num b e r sta ff
number of team members in 5
project is controlled manner;
0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
baseline (abs) re po rting c yc le
10
Rationale:
‘Very’ Early warning
num b e r sta ff
5
Explanation
A quality check for a realistic schedule. For
example a project schedule with this curve is
doomed to fail. The number of mandays is equal for
0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 both schedules.
baseline (abs) re po rting c yc le

Total Quality Project Management : Milestone chart (Deliverables Chart)
Deliverables Chart
Purpose: sep/11
•Management communication jul/11
Deliverables dates
•Interdependencies communication jun/11
apr/11
Business Requirements
Functional Design
feb/11
Coding & Testing
Launch
jan/11
nov/10
baseline 28/02/2011 31/03/2011 30/04/2011 31/05/2011
re po rting c yc le
Rationale:
Early warning
Explanation
When a (first) milestone has been missed, very probably, following milestones will be
delayed too.
Inclusive the closure milestone.
This chart will help to show and understand the moving milestones (pushed away in
time) and indicates a new ‘closure’ date.

Total Quality Project Management : average costs of project team members , evolutive
Purpose:
•Follow up of average costs of IT profiles;
Average day
•Influence contract negotiations of –external- IT staff ; rate (€) per
month.
•Control of budget.
Totaal
910
900
890
Astitel
880
Totaal
870
860
850
840
Rationale: 707 708 709 710 711 712 801 802 803 804
cost improvement
Explanation
Follow up of contract costs of IT staff, and potentially re-negociate contracts;
In case of increasing contract costs, it could have impact on project budget;
This chart will help to show and understand the evolution of average hiring costs of IT
staff.

Total Quality Project Management : number of external project team members ,
evolutive
Purpose:
inte rna l ve rsus e xte rna l p ro je c t sta ff
•Follow up of number of external 15
project staff;
•Influence contract negotiations of
10
–external- IT staff ;
# project staff
•Optimising of available staff
5
internal staff (#)
external staff (#)
0
baseline apr/11 jun/11 aug/11 okt/11 dec/11
Project Life Cycle
Rationale:
cost improvement
Explanation
Follow up of contract costs of IT staff, and potentially re-negociate contracts;
In case of increasing contract costs, it could have impact on project budget;
This chart will help to show and understand the evolution of number of external staff,
the hiring costs of IT staff. And more important , it could help to optimising resources,
when done on programme/portfolio level: future needs of external staff

Total Quality IT / asset Management : TCO of applications, infrastructure, and
maintenance related costs (existing IT-infrastructure)
Not entirely in scope of this presentation , but….
Purpose:
•Management decisions
•Optimising of portfolio, and asset
management.
•Strategic IT management
•TCO (total cost of ownership)
•Technology follow up (don’t stay
behind the competition)
Rationale:
knowing when to make a technology switch (‘warning’)
Explanation
Assessing the existing technology applied in IT infrastructure (hardware and software);
List the known expenses for each of the configuration item;
Controlling the total cost of ownership of each configuration item;
Knowing at the right moment when to switch to other technology;
Plan(-ned) investment: less unlucky surprises;
Add to roadmap: know what resources will be needed (fiscal year, staffing, priority);
TQPM : Balanced scorecard (new product project selection)
• Factor 1: strategic fit and importance

• Factor 2: product and competitive advantage
• Factor 3: market attractiveness
• Factor 4: core competencies leverage
• Factor 5: technical feasibility
• Factor 6: financial reward versus risk

• Factor 1: Strategic fit and importance

– Alignment of project with business’s strategy
– Importance of project to the strategy
– Impact on the business

• Factor 2: product and competitive advantage

– Product delivers unique customer or user benefits
– Product offers customer / user excellent value for money
– Competitive rationale for project
– Positive customer / user feedback on product concept (concept test
results)
Driver:
ECV – expected commercial value
ROI – return on investment

• Factor 3: Market attractiveness
– Market size
– Market growth and future potential
– Margins earned by players in this market
– Competitiveness – how tough and intense
competition is
• Factor 4: core competencies leverage
– Project leverages our core competencies and
strengths in:
• Technology
• Production / operations
• Marketing
• Distribution / sales force

• Factor 5: Technical feasibility
– Size of technical gap
– Familiarity of technology to our business
– Newness of technology (base to embryonic)
– Technical complexity
– Technical results to date (proof of concept)
• Factor 6: financial reward versus risk
– Size of financial opportunity
– Financial return (npv , ecv)
– Productivity index
– Certainty of financial estimates
– Level of risk and ability to address risks
Abbreviations:
NPV – net present value
ECV – expected commercial value
Some ‘play-’rules:
• Projects are scored by the gatekeepers (senior management) at
the gate meeting using these six factors on a scorecard (0-10
scales);
• The scores are tallied, averaged across the evaluators, and
displayed for discussion;
• The project attractiveness score (PAS) is the weighted or un-
weighted addition of the scores, taken out of 100;
• A PAS score of 60/100 is usually required for a go decision.

Some ‘play-’rules:
• Projects are scored by the gatekeepers (senior management) at
the gate meeting using these six factors on a scorecard (0-10
scales);
• The scores are tallied, averaged across the evaluators, and
displayed for discussion;
• The project attractiveness score (PAS) is the weighted or
unweighted addition of the scores, taken out of 100;
• A PAS score of 60/100 is usually required for a go decision.

What is needed , what is to understand
• For all the shown graphical support tools, a proper planning is

required, according to some applied planning guidelines;
• For all the shown graphical support tools, a proper follow up
(progress capturing, man-days, financial data) is required;
• And proper project management (skills);
BUT:
• It is not necessary to have all these graphical analysis tools, use
what is needed to execute your project, programme, portfolio.

Time is up. Much more to talk about this interesting topic….
Questions ?
? ? ?? ? ?? ? ?
Linkedin Jan Biets - Jan_biets@hotmail.com - +32(0)477 329011

Project - Programme - Portfolio Management - View On Reporting

Uploaded by

Copyright:

Available Formats

You might also like

Project - Programme - Portfolio Management - View On Reporting

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Project - Programme - Portfolio Management - View On Reporting

Uploaded by

Copyright:

Available Formats

Juni 03-23-05

project – programme – portfolio management – view on reporting

Presented by Jan Biets

Jan_biets@hotmail.com +32(0)477 32 90 11 Mechelen - Belgium

• What is the purpose:

Project management – view on reporting Juni 2011 page 2 • View on Reporting

• it does not matter who takes up the initiative to implement ‘View on

Project management – view on reporting Juni 2011 page 3 • View on Reporting

• Remarkable observations (after + 20 years of professional project

Project management – view on reporting Juni 2011 page 4 • View on Reporting

• Improving the planning quality;

Project management – view on reporting Juni 2011 page 5 • View on Reporting

• Inform all stakeholders (e.g. operations, management, team leads, pm’s,

Project management – view on reporting Juni 2011 page 6 • View on Reporting

• Reports , on progress, risks, resources (next skills);

Project management – view on reporting Juni 2011 page 7 • View on Reporting

•Good defined BSC allows a in-depth view on the projects, thus:

Project management – view on reporting Juni 2011 page 8 • View on Reporting

• Customer partnership and involvement

Project management – view on reporting Juni 2011 page 10 • View on Reporting

Project management – view on reporting Juni 2011 page 11 • View on Reporting

Project management – view on reporting Juni 2011 page 12 • View on Reporting

• There is a lot of –valuable - information available when executing

Project management – view on reporting Juni 2011 page 13 • View on Reporting

• There is a lot of –valuable - information available when executing

Time: How are we going against schedule;

– Metrics & status : traffic light

Project management – view on reporting Juni 2011 page 15 • View on Reporting

Cost: How are we going against budget schedule

– Metrics & status : traffic light

– Define reason to understand

• Indication for quality of

SPI <1 means project is behind

• Define reason (e.g. over-/ Note:

CPI < 1 means project is over -10

• identify reason(-s) (e.g. over-/ under-estimated costs, wrong cost

Every milestone (or phase) has a budget

Milestones budget tracking

•close follow up of milestone planned manhrs 40%

Project management – view on reporting Juni 2011 page 20 • View on Reporting

•quality check of planning: most realistic plannings have a specific wave-profile:

Planned (Man Hrs / week)

project progress : mandays (cumulative)

Project management – view on reporting Juni 2011 page 23 • View on Reporting

Project management – view on reporting Juni 2011 page 24 • View on Reporting

Rationale: # open tasks (late)

Project management – view on reporting Juni 2011 page 25 • View on Reporting

150 baseline [md]

Project management – view on reporting Juni 2011 page 26 • View on Reporting

•quality check of resources planning

Project management – view on reporting Juni 2011 page 28 • View on Reporting

•Define clear user requirements

Project management – view on reporting Juni 2011 page 29 • View on Reporting

Project management – view on reporting Juni 2011 page 30 • View on Reporting

• Schedule: How is actual against baseline (cumulative)

Project management – view on reporting Juni 2011 page 32 • View on Reporting

• Schedule: How is actual against baseline (cumulative)