1 / 19

UCL/APM Principles of Project Management Hand-Over and (Post-) Project Evaluation Review and course summary Graham Colli

UCL/APM Principles of Project Management Hand-Over and (Post-) Project Evaluation Review and course summary Graham Collins, UCL. graham.collins@ucl.ac.uk. Format of the evening. Hand-Over and (Post) Project Evaluation Review

johana
Télécharger la présentation

UCL/APM Principles of Project Management Hand-Over and (Post-) Project Evaluation Review and course summary Graham Colli

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. UCL/APM Principles of Project ManagementHand-Over and(Post-) Project Evaluation Reviewand course summaryGraham Collins, UCL graham.collins@ucl.ac.uk

  2. Format of the evening • Hand-Over and (Post) Project Evaluation Review • Reminder of the areas of the body of knowledge and coverage of remaining syllabus • APM examinations and web-site • (Just outside the Housman room there is an exhibition which you may wish to view) • Opportunity to meet informally in the Garden Room 7.45/8.00pm • Evening ends 8.30pm ©Graham Collins 2005

  3. APM Project Management Body of Knowledge 1. General Project Management Programme Management Project Context 2. Strategic Project Success Criteria Value Management Quality Management Strategic/Project Management Plan Risk Management Health, Safety and Environment 3 Control Work content and scope management Time Scheduling/Phasing Resource Management Budgeting and Cost Management Change Control Earned Value Management Information Management 4 Technical Design, Implementation and Hand-Over Requirements Management Estimating Technology Management Value Engineering Modelling and Testing Configuration Management 5 Commercial Business Case Marketing and Sales Financial Management Procurement Legal Awareness 6. Organisational Life Cycle Design and Management Opportunity Design and Development Implementation Hand-Over Post) Project Evaluation and Review Organisation Structure Organisation Roles 7. People Communication Teamwork Leadership Conflict Management Negotiation Personnel Management Adapted from the APM BoK (Body of Knowledge) ©Graham Collins 2005

  4. Hand-Over • ‘Hand-Over is the completion of the project to the satisfaction of the sponsor. It involves management of the introduction of the product or service being delivered by the project • During Hand-Over, project records together with an audit trail documentation are completed and delivered to the sponsor. This documentation will be at the post project evaluation review. • There should also be a review of the original business case (Benefits Assessment) at this time, and /or in the next phase Post Project Evaluation.’ From section 64 APM BoK (Body of Knowledge) Fourth Edition 2000 edited by Miles Dixon, and based on the research of Peter Morris, UCL ©Graham Collins 2005

  5. Hand-Over Handover criteria Proposal Contract Planning for handover Planning Design Construction(and pre-commissioning) Project Handover Project Acceptance Purchasing Commissioning: advancement of an installation from the stage of static completion to full working order and achievement of the specified operational requirements Adapted from ‘project planning and corrective action links to handover’ diagram in section 64 ‘Handover’ by Peter Jones, in Project Management Pathways, edited by Martin Stevens, APM 2002. ©Graham Collins 2005

  6. Acceptance Definitions • Acceptance: the formal process of accepting delivery of a product or a deliverable • Acceptance Criteria: performance requirements and essential conditions that have to be achieved before project deliverables are accepted • Acceptance Test: formal, pre-defined test conducted to determine the compliance of the deliverable item(s) with the acceptance criteria ©Graham Collins 2005

  7. Team members • ‘As closure approaches the team members are concerned about their next assignment’ • ‘May show as reduced motivation with a slowing down of effort and lack of commitment’ • ‘You must keep the momentum going and avoid losing team members to others projects’ (subject of last week’s talk, and research cited) Extracts from ‘Successful project management, Trevor L Young, Sunday Times series, Kogan Page, 2000 ©Graham Collins 2005

  8. Team Development: Tuckman Model Forming, starting to interact, tentatively identify purpose of group Storming, views put forward more forcefully. Conflicts may emerge. Challenges to the tasks and responsibilities may ensue Norming, group will establish norms and conflict is controlled by group members Performing, once group has progressed through previous stages the group can work cohesively and effectively to deliver the team (and project) goals • Number of research studies outline how a group develops over the project life cycle • One study was carried out by Tuckman (1965) • Tuckman’s research suggested four stages of development - forming, storming, norming and performing ©Graham Collins 2005

  9. Project drift ‘Occurs when you take the pressure off the control system and allow the customer or any stakeholder to throw in a few add-ons: ‘Just before you finish the project, have a look at this modification’ Control of late changes of mind adds significant extra work and considerable costs to the project. This is often when some sleeping stakeholders suddenly wake up and start making a lot of noise!’ from ‘Successful project management, Trevor L Young, Sunday Times series, Kogan Page, 2000 ©Graham Collins 2005

  10. Change Control definitions • Change log: a record of all project changes, proposed, authorised and rejected • Change Management: the formal process through which changes to the project plan are approved and introduced • Change Control: process that ensures potential changes to the deliverables of a project or a sequence of work in a project, are recorded, evaluated authorised and managed • Change Control Board: A formally constituted group of stakeholders responsible for approving or rejecting changes to the project baselines • Change Request: a request needed to obtain formal approval for changes to the scope, design, methods, costs or planned aspects of a project. Change requests may arise through changes in the business or issues in the project. Change requests should be logged, assessed and agreed on before a change in the project can be instigated. ©Graham Collins 2005

  11. Completion criteria • All tasks finished • Agreed deliverables completed • Testing completed • Training materials prepared • Equipment installed and operating • Documentation manuals finished • Process procedures finished and tested • Staff training finished The acceptance process should be in your plan i.e. PMP Check that the specific criteria they agreed to use at the outset is still valid All criteria must be measurable by agreed metrics or conflicts will arise from ‘Successful project management, Trevor L Young, Sunday Times series, Kogan Page, 2000 ©Graham Collins 2005

  12. Acceptance process checklist Activities that must be finished before acceptance is confirmed Agree action plans to complete outstanding tasks to avoid giving your client an excuse to hold up the acceptance process • Unfinished non-critical work • The project tasks completed • The deliverables achieved • Quality standards attained • Supply of equipment • Installation of equipment • Testing and validation of equipment • Testing and validation of operating processes • Documentation manuals • New standard operating procedures • Design of training programmes • Training of operating staff and management • Training of maintenance staff • Setting up of a help desk • Establishing maintenance functions • Outstanding issues awaiting resolution • Identifying any follow on projects • Limits of acceptability • Who monitors post project performance • Budget over-runs Source ibid ©Graham Collins 2005

  13. The close out meeting • Review the project results achieved • Go through the handover checklist • Confirm and explain action plans for any outstanding work to tidy up • Confirm and explain action plans for any issues • Agree and confirm responsibilities for any ongoing work or support • Confirm who is responsible for monitoring project benefits • Thank the team and stakeholders for their efforts and support • Thank the customer and your project sponsor for their support and commitment Provided you have done everything the checklist demands, acceptance should be agreed and the completion certificate approved and signed. You can then organise an appropriate celebration for the team and stakeholders Source ibid ©Graham Collins 2005

  14. (Post) Project Evaluation Review • Projects as outlined, the Millennium Dome etc seem to have a track record for being failures. Often projects cost more, invariably exceed timescales. Typically various stakeholders are unhappy with the process, do not assess that the project has delivered the expected benefits. Each stakeholder has their own perception of success criteria. • At the start of a project, these reviews need to be examined, for lessons learnt, and apply lessons where necessary. • In addition, Health Checks can be carried out to ensure stakeholders are focusing on the same criteria. ... ‘I go over what I should or shouldn’t have said to somebody.’ Alan sugar, discussing ‘The Apprentice’ series in the article ‘Sweet Smell of Success’, Media section,p11 Independent 02/05/05 Based on APM Pathways ©Graham Collins 2005

  15. What is evaluated • Active evaluation (during the project) i.e. learning from doing. The process, progress and management are all considered. An example could be an iterative project where the progress, approach etc are examined at each iteration, or milestone. • Initial post project evaluation (at closure). It is important to learn what went well and what didn’t. Were the benefits achieved. What processes enabled team work and innovation. • Final post project evaluation (at a fixed period after closure). This is often focused on the evaluation of the business case and also the technical performance. When you have finished the project, and the customer considers it a success and submitted your final evaluation report, have a celebration meeting. Above all, give recognition to the contribution of everyone involved ©Graham Collins 2005

  16. Estimating • Estimating: the act of combining the results of project reviews, metrics, consultation and informed assessment to arrive at time and resource requirements for an activity • Parametric estimating: an estimating technique that uses a statistical relationship between historic data and other variables (e.g. square metreage in construction, lines of code in software development*) to calculate the estimate • Non-quantitative approach may include comparative approaches cover examining similar activities. Also, qualitative approaches may be through the experience of project individuals. Quantitative methods include parametrics, and analytical (bottom-up) based on the costs of the of the individual tasks, in the WBS. • Statistical approaches, include Monte Carlo estimates particularly applicable for risk (mentioned by speaker in risk lecture). *A more up to date approach is for example function points, which give a better estimate of size, however this is still of use as it is easy to measure and there is often historic data from other projects to act as a comparison ©Graham Collins 2005

  17. A current study During the course I’ve mentioned iterative projects, these often encompass best practice and trends in project management. A recent article on the management of such projects can be found at: www-106.ibm.com/developerworks/rational/library/may05/bittner-spence/index… The authors assert that it is better is measure progress in terms of results (working software) rather than subjective assessment of progress (e.g. in terms of documentation produced). Reading pages 2 and 4 of this article one can then consider the previous example (based on an actual project) I gave earlier in the course 100% Planned budget In the project (previously outlined) actual and earned value EV were lower than planned Development progress (% complete scenarios) cost Results in working software actual EV 0% iterations time ©Graham Collins 2005

  18. Final thoughts • Thucydides, commenting on Pericles, ‘power depended on his oratory but also reputation and upon the confidence he enjoyed as a man who was immune to bribes’ • Churchill was well known for his oratory, but above all he thanked the people • Drucker, (mentioned at the start of the course) outlined the importance of goals and defining the purpose, and ensuring your team understood these. In his latest article in Harvard Business Review, he outlines the most important skill for a leader is to listen. ©Graham Collins 2005

  19. Book slot Body of Knowledge Fifth Edition 2006 Association of Project Management ISBN 1-903494-00-1 The foundation of this version was an extensive research programme conducted by Professor Peter Morris, UCL. ©Graham Collins 2005

More Related