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

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

The control cycle Plan

The control cycle Plan Delegate

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

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

The control cycle Plan Delegate Monitor and Report

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

Project register

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.

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

Project Manager Project Team Progress Meetings:

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

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

PFR: 1. Time Forecast

PFR: 2.1. Cost Forecast by Type

PFR: 2.2. Cost Forecast by Product

PFR: 3. Project Quality Forecast

PFR: 4. Product Quality Log

PFR: 5. Benefits Forecast

PFR: 6. Risk Register

Timesheet

Earned value Analysis

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

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

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

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

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

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)

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, ...)

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

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

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

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

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

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

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, ...

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

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 ↑

Thank you for your attention!