1. Merima Halkic Ganna Shulika Katharina Reiter
Project delivery
Merima Halkic
Ganna Shulika
Katharina Reiter

2. Agenda The control cycle The portfolio management team
Plan, delegate, monitor, report and control
The portfolio management team
Project register
Project steering group
Stage meerings
Unscheduled project steering group meetings
Scheduled project steering group meetings

3. The control cycle
Plan

4. The control cycle
Plan
Delegate

5. Delegate The delegator and the delegate must agree on the following:
Product description
Planned start/finish date
Planned effort/cost
Dependencies
Prerequisite products

6. Delegate This list focuses on the outcome expected from the delegatee:
Timesheet code
Skills/experience required
Roles
Reporting arrangements
Escalation conditions
Techniques,processes,procedures

7. The control cycle
Plan
Delegate
Monitor and Report

8. Portfolio management team
The regular meetings should have a standard agenda that takes into account the following:
Prospects
Initiated projects
Notifications
Completions
Realisations

9. Project register

10. Project steering group
The project steering group can intervene through:
project initiation and closure
holding meetings at the different stages of the project
holding unscheduled meetings
holding scheduled meetings
project forecast reports.
The project steering group should schedule a meeting at the beginning of every planned stage of the project.

11. Project steering group
Stage meetings
Review of previous stage plan
Review of project plan
Review of business case
Review of next stage plan
Approval of controls
Approval to proceed
Unscheduled project steering meetings
Scheduled project steering meetings

12. Project Manager
Project Team Progress Meetings:

13. Project Forecast Reports
Summary Project Forecast Report
The important terms of SPFR:
Baseline
Actual to date (ATD)
Estimate to complete (ETC)
Forecast at completion (FAC)
Variance
Box colours

14. Project Forecast Reports (PFR)
Time Forecast
Cost Forecasts by type, product
Project Quality Forecast
Product Quality Log
Benefits Forecast
Risk Register
Timesheet
Earned value Analysis
planned cost vs. actual cost
earned value vs. planned value
earned value vs. actual cost
earned value summary

15. PFR: 1. Time Forecast

16. PFR: 2.1. Cost Forecast by Type

17. PFR: 2.2. Cost Forecast by Product

18. PFR: 3. Project Quality Forecast

19. PFR: 4. Product Quality Log

20. PFR: 5. Benefits Forecast

21. PFR: 6. Risk Register

22. Timesheet

23. Earned value Analysis

24. Earned value analysis
Important: Measurability of completeness of product
Successful execution depends on managing quality, time and cost
Records results of more substantial product review process

25. While product development
Quality criteria set out quality expectations
Complex product description, room for misinterpretation → advisable quality review
Compares draft product and product description
Different forms

26. Forms of quality review
Testing – physical test
Inspection – scrutinization of product or service
Demonstration – error identification by a display
Formal quality review – reviewers challenge a product
Informal quality review – less structured version

27. Quality review: Preparation
Begins during initiation:
Product descriptions developed and
Approved as part of the project plan (quality plan) + quality responsibilities
Roles of reviewers:
Chair
Scribe
Author
Reviewers

28. Quality review: Preparation
Variety of commercial, customer and developer backgrounds of reviewers
Invitation to all reviewers:
Informing of their role
Error list
Copy of product description
Draft product
Scribe: action form
Room should be booked for sufficient time
NOTING ERRORS
COMPARING

29. Quality review: review
Proceeding (assuming product is a document):
Identification of significant errors (rework if critical errors)
Presentation and description of error lists in turn
Contemplation of each page of document (possible contribution of each reviewer)
Each quality criterion in product description is considered in turn: must be reliable (criterion) and of a high standard (description)

30. Quality review: review
Rules for conducting:
Prepared participants
Aim to work within time limits
Respecting authority of chair, be tactful
Reschedule if too few/ underqualified participants
Objective comparison
Identify erros not solutions
Annotation with trivial matters (spelling errors, ...)

31. Quality review: review
Scribe:
Records actions and decisions on action form
Assigns each action to agreed participant
After review: reads back, collects copies and error lists
Chair determines conclusion:
Approved – product accepted
Approved to amendments – product can be approved
Revise and reschedule – little up to significant change, not enough/qualified/prepared reviewers

32. Quality review: follow-up
perfect correction: everyone receives action form and author annotated copies
Author decides on possible changes within time and budget and informs project manager
Project manager updates product quality log and decides how to continue
Author amends product using action form and copies
Revised version sent to reviewers to confirm correction → chair can approve product

33. Informal quality review
Common form of product appraisal
Cheaper to implement
Product sent via
Often less rigorous, error identification unsatisfactory

34. Control Corrections must be subject to tight governance
Possible errors:
failed anticipation
timescales may have slipped
cost overrun
quality expectations not been met
While changing: bound to be continued pressure
Change requests → If parameters have to change: conscious, intended management control

36. Change must be managed: form
Everything known about CR or issue included on form
Also: reasons for issue

37. Change: possible significant and expensive effect on project
Availability of critical baseline documents:
Business case
User requirements document
Solution design document
Project plan
Risk register
Necessary if there are several CR or issues

38. Number of options → clear outline for recommendation
All solutions will have impact, e.g.
Fixed deadline → more/faster resources, ...
Fixed budget → cheaper/fewer resources, ...
Original quality → more/better resources, delayed delivery dates, ...

39. Baseline agreed in initiation stage → clear how project will be affected by CR or issue
Red, amber and green escalation conditions for determinig who should make decision →clearly identified in all chapters → possible to determine who is authorised

40. Either business case or project plan (or both) need update
Solution approved by project manager: includes altering forecast timescales, bugets or quality expectations
Required changes if project steering group or portfolio management team involved
If degree of change ↑ anxiety of most senior authorities → escalation conditions more sensitive → acception of solutions ↑

41. Thank you for your attention!