Bugfree.dk – Ronnie Holm's blog

Not anti-anything, just pro-quality

Prince2 foundation

1 Prince2 foundation

1.1 Session 1: Course introduction

  • Recognized examination standards
  • Defined by UK Office of Government Commerce
  • Levels
    • Foundation
    • Practitioner
  • Course is about operating as an informed member of a project team
  • Characters
    • Project board: overall direction and management
      Executive, senior supplier, senior user
    • Project manager: runs the project on day to day basis
      Responsible for producing products to required cost, time, quality
  • Projects variables
    • Cost
    • Time
    • Quality
    • Scope: what to deliver
    • Risk: how to manage risks
    • Benefits: why we’re doing the project
      Getting these factors right is what a good project is about
  • Organizations balance between business as usual (BAU) and change
  • Project vs. BAU
    • Bring about change
    • Temporary in nature
    • Cross-functional in organization
    • Uniqueness
    • Uncertainty
      Project introduces threats/opportunities over/above those in BAU
  • What Prince2 isn’t
    • Software
    • Planning tool
    • Carved in stone
    • Unnecessarily bureaucratic
    • Restricted to large projects
    • A guarantee of successful outcomes
  • What Prince2 is
    A book describing a structured method to approach, manage, and
    close down a project of any type and size, regardless of scale
    type, nature of organization, culture, and location
  • How method becomes generic
    • Isolates management and specialist aspects of project work
    • Day to day work handled separately from project deliverables
  • Prince2 players
    • Office of Government Commerce
    • The Stationary Office (TSO)
      • Printing/distributing manuals
    • APM Group
      • Coordinates examination procedures
      • Accredits training organizations
    • Accredited Training Organizations (ATOs)
      • Companies approved by APM Group to deliver Prince2 training
    • United Kingdom Accreditation Service (UKAS)
      • Provides higher level of accreditation
      • Audits procedures of APM Group to verify they meet standards
  • Prince2 is about what and why, not how
  • Prince2 is not prescriptive, but descriptive

1.2 Session 2: Overview and principles

  • Main aspects
    • How to approach task (method)
    • How work is organized
    • Main factors to take into account
    • Who has responsibility for what
    • How is progress monitored and communicated
  • Prince2 provides best-practice guidance on main aspects through
    • 7 principles
      • Provides best-practice framework for projects
      • Ultimately they define a Prince2 project
    • 7 themes
      • Provides guidance on project work to address during undertaking
      • Relates to each other and are integrated into processes
    • 7 processes
      • Offers journey through project
      • Ensures critical aspects are not forgotten nor treated lightly
      • Forms a process model to take team from start to finish
  • Using Prince2 on projects encourages
    • Production of business case
    • Setting up management structure
    • Defining roles and responsibilities
    • Using management procedures and processes as guidance
  • Key project techniques
    • Product-based planning (as a means of obtaining objectivity)
    • Prince2 doesn’t include or mandate the use of tools
      • Computers/software
      • Critical path analysis
      • Gantt charts
    • Prince2 says tools should be chosen and used as appropriate
  • Key elements of Prince2
    • Does not exist or operate in isolation from rest of organization
    • ISO9000 and common sense is the foundation on which Prince2 is used
    • Every project must have a business case
      • Given the risks, is this project worth undertaking
      • Cost/benefit analysis
      • Avoid starting projects that were never worth it
      • Prince2 is used on project before beginning on specialist products
    • Principles (true before, during, and after project)
      1. Continued business justification

        • Create business case to investigate project viability
        • Business case is documentary evidence of followed the principle
      2. Learn from experience

        • Same group of people may not work together again
        • No project should reinvent the wheel
        • Collective memory should be captured formally
        • Use a Lessons log to capture lessons learned
      3. Defined roles and responsibilities

        • Know what’s expected of you and what you can expect of others
      4. Manage by stages

        • Divides project into manageable chucks
        • Project board evaluates viability of project periodically
        • Project manager not required to plan in detail far ahead
      5. Manage by exception

        • Each level of management is given clear responsibilities
      6. Focus on products

        • Looks at bigger picture rather than activities, e.g., TODO lists
        • Forces question of what to make rather than what to do
      7. Tailor to suit project environment

        • Each project is unique
        • Otherwise Prince2 becomes bureaucratic rather than pragmatic
    • Themes (essential for any successful project)
      1. Business case

        • Form part of foundation for project
        • Used to ensure progress is aligned with business objective
      2. Organization

        • Define roles, responsibility, and relationship of people involved
      3. Quality

        • Emphasis on deliverables makes it easier to focus on quality
      4. Plans

        • Backbone of management information system for any project
        • Prince2 works with different levels of plans
      5. Risk

        • Identify and take relevant action is response to uncertainty
      6. Change

        • Changing a project as it progresses is a necessity
      7. Progress

        • When actual is known, it’s easier to compare with planned
    • Processes
      1. Starting up a project (pre-project activities)
      2. Directing a project
      3. Initiating a project
      4. Controlling a stage
      5. Managing product delivery
      6. Managing a stage boundary
      7. Closing a project

1.3 Session 3: Themes, part 1

  • Business case
    • Any project should be driven by a viable business case
    • Should contain
      • Reasons
      • Benefits
      • Costs
      • Risks
      • Timescales
    • Created at the start of project and reviewed at each stage
    • Lets the project board decide if project is
      • Desirable
      • Viable (cost/benefit)
      • Achievable
    • Main sections
      • Execute summary
      • Reasons
        • Compulsory: legislative
        • Non-profit: need to change procedures, improve moral
        • Research and development: unknown outcomes
        • Customer/supplier: product development
        • Multi-organization: with partners
      • Business options (do nothing, do minimum, do something)
      • Expected benefits
      • Expected dis-benefits
      • Timescale
      • Costs
      • Investment appraisal (ROI, net present value)
      • Major risks
    • Business case is owned by executive
      Executive’s responsible for alignment of objectives, costs,
      and benefits with business strategy/program objectives
    • Project mandate is a preliminary version of business case
      Created by program management and handed to project board.
      During initiating a project, the business case is fully
      developed
    • Senior user is responsible for realizing benefits after release
  • Organization
    • Assumes project takes place in customer/supplier environment
    • Combined with the need for a sound business for project
    • Levels of organization
      • Corporate/program management
        • Commissions project
        • Identifies executive
        • Defines project level tolerances
      • Directing
        • Activities of project board
      • Managing
        • Day to day activities of project manager
      • Delivering
        • Build or develop project products
    • Project board
      • Members work part-time on project
      • Should represent interests of
        • User
          • Senior user role
            • Represents interest of users affected by project
            • Responsibility start with specification of user needs
            • Identification/realization of benefits
            • Responsibility continues beyond lifetime of project
            • Often requires several people to represent all interests
        • Supplier
          • Senior supplier role
            • Represents interests of those developing actual products
        • Business interests
          • Executive role
            • Ultimately responsible for entire project
            • Owns business case and must ensure project delivers value
            • Chairs project board meetings
      • Minimum number of people making up project board is two
    • Project manager
      • Plans and oversees day to day activities
      • Makes sure project produces
        • Right products
        • Right time
        • Right quality
        • Right cost
      • Project manager is always comprised of a single person
      • Team managers may optionally support project manager
      • Overall responsibilities
        • Planning project
        • Motivating and leading staff
        • Liaison with program management for related projects
        • Define responsibilities for specialist team managers
        • Report progress to project board
      • Makes sure benefits described in initiation document is achieved
    • Team managers
      • Works under project manager
      • Runs checkpoint meetings and creates checkpoint reports
      • Project manager provides highlight reports to board based on these
    • Project support
      • All projects require administration
      • In large projects several people may take on project support role
      • Enables project manager to concentrate on management of project
      • Tasks
        • Setting up and maintaining project documentation
        • Updating plans and assessing impact of changes
        • Defining and maintaining project management standard
        • Configuration and change management control
        • Taking minutes at meetings and compiling reports
    • Project assurance
      • Project board may be in doubt whether
        • Things are going as well as told
        • Problems are being hidden from them
        • Solution is what we want
      • Organizations needs to assess project independent of project manager
      • Prince2 separate project assurance from project support
      • Each board member has his own project assurance responsibilities
        • Business assurance
        • User assurance
        • Supplier assurance
      • Board member may delegate assurance responsibility to third party
    • Change authority
      • Person/group responsible for agreeing to changes
      • By default change authority = project board, but they may delegate
  • Quality
    • Make sure products produced are fit for intended purpose
    • Customer quality expectations are defined in project brief
      Becomes project initiation document and later business case
    • Quality management is made up of
      • Quality system
      • Quality assurance
      • Quality planning
        • Lays down objectives and requires
        • Defines the overall approach
        • Establishes stage level quality activities
      • Quality control
    • Quality manual
      • Main tangible evidence of quality management
      • Contains clear statement of company’s quality policy
      • Documents all quality processes and procedures in organization
    • Quality assurance function
      • Responsible for setting up quality management system
      • Quality assurance ensures everything is in line with quality manual
      • Quality assurance may be an external function to project
    • Types of quality methods
      • In-process
        Specialist methods are used in creation of products
      • Appraisal
        Finished products are assessed for completeness
    • In Prince2 quality review technique complement product descriptions
    • Quality review is where a completed product is checked for errors
      • Quality criteria from product description is used as the basis
      • Ensures early identification of defects during review
      • Objectives
        • Assess product against set criteria
        • Provides wider acceptance of product
        • Confirms product is complete
        • Baseline product for change control
    • Quality register
      Provides audit trail of quality events planned and undertaken
    • Steps in quality review procedure
      1. Review preparation
      2. Review meeting agenda
      3. Review follow-up
    • Quality review roles (minimum two people)
      • Chair
      • Presenter
        Represents producers of products
      • Reviewer
      • Administrator
        Records results
  • Plans
    • Project plans
      • Created during project initiation
      • Provides statements of
        • How to achieve project targets (time, cost, scope, quality)
        • Identifies major products, activities, resources required
        • Provides business case
        • Identifies control points (management stages, milestones)
      • Used by project board as a baseline to measure progress
      • In Prince2 a plan is not just a Gantt chart. It should state
        • What is to be produced
        • What has to be done to produce it
        • What will be produced
        • How will progress be monitored
        • What will be done to control risk
    • Stage plans
      • Produced for each stage
      • Each plan broken down into level of detail for day to day control
      • Stage plan finalized near end of previous stage
      • Developed with the benefits of hindsight from earlier stages
    • Team plan (optional)
      • Team manager may produce team plans
    • Exception plan
      • A plan used to replace original plan no longer holding
        When original plan will not finish within agreed tolerances
      • Prepared at same level of detail as the one it replaces
      • Once approved, exception plan becomes new baseline plan
    • Product-based planning
      • Old school
        • Start by defining all activities making up a product
      • Prince2 school
        • Start by defining all products to be created by project
          Product is anything produced by or on the way through
          project, i.e., not just the final deliverable, but also
          paperwork, reports, and control mechanisms that are
          produced
        • Makes it easier to identify/define activities used to create them
      • Main steps
        • Writing project product description
          In principle written by senior user, but in practice
          completed by project manager and executive
        • Produce product breakdown structure
          • Relies on project product description
          • Take top-down view of all products to be generated
          • Start on top with finished deliverable or outcome
          • Provides no indication of sequence and timing
        • Writing product descriptions for identified products
          Prince2 recommends headings for product description
        • Produce product flow diagram
          Sequence in which products are to be created. Forms the
          basis for the creation of a schedule
    • Benefits of product-based planning
      • Clearly and consistently identified products
      • Clear requirements
      • Improves communication
      • Clarifies scope boundary
      • Identifies external products and associated risks
      • Create a basis for work packages for suppliers
      • Gain agreement on approval procedure

1.4 Session 4: Themes, part 2

  • Risk
    • Threat: risk with negative impact
    • Opportunity: risk with positive impact
    • For risk management to work risks must be
      • Identified
      • Assessed (likelihood, impact, proximity)
      • Controlled (assign owners and monitoring responses)
    • Prince2′s approach to risk is based on nine principles
      • Understanding project context
      • Involve stakeholders
      • Establish clear project objective
      • Develop risk management approach
      • Report on risks regularly
      • Define clear roles and responsibilities
      • Establish support structure
      • Monitor for early warning indicators
      • Establish review cycle
    • Prince2 attempts to reduce avoidable/unnecessary risks in a project
    • Starting point
      • Does your company have a risk management policy?
      • Use policy to define risk management strategy for project
      • Risk tolerance: how much risk you’re prepared to take
      • Risk register: should record all identified risks
        • Identifier
        • Author
        • Registration date
        • Risk category (schedule, legal, quality)
        • Description
        • Probability, impact, expected value
        • Proximity (how close to present time, e.g., imminently)
        • Response category (avoid, reduce, transfer, accept)
        • Response (document response to risk)
        • Status (active/closed)
        • Owner
        • Actionee (implement action described in response)
    • Risk management procedure
      • Identify
        • Identify context so risk management strategy can be established
        • Look at project mandate to establish project objectives
        • Not about eliminating risks, but understanding risks
        • Record risks in risk register
        • Identify risk in terms of
          • Cause
          • Event
          • Effect
      • Assess
        • Probability: likeliness of risk occurring
        • Impact: what happens if risk occurs
        • Proximity: when will risk happen
        • Define a risk impact grid and use as a ranking system
      • Plan
        • Mitigating action for a risk
        • Responses to threats
          • Avoid
          • Reduce
          • Fallback
          • Transfer
          • Accept
          • Share
        • Responses to opportunities
          • Exploit
          • Enhance
          • Reject
          • Share
      • Implement
        Put risk response into action
      • Communicate
        Carried out in parallel with other steps
  • Change
    • About
      • Identification
      • Assessment
      • Control
    • Change can only be established with respect to a baseline
    • Configuration management system
      • Records baseline for product
      • Handles issue and change control
    • Types of issues
      • Request for change
      • Off-specification
      • Problem or concern
    • Important aspects
      • Change authority: agrees to implement a change
      • Change funding: method of funding
    • Configuration management documentation
      • Configuration item records document information about products
        • Status
        • Version
        • Variance
      • Product status account
        • State of all products
      • Daily log
        • Records problems and concerns that the project manager
          resolves informally. Where an issues requires formal
          consideration, it’s recorded in an issue report and
          documented in the issue register
        • Possible required actions
        • Significant events
    • Core activities of configuration management
      • Planning: level of control
      • Identification: products and sub-products
      • Control: configurations are baselined
      • Status accounting: recording and reporting of status of products
      • Verification: reviews and audits to make sure status = actual
    • How to deal with issues
      • Capture
        Issue is analyzed to see if it can be handled informally
      • Examine
        Impact analysis is carried out
      • Propose
        Weigh most appropriate actions against each other
      • Decide
        Make decision of most appropriate course of action
      • Implement
  • Progress
    • Establish mechanisms to monitor and compare real against planned
    • For each level of the project management team, level above can
      • Monitor progress
      • Compare achievements with plan
      • Review plan
      • Detect problems
      • Identify risks
      • Initiate corrective action
      • Authorize further work
    • Controls
      • Manage by exception
        Project board is only notified in case of exceptions to plan
      • Main controls
        • For project board
          • Authorization
          • Highlight reports
          • Exception reports
          • Issue reports
          • Exception assessments
        • For project manager
          • Authorization
          • Progress updates
          • Exception/changes
    • Define tolerances for
      • Time
      • Cost
      • Quality
      • Risk
      • Benefit
      • Scope
    • Avoids unnecessary communication if within tolerance limits
    • Tolerance limits are laid down by project board
    • Types of project stages
      • Management (cannot overlap)
      • Technical (may overlap)
    • Project shouldn’t stop while management stage runs
      To prevent this, management stages often overlap technical
      stages. Towards the end of one technical stage, the planning
      of the next technical stage is carried out as a management
      stage

1.5 Session 5: Processes

  • Process is an operation that transforms x into y
    • Takes inputs and produces outputs
    • Raw materials => industrial process => finished goods
    • Prince2 processes are management processes
      • Inputs is information and requests
      • Outputs is updated info and decisions
    • ISO9000 dictates that all major processes should be documented
      in a quality manual
  • Process model
    Show processes and input/output and how they’re related
  • Processes
    • Directing a project
      • Runs from starting up of project to close-down
      • Used exclusively by project board
      • Activities
        • Authorize initiation
        • Authorize project
        • Authorize stage or exception plan
        • Give ad-hoc direction
        • Authorize project closure
    • Starting up project
      • Makes up for lack of objectivity and planning at startup
      • Ensures that prerequisites for initiating project are in place
      • Input
        Project mandate
      • Output
        • Project brief
        • Project management team
        • Project approach
        • Plan for initiation stage
        • Lessons log
        • Daily log
      • Activities
        • Appoint executive and project manager
        • Capture previous lessons (learn from past projects)
        • Design and appoint project management team
        • Prepare outline business case
        • Select project approach and assemble project brief
        • Plan the initiation stage
    • Initiate project
      • Process is about ensuring that a firm baseline exists for project
      • Make sure everyone involved know what the project want to achieve
      • Input
        Input from starting up project
      • Output
        • Project initiation document (PID)
          Used as basis for project and updated at the end of each stage
        • PID contains details on
          • Project definition
          • Project approach
          • Business case
          • Project management team structure
          • Role descriptions
          • Management strategies
          • Project plan
          • Project controls
      • Activities
        • Prepare risk management strategy
        • Prepare configuration management strategy
        • Prepare quality management strategy
        • Prepare communication strategy
        • Set up project controls
        • Create project plan
        • Refine business case
        • Assemble project initiation document
      • PID and detailed plan for next stage is approved by project
        board at the end of the stage
    • Controlling a stage
      • Forms main part of project managers work
      • Activities
        • Capture and examine issues and risks
        • Escalate issues and risks activity
        • Take corrective action
    • Managing product delivery
      • Ensures that what should be produced is indeed produced
      • Progress must be reported to project manager
      • Carried out by the individual team member or team leader
      • Input
        Authorized work package
      • Output
        Signed-off product and progress reports
      • Activities
        • Accept work package
        • Execute work package
        • Deliver work package
    • Managing stage boundary
      • Process is directed at the project board
      • By focusing on start and finish, attention can be given to
        • Whether stage products have all been completed
        • Within valid tolerance
        • Whether remaining products are still required
        • Whether business case remains valid
      • Output
        • End stage report
        • Next stage plan
        • Request to board meeting to approve next stage plan
        • Feeds into authorize stage/exception plan activity
      • Activities
        • Plan the next stage
        • Update project plan
        • Update business case
        • Report stage end
        • Produce exception plan (only if project is in exception)
          Replaces Plan the next stage activity
    • Closing project
      • Executes controlled and orderly close regardless of circumstances
      • Normally carried out by project manager
      • Activities
        • Prepare planned closure
        • Prepare premature closure
        • Hand over products
        • Evaluate project
        • Recommend project closure
      • Inputs
        • Product status account
        • Project initiation document
        • Issue register
        • Risk register
        • Quality register
        • Lessons log

1.6 Session 6: Case study

1.7 Session 7: Exam technique

  • Goal of exam
    • Ensures that candidate can act as an informed member of project team
    • Tests whether candidate knows what’s contained in manual
  • Requirements
    • Understand purpose and responsibility of all roles
    • 7 principles, themes, and processes
    • Product-based planning and review technique
    • Which management products are input, output, and updated
      In the seven processes and their activities
    • Purpose of all management products and composition of business case
    • Relationship between principles, process, themes, deliverables, roles
  • Exam consists of 75 multiple choice questions, 1 hour allowed
  • 50% of questions must be correctly answered
  • Closed book exam
  • 95% pass at foundation level
  • 75-80% pass at practitioner level
  • Share/Bookmark

Leave a Reply

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>