http://www.tiddlywiki.com/
PrinceII Framework
Projects in a controlled environment
!~Starting-Up a Project\nNot to be confused with Initiating a Project, this process does the groundwork on which successful initiation depends. You'll need to do this to the extent necessary in your organisation to ensure that\n\n- you know who's on the [[Project Management Team]]\n\n- you know who the project manager is going to be, at least for the [[Initiation Stage]]\n\n- you know what the [[Project Brief]] is, so that everyone knows what project is going to be initiated in the initiation process.\n\n- you know how it's going to be done - the [[Project Approach]]\n\n- and there is a [[Business Case]] for the project\n\n- there is a [[Plan]] for the [[Initiation Stage]] of the project\n\nIn theory, this process should happen only as a result of a [[Project Mandate]] being produced by the business, setting out the reasons for doing the project and the expected outcome. In practice, the mandate may be no more than a memo or email, or may be a document which has done all the groundwork mentioned above. Somebody's got to do this work - to the extent necessary - and it's often the project manager who has to assemble all the elements.\n\nOnce all the elements are complete, they are passed to the project board for approval and their authorisation to proceed with [[Initiation]]\n\n
!Managing Stage Boundaries\nOne of the key principles of [[Prince2]] is that projects should be broken down into brain-sized chunks called '[[Stages]]'. However these stages are defined, the [[Managing Stage Boundaries]] process is the means by which the transition is made from one stage to the next, giving the organisation an opportunity to assess the continuing viability of the project against its business case.\n\nDuring this process, information supporting the proposition that the current stage is completing is collated, the detailed [[plan for the next planned stage]] is produced and the risks and business case are reassessed. Additionally, the high level project plan will be updated. This information will then be passed to the [[Project Board]] for approval of the [[next stage]].\n\nThe process will be entered [[one of two ways]] - either because the current stage is drawing to a close on successful completion, or because the [[Project Board]] has requested that an [[exception plan]] be produced, thus closing the current stage prematurely.\n\n
!Products of the Planning Process\nThe role of the [[Managing Stage Boundaries]] process is to ensure that the transition from one stage of the project to the next is properly controlled. At this time, a detailed plan must be produced for the next planned stage of the project which must be approved by the [[Project Board ]]before that stage can begin.\n\nTwo types of plan can be produced at this point:\n\n- a 'normal' plan for the next stage, produced when everything's going okay, and the previous stage has completed successfully\n\n- an 'exception' plan for recovery from an exception situation during a stage, for example an overspend which exceeds pre-defined [[tolerance]].\n\nDetailed plans for a stage must also include the plans for [[Quality Control]] of the products to be produced in that stage.\n\n
!Directing a Project\nThis process is where the [[Project Board]] do their work. They are responsible for:\n\n- approving the initiation of a project against a project brief, draft initiation stage plan and other documents produced during [[Starting Up a Project]]\n\n- approving the commencement of work on the project's deliverables against a Project Initiation Document produced during [[Initiating a Project]]\n\n- Monitoring the progress of a stage by reviewing Highlight reports, setting stage tolerances, providing ad-hoc guidance to the project manager, dealing with escalated issues and making decisions about exception situations arising during [[Controlling a Stage]]\n\n- approving the start of subsequent stages of work against updated plans and other information produced during [[Managing Stage Boundaries]]\n\n- approving the recommendation from the project manager to close down the project and ensuring this happens correctly during [[Closing a Project]]\n
!Products of the Controlling a Stage process\nThis link is really a control link rather than having specific products associated. It's the trigger to start planning for the next [[stage ]]in [[Managing Stage Boundaries]].\n\nThis will happen one of two ways:\n\n- because the current stage is ending successfully, so the detailed plan for the next stage has to be produced ready for [[Project Board]] approval prior to the next stage\n\n- or because the project board have asked for an exception plan to be produced, following the PM's [[escalation of an exception report]] in the current stage. \n\nEither way, the current stage is going to be shut down, and a new stage will begin.\n\n
!Products of the Controlling a Stage process\nVarious outputs from [[Controlling a Stage]] will need to make their way to the [[Project Board]] for review or decision making. These are:\n\n- Highlight Reports, summarising the current status of the stage\n\n- Escalated project issues or requests for advice from the Project Board for which the [[Project Manager]] needs 'ad-hoc' direction\n\n- Exception Reports, describing a situation which threatens the successful completion of the stage within [[tolerances]] previously set by the Project Board.\n
No work should happen on a Prince2 project until the [[Project Board]] has seen and approved this bunch of goodies, produced during the ~Starting-Up a Project process:\n\n- a properly constituted [[Project Brief]], setting out, amongst other things, the objectives and scope of the project, the deliverables, the outline business case, the acceptance criteria and an appreciation of the risks involved\n\n- a set of role and job descriptions for the project management team\n\n- an initial [[Risk Log]]\n\n- the [[Project Approach]] document, setting out how the project will be done\n\n- a plan for the project initiation stage of the project\n\n
!~Starting-Up a Project\nNot to be confused with [[Initiating a Project]], this process does the groundwork on which successful initiation depends. You'll need to do this to the extent necessary in your organisation to ensure that\n\n- you know who's on the [[Project Management Team]]\n\n- you know who the project manager is going to be, at least for the initiation stage\n\n- you know what the [[Project Brief]] is, so that everyone knows what project is going to be initiated in the initiation process.\n\n- you know how it's going to be done - the [[Project Approach]]\n\n- and there is a [[Business Case]] for the project\n\n- there is a plan for the initiation stage of the project\n\nIn theory, this process should happen only as a result of a [[Project Mandate]] being produced by the business, setting out the reasons for doing the project and the expected outcome. In practice, the mandate may be no more than a memo or email, or may be a document which has done all the groundwork mentioned above. Somebody's got to do this work - to the extent necessary - and it's often the project manager who has to assemble all the elements.\n\nOnce all the elements are complete, they are passed to the project board for approval and their authorisation to proceed with Initiation\n
!Closing a Project\nPrince2 projects have a beginning and a middle, and also an end. This process brings the project to a controlled close by\n\n*checking that everything's been done\n\n*ensuring that the products have been handed over to and approved by the customer\n\n*documenting any later actions that need to taken by others, such as maintenance and support groups\n\n*setting out a plan for the assessment of the achievement of the benefits described in the business case\n\n*compiling a final report on the performance of the project against its [[Project Initiation Document]]\n\n*finalising the [[lessons learned report]].\n\nand finally, requesting that the project be closed down by the [[Project Board]].
Product Based Planning is a key feature of Prince2, providing a focus on the products to be delivered and their quality. It forms an integral part of the Planning process and leads into the use of other generic planning techniques such as network planning and Gantt charts. Plans are produced in the planning process using this technique.\n\nThere are three elements to the Product Based Planning approach.\n\nThe first is the [[Product Breakdown Structure]] (PBS). This is a deliverable oriented, heirarchical structure (which is often termed a [[Work Breakdown Structure]] in non-Prince2 projects) which seeks to define the entire scope of the project as a set of products.\n\nThe second element is the [[Product Description]], which specifies a product in the PBS. This Product Description dcescribes not just the deliverable, but also the quality criteria and method by which it will be accepted. The Product Description is a key feature of the quality approach in a Prince2 project.\n\nThe third element, the [[Product Flow Diagram]] shows the sequence of development of the Products in the PBS, helping to ensure that all items are identified in the scope and assisting in the development of project, stage and activity plans. (For those not familiar with Prince2, it is an intermediate step between Work Breakdown Structure and Activity Networking in an overall planning process).\n\n
!Managing Product Delivery\nThis is where the work is done in a Prince2 project, either by in-house teams or subcontractors. Once a [[Work Package]] is received, the deliverable defined in the work package is produced according to the agreed plan under the management of a [[Team Manager]] (in Prince2 terminology).\n\nThis process deosn't define the methodology by which the products should be produced. It may be, for example, that a subcontractor doesn't use Prince2 at all. Prince2 therefore only defines the interfaces of [[Work Package]] input, the production of [[Checkpoint Report]], and the return of the completed product.
A progress report of the information gathered at a checkpoint meeting, which is given by a team to the [[Project Manager]] and provides reporting data as defined in the [[Work Package]].
Part of the [[Project Initiation Document]] describing how the project’s stakeholders and interested parties will be kept informed during the project.
An item that the project has to create as part of the requirements. It may be part of the final outcome or an intermediate element on which one or more subsequent deliverables are dependent. According to the type of project, another name for a deliverable is ‘[[product]]’.
A report given by the [[Project Manager]] to the [[Project Board]] at the end of each management stage of the\nproject. This provides information about the project performance during the stage and the project status at stage end.
The review by the [[Project Board]] and [[Project Manager]] of the [[End Stage Report]] to decide whether to approve\nthe next [[Stage Plan]] (unless the last stage has now been completed). According to the size and criticality of the project, the review may be formal or informal. The approval to proceed should be documented as an important management product.
Report from the [[Project Manager]] to the [[Project Board]] on a time-driven frequency on stage progress.
A log of all [[Project Issues]] including requests for change raised during the project, showing details of each issue, its evaluation, what decisions about it have been made and its current status.
That which must be done to bring about a particular outcome, in terms of information to be gathered,\ndecisions to be made and results that must be achieved.
A report that describes the lessons learned in undertaking the project and that includes statistics from the [[quality control]] of the project’s management products. It is approved by the [[Project Board]] and then held centrally for the benefit of future projects.
Something that should be provided by the project, but currently is not (or is forecast not to be) provided. This might be a missing product or a product not meeting its specification.
Any input to or output from a project. PRINCE2 distinguishes between management products (which are produced as part of the management or quality processes of the project) and specialist products (which are those products that make up the final deliverable). A product may itself be a collection of other products.
A list of the major products of a plan, plus key dates in their delivery.
The Project Board’s responsibilities to assure itself that the project is being conducted correctly.
A description of what the project is to do; a refined and extended version of the [[Project Mandate]], which has been agreed by the [[Project Board]] and which is input to project initiation.
Notification prepared by the [[Project Manager]] for the [[Project Board]] to send (when the board is satisfied that the project can be closed) to any organisation that has supplied facilities to the project.
A logical document which brings together the key information needed to start the project on a sound basis\nand to convey that information to all concerned with the project.
A term used to cover either a general issue, query, a [[Request for Change]], suggestion or [[Off Specification]]\nraised during a project. Project Issues can be about anything to do with the project.
The person given the authority and responsibility to manage the project on a day-to-day basis to deliver the required products within the constraints agreed with the [[Project Board]].
A high-level plan showing the major products of the project, when they will be delivered and at what cost. An initial Project Plan is presented as part of the [[Project Initiation Document]]. This is revised as information on actual progress appears. It is a major control document for the [[Project Board]] to measure actual progress against expectations.
A plan defining the key quality criteria, quality control and audit processes to be applied to project\nmanagement and specialist work in the PRINCE2 project. It will be part of the text in the [[Project Initiation Document]].
A quality review is a quality checking technique with a specific structure, defined roles and procedure designed to ensure a product’s completeness and adherence to standards. The participants are drawn from those with an interest in the product and those with the necessary skills to review its correctness. An example of the checks made by a quality review is ‘Does the document match the quality criteria in the [[Product Description]]?’
A means of proposing a modification to the current specification of a product. It is one type of [[Project Issue]].
A role that may be employed by the [[Project Manager]] or a specifically appointed alternative person to manage the work of project team members.
A document that provides identification, estimation, impact evaluation and countermeasures for all risks to the project. It should be created during the start-up of the project and developed during the life of the project. Also known as Risk Register.
The permissible deviation above and below a plan’s estimate of time and cost without escalating the deviation to the next level of management. Separate tolerance figures should be given for time and cost. There may also be tolerance levels for quality, scope, benefit and [[risk]]. Tolerance is applied at project, stage and team levels.
The set of information relevant to the creation of one or more products. It will contain the [[Product\nDescription]](s), details of any constraints on production such as time and cost, interfaces and confirmation of the agreement between the [[Project Manager]] and the person or [[Team Manager]] who is to implement the Work Package that the work can be done within the constraints.
!Organisation\n!!The Project Board\nThe Project Board comprises three roles which together provides the decision making body for the project, and which delegates the day-to-day running of stages of the project to a [[Project Manager]]. The roles on the board are:\n\n!!!The Executive\nThe 'owner' of the [[Business Case]] for the project and the final decsion maker on the board (it's not a democracy!). The executive is accountable to the business for the success of the project. The Executive is supported by the Senior User and the Senior Supplier.\n\n!!!The Senior User\nThe Senior User is responsible for specification of the user requirement, for user liason with the project team and for ensuring that the final product will meet the needs of the users within the constraints of the business case.\n\n!!!The Senior Supplier\nThe Senior Supplier represents the interests of those who are producing the products meeting the [[Business Case]], and is accountable for the quality of the deliverables.\n
[[Crazy Colour|http://www.crazycolour.com/p2/]]
A portfolio of projects selected, planned and managed in a co-ordinated way.\n\n!When are Programmes Established?\nProgrammes are established when: \n#there are inter-dependencies between projects \n#two or more projects need to use the same resource(s) \n#a group of projects are working towards the same overall objective.\n\n!!What is Programme Management?\nProgramme Management brings together related projects to manage their interdependencies. The OGC's "Managing Successful Programmes" method provides and maintains a strategic view over the set of projects, aligning and co-ordinating them within a programme of business change in support of specific business strategies. Programme Management provides the framework for implementing business strategies and initiatives, or large scale change, where there is a "vision" of the programme's outcome - a transformed organisation for example. The path to achieving the vision may be full of complexities and may change direction. Programme Management helps to organise, manage, accommodate and control these changes so that the eventual outcome meets the objectives set by the business strategy.\n\n!!Advantages of Programme Management\nHere are just some of the advantages of using Programme Management: \n#Improved co-ordination and control over projects \n#benefit realisation \n#transition of project products (outputs) to operational use \n#quality, risks, issues and conflicts \n#business objectives \n#stakeholders \n#Scheduling projects optimises the use of resources\n#Takes advantage of economies of scale \n#Lessons learned are captured & shared
[[PRINCE2]]
*basis for project management control throughout a stage \n*includes, Baseline, Tolerance, quality controls, objectives and what products are to be produced \n*main components include: \n**plan description including approach \n**[[Project Quality Plan]]\n**prerequisites \n**[[tolerances]] (time and budget)\n**reporting, monitoring\n**graphical plans (including GANTT Chart, activity network, Product Flow Diagram and Product Breakdown Structure) \n**[[Product Description]]s\n*created from the [[Project Plan]]\n*updated during CS2, SB5 and CS7
No work on the project's deliverables is done in Controlling a Stage - it's all done in Managing Product Delivery. One of the tasks of the Project Manager in [[Controlling a Stage]] is to ensure that the work is properly authorised.\n\nThis is done by passing a Work Package to the manager, maybe a Team Leader or external subcontractor, responsible for carrying out the work and delivering the completed product back to the project manager.\n\nThe [[Work Package]] will vary in content and formality according to the circumstances, but it should describe the complete relationship between the project manager and the manager responsible for delivery of the product, the detailed responsibilities of the supplier and of course should include the [[Product Desccription]] of the deliverable to be provided. Additionally, the Work Package should be associated with a detailed team level plan which is agreed with the [[Project Manager]].
!Controls - Stages\nStages are a key [[control]] of a Prince2 project. Every project has at least two - [[initiation]] and the rest of the work. (Interestingly, [[closedown]] is not regarded as a stage).\n\nStages are partitions of a project with decision points, often called 'firebreaks', and relate to management rather than technical stages. These firebreaks create an opportunity for the [[project management team]] to plan the next stage in detail, re-assess the [[business case]] and the [[risks], and make a conscious decision to carry on pumping money and resources into the project.\n\nThe first of these decision points will be at the end of [[initiation]], when the [[Project Initiation Document]] is reviewed, and the decision is made to proceed with the work. At this point, the planned stages of the project can be agreed. Subsequent decision points occur at the end of each stage of the project, based on input of the [[end stage report]] and [[next stage plan]] produced by the project manager in [[Managing Stage Boundaries]]. Transition from stage to stage is therefore a key control of the project board.\n\nThere are no specific rules for how to define stages in a project. They should be set according to the size, risk and complexity of the project and an assessment of how far ahead it is sensible to plan in detail.\n\n
A prioritised list of criteria that the final product(s) must meet before the customer will accept them; a measurable definition of what must be done for the final product to be acceptable to the customer. They should be defined as part of the [[Project Brief]] and agreed between customer and supplier no later than the [[Project Initiation Stage]]. They should be documented in the [[Project Initiation Document]].
!Change Control\nEvery project must have processes in place to manage the inevitable changes which will occur, for example to the scope (often called ''scope creep'').\n\nPrince2 change control is based on the collection of project issues and the categorisation of these issues as\n\n*[[Request for Change]], causing a change to specification or [[Acceptance Criteria]], which will be funded usually by the customer\n\n*[[Off Specification]], covering errors or omissions to implementation against a previously agreed product description, the correction of which will usually be funded by the supplier\n\n*or none of the above\n\nThe component deals also with authority levels for change and discusses the use of change budgets.
A situation where it can be forecast that there will be a deviation beyond the tolerance levels agreed between [[Project Manager]] and Project Board (or between [[Project Board]] and corporate or [[programme management]], or\nbetween a [[Team Manager]] and the Project Manager).
A report that describes an exception, provides an analysis and options for the way forward and identifies a recommended option. The [[Project Manager]] presents it to the [[Project Board]].
This is a plan that often follows an [[Exception Report]]. For a [[Stage Plan]] exception, it covers the period from the present to the end of the ''current stage''. If the exception were at a project level, the [[Project Plan]] would be replaced.
!What is PRINCE2?\n\n[img[Prince2 Logo|http://www.prince2.org.uk/Web/MultimediaFiles/LOGO_PRINCE2.GIF]]\n\nBefore we go into the specifics of PRINCE2, there are some general points about the subject of project management, which should help put everything into context...\n\n!Why project management is important\nWhenever we decide we want to do something, go somewhere, build something, achieve something, we need to know the answer to some questions. What are we trying to do? When will we start? What do we need? Can we do it alone, or do we need help? How long will it take? How much will it cost? These are typical questions asked at the start of any project and the answers are the building blocks of project management - defining what we want to do and working out the best way we can do it.\n\nStructured project management means managing the project in a logical, organised way, following defined steps. A structured project management method is the written description of this logical, organised approach. PRINCE2 is a structured project management method.\n\nWe have briefly covered what structured project management, and hence PRINCE2, are all about. Now for some more details about the PRINCE2 method.\n\n!Coverage of PRINCE2\nPRINCE2 says that a project should have:\n\nAn organised and ''controlled start'', ie organise and plan things properly before leaping in; \nAn organised and ''controlled middle'', ie when the project has started, make sure it continues to be organised and controlled; \nAn organised and ''controlled end'', ie when you’ve got what you want and the project has finished, tidy up the loose ends. \nIn order to describe what a project should do when, PRINCE2 has a series of processes which cover all the activities needed on a project from starting up to closing down.\n\nOrganising and controlling a project means that we need to have someone responsible for doing the organising and controlling - this person is called the [[Project Manager]]. The [[Project Manager]] will select people to do the work on the project and will be responsible for making sure the work is done properly and on-time. The [[Project Manager]] draws up the [[Project Plan]]s that describe what the project team will actually be doing and when they expect to finish.\n\n
!Quality in a project Environment\nThe esence of the quality approach in Prince2 is 'fitness for purpose', achieved through combining the customer's [[quality expectations]], and the means to achieve them, with the existing quality policy, processes and procedures of the organisation into a [[Quality Plan]] which will set out the project's approach to quality. The approach is based on four elements:\n\n*A quality system, comprising an organisation structure, processes and procedures, which may exist on both customer and supplier side of the project. One or other can be chosen as the basis for the project quality plan, or a combination of the two.\n\n*A [[Quality Assurance]] (QA) function which creates and maintains the quality system, for example an internal QA department, and which monitors the implementation of a project's quality plan. \n\n*[[Quality Planning]], based on understanding of the customer's quaality expectations in Starting Up a Project, and a Quality Plan produced as the first step in Initiating a Project. The quality plan produced here will inform the planning of the project from that point on.\n\n*[[Quality Control]], which is the means by which products are checked for compliance to their [[Product Description]]s, the plans for which are elaborated when constructing the detailed [[Stage Plan]]s.
A description of a product’s ''purpose, composition, derivation and quality criteria''. It is produced at planning time, as soon as the need for the product is identified.
!Product Based Planning\nA ''hierarchy'' of all the products to be produced during a plan.\n\n''Product Based Planning'' is a key feature of Prince2, providing a focus on the products to be delivered and their quality. It forms an integral part of the Planning process and leads into the use of other generic planning techniques such as network planning and Gantt charts. Plans are produced in the planning process using this technique.\n\nThere are three elements to the Product Based Planning approach.\n\n*The first is the ''Product Breakdown Structure'' (PBS). This is a deliverable oriented, heirarchical structure (which is often termed a Work Breakdown Structure in non-Prince2 projects) which seeks to define the entire scope of the project as a set of products.\n\n*The second element is the [[Product Description]], which specifies a product in the PBS. This Product Description dcescribes not just the deliverable, but also the quality criteria and method by which it will be accepted. The Product Description is a key feature of the quality approach in a Prince2 project.\n\n*The third element, the [[Product Flow Diagram]] shows the sequence of development of the Products in the PBS, helping to ensure that all items are identified in the scope and assisting in the development of project, stage and activity plans. (For those not familiar with Prince2, it is an intermediate step between [[Work Breakdown Structure]] and Activity Networking in an overall planning process).
A diagram showing the sequence of production and interdependencies of the products listed in a [[Product\nBreakdown Structure]].\n\n[[See Product Breakdown Structure|Product Breakdown Structure]]
!SU Starting Up a Project\nPRINCE2's first process, after SU, and upon approval by the Project Board, the project has commenced \n*SU1 Appointing a Project Board Executive and a Project Manager\nSub-process 1 in Starting Up a project primarily to appoint the Executive and Project Manager \n*SU2 Designing a Project Management Team\nSub-process 2 in Starting Up a project primarily to design the Project Management Team Structure \n*SU3 Appointing a Project Management Team\nSub-process 3 in Starting Up a project primarily to appoint and confirm responsibilities to the PM Team \n*SU4 Preparing a Project Brief\nSub-process 4 in Starting Up a project primarily to prepare a brief \n*SU5 Defining Project Approach\nSub-process 5 in Starting Up a project primarily to produce the Project Approach document \n*SU6 Planning an Initiation Stage\nSub-process 6 in Starting Up a project primarily to create the Initiation Stage Plan \n!IP Initiating a Project\nIP lays the foundations for the project, it includes planning, cost analysis, evaluating the Business Case and finally producing a PID \n*IP1 Planning Quality\nSub-process 1 in Initiating a Project, primarily to create the Project Quality Plan \n*IP2 Plan a Project\nSub-process 2 in Initiating a Project, primarily to create the Project Plan \n*IP3 Refine Business Case and Risks\nSub-process 3 in Initiating a Project, primarily to assess risks and the Business Case relative to the current Project Plan \n*IP4 Setup Project Controls\nSub-process 4 in Initiating a Project, primarily to create the Communication Plan and Project Controls \n*IP5 Setup Project Files\nSub-process 5 in Initiating a Project, primarily to put in place a filing system \n*IP6 Assembling a PID\nSub-process 1 in Initiating a Project, primarily to create the Project Initiation Document \n!DP Directing a Project\nWhere senior project management staff exercise overall control and make key decisions, this runs from Start Up (SU) till the project closure. \n*DP1 Authorising Initiation\nRatify the Project Brief, approve the plan to produce the PID and thereby commit resources. \n*DP2 Authorising a Project\nSubmit a draft PID using the Project Brief as a base once approved the project just needs the first stage authorised to start \n*DP3 Authorising a Stage or Exception Plan\nAuthorising a Stage or Exception Plan \n*DP4 Giving ad hoc Direction\nProject Boards should be available for informal discussions about the state of a project or questions that may arise. \n*DP5 Confirming Project Closure\nOnce either the last Stage, or an Exception Plan is completed is necessary to ensure a clean, orderly closure to a project. \n!CS Control Stage\nCovers the control and monitoring that the Project Manager has over the Team Managers and overall project, with regular reporting to the Project Board. \n*CS1 Authorising a Work Package\nDecision and control point to ensure that work is accurately represented before commencing it. \n*CS2 Assessing Progress\nCreate Checkpoint Report with resource and progress reports from the Team Managers, thereby updating the Stage Plan. \n*CS3 Capturing Project Issues\nEnsures that Project Issues are dealt with constantly and if necessary lead to Request for Change or Off-specification Request. \n*CS4 Examining Project Issues\nOn a regular basis examine those Issues captured in CS3 and update logs as required. \n*CS5 Reviewing Stage Status\nThe Project Manager must spend time reviewing external events to ensure the project (stage) does not get out of control. \n*CS6 Reporting Highlights\nTo create Highlight Report for the Project Board, at a required interval specified by the Communication Plan. \n*CS7 Taking Corrective Actions\nResolve deviations from the set Stage Plan and identify the cause and effect of these. \n*CS8 Escalating Project Issues\nOnce an issue has been forecast to go beyond tolerances complete impact analysis is required resulting in an Exception Report. \n*CS9 Receiving Completed Work Package\nThe Work Package is checked and then, if it meets all specification is approved. \n!MP Managing Product Delivery\nCovers those responsibilities the Team Manager has from accepting a work package to delivering the final product back. \n*MP1 Accepting a Work Package\nBy the Team Manager from the Project Manager confirming the constraints and details of the product. \n*MP2 Executing a Work Package\nEncompasses the creation of the product as specified in the Work Package, this process may or may not include PRINCE2 methodology. \n*MP3 Delivering a Work Package\nThe process by which a Work Package (WP) is completed - the Team Manager ensures that the WP is handed over to the Project Manager. \n!SB Managing Stage Boundaries\nProcesses for the Project Manager to ensure the Stage has been completed, all plans have been correctly updated and the Business Case is still intact. \n*SB1 Planning a Stage\nCreate next Stage Plan including dates, costs and quality requirements. \n*SB2 Updating a Project Plan\nSequence of updating the Stage, Exception and Quality Plan while updating the Project Plan. \n*SB3 Updating a Project Business Case\nUpdate the Business Case with costs, benefits and timings to reflect the recent Stage End and the updated Project Plan. \n*SB4 Updating the Risk Log\nAnalysis and updated when a risk has increased, decreased, disappeared or stayed the same. \n*SB5 Reporting Stage End\nTo give a report to the Board about the end of a Stage (or just before an Exception Plan). \n*SB6 Producing an Exception Plan\nThe result of a Stage or the whole plan exceeding tolerances, usually picked up at the process Controlling a Stage. \n!PL Planning\nAs PRINCE2 is a product based methodology 'what' is to be produced defines its success, planning is the process to identify the product to be produced. \n*PL1 Designing a Plan\nBased on the Project Approach and using planning tools and estimation a Plan Design is be produced. \n*PL2 Defining and Analysing Products\nProduce a ordered sequence of all products required by the project to achieve its objective. \n*PL3 Identifying Activities and Dependencies\nEnsure interdependencies between activities are sequenced and dealt with appropriately. \n*PL4 Estimating\nOutline all assumptions and margins of error when estimating the resources and time required for each activity in the project. \n*PL5 Scheduling\nComplete process where by activity resources are allocated, agreed upon and the schedule is updated. \n*PL6 Analysing Risks\nUse risk management techniques to evaluate each resource. \n*PL7 Completing a Plan\nLists products to be produced within a stage plan. \n!CP Closing a Project\nProjects should be finite - without a clear Project closure there is a tendency to drift into operational management. \n*CP1 Decommissioning a Project\nNotify, hand over and create Status Account, ensure acceptance by both Customer and Supplier that the project is about to close. \n*CP2 Identifying Follow-on Actions\nCreate Post Project Review plan and document Follow-on Actions. \n*CP3 Project Evaluation Review\nAssess the project's results, quality of management and quality of risk and quality management.
Information created ''externally'' to the project, which forms the terms of reference and is used to start up the PRINCE2 project.\n\nUse the Project Mandate to: \n*confirm that the project is ''worthwhile''\n*define ''responsibilities and roles''\n*create the [[Initiation Stage Plan]] to enter IP [[Initiating a Project]]\n*provide information for the [[Project Brief]]\n*establish the [[Project Approach]]\n*design and appoint the [[Project Management Team]]\n*create the [[Stage Plan]]\n*help in setting up the [Risk Log]]
Organisation of the project management team is crucial to a successful project. Prince2 suggests an organisation structure and a set of [[roles]] which ensures that the ''interests of the Business'', the ''User'' and the ''Supplier'' are represented during the project, and which supports the concepts of management by exception. In this structure, roles for decision making are clearly defined, and the lines of ''authority'' are clearly delineated.
*produced in the process SU5 Defining Project Approach\n*type of solution (bespoke, contracted, ready made) \n*''reason'' for the approach\n*derived from the [[Project Brief]] and sometimes supplied by the Programme
A report given by the [[Project Manager]] to the [[Project Board]], that confirms the hand-over of all //products// and provides an updated [[Business Case]] and an assessment of how well the project has done against its [[Project Initiation Document]].
The single individual with ''overall responsibility'' for ensuring that a project or programme meets its objectives and delivers the projected benefits. This individual should ensure that the project or programme maintains its business focus, that it has clear authority and that the work, including risks, is actively managed. The chairperson of the [[Project Board]], representing the customer and owner of the [[Business Case]].
A report that can be used as input to the process of creating a [[Business Case]]/[[Project Mandate]] for any follow on PRINCE2 project and for recording any follow on instructions covering incomplete products or outstanding issues. It also sets out ''proposals'' for ''post-project review'' of the project’s products.
!Configuration Management\nConfiguration Management is the discipline of ''managing the assets'' of a project to ensure that they are specified, ''tracked''' and ''controlled''. A configuration management system should be able to handle ''version control'' and ''change control'' of individual products, the baselining of groups of products, product identification schemes and the audit trail of products from concept to implementation.\n\nWithout a configuration management system, any non-trivial project will quickly slide into chaos!\n\nIn Prince2, configuration management is described as five basic functions of\n\n*Planning of the configuration management processes and procedures for the project\n\n*Setting up of an ''identification scheme''\n\n*Control of products through mechanisms to protect against unauthorised change, and to track authorised change\n\n*Status accounting of the audit trail of each product\n\n*Verification of products and baselines to ensure that the configuration management system accurately reflects the true situation.\n\nThe means by which this is achieved on a Prince2 project should be defined in a Configuration management Plan, part of the project [[Quality Plan]]
Not to be confused with [[Initiating a Project]], this process does the groundwork on which successful initiation depends. You'll need to do this to the extent necessary in your organisation to ensure that\n\n- you know who's on the [[Project Management Team]]\n\n- you know who the project manager is going to be, at least for the initiation stage\n\n- you know what the Project Brief is, so that everyone knows what project is going to be initiated in the initiation process.\n\n- you know how it's going to be done - the [[Project Approach]]\n\n- and there is a [[Business Case]] for the project\n\n- there is a plan for the initiation stage of the project\n\nIn theory, this process should happen only as a result of a Project Mandate being produced by the business, setting out the reasons for doing the project and the expected outcome. In practice, the [[mandate]] may be no more than a memo or email, or may be a document which has done all the groundwork mentioned above. Somebody's got to do this work - to the extent necessary - and it's often the project manager who has to assemble all the elements.\n\nOnce all the elements are complete, they are passed to the project board for approval and their authorisation to proceed with Initiation
Following [[Starting up A Project]], the [[Project Board]] will have approved the [[Project Brief]] and other products, and will authorise the initiation stage of the project according to the [[Draft Initiation Stage Plan]]. Now the detailed planning of the project can start.\n\nThe first step will be the planning of the [[quality systems]] which will be used on the project, aligned with both the customer's quality expectations and any internal or external quality standards to which the organisation adheres. This is necessary so that a [[project plan]] can be produced - clearly a plan for a quick-and-dirty project is a different proposition to one for a mission-critical core system development.\n\nThe outline business case must also be developed to the point where it will support a decision to proceed further with the project, and the [[risk]]situation must be comprehensively understood.\n\nInitiation of a project will also include administrative planning of how the project will be controlled and setting up of project filing systems.\n\nAll of these plans and information is then collated into a [[Project Initiation Document]] for approval by the [[Project Board]].\n\n*forms a contract between the [[Project Manager]] and the [[Project Board]] cementing the understanding of what will be delivered, how, by when and by whom \n*first step to helping the Project Board to take ownership of the project \n*defines how [[quality]] will be achieved \n*creates a plan to react to a Customer's quality expectations \n*at each relevant point consider the Programme as a whole
Every project depends on ''planning'', and of course a Prince2 project is no different. The process of planning is well defined in the Prince2 methodology, using the usual planning suspects of work breakdown, activity networking and scheduling. In Prince2, the method of work breakdown is the [[Product Breakdown Structure]], essentially the same as a deliverable oriented [[Work Breakdown Structure]], supplemented by the [[Product Flow Diagram ]](PFD). The PFD allows a high-level structure for the project plan to be agreed at the deliverable level, which could be described as a milestone-led approach. It's useful stuff, and when pragmatically integrated with your existing planning approach can deliver great benefits in the (often badly done) scope definition phase of planning.\n\n''Planning'' is also closely integrated with the [[Quality]] systems, with the methodology defining the production of the [[Product Description]] as a product of the process. Together, the Product Breakdown, Product Descriptions and Product Flow create an effective (and necessary!) scope definition prior to commitment of resources to the project.\n\nDon't confuse this process with the Prince2 component 'Plans', which are a product of Planning, or 'stages', which define a Prince2 planning principle explored in the 'Controls' component.\n
Risk will be a factor in any project, and the Prince2 component sets out the principles of management of risk, aligning best practice to the roles of project board, project manager and others within the project management team. The principles described in the Prince2 component are also very much aligned with the latest [[Office of Government Commerce]] guidance on Management of Risk. \n\nA typical management approach is advocated, based on two activity groups of Risk Analysis and Risk Management.\n\nResponsibilities for risk in Prince2 are clearly defined:\n\n*The project manager is responsible for ensuring that risks are identified, recorded and regularly reviewed\n\n*The project board is responsible for\n\n**Notifying the project manager of external risk exposure to the project\n\n**Making decisions on the project manager's recommended responses to risk\n\n**Balancing the overall project risk and benefit levels\n\n**Ensuring the business is aware of risk exposure that may threaten business objectives.\n\nPrince2 emphasises that management of risk is a full [[lifecycle]] activity, but nevertheless defines specific points in the Prince2 process model at which the subject needs to be explicitly looked at.\n\n
The Business Case lies at the heart of any Prince2 project. It is a description of the reasons for the project and the justification for doing it, based on an appraisal of the ''costs'' and ''benefits'' (both tangible and intangible) and the risks.\n\nPrince2 doesn't define the exact format of the business case - this will be a standard within the organisation. Any business case should, however, contain at least the following sections:\n\n- The reasons for the project\n\n- An appraisal of the different options to achieve the business benefit, and the reasons why the chosen option is selected\n\n- Identification of the tangible and intangible benefits\n\n- an appraisal of the risks involved\n\n- an analysis of the expected costs and timescales\n\n- an [[Investment Apprasial]].\n\nThe business case should exist throughout the project lifecycle, and be regularly re-appraised so as to answer the question 'Do we still have a viable and worthwhile project?' At the very least, Prince2 would expect busines case activity at these points:\n\nDuring [[Starting Up a Project]], during [[Initiating a Project]], during [[Managing Stage Boundaries]], during [[Controlling a Stage|Stages]] when analysing the impact of issues, and during [[Closing a Project]] to help inform the post-project review planning.
[[Overview]]\n[[Business Case]]\n[[Starting a project]]\n[[Initiating a Project]]\n[[Planning]]\n[[Change Control]]\n[[Risk]]\n[[Quality]]\n[[Config Mgmt]]\n\n----\nJonathan Camp\n2005\n----\n[[Programme Management]]\n[[Links]]\n\n<<newTiddler>>\n<<newJournal "DD MMM YYYY">>
#tiddlerNotes .title {background-color: #FFCD62; color: #6A6A6A}\ndiv[tags~="todo"].viewer {background-color: #FFF5DC;}\nhr { border: none; border-top: dotted 1px #777; height: 1px; color: #777;margin: 7px 0;}\nbody {font: 13px/125% "Lucida Grande", "Trebuchet MS", "Bitstream Vera Sans", Verdana, Helvetica, sans-serif;}\n#popup { background-color: #4275A8; color: #FFF;border-right: 2px solid #BCBCBC;border-bottom: 2px solid #BCBCBC;}\n#popup a {color: #EEE;}\n#popup a:hover {background-color: #6699CC;color: #FFF;}\n.toolbar {position:relative;top:19px;left:-1px;border-bottom: 2px solid #DCDCDC;border-right: 2px solid #DCDCDC; background-color: #EEE; color:#000; height:16px;padding-top:2px;margin-left:250px;padding-right:0}\n.toolbar A{color: #4275A8;}\n.toolbar A:active {color: #ffffff;background-color: #4275A8;}\n.toolbar A:hover {color: #ffffff;background-color: #6699CC;}\n.toolbar #popup {background-color: #4275A8; color: #FFF;border-right: 2px solid #BCBCBC;border-bottom: 2px solid #BCBCBC; width:50%}\n.toolbar #popup a {color: #EEE;}\n.toolbar #popup a:hover {background-color: #6699CC;color: #FFF;}\n.tiddler .button:active {background-color: #FFF;color: #4275A8;}\n.tiddler .button {color: #6699CC; border-left: 1px solid #CFCFCF; border-right: 2px solid #CFCFCF;border-top: 1px solid #CFCFCF; border-bottom: 2px solid #CFCFCF;}\n.tiddler .button:hover {background-color: #6699CC;color: #FFF; border-right: 1px solid #CFCFCF; border-left: 2px solid #CFCFCF;border-top: 2px solid #CFCFCF; border-bottom: 1px solid #CFCFCF;}\n.selectedTiddler {padding: 0px 2px 0px 2px;}\n.unselectedTiddler {padding: 0px 2px 0px 2px;}\n#messageArea {border: 1px solid #DCDCDC; background-color: #D6E7FF; color: #000000;}\n#messageArea a:link, #messageArea a:visited {color: #4275A8;}\n#messageArea a:hover {color: #FFF;background-color: #4275A8;}\n#messageArea a:active {color: #4275A8;}\n#mainMenu {width: 11em;border: 1px solid #555;background-color:#EEE;padding-top:0px;color:#4275A8;font-size: 9pt;}\n#mainMenu .tiddlyLink {color: #4275A8;}\n#mainMenu h1 { font-size:11pt;}\n#mainMenu h1 .tiddlyLink{ font-size:11pt;color:#FFF}\n#mainMenu h2 { font-size:10pt;}\n#mainMenu h2 .tiddlyLink { font-size:10pt;color:#FFF}\n#mainMenu .tiddlyLink:hover {background-color: #4275A8;color: #ffffff;}\n#mainMenu .externalLink:hover {background-color: #4275A8;color: #ffffff; text-decoration: underline;}\n#mainMenu .externalLink{color: #4275A8;text-decoration: none}\n#mainMenu table {font-size:7pt;}\n#titleLine {color: #ffffff; background-color: #6699CC; padding: 5px;padding-top:15px}\n\n.editor input {font-family: Courier, MS Courier New, Prestige, Everson Mono; background:#ffe; border:solid #aa9 2px; margin:4px; font-size: 8pt;}\n.editor textarea {font-family: Courier, MS Courier New, Prestige, Everson Mono; background:#ffe; border:solid #aa9 2px; margin:4px; font-size: 8pt; height: 350;}\n\n.title {font-size: 10pt; font-weight: bold; background-color:#DCDCDC; color:#4275A8;display:inline;margin:0px;padding-left:30px;padding-right:30px;}\n.viewer h1,h2,h3,h4,h5,h6 {background-color: #D6E7FF; color:#000000; text-align:left}\n.viewer{padding:10px;border: 1px solid #DCDCDC;background-color:#F2F2F2;z-index: -2;}\n.viewer a:link, .body a:visited {text-decoration: none; color: #4275A8;}\n.viewer a:hover { color: #ffffff; background-color: #4275A8;}\n.viewer table {border-collapse: collapse;border: 2px solid #303030; font-size: 11pt; margin: 5px;}\n.viewer th {background: #DEDEDE;border: 1px solid #aaa;color:#000;padding: 3px; font-size: 11pt}\n.viewer td {border: 1px solid #aaa;padding: 3px; font-size: 11pt}\n.viewer caption {padding: 3px; font-size: 11pt}\n.viewer hr { border: none; border-top: dotted 1px #777; height: 1px; color: #777;margin: 7px 0;}\n.viewer pre { border:1px solid #CBCBCB; margin:5px;padding: 2px;background: #EAEAEA;color:#3C6FA2;}\n.viewer code {background: #EAEAEA;color:#3C6FA2;}\n.viewer input { border: 0px solid black;color:#4275A8;}\n.viewer #popup {background-color: #4275A8; color: #FFF;border-right: 2px solid #BCBCBC;border-bottom: 2px solid #BCBCBC;}\n.viewer #popup a {color: #6699CC;}\n.viewer #popup a:hover {background-color: #6699CC;color: #FFF;}\n.viewer .button {background-color: transparent;}\n.viewer .button:active {background-color: #FFF;color: #4275A8;}\n.viewer .button:hover {background-color: #6699CC;color: #FFF;}\n.sparkline {background-color: transparent;border: none;}\n.sparktick {background-color: #6699CC;outline: 0;}\n#sidebar {float: right; width: 16em;background-color:#EEE;color: #000;font-size: 8pt;border: 1px solid #555;}\n#sidebar input { border: 1px solid black;background-color:#FFF; color:#4275A8;}\n#sidebar a {color: #4275A8;}\n#sidebar a:active {background-color: #FFF;color: #4275A8;}\n#sidebar a:hover {background-color: #6699CC;color: #FFF;}\n\n#sidebar table { border: 1px solid #EAEAEA; border-collapse: collapse; color: #000000; font-size: 10px; margin-left: 1em; padding: 1px;}\n#sidebar th { border: 1px solid #EAEAEA; font-size: 10px; color: #000000; background-color: #D6E7FF; padding: 1px;}\n#sidebar td, tr { border: 1px solid #EAEAEA; font-size: 10px; color: #000000; padding: 2px;}\n\n#sidebarOptions {padding-top: 3px; background-color: #FBFBFB;color:#000;}\n#sidebarOptions .button {color: #6699CC;}\n#sidebarOptions .button:active {background-color: #FFF;color: #4275A8;}\n#sidebarOptions .button:hover {background-color: #6699CC;color: #FFF;}\n#sidebarOptions .sliderPanel {background-color:#DCDCDC;}\n#sidebarOptions .sliderPanel A {color: #4275A8;}\n#sidebarOptions .sliderPanel A:active {color: #FFF;background-color: #4275A8;}\n#sidebarOptions .sliderPanel A:hover {color: #FFF;background-color: #6699CC;}\n.sidebarSubHeading {font-size: 7pt;color: #FBFBFB;}\n#sidebarTabs { color: #000; background-color: #FBFBFB; padding: 0px 3px 3px 3px;}\n#sidebarTabs a {color: #4275A8;}\n#sidebarTabs a:hover {color: #FFF; background-color: #4275A8;}\n#sidebarTabs a:active {color: #000; background-color: #4275A8;}\n#sidebarTabs .tabSelected {border-top: 1px solid #555; border-left: 1px solid #555; border-right: 1px solid #555; border-bottom: 0px solid #555; background-color: #F2F2F2; padding: 0px 3px 3px 3px; font-weight: bold; color:4275A8; }\n#sidebarTabs .tabUnselected {border-top: 1px solid #555; border-left: 1px solid #555; border-right: 1px solid #555; border-bottom: 0px solid #555; background-color: #DCDCDC; color: #4275A8; padding: 0px 3px 0px 3px; }\n#sidebarTabs .tabContents {border: 1px solid #555; padding: 0px 3px 3px 3px; background-color: #EEEEEE;}\n#sidebarTabs .tabContents span {font-weight: bold;}\n#sidebarTabs .tabContents .tiddlyLink {color: #4275A8;}\n#sidebarTabs .tabContents .tiddlyLink:hover {color: #FFF;background-color: #4275A8;}\n#sidebarTabs .txtMoreTab .tabSelected {border-top: 1px solid #555; border-left: 1px solid #555; border-right: 1px solid #555; border-bottom: 0px solid #555; font-weight: bold; color: #4275A8; background-color: #F2F2F2; padding: 0px 3px 3px 3px; }\n#sidebarTabs .txtMoreTab .tabUnselected {border-top: 1px solid #555; border-left: 1px solid #555; border-right: 1px solid #555; border-bottom: 0px solid #555; font-weight: normal; color: #4275A8; background-color: #DCDCDC; padding: 0px 3px 0px 3px;}\n#sidebarTabs .txtMoreTab .tabContents { color: #000;background-color: #EEEEEE;}\n#sidebarTabs .txtMoreTab .tabContents .tiddlyLink {color: #4275A8;}\n#sidebarTabs .txtMoreTab .tabContents .tiddlyLink:hover {color: #FFFFFF;}\n#sidebarTabs .tabContents .button {color: #4275A8;}\n#sidebarTabs .tabContents .button:active {background-color: #FFF;color: #4275A8;}\n#sidebarTabs .tabContents .button:hover {background-color: #6699CC; color: #FFF;}\n#sidebarTabs .tabContents #popup {background-color: #4275A8; color: #FFF;border-right: 2px solid #BCBCBC; border-bottom: 2px solid #BCBCBC;}\n#sidebarTabs .tabContents #popup a {color: #EEE;}\n#sidebarTabs .tabContents hr{color: #FFF;}\n#sidebarTabs .tabContents #popup a:hover {background-color: #6699CC;color: #FFF;}\n#SidebarTabs .listTitle {font-weight: bold; color: #4275A8;}