Project Management Comparison of Prince2 and Pmbok

INTRODUCTION

Through it’s evolution over the past three decades, the Project Management Institute’s (PMI) Guide to the Project Management Body of Knowledge (PMBoK) has become clearly established as the leading methodology for the understanding, analysis and execution of project management globally.

The increasing need for, and implementation of, project management practices within private and public sector organisations concurrently however, has resulted in the emergence of alternate project management methodologies and frameworks. As an alternative option available to Project Managers, the Projects in Controlled Environments (PRINCE) methodology has gained significant attention and increased favour for implementation by organisations globally.

This report has been prepared to describe in detail the PRINCE methodology, comparing its features and processes against those of the PMBoK, and analysing its relative strengths and weaknesses. This report will detail the benefits available to organisations in the application of the PRINCE methodology, how this tool can effectively and efficiently be employed for project management and recommendations for how organisations can tailor the methodology to maximise their chances for project success.

LITERATURE REVIEW BACKGROUND

The PRINCE methodology for project management was first developed in 1989 by the UK Computer and Telecommunications Agency. This governmental agency, now part of the Office of Government Commerce (OGC), originally developed PRINCE for application in government IT projects (Langley 2006 p30). The methodology was further revised and refined in 1996 by a consortium of 150 public and private sector organisations. The revision resulted in the creation of PRINCE2; a methodology with a much broader application to any and all projects, not just IT projects (Langley, 2003, p50).

PRINCE2 has since gone through a number of revisions, the most recent of which is PRINCE2 2009 (Science Letter 2009). This methodology has received increased international interest and attention since it’s inception; and has now experienced widespread application across private sector, to become the accepted standard methodology for project management within the UK.

As a practical tool of public domain, originally developed by government for project management, limited literature exists on the methodological description of PRINCE2’s structure, processes and application.

A number of UK governmental publications and Project Management Professionals (PMPs) however, have developed summaries and guides to the method which explain the purpose and structure of PRINCE2. Birlouez (2009) draws directly from the PRINCE2 guide to describe the methodology as a “process-based approach for project management”. It is designed to be a structured method that the Project Manager can apply to guide the processes and procedures applicable to all projects.

COMPONENTS

The OGC have structured the PRINCE2 methodology to address eight core ‘components’ of project management (ILX Group 2009). The Business Case The business case provides the driving force within PRINCE2 from the inception of, and throughout, the project lifecycle. As Wideman (2002) highlights, the business case “justifies the undertaking of the project in terms of reasons, benefits, cost, time and risk…” and is the base document that shapes the suitability of a project for acceptance.

Academics agree (Birlouez 2009, Siegelaub 2006) that the business case remains relevant throughout the project lifecycle and ultimately determines whether, through a change to feasibility of the business case at a certain point, the project should be terminated. Organisation PRINCE2 advocates a clear definition of the project organisation structure, to provide the Project Manager with the staff and resources to efficiently and effectively complete the project. Plans

Planning is a core concept emphasised within PRINCE2, providing a focus for the outputs and products to be delivered at various stages in the product lifecycle (Wideman 2002) and ensuring that plans are developed and executed not only at the strategic level but also down to the lower (team) levels (ILX Group 2009). Product-based planning is the key PRINCE2 technique with which to achieve this and represents the first of three techniques available to project managers in using PRINCE2 (Birlouez 2009). Controls

Siegelaub (2006) has described the ‘controls’ component of PRINCE2 as an area targeted to assist decision making. He identifies that the implementation of project control measures ensures:

• products generated meet defined acceptance criteria,
• the project is being completed in accordance with time/schedule, cost and resource plans,
• throughout the project lifecycle, the project and it’s associated Business Case remain viable,
• the project is conducted within an acceptable level of risk.

Control of technical work within PRINCE2 is achieved through the authorisation of work packages allocated against individuals or teams. These packages are measured against time, cost and quality requirements with responsible agents required to report back against these through identified checkpoints and triggers (Wideman 2009). Management of Risk Due to the unpredictable nature of project management and it’s susceptibility to the influence of environment variables, PRINCE2 advocates the employment of risk management to contain and minimise risk.

PRINCE2 offers a risk log and scoring system to facilitate this requirement (ILX Group 2009). Quality in a Project Environment Time and cost targets represent only one part of successful project delivery. Quality is a critical factor in meeting customer requirements and ensuring project performance is achieved. PRINCE2 employs ‘Product Descriptions’ to establish the minimum standards for project deliverables. Quality reviews then represent the second technique available for successful project management (Birlouez 2009), as a measure for comparison of planned versus actual performance.

Configuration Management Configuration Management is closely linked to quality within PRINCE2 in that it provides the means for monitoring and managing project deliverables, hence enhancing the project management team’s control over the project’s assets and products. Change Control PRINCE2 identifies the requirement for a means of assessing scope changes, their impact on project inputs, requirements and outputs, and most importantly, their impact on the Business Case.

This component permits project managers to make informed decisions on the relative value of scope changes; and through the series of detailed change control techniques, processes and requests offered by PRINCE2 (ILX Group 2009), determine whether to include them. Change control is the third and final technique available to PRINCE2 practitioners. PROCESSES Within the context of the key components highlighted previously, PRINCE2 identifies a ‘stage’ process for the conduct and management of a project, similar to the phases espoused by the PMBoK.

These stages focus specifically on the execution of a project, and do not cover in detail the associated preliminary project management activities associated with ‘soft’ project management functions like staffing or procurement. Appendix 1 is the PRINCE2 Process Model, which provides a graphical representation of the processes involved in delivering a project. These processes can be viewed as a structured checklist of how organisations can effectively manage a project. Start-up

Starting up a Project is the preliminary step in conducting any project, to enable the fundamental activities required to assess project oversight and viability. The stage involves the appointment of project key and team staff and preparation of the project brief, stage plan and the initial (outline) business case (ILX Group 2009) This stage also identifies the Acceptance Criteria for the project, a unique management product that defines measurable requirements of the project (Wideman 2009)

Initiation The project initiation stage directly follows project start-up and is predicated on authority to initiate. This stage provides the tools for the holistic development of the Project Plan and through PRINCE2’s Project Initiation Document (PID), provides an overview of the critical elements to the project (Siegelaub 2009)(including the Risk, Configuration, Quality and Communication Management Strategies (ILX Group 2009)). Directing a project

The directing stage is a continuous stage which runs throughout the lifecycle of a project. This process is inter-related with all other processes and provides the framework for the decisions required of the Project Board and Project Manager in authorizing and directing the conduct of, and progression between, all the other PRINCE2 processes. Controlling a stage Controlling a stage incorporates key activities that guide how the Project Manager manages the specific activities of the project.

Through configuration management and change control (Wideman 2002) this stage focuses on the authorisation, assignment and review of work packages, issue and change management and corrective action to ensure each project stage remains aligned with project objectives and targets. Managing product delivery The product delivery stage focuses specifically on the execution of the technical requirements of the project. It addresses the work that is to be performed, how it is executed and the delivery of the final outputs on completion.

Siegelaub (2009) highlights that the activities within this stage constitute part of PRINCE2’s Work Authorisation System. Managing stage boundaries This stage provides the guidance for the Project Manager on how to effectively transition between completion of one project stage and commencement of the next, including review and update to the Project Plan and Business Case (ILX Group 2009). This stage is closely linked to the ‘Directing a Project’ stage, as it provides the input to the Project Board at stage completion for decision on ongoing project viability, and develops the plan for subsequent work stages.

Closing a project The closing stage of a project effectively terminates the project and transitions responsibility back to the organisation. Termination can be initiated due either to completion of work, or through premature termination, where project viability is no longer apparent (Siegelaub 2009). This stage includes the capture and evaluation of ‘lessons learned’ for organisational learning and final closure of all project activities.

PRINCE2 identifies that any product will have a lifespan of five phases. Of these phases (Conception, Feasibility, Implementation, Operation and Termination), PRINCE2’s methodology and process model specifically operate within the Implementation phase of the product lifecycle. From this application, it can be seen that PRINCE2 is therefore an ‘implementation methodology’ as opposed to a more encompassing and holistic project management methodology (Wideman 2002).

ANALYTICAL DISCUSSION COMPARISON

In order to highlight the differences that exist between PRINCE2 and PMBoK, t is necessary first to draw comparison between the two methodologies. PMBoKs processes are effectively building blocks, each of which can be categorized into a Process Group and Knowledge Area (Birlouez 2009).

The major knowledge areas are:

• Project Integration Management
• Project Scope Management
• Project Time Management
• Project Cost Management
• Project Quality Management
• Project Human Resource Management
• Project Communication Management
• Project Risk Management
• Project Procurement Management

The Project Integration Management area acts as a lynchpin for the PMBoK, linking all other areas. Birlouez (2009) uses the development of the Project Management Plan as an example for this, as this document will incorporate all plans from the other knowledge areas (Risk, Communication, Quality, etc).

It is easy to observe then the similarities between the critical concepts addressed by each methodology. The application of PRINCE2 to project management however, differs in scope from the PMBoK. From the outset, PRINCE2 does not claim to comprehensively cover the subject of project management. Rather, it is a methodology that is based on the principles of the PMBoK. Siegelaub (2006) highlights that PMBoK: “specifically calls on the practitioner to apply a project management methodology (as a tool/technique), and PRINCE2 provides one. Viergever (2009) supports this argument, suggesting that PMBoK provides the framework, where PRINCE2 provides the method.

CONTRAST

Academic opinion (Birlouez 2009, Siegelaub 2006, Viergever 2009, Wideman 2002) generally prescribes that the PMBoK and PRINCE2 serve different purposes and are not easily comparable. Where PMBoK provides a comprehensive means for teaching the subject of each knowledge area of project management as a discipline, PRINCE2 provides a more detailed approach for the running of a particular project. When examining the process side of project management, PMBoK tends to focus on higher-level descriptions rather than a detailed explanation of processes. PRINCE2 by contrast offers a more detailed explanation of the processes (Viergever 2009). Several authors (Webber 2009, Van Bon 2006) have highlighted PRINCE2’s level of detail within project processes as a major advantage over PMBoK.

Assessment from various PMPs and methodology description within the PRINCE2 guide advocate an extensive list of strengths for PRINCE2; as both a stand-alone methodology and in comparison to the PMBoK. Major strengths of the methodology based on public and private sector application have been grouped together into the following areas.

STRENGTHS Methodology structure

The detailed process model that PRINCE2 offers provides a controlled start, progress and close to projects. The structure of the methodology provides a standardised process for project completion that permits consistency between projects within an organisation. It also provides a framework for delegation and communication, and stipulates points for review and flexible decision points against the project plan, business case and risks (Ruleworks, 2009).

The processes within permit a stage-by-stage breakdown of work requirements for project managers that goes into greater detail than the five project phases espoused by the PMBoK (Initiating, Planning, Executing, Controlling and Monitoring, Closing (IT Governance Ltd 2009)), effectively providing a ‘checklist’ for project managers; however as a generic methodology remain flexible enough that activities can be tailored to suit the organisation and project (and do not all require rigid application to all projects).

The methodology is supported by a well-defined set of progressive documentation requirements that provide an easy guide to assist the project team. Thirty-three standard management ‘products’ are available to PRINCE2 practitioners as templates which can be employed as key outputs across the multiple stages (Wideman 2002). The Business Case and Project Brief provide uidance on viability during the start-up phase that is not recognized by the PMBoK, while the PID offers the detailed description of how the project is to be executed. Although the PMBoK has an equivalent document (the Project Charter) the requirement for a substantiated Business Case does not serve as a prerequisite.

This ‘commercial-off-the shelf’ (COTS) methodology is favoured amongst many organisations globally, as it provides significant cost and time savings (in multiple months and thousands of man-hours), compared to the decision to develop and launch a unique methodology for a business and educate staff in its application (Kippenberger 2009).

Project organisation and assignment of responsibilities Another strength of PRINCE2 is its identification of management roles rather than jobs, which can then be allocated amongst organisational staff to suit the organisation. PRINCE2 goes beyond the PMBoK identification of a ‘Project Sponsor’ to highlight the benefits of using a ‘Project Board’ (a team of senior executives that provide oversight for the project and grant authority to the Project Manager through commitment of resources (Siegelaub 2006). Although not a mandated requirement of PRINCE2, the Project Board is a function which can facilitate greater project ownership from key stakeholders.

Representation will ordinarily be provided on the board through appropriate senior members from the business (usually the Senior Executive), the user organisation and the supplier. Presence of a Senior User ensures that customer specifications for a project are adhered to at various review points in the project lifecycle, while the Senior Supplier represents the interests of the team/s designing, developing and implementing the project, to ensure appropriate resources are committed and quality maintained (Wideman 2002).

The importance of the customer/supplier environment that PRINCE2 espouses cannot be overemphasised. In a case study of four interactive media companies trialing the use of PRINCE2, England (2006) identified that wareness of project management practices on both user and supplier sides of any project was essential to facilitating effective project management and in managing stakeholder perceptions and expectations.

Companies that achieved this when implementing PRINCE2 had improved communication and smoother reporting. PRINCE2 also advocates defined roles for project assurance and a configuration librarian, support roles that ensure all interests of a project are served and project and management documentation is maintained and accessible. Business case based decision making PRINCE2’s use of defined ‘go/no-go’ criteria for evaluating a business case by a project board provides an initial stage-gate check for project viability, significantly enhancing the chances of project success.

As part of PRINCE2’s processes, the project start-up stage assigns responsibility to a project owner for preparation of the business case. Ownership of the business case encourages the person/s assigned to put sufficient rigour into the business case for approval (thus reducing the likelihood for ill-planned projects to be approved). In a review of one Dutch bank using PRINCE2 for it’s project management, this process (requiring a detailed justification for business cases) resulted in 30% less projects approved for initiation. Further analysis of these figures confirmed that the reduction of project approvals was attributable to Business Case reviews that identified non-viable projects prior to initiation (Viergever 2009).

Product based planning

Practitioners generally concur on PRINCE2’s planning method as a major strength of it’s methodology. PRINCE2 expands upon PMBoKs use of a Work Breakdown Structure (WBS) to incorporate detailed Product Descriptions into a Product Breakdown Structure (PBS). This inclusion for deliverables not only clarifies expectations of project teams and end-users to ensure that the output provided meets requirements, but also provides a baseline against which scope changes can be measured (Siegelaub 2008). This benefit has been espoused by a number of PMPs (England 2006, Tang 2008, Webber 2009). Wideman (2009) notes that this process can be applied to any project at any level for positive results.

The PBS provides a far greater level of detail than the PMBoK WBS by demonstrating the links between products and their associated work activities in the Product Flow Diagram, which facilitates identification of the necessary activities to achieve the final outcome and the creation of associated Gantt charts. As the CEO of IT Governance Ltd (the most comprehensive publisher of governance, risk and compliance books and tools globally), Alan Calder has endorsed the PRINCE2 methodology’s product-based planning approach.

In his article on IT Project Governance, Calder (year unknown) highlights that this approach does not simply plan when an activity will be conducted; it goes further to clarify the result that is required. Work Packages Siegelaub (2006) has identified PRINCE2’s use of Work Packages (the core element of the PRINCE2 work authorisation system) as a major gap in the PMBoK Project Management methodology that PRINCE2 fills.

The Work Packages extensively define: the work to be performed through Product Descriptions, time, cost and resource constraints; techniques for the work to be performed; the review and submission process for the work and the procedures for issue reporting. Content can be tailored to the organisation and the type of project; and offers a more comprehensive method for defining work. This is one of the fundamental tools that demonstrate how PRINCE2 provides the ‘nuts and bolts’ method that the PMBoK’s framework does not describe in detail. Registers of Scotland Executive Agency (a land title registration agency) have implemented Work Packages as a key Project Management deliverable and have experienced greater awareness amongst managers of the detailed structure to their projects and control over the work being performed.

Implementation of PRINCE2 within the organisation, specifically through the pplication of the PID, defined the boundaries of projects within and the subsequent allocation of work packages significantly reduced scope creep amongst the company (Gardiner 2002). Change control and configuration management Until recently, change control and management was covered almost exclusively by PRINCE2. PMBoK 4th Edition has started to address this through it’s section on Integrated Change Control (Kerzner 2009 p 475) however this is not at the same level of maturity as PRINCE2’s configuration management and change control approach, as PMBoK identifies the requirement without detailing the means or process to achieve change control. PRINCE2 2009 continues to provide a more detailed change management process (Webber 2009).

Work Package control in PRINCE2 is closely monitored through the checkpoints and reporting requirements stipulated in the methodology process (including Highlight Reports and Exception Reports) and the requirement to define tolerance levels, contingency plans and change control processes further aid configuration management (Wideman 2002), an area that the PMBoK lacks. ‘Directing the project’ across all phases PRINCE2’s thorough description of critical activities across processes facilitates a much more controlled project management process. Definition of how the project will handle exception situations, and the associated management actions required, as part of the PID during the ‘Start-up’ stage ensures key participants in the project have a clearly defined process to follow in escalating issues and taking corrective action.

This, combined with the employment of Quality Reviews against project deliverables within PRINCE2, ensures that the Project Manager and Project Board can track project performance across all stages of the project. PRINCE2 offers a simple set of steps to guide how Quality Reviews are employed against these deliverables. Finally, PRINCE2 expands on the PMBoK’s reference to the requirement to manage issues, by providing a mechanism for conducting this: the Issue Log. The Issue Log provides a recommended format for tracking issues and identifies key points in the project lifecycle that issues should be identified, updated and reviewed (Siegelaub 2006). WEAKNESSES Despite the obvious strengths to the methodology, PRINCE2 as a project management tool in isolation is not an infallible methodology.

The method is subject to several weaknesses. Application One of the basic weaknesses of PRINCE2, applicable across both Public and Private sectors, is the methodology complexity and range. A number of organisations are subject to implementing ‘PRINCE2 in name only’ (PINO), arbitrarily selecting various templates and products from the methodology without sufficient regard to the applicability to their projects, hence failing to effectively apply the processes. In these situations, the ‘document-centric’ nature of the methodology leads to the documents becoming ends in themselves instead of tools and products to assist the progress of the project (Project Management Australia 2009).

When this occurs excess work may be generated for a project, which overshadows and detracts from the project itself. It must be highlighted however, that these particular shortcomings are failures of the practitioner rather than the methodology. Viergever (2009) supports this view, highlighting the propensity of the methodology to become mired in bureaucracy. Foremost, Viergever highlights culture as a reason for this. PRINCE2 assumes a customer/supplier environment, where both stakeholders have input to the requirements and management of the project. In a culture lacking this cooperation, the supplier ‘drives the ship’ and so much bureaucratic documentation is prepared without consideration for end user requirements.

Secondary to, and supporting this, Viergever acknowledges that organisations have a tendency to apply all the templates and procedures described by PRINCE2. The methodology does not prescribe which of these are essential for different types of projects, therefore many organisations ‘over-prescribe’ and apply them all. The case of Suffolk County Council (SCC) is a good example where this ‘pitfall’ was experienced and rectified. After initial attempts to apply PRINCE2 for better management of public services were met with resistance (due to a perception of bureaucracy and over-prescription of practices), SCC tailored the system into a framework that suited them: PRINCE2 Suffolk Style (PRINCESS).

Subsequently, the tailored approach provided the general guidance required by managers and employees to clarify role expectations and generic process to be followed, while scaling down the ‘reporting product’ requirements to better suit the organisation and it’s (comparatively simple) projects (Ling 2009). Poor definition of contracting and procurement Wideman (2002) illustrates a major weakness of the PRINCE2 methodology in the lack of strong detail during Project ‘Conception’. As the methodology largely focuses on the commencement of a project from ‘Start-up’ (or the ‘Implementation’ phase of the project lifecycle) little attention is paid to how the project may be run when conducted within a contract context; and scarce detail is provided on the procurement requirements applicable.

Considered in isolation then, the PRINCE2 methodology lacks the detail on how to conduct these activities; a significant omission given the emphasis on sub-contracting project phases and elements in recent years. The PMBoK by contrast provides a dedicated chapter to procurement which provides guidance on these activities, including the actual procurement, pre-assignment or negotiation for project team members (ILX Group 2009).

Lack of Human Resource focus PRINCE2 does not explore in significant detail the management issues associated with human resources (including team acquisition planning, training, team-building and recognition) despite the importance placed on human assets in various management disciplines (Webber 2009). Van Bon and Verheijen (2006) support this view, arguing that PRINCE2 lacks any real detail on the soft skills of Project Management, where PMBoK does address these issues through a detailed section human resource management.

RECOMMENDATION – THE APPLICATION OF PRINCE2 AND PMBOK IN COMBINATION

Notwithstanding the aforementioned weaknesses of PRINCE2, the methodology remains a very effective project management tool. Noting the obvious ‘conceptual’ areas that PRINCE2 fails to address in detail, these areas are captured and expanded upon in the PMBoK. Consideration must be given therefore, to the application of both methodologies in concert. Many academics emphasise how each methodology can be used to complement the other (Siegelaub 2006, Wideman 2009, Yeong 2007).

PRINCE2’s lack of focus on Communications, Human Resource and Procurement Management are areas that are complemented by PMBoK. Alternatively, PRINCE2’s strengths in process and documentation, coupled with its business case approach, provide a stronger focus on the strategy aspects that PMBoK addresses only at higher levels. At the work unit level, the WBS of the PMBoK can be combined with PRINCE2’s PBS for a more comprehensive means of structuring project deliverables. Using PMBoK and PRINCE2 as an ‘integrative project management methodology’ (Yeong 2007) permits organisations to complement the strengths of each while mitigating their individual weaknesses.

Ideally, the procedural and product concepts unique to PRINCE2 (Business Case, Project Boards, Issue Logs, Tolerance and Exception Plans, Configuration Management, etc) should be used to ‘flesh out’ and strengthen the PMBoK’s knowledge areas. The case of Getronics (a leading vendor of Information Communication and Technology solutions) provides an interesting example for the combination of both the PMBoK ‘framework’ and the PRINCE2 ‘method’. Following its adoption of PRINCE2, Getronics commenced a review of internal methodology to combine both methods. The company had drawn upon its PMP experience to apply the principles of Project Management advocated in the

PMBoK; including project management ‘soft skills’ (communication management and people management) as well as other critical areas such as contract (procurement) management and the incorporation of an earned value system. Concurrently, Getronics grounded these aspects in a business case driven environment (one of the hallmarks of the PRINCE2 methodology), with a clearly defined process model for specific activities that were required throughout the project; and product based planning that was deliverables driven. This combination evolved into the Getronics Global Project Management Methodology and has been successfully applied by the company across 30 countries (APM Group 2003).

At the individual level, the complementary nature of both methodologies means that the method-based certifications of PRINCE2 practitioners, combined with the PMI accreditation provided to PMPs, allows for a more ‘well-rounded’ PMP with a holistic understanding of Project Management. At the same time, these skillsets are complemented by technical skills for selecting and applying techniques. The combination makes for a more comprehensive approach that is easily obtained and adopted, based on public domain elements. Essentially, PRINCE2 can provide the depth the PMBoK lacks, while the PMBoK can address the broader elements of project scope not covered by PRINCE2.

An obvious limitation of the research conducted within this report was the lack of quantitative data for analysis. Analysis of case studies is based largely on anecdotal evidence from participating organisations. Whilst the documentation available on PRINCE2’s application in business is not propagandistic, there is a notable prevalence of favourable literature and examples published, while examples of failed applications of PRINCE2 appear to be limited. Further quantitative analysis into unsuccessful trials of the methodology (incorporating productivity figures, schedule and cost variances) may provide an interesting counterpoint to the analysis conducted within this report.

CONCLUSION

As a project management methodology, PRINCE2 represents an alternative option to the PMBoK. PRINCE2 is a more detailed, process-based approach that provides thorough guidance on the management of a particular project. PMBoK by comparison is a more generic methodology that addresses the core knowledge areas of the project management discipline, establishing the framework within which PRINCE2 functions. PRINCE2 has a number of strengths that lie in its detailed processes, however the multiple products and deliverables that the methodology advocates can be incorrectly applied by practitioners if not appropriately adapted to suit the organisation. Despite the widespread support for this methodology across both public and private sector organisations, the methodology is not infallible.

Through application in conjunction with the PMBoK however, the relative strengths of each methodology can be applied to counter and reduce the associated weaknesses of the other, for a combined and comprehensive project management methodology. Organisations that embrace the combination of these two approaches and careful application to their project environment are far more likely to experience effective project management and project success.

REFERENCES 

1. APM Group 2003, PRINCE2 Case Study – PRINCE2 and PMI/PMBOK A Combined Approach at Getronics, ILX Group, retrieved 15 September 09 http://www. prince2. com/prince2-downloads. asp
2. England, E 2006, Prince 2 Project Management and Interactive Media: Is there a fit? , ILX Group, retrieved 14 September 09 http://www. prince2. com/prince2-downloads. asp
3. Gardiner A 2002, Registers of Scotland Executive Agency – Implementing PRINCE2 in a Business Change Environment, ILX Group, retrieved 14 September 09, http://www. prince2. com/prince2-downloads. asp
4. Kippenberger, T 2009, PRINCE2 Goes to China, Best Management Practice Homepage, retrieved 15 September 09, http://www. best-management-practices. com/Knowledge-Centre/Guest-Writer/PRINCE2-Managing-Successful-Programs-and-Management-of-Risk/? DI=571314
5. Ling, K 2009, Suffolk County Council – PRINCE2 2009 Pilot Case Study, ILX Group, retrieved 14 September 09 http://www. prince2. com/prince2-downloads. asp
6. Project Management Australia 2009, PRINCE2 Weaknesses, Project Management Australia Homepage, retrieved 15 September 09 http://www. projectmanagement. net. au/prince2_weaknesses
7. Siegelaub, J 2006, How PRINCE2 Can Complement PMBOK and You PMP, PMI Global Congress Proceedings, Watermark Learning, retrieved 14 September 09 http://www. watermarklearning. com/enews/March08_Article. pdf
8. Tang, Y 2008, Lecture – The Other Side of PRINCE2, delivered at the BCS Swindon Branch Meeting, Bryanbarrow. com, 25 September 08, retrieved 15 September 09 http://bryanbarrow. com/the-other-side-of-prince2. htm
9. Van Bon, J and Verheijen, T 2006, Frameworks for IT Management, Van Haren Publishing, Amersfoort, p. 203. Viergever, N 2009, Comparing PMBOK and PRINCE2, NVi Homepage, retrieved 14 September 09 http://www. viergever. info/en/pmbokp2. aspx