lecture 3
Upcoming SlideShare
Loading in...5

lecture 3






Total Views
Views on SlideShare
Embed Views



0 Embeds 0

No embeds



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment
  • PID must be formally approved by Board Check that business objectives are understood All concerned understand their responsibilities Project plans are acceptable

lecture 3 lecture 3 Presentation Transcript

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