Title: PRINCE2™ Edition – A Pocket Guide. Series: Best Practice. Authors: Bert Hedeman, Ron Seegers. Reviewers: Ernst Bosschers (ISES International). The PRINCE2® pocketbook has been specifically designed for Accredited Training Providers. The pocketbook is a light touch guide to. This is where the PRINCE2 project management method adds real value, as the globally recognized standard for delivering successful projects.
|Language:||English, Spanish, Arabic|
|Genre:||Science & Research|
|Distribution:||Free* [*Registration Required]|
Prince2 Pocket Book. Unknow. Prince2 Pocket Book. terney.info ISBN: , | 0 pages | 2 Mb. what makes a project a PRINCE2 project and provide guiding . PRINCE2 Pocketbook. • The Executive Managing Successful Projects with PRINCE2 PDF. PRINCE2 is owned and developed by the Office of Government Commerce (OGC ). PRINCE2 is a registered .. PRINCE2 pocketbook. (). 3rd ed. London.
Therefore, in all cases you need to decide which option suits you and then shop around. But please make sure you only use a provider who is accredited to provide official PRINCE2 training otherwise you may find that your qualification is not valid. You can download a PDF file of the guide from the link below:. Thanks Ian. I will get this. I am going to use this as my reference for the future. I am enrolling for Prince2 in order to be a certified PM.
Many Thanks to you Ian. Thank you very so much. Its very helpful specially for desertation students to know how can we applied the basics, tools and principles of project managment on the final project. This could include training on any processes and standards to be used on the project such as configuration management procedures, quality methods, progress reporting and other project-specific areas , or it could be an introduction to the project and its goals designed to motivate the team members.
Project Board members may also need training on their roles, including what is expected of them and the procedures needed to carry out their responsibilities.
During a project, team members may also need specialist training to enable them to complete their assigned tasks. The Project Manager should ensure that training needs are built into the appropriate plans.
The manager of a small project is therefore likely to find that team members are working on the project on a part-time basis.
Parttime team members suffer more absences and diversions, as a percentage of their working time, than full-time team members. The Project Manager should allow for this when designing a plan — either by negotiating guaranteed availability or greater tolerance.
If individuals are tasked with working on too many projects, they will simply stand still on all of the projects, expending a lot of effort but making no forward progress. Solutions include undertaking fewer projects in parallel or, where possible, allocating staff full time to projects for limited periods.
As a result, the Project Board may need to be involved more closely to lead, direct and prioritize work and resolve issues. Whatever the environment, the Project Manager will have to adapt to, and work within, the corporate organization and this will affect the level of management required for the team members.
Understanding and working within the wider corporate organization can be challenging for the Project Manager, particularly if working part-time or on a contract basis. Setting up clear project controls at the start of the project, and agreeing these with the Project Board, will help to ensure that the Project Manager understands the level of interaction and support to expect during the project and is given appropriate exposure to other areas of the corporate organization.
Organization 5. It is important to analyse who these stakeholders are and to engage with them appropriately.
Such people may: Note that some of these were external to the project management team but internal to the corporate or programme management organization. It is usually carried out at the programme level. All projects need to have some level of some stakeholder engagement, particularly if not part of a programme.
Parties external to the project management team can exert a powerful influence on a project. Gaining an understanding of the influences, interests and attitudes of the stakeholders towards the project and the importance and power of each stakeholder.
For instance, is a particular group likely to be negative, irrespective of the message, and therefore require particular care? They have the potential to affect the success of the project.
Perceptions may be mistaken, but they must be addressed. Defining how the project can effectively engage with the stakeholders, including defining the responsibilities for communication and the key messages that need to be conveyed. For each interested party, agree the: Defining the methods and timings of the communications. These are best planned after defining how the project will engage with the different stakeholders. When selecting the senders of information, it is important to select communicators who have the respect and trust of the audience.
Their position in the corporate organization and expertise in the subject matter will greatly influence their credibility. Many projects have a formal commencement meeting to introduce the project and its aims to the corporate organization.
Project Assurance could be involved in checking all the key stakeholders, their information needs and that the most appropriate communication channels are covered. It facilitates engagement with stakeholders through the establishment of a controlled and bi-directional flow of information. Where the project is part of a programme, the Communication Management Strategy should also define what information the programme needs and how this is to be communicated.
If a formal stakeholder engagement procedure has been completed, such as that described earlier, this should also be documented as part of the Communication Management Strategy.
Refer to Appendix A for more details of the suggested content for the Communication Management Strategy. The Project Manager should be responsible for documenting the Communication Management Strategy during the Initiating a Project process.
It is also important to review and possibly update the Communication Management Strategy at each stage boundary in order to ensure that it still includes all the key stakeholders. When planning the final stage of the project it is also important to review the Communication Management Strategy Organization to ensure it includes all the parties who need to be advised that the project is closing.
During a project, corporate or programme management retains control by receiving project information as defined in the Communication Management Strategy and taking decisions on project-level exceptions escalated by the Project Board. If a project forms part of a programme, there will need to be consistency and communication between the project and programme levels of management.
Refer to Chapter 19 for more detailed information on programme roles and how they may interact with project roles. Table 5. Provide information to the project as defined in the Communication Management Strategy. Executive Appoint the Project Manager if not done by corporate or programme management. Confirm the appointments to the project management team and the structure of the project management team. Approve the Communication Management Strategy. Senior User Provide user resources.
Define and verify user requirements and expectations. Senior Supplier Provide supplier resources. Review and update the Communication Management Strategy. Design, review and update the project management team structure. Prepare role descriptions. Team Manager Manage project team members. Advise on project team members and stakeholder engagement. Project Assurance Advise on selection of project team members.
Advise on stakeholder engagement. Ensure that the Communication Management Strategy is appropriate and that planned communication activities actually take place. Project Support Provide administrative support for the project management team. Without this understanding, the project would be exposed to major risks such as acceptance disputes, rework, uncontrolled change, user dissatisfaction that could weaken or invalidate the Business Case. Capturing and acting on lessons contributes to the PRINCE2 quality approach, as it is a means of achieving continuous improvement.
This can lead to misunderstandings. It is defined by the product breakdown structure for the plan and its associated Product Descriptions. A quality management system is the complete set of quality standards, procedures and responsibilities for a site or organization.
A programme, for instance, can be regarded as a semi-permanent organization that sponsors the project, and may have a documented quality management system. It is frequently the case that more than one permanent organization will be involved in a project — for example, separate customer and supplier businesses — and it follows that each may have its own quality management system.
Alternatively, if the project has a single key sponsoring organization, or is part of a programme, a single established quality management system is more likely to apply. Quality planning is about defining the products required of the project, with their respective quality criteria, quality methods including effort required for quality control and product acceptance and the quality responsibilities of those involved.
Quality assurance activities are outside the scope of PRINCE2 as it is the responsibility of the corporate or programme organization. Quality assurance is about independently checking that the organization and processes are in place for quality planning and control i.
Note that, in both senses of the term, quality assurance involves contributions that are independent of the project management team, whereas quality planning and quality control are undertaken by the project. Nevertheless, it is a project management responsibility to ensure that adequate quality assurance is arranged. Quality assurance should not be confused with Project Assurance. Provide assurance to the wider corporate or programme organization that the project is being conducted appropriately, properly and complies with relevant corporate or programme management standards and policies.
Performed by personnel who are independent of the project i. Responsibility of the Project Board, Responsibility of the corporate or therefore undertaken from within the programme management organization, project.
How they relate Quality assurance as a corporate or programme management function could be used by the Project Board as part of its Project Assurance regime for example, having quality assurance perform a peer review.
Quality assurance would look for or require effective Project Assurance as one of the indicators that the project is being conducted properly. This is, therefore, a responsibility within the project management team. Although Project Assurance is independent of the Project Manager, unlike quality assurance it is not independent of the project.
However, Project Assurance and quality assurance do overlap, as illustrated in Table 6. The first two of these are covered by quality planning section 6. The terms used in the diagram are explained in the remainder of this section.
When these aspects of planning are neglected, the people involved in the project may have conflicting views on the scope of the solution, on what constitutes a successful result, on the approach to be adopted, on the extent of the work required, on who should be involved, and on what their roles should be.
Quality planning comprises: They are defined and agreed early in the Starting up a Project process. The expectations are captured in discussions with the customer and then refined for inclusion in the Project Product Description. The key quality requirements will drive the choice of solution and, in turn, influence the time, cost, scope, risk and benefit performance targets of the project.
They are then used to identify more detailed acceptance criteria, which should be specific and precise. Quality 6. Examples are ease of use, ease of support, ease of maintenance, appearance, major functions, development costs, running costs, capacity, availability, reliability, security, accuracy, and performance. Acceptance criteria should be prioritized as this helps if there has to be a trade-off between some criteria — high quality, early delivery and low cost, for example, may not be compatible and one of them may need to be sacrificed in order to achieve the other two.
This may include complying with certain engineering standards relating to product durability. Identifying the acceptance methods is crucial because they address the question: Example of a prioritization technique — MoSCoW 6. The Project Product Description is created in the Starting up a Project process as part of the initial scoping activity and may be refined during the Initiating a Project process when creating the Project Plan. It is subject to formal change control and should be checked at stage boundaries during Managing a Stage Boundary to see if any changes are required.
It is used by the Closing a Project process as part of the verification that the project has delivered what was expected of it and that the acceptance criteria have been met. The acceptance criteria should be agreed between the customer and supplier during the Starting up a Project process and documented as part of the Project Product Description. Consequently, it is often the case that acceptance criteria will be refined and agreed during the Initiating a Project process and reviewed at the end of each management stage.
Once finalized in the Project Product Description, acceptance criteria are subject to change control and can only be changed with the approval of the Project Board.
In considering acceptance criteria, it is useful to select proxy measures that will be accurate and reliable indicators of whether benefits will subsequently be achieved. The approved Project Product Description is included as a component of the Project Brief and is used to help select the project approach.
The Project Product Description defines what the customer is expecting the project to deliver and the project approach defines the solution or method to be used by the supplier to create the project product. The Quality Management Strategy describes how the quality management systems of the participating organizations will be applied to the project and confirms any quality standards, procedures, techniques and tools that will be used.
Where models and standards are to be tailored, the tailoring should also be outlined in the Quality Management Strategy for approval. The Quality Management Strategy also provides a means by which the levels of formality to be applied in the quality plans and controls can be scaled and agreed according to the particular needs of the project. It should outline the arrangements for quality assurance, including independent audits where these are required by the policies of the participating organizations.
Key responsibilities for quality should be defined both within and outside the project management team , including a summary of the approach to Project Assurance.
Where there is already an established quality management system for projects, for example in a programme, only the measures specific to this project may need to be documented. The Quality Management Strategy is maintained, subject to change control, throughout the life of the project. Product Descriptions are not optional. They govern the development of the products and their subsequent review and approval. The content of a Product Description is described fully in Appendix A.
These define the quality controls that must be applied during product development and in the review and approval procedures for the completed product. Care should be taken not to write Product Descriptions in too much detail. They exist to help support the planning, development, quality and approval methods.
Product Descriptions that are too detailed can lead to an unnecessary increase in the cost of quality for the project. Where necessary, the Product Description should reference supporting information, such as any applicable standards or specialist design documents. The time needed to create good Product Descriptions will depend on factors such as how important, complex and unique the product is, how many stakeholders will review and approve the product, and whether the organization has a library of standard Product Descriptions for reuse.
Quality criteria The Product Description should include the quality specifications that the product must meet, and the quality measurements that will be applied by those inspecting the finished product. The quality criteria should be of sufficient detail and clarity to enable those reviewing a product to unambiguously confirm whether the product meets its requirements.
Quality tolerances Quality tolerances for a product can be specified in quality criteria by defining an acceptable range of values. One quality criterion is that the camera and its packaging must weigh no more than 1 kg. The product breakdown structure identifies a user guide product. It follows that the size and weight of the user guide is an important factor and not, for example, the number of pages. Questions to be asked include: What is the target market for the camera?
Does this also imply that the manual needs to be written in several languages? Will that mean it gets heavier? This could reduce the weight of the manual and allow the camera itself to be heavier. There are two primary types of quality methods: Quality responsibilities To avoid doubt, the quality responsibilities for a product should be specified.
The responsibilities will fall into one of three categories: Considering quality criteria often highlights connections and factors such as these which inform the subsequent planning process. Where specialized skills are implicit in the quality The Quality Register is effectively a diary of the quality events planned and undertaken for example, workshops, reviews, inspections, testing, pilots, acceptance and audits.
It is created during the Initiating a Project process as the products and quality control measures are being defined. It is then maintained in line with the current baseline plans throughout the project.
The Quality Register provides key audit and assurance information, relating what was planned and agreed in the Quality Management Strategy and Product Descriptions to the quality activities actually performed. The amount of information included in the Quality Register can vary considerably, depending on the extent to which quality metrics e. An example of a Quality Register is shown in Table 6. Quality control comprises: It is much easier and cheaper to correct a design document early in the project than to correct a design fault that is only discovered when the finished product is being tested or, worse, when the product is already in operational use.
It follows that quality inspections, implemented early in the design and development process, are potentially the most costeffective quality methods available. There are two types of quality methods: There are, in essence, two types of appraisal methods, depending on the extent to which it is possible to define objective quality criteria: A quality inspection is a systematic, structured assessment of a product conducted in a planned, documented and organized fashion.
A systematic but flexible approach to quality inspection can be used: The techniques can be used within the project, as quality controls, and by independent experts, as part of quality assurance. Peer and gateway reviews are examples of quality assurance activities that can be implemented by using or adapting a generic inspection technique. Used as a project management team control, conducting systematic quality inspections can also have valuable teambuilding side-benefits. Even when testing is the primary appraisal method, it is often the case that someone has to check that the test results meet the criteria for success and so a simple inspection is still required.
There are a variety of systematic inspection techniques, some being specific to certain industries or types of product. The presenter also coordinates and tracks the work after the review, i.
The minimum form of review used for simple inspections, e. Thus the quality review roles have no specific relationship to roles in the project management team structure. However, team-building benefits can be realized where Project and Team Managers regularly chair reviews.
Chairing quality reviews requires competence in facilitation and independence of the product being reviewed the primary responsibility is to ensure that the review is undertaken properly.
Global questions are ones that appear repeatedly throughout the product. The review team agrees any action on each question as it is raised. The review team agrees actions on each question as it is raised. The administrator records the actions and responsibilities Read back actions administrator Confirm the actions and responsibilities Determine the review result chair Lead the review team to a collective decision. The options are: The reviewers must have the opportunity to introduce their issues but allowing too much time invites comments that would not otherwise be made.
Does the product have to be changed or not? Do not allow discussions to drift. Remember, the purpose of the review is to identify defects, not to design solutions to them.
Avoid the temptation to formulate and agree solutions. The formal approval of a product may or may not result from a quality review. Products that have been signed off as complete at an inspection or review may still have to be submitted to a separate authority for approval. The PRINCE2 quality review technique and other quality inspection techniques can yield substantial side-benefits, particularly in terms of: This is particularly true for users.
Structured quality inspections are among the most effective ways of encouraging download-in to the project. The records support entries in the Quality Register by providing the Project Manager and the Project Board with assurance that: When these records are received by Project Support, the Quality Register entries for the relevant products can be completed. During the project and at project closure, the quality records provide a valuable source of information for analysis in accordance with the PRINCE2 principle that projects should learn from 57 experience.
For example, quality metrics, such as defect types and trends, can be used as a source for lessons learned and process improvements.
The format for approval records could include, for example, a note in the minutes of a meeting, an email, a letter, a signature on a document, or a certificate. Acceptance is frequently required from more than one set of stakeholders, e. Where concessions have been granted by the Project Board, it may be necessary to recommend follow-on actions for later improvements or remedies for the products concerned.
Executive Approve the Project Product Description. Provide quality assurance. Approve the Quality Management Strategy. Confirm acceptance of the project product. Approve the Project Product Description. Approve Product Descriptions for key user products. Provide resources to undertake user quality activities and product approval. Provide acceptance of the project product. Approve the quality methods, techniques and tools adopted in product development.
Provide resources to undertake supplier quality activities. Approve Product Descriptions for key specialist products.
Prepare the Project Product Description with users. Prepare the Quality Management Strategy. Prepare and maintain the Product Descriptions. Team Manager Produce products consistent with Product Descriptions. Manage quality controls for the products concerned. Assemble quality records. Advise the Project Manager of product quality status. Project Support Provide administrative support for quality controls.
Maintain the Quality Register and the quality records. Plans 7 7 Plans 7. Effective project management relies on effective planning as without a plan there is no control. Planning provides all personnel involved in the project with information on: The development and maintenance of credible plans provides a baseline against which progress can be measured.
They enable planning information to be disseminated to stakeholders in order to secure any commitments which support the plan. It is such rehearsal that enables omissions, duplication, threats and opportunities to be identified and managed. When asked to describe a plan, many people think of a chart showing timescales. It is a document describing how, when and by whom a specific target or set of targets is to be achieved. A plan must therefore contain sufficient information and detail to confirm that the targets are achievable.
Plans are the backbone of the management information system required for any project. It is important that plans are kept in line with the Business Case at all times. A plan requires the approval and commitment of the relevant levels of the project management team. Planning is the act or process of making and maintaining a plan.
The term is also used to describe the formal procedures used in this exercise, such as the creation of documents and diagrams.
Planning is essential, regardless of the type or size of the project; it is not a trivial exercise but is vital to the success of the project. Without effective planning, the result of complex projects cannot be predicted in terms of scope, quality, risk, timescale, cost and benefits.
Those involved in providing resources cannot optimize their operations. Poorly planned projects cause frustration, waste and rework. It is therefore essential to allocate sufficient time for the planning stage. The period of time for which it is possible to accurately plan is known as the planning horizon. Because of this, it is seldom desirable, or possible, to plan an entire project in detail at the start. Therefore plans need to be produced at different levels of scope and detail see section 2.
PRINCE2 recommends three levels of plan to reflect the needs of the different levels of management involved in the project, stage and team. A Product Description for a plan can be found in Appendix A. Note that since the Initiation Stage Plan is created prior to the Project Plan, it is influenced by the corporate or programme plan or equivalent from the organization commissioning the project.
Team Plans are created by the Managing Product Delivery process. This covers activities during and after the project and therefore may be part of a corporate or programme plan. The Benefits Review Plan covers corporate, project and stage levels. The Project Plan: The Stage Plan is similar to the Project Plan in content, but each element will be broken down to the level of detail required to be an adequate basis for day-to-day control by the Project Manager. Each Stage Plan for the next management stage is produced near the end of the current management stage.
This approach allows the Stage Plan to: See Chapter 10 for further guidance on partitioning a project into management stages. Team Plans are optional; their need and number will be determined by the size and complexity of the project and the number of resources involved. There may be more than one team on a project and each team may come from separate organizations following different project management standards not necessarily PRINCE2. Therefore the formality of the Team Plan could vary from simply appending a schedule to the Work Package to a fully formed plan in similar style to a Stage Plan.
If approved, the Exception Plan will replace the plan that is in exception and it will become the new baselined Project Plan or current Stage Plan, as appropriate. If a Stage Plan is being replaced, this needs the approval of the Project Board. Replacement of a Project Plan should be referred by the Project Board to corporate or programme management if it is beyond the authority of the Project Board.
An Exception Plan is prepared to the same level of detail as the plan it replaces. It picks up from the current plan actuals and continues to the end of that plan. Exception Plans are not produced for Work Packages.
Should a Team Manager forecast that the assigned Work Package may exceed tolerances, they will notify the Project Manager by raising an issue. If the issue relating to the Work Package can be resolved within stage tolerances, the Project Manager will take corrective action by updating the Work Package or issuing a new Work Package s and instructing the Team Manager s accordingly. Design the plan 7. This is known as product-based planning and is used for the Project Plan, the Stage Plan and, optionally, the Team Plan.
Figure 7. Each step in the planning procedure may need to be revisited on completion of later steps for example, in preparing the schedule if additional activities or dependencies are identified. This will include the use of diagrams versus text and will be driven, in part, by any standards adopted by the project. Where the project is part of a programme, the programme may have developed a common approach to project planning.
This may cover standards — for example, level of planning — and tools. These will be the starting point for designing any Project Plan. Any project-specific variations should be highlighted and the agreement of programme management sought.
There may also be a company standard for planning and control aids, or the customer may stipulate the use of a particular set of tools. The choice of planning tool may depend on the complexity of the project — hence the choice may need to be deferred until the level of complexity is known. The estimating methods to be used in the plan may affect the plan design, so decisions on the methods should be made as part of the plan design itself.
The use of planning tools is not obligatory, but it can save a great deal of time if the plan is to be regularly updated and changed. A good tool can also validate that the correct dependencies have been built in and have not been corrupted by any plan updates.
Write the Project Product Description 7. In the case of Product Descriptions, this means that at first it may comprise simply a title and a statement of purpose. The format and presentation of the product breakdown structure and product flow diagram is determined by personal preference. See Appendix D for examples. The benefits of product-based planning include: This reduces the risk of important scope aspects being neglected or overlooked Removing any ambiguity over expectations Involving users in specifying the product requirements, thus increasing download-in and reducing approval disputes Improving communication: Although the Senior User is responsible for specifying the project product, in practice the Project Product Description is often written by the Project Manager in consultation with the Senior User and Executive.
Every effort should be made to make this Product Description as complete as possible at the outset. A lower-level product can be a component of only one higher-level product. The resultant hierarchy of products is known as a product breakdown structure.
When creating a product breakdown structure, consider the following: For example, if the output of the plan is a computerized accounts system, users might want to separate the system into Accounts Payable, Accounts Receivable, General Ledger etc.
The suppliers, however, may prefer Screens, Reports, Databases etc. The Project Manager is not accountable for the creation of external products as they will be supplied by parties external to the project management team.
For each external product there should be a corresponding entry on the Risk Register detailing the threat to the plan if they are late or not to the required specification. It could be appropriate to identify the different states as separate products, where each state would require its own Product Description with different quality criteria and quality controls. This may be particularly useful when the responsibility for creating each state will pass from one team to another.
Alternatively, a single Product Description could be used with a set of quality criteria that the product needs to meet in order to gain approval for each state When presenting the product breakdown structure, consider the use of different shapes, styles or colours for different types of product.
For example, a rectangle could be used in a product breakdown structure to represent most types of product, but it may be helpful to use different shapes such as ellipses or circles to distinguish external products.
Colours could be used to indicate which team is responsible for the product or in which stage the product will be created If the project is broken down into several stages, the products for each stage are extracted from the project product breakdown structure to form the stage product breakdown structure.
Care must be taken to use the same names in the Stage Plan diagrams as were used in the Project Plan. In such cases the steps in the PRINCE2 product-based planning technique should not be skipped but used to verify the completeness of any library material. As every project is unique, there may be additional product requirements for this project or subtle differences in the quality criteria; the locations may be different, or the people and responsibilities involved may be different.
When creating a Product Description, consider the following: They will be refined and amended as the product becomes better understood and the later planning steps are done A Product Description should be baselined when the plan containing the creation of that product is baselined.
If the product is later changed, the Product Description must also pass through change control Although the responsibility for writing Product Descriptions rests officially with the Project or Team Manager, it is wise to involve representatives from the area with expertise in the product and those who will use the product in question.
Available immediately. Delivery options and charges. You May Also Like The handbook is a great reference guide that is easily transportable. I bit struggle with how to utilise this resource. Good ebook. Quick and relevant reference document - I downloadd the previous addition last year,.