lecture 3


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • PID must be formally approved by Board Check that business objectives are understood All concerned understand their responsibilities Project plans are acceptable
  • lecture 3

    1. 1. EPP3 TECH3001 Project Planning with PRINCE2 (Acknowledgement: Steve McRobb produced the original material, amended by myself)
    2. 2. Overview <ul><li>PRINCE </li></ul><ul><li>Project planning </li></ul><ul><li>PRINCE organisation structure </li></ul><ul><li>PRINCE project management process </li></ul><ul><li>Resource allocation issues </li></ul><ul><li>Procedures to define project control: </li></ul><ul><ul><li>At initiation </li></ul></ul><ul><ul><li>During project </li></ul></ul><ul><ul><li>At project close </li></ul></ul><ul><li>Various documents are defined to support the procedures </li></ul>
    3. 3. PRINCE <ul><li>PR ojects IN C ontrolled E nvironments </li></ul><ul><li>Project management methodology </li></ul><ul><li>Since 1989, UK govt standard for IT / IS projects </li></ul><ul><li>Controlled and published by CCTA </li></ul><ul><li>PRINCE 2 has been made more flexible </li></ul><ul><li>Can be used for any type of project, but for our purposes large scale MM projects </li></ul>
    4. 4. Planning <ul><li>Important activity in any project </li></ul><ul><li>Not just an annoying precursor to the ‘real’ work! </li></ul><ul><li>We plan: </li></ul><ul><ul><li>To enable budgeting and resourcing </li></ul></ul><ul><ul><li>To make sure we understand what is involved </li></ul></ul><ul><ul><li>To predict completion dates for milestones </li></ul></ul>
    5. 5. Problems in planning <ul><li>Incomplete information </li></ul><ul><li>External pressures </li></ul><ul><li>Unexpected changes </li></ul><ul><li>Unknown resource availability </li></ul><ul><li>Where do we start? </li></ul>
    6. 6. PRINCE Org Structure <ul><li>First step in a project: establish org structure </li></ul><ul><li>PRINCE 1 has prescribed org structure for IS/IT projects </li></ul><ul><li>PRINCE 2 org structure is a bit more generic </li></ul><ul><li>(To suit other types of org and project than just IS / IT) </li></ul>
    7. 7. PRINCE 2 Process Model <ul><li>Essential philosophy of PRINCE 2 summarised in process model </li></ul>
    8. 8. PRINCE 2 Process Model <ul><li>Major processes give general framework and guidance </li></ul><ul><li>How to start up a project </li></ul><ul><li>How to manage its stages </li></ul><ul><li>How to handover from one stage to another </li></ul>
    9. 9. PRINCE 2 Process Model <ul><li>Read vertically: authority and reporting </li></ul><ul><li>Read horizontally: sequence of activities </li></ul><ul><li>Some activities are repeatable </li></ul><ul><ul><li>'Controlling a Stage' </li></ul></ul><ul><ul><li>'Managing Stage Boundaries’ </li></ul></ul><ul><li>Some are ongoing: </li></ul><ul><ul><li>'Managing Product Delivery’ </li></ul></ul><ul><ul><li>'Planning’ (at many levels) </li></ul></ul>
    10. 10. SU Starting Up a Project <ul><li>Ensure information required by the project team is available </li></ul><ul><li>Design and appoint the project management team </li></ul><ul><li>Create Initiation Stage Plan </li></ul>
    11. 11. IP Initiating a Project <ul><li>Is there enough justification to proceed? </li></ul><ul><li>Establish stable basis for management </li></ul><ul><li>Document an acceptable business case </li></ul><ul><li>Agree to commit resources for first stage </li></ul><ul><li>Enable project board to take ownership </li></ul><ul><li>Give a baseline for later decisions </li></ul><ul><li>Evaluate investment and anticipated risks </li></ul>
    12. 12. CS Controlling a Stage <ul><li>Authorise work to be done </li></ul><ul><li>Gather progress information </li></ul><ul><li>Watch for changes </li></ul><ul><li>Review the situation </li></ul><ul><li>Report </li></ul><ul><li>Take corrective action </li></ul>
    13. 13. SB Managing Stage Boundaries <ul><li>Assure board that deliverables are complete as planned </li></ul><ul><li>Give board information to: </li></ul><ul><ul><li>assess continuing viability </li></ul></ul><ul><ul><li>approve stage completion </li></ul></ul><ul><ul><li>authorise start of next stage </li></ul></ul><ul><li>Record any useful lessons </li></ul>
    14. 14. MP Managing Product Delivery <ul><li>Make sure work: </li></ul><ul><ul><li>is authorised and agreed </li></ul></ul><ul><ul><li>conforms to Work Package interfaces (avoid unplanned side-effects) </li></ul></ul><ul><ul><li>is done </li></ul></ul><ul><li>Check progress against forecasts </li></ul><ul><li>Ensure products meet quality criteria </li></ul><ul><li>Get completed products approved </li></ul>
    15. 15. CP Closing a Project <ul><li>Check aims in Project Initiation Document have been met </li></ul><ul><li>Confirm customer satisfaction </li></ul><ul><li>Get deliverables formally accepted </li></ul><ul><li>Confirm maintenance / operational arrangements </li></ul>
    16. 16. CP Closing a Project <ul><li>Recommend any follow-on-actions </li></ul><ul><li>Capture and report on lessons learned </li></ul><ul><li>Prepare End Project Report </li></ul><ul><li>Formally notify host org of intention to disband </li></ul>
    17. 17. PL Planning <ul><li>Repeats at different levels of project </li></ul><ul><li>Planning involves: </li></ul><ul><ul><li>what products are needed </li></ul></ul><ul><ul><li>sequence of production </li></ul></ul><ul><ul><li>form and content of each product </li></ul></ul><ul><ul><li>activities necessary for creation and delivery </li></ul></ul><ul><li>Identifying products is very important, and precedes any thought about activities </li></ul>
    18. 18. Planning stages <ul><li>CPA or PERT charts used to: </li></ul><ul><ul><li>map sequence of stages </li></ul></ul><ul><ul><li>plan times </li></ul></ul><ul><ul><li>allocate resources </li></ul></ul>
    19. 19. PRINCE project control <ul><li>Having planned the project…. </li></ul><ul><li>Now necessary to define control points </li></ul><ul><li>These help ensure sure everything is going to plan </li></ul><ul><li>PRINCE 2 defines: </li></ul><ul><li>various checkpoints and formal documents during the project </li></ul>
    20. 20. Main points of control <ul><li>Project initiation </li></ul><ul><li>During project progress </li></ul><ul><li>When closing down project </li></ul>
    21. 21. Start-Up and Initiation <ul><li>Project Mandate </li></ul><ul><li>formally kicks-off a project </li></ul><ul><li>identifies client and general subject </li></ul><ul><li>May state how project relates to a longer term programme of projects </li></ul>
    22. 22. Other initiation documents <ul><li>May refine mandate into Project Brief </li></ul><ul><ul><li>Defines project objectives </li></ul></ul><ul><li>Project Approach specifies whether: </li></ul><ul><ul><li>bespoke </li></ul></ul><ul><ul><li>off-the-shelf </li></ul></ul><ul><ul><li>develop in-house </li></ul></ul><ul><li>Completes Project Start-Up Stage </li></ul>
    23. 23. Initiation Stage <ul><li>We can now plan the project in detail </li></ul><ul><li>Initiation stage main documents: </li></ul><ul><ul><li>Project Quality Plan </li></ul></ul><ul><ul><li>Project Plan </li></ul></ul><ul><ul><li>Risk Log </li></ul></ul><ul><ul><li>Project Initiation Document (PID) </li></ul></ul><ul><li>Brings together all documents to this point </li></ul>
    24. 24. Controlling a Stage <ul><li>Several formal control points, regular checks on…. </li></ul><ul><ul><li>Quality </li></ul></ul><ul><ul><li>Completeness….so far </li></ul></ul><ul><li>As a stage progresses we learn more </li></ul><ul><ul><li>business environment </li></ul></ul><ul><ul><li>technical aspects of project </li></ul></ul><ul><ul><li>capabilities of team </li></ul></ul>
    25. 25. Controlling a Stage <ul><li>During a stage we need to consider: </li></ul><ul><li>Impact of changes on next stage </li></ul><ul><li>Review resource allocations </li></ul><ul><li>Identify and document potential problems </li></ul>
    26. 26. CS3 Capturing project issues <ul><li>Possible Outcomes: </li></ul><ul><ul><ul><li>Request for Change (modification of user requirements) </li></ul></ul></ul><ul><ul><ul><li>Off-Specification (known but acceptable error or omission) </li></ul></ul></ul><ul><ul><ul><li>Highlight Report (progress within tolerances) </li></ul></ul></ul><ul><ul><ul><li>Exception Report tolerances may be exceeded -- documents both causes and possible solutions </li></ul></ul></ul>
    27. 27. Managing Stage Boundaries <ul><li>Formally closes one stage, initiates another </li></ul><ul><li>Stage closure updates: </li></ul><ul><ul><li>plan </li></ul></ul><ul><ul><li>business case </li></ul></ul><ul><ul><li>risk log </li></ul></ul><ul><li>Stage end is formally reported to Board </li></ul><ul><li>Exception report completed if appropriate </li></ul>
    28. 28. Managing Stage Boundaries <ul><li>Before next stage begins, produce stage plan </li></ul><ul><ul><li>never done too soon </li></ul></ul><ul><ul><li>circumstances change while project is underway </li></ul></ul><ul><ul><li>detailed planning left till shortly before start of stage </li></ul></ul><ul><li>Is project still viable? </li></ul><ul><li>Board is responsible for formally authorising next stage </li></ul>
    29. 29. Managing Product Delivery <ul><li>Project Manager may not directly supervise </li></ul><ul><ul><li>contract staff or sub-contractor organisation </li></ul></ul><ul><ul><li>may not use PRINCE methodology </li></ul></ul><ul><li>Defined interface between project and 3 rd parties: </li></ul><ul><ul><ul><li>MP1 Accept a work package </li></ul></ul></ul><ul><ul><ul><li>MP2 Execute a work package </li></ul></ul></ul><ul><ul><ul><li>MP3 Deliver a work package </li></ul></ul></ul>
    30. 30. Closing a Project <ul><li>Orderly decommissioning </li></ul><ul><li>Products should have been checked off as stages close, but final check done in case of omission </li></ul><ul><li>Unresolved issues listed in Follow-On Actions Report </li></ul><ul><li>Project files archived </li></ul>
    31. 31. Closing a Project <ul><li>Formal notification that project has closed </li></ul><ul><li>Documents available at final Board: </li></ul><ul><ul><li>System Acceptance letter </li></ul></ul><ul><ul><li>User Acceptance letter </li></ul></ul><ul><ul><li>Operations Acceptance letter </li></ul></ul><ul><ul><li>Business Acceptance letter </li></ul></ul>
    32. 32. Closing a project: documents <ul><li>Project End Report </li></ul><ul><li>Extent to which objectives in PID were met </li></ul><ul><li>Lessons Learnt Report </li></ul><ul><li>Post-implementation review, 6 – 12 months after implementation </li></ul>
    33. 33. Technical control reports <ul><li>Project Issue Report </li></ul><ul><ul><li>errors in system </li></ul></ul><ul><ul><li>failure to meet user requirements </li></ul></ul><ul><ul><li>inconsistency between versions </li></ul></ul><ul><ul><li>idea for improvement </li></ul></ul><ul><ul><li>forgotten function or program </li></ul></ul><ul><ul><li>policy or legislation change </li></ul></ul>
    34. 34. PIR <ul><li>Anyone can raise a PIR </li></ul><ul><ul><li>Initially handled by stage manager and project assurance team </li></ul></ul><ul><ul><li>Outcomes must be documented </li></ul></ul><ul><ul><li>All PIRs should be dealt with before Project Closure Meeting </li></ul></ul>
    35. 35. Off-Specification <ul><li>Documents serious deviations: </li></ul><ul><ul><li>something exceeds agreed tolerances </li></ul></ul><ul><ul><li>something specified is impossible to do </li></ul></ul><ul><ul><li>may arise from a PIR </li></ul></ul><ul><ul><li>may have significant effect on project as a whole </li></ul></ul><ul><ul><li>E.g. corrective work on other modules </li></ul></ul>
    36. 36. Off-Specification <ul><li>Typical issues: </li></ul><ul><ul><li>Can we do the work within the bounds of the current stage plan? </li></ul></ul><ul><ul><li>Do we persuade the user to drop the requirement? </li></ul></ul><ul><ul><li>Can we delay it until the next stage? </li></ul></ul><ul><ul><li>Will we have to replan the stage? </li></ul></ul><ul><ul><li>What are the consequences on the rest of the programming? </li></ul></ul>
    37. 37. Request for Change <ul><li>Usually an alteration to requirements that originates with users </li></ul><ul><ul><li>proposes some modification to system </li></ul></ul><ul><ul><li>Must have approval of project manager </li></ul></ul><ul><ul><li>Some level of Change Control is necessary </li></ul></ul>
    38. 38. Summary <ul><li>In this lecture we have: </li></ul><ul><li>met an overview of the PRINCE 2 organisation structure and process model </li></ul><ul><li>examined the major stages of the PRINCE 2 process </li></ul><ul><li>seen how to plan a PRINCE 2 project </li></ul><ul><li>Advantages: formal reporting & organisational structure, good information flow </li></ul><ul><li>Disadvantages: suitable for large projects only, adds significantly to cost, bureaucratic </li></ul><ul><li>Procedures to define project control: </li></ul><ul><ul><li>At initiation </li></ul></ul><ul><ul><li>During project </li></ul></ul><ul><ul><li>At project close </li></ul></ul><ul><li>Important documents include: </li></ul><ul><ul><li>Request for Change </li></ul></ul><ul><ul><li>Project Issues Report </li></ul></ul><ul><ul><li>Follow-On-Actions Report </li></ul></ul>
    39. 39. Reading and References <ul><li>Software Project Management 3rd Hughes and Cotterill, </li></ul><ul><li>CCTA website: www.ccta/gov.uk/prince/prince.htm </li></ul><ul><li>http://www.ccta/gov.uk/prince/prince.htm </li></ul><ul><li>Keyskills website: www.prince2.com </li></ul>