From Prompt to Prince2

PROMPT – is the methodology of running IT projects developed (in the 1970s) by the company Simpact Systems Limited. Part of the standard under the name PROMPT II was introduced in 1983 in the government administration units of the United Kingdom. On government orders, it was enriched with the issue of quality management.
After purchasing the rights to the PROMPT methodology by LBMS, in 1989 the British government agency Central Computer and Telecommunications Agency (CCTA) published the standard under the new name of PRINCE (Projects in Controlled Environments) and identified it as a collection of the best IT project management practices.
PRINCE2 has gained wider and wider recognition around the world as a major alternative (not excluding) for the PMBOK methodology of the PMI institute. Recent changes were published in 2005 by the Office for Government Commerce (OGC), successor to the CCTA.

PRINCE2 is characterized by a process approach to project management. Defines in detail eight top-level processes, which in turn are divided into subprocesses:
• 1. Strategic project management (SZP) Directing a project (DP)
• 2. Planning (PL) Planning (PL)
• 3. Launching the Project + Preparing the Project Assumptions (PZP) Starting up a project (SU)
• 4. Project initiation (IP) Initiating a project (IP)
• 5. Stage Control (SE) Controlling a stage (CS)
• 6. Managing Product Production (ZWP) Managing product delivery (MP)
• 7. Management of the Stage Scope (RES) Managing stage boundaries (SB)
• 8. Closing the Project (ZP) Closing a project (CP)
Processes Preparation of Project Assumptions, Project Initiation and Closing a Project are simultaneously defined phases of a project’s life cycle.
Project Stage Control, Product Manufacturing Management and Stage Scope Management are implemented in the project implementation phase.
The Strategic Project Management process covers the entire project lifecycle, while Planning is active in all phases except the last Closing project.

A project compliant with PRINCE2 must contain at least two management stages:
• I. Initializing the project
• II. Implementation of the project
The project implementation phase can be broken down into implementation stages.
A detailed description of the stages and components can be found in another article. Now, however, I would like to focus on the strengths and weaknesses of the Prince2 methodology.
Strengths of PRINCE2

It is a good tool that controls the start, implementation and end of the project. The application of this methodology in the process of implementing IT systems ensures high standardization and repeatability of projects with a common approach, terminology and documentation. Thanks to this, it is possible to improve the competences of the staff implementing the systems. The methodology is rationally based on the best practices in project management, provided that they are already developed and described. Usually, in the documentation process, templates containing the required metrics, chapters and information fields are used, which ensures transparency, standardization and completeness of the documentation. Thanks to properly prepared documentation, an additional opportunity to adapt to the special needs of an organization, program or project is created.

Weaknesses of PRINCE2 A common mistake made by organizations using this methodology is the so-called PINO syndrome (Prince In Name Only), i.e. selective, without further analysis, using only some of the components of the methodology without paying attention to the basic principles.
(Like several complaints, this is a problem not of the methodology but its application.) PRINCE2 puts a lot of emphasis on documenting as a tool for efficient control of the way the project is implemented. In some organizations, however, documents become an end in themselves, and actual projects fail. For this reason, PRINCE2 is sometimes accused of excessive bureaucratisation of the management process. Similarly, PRINCE2’s attention to the need for good organization and the regular exchange of information between stakeholders is wrongly perceived as an incentive for continuous unproductive meetings taking the time necessary for real work.
PRINCE2 does not explicitly define the requirements analysis. As the implementation methodology can lead to project failure due to the adoption of false assumptions.
On the other hand, it is clear who is responsible for adopting the wrong assumptions and accepting the wrong business case and the reasons for these decisions are documented and may be a lesson for the future.
Too strict adherence to PRINCE2 without proper adaptation to business realities may be too labor-intensive to apply to some IT projects.

To sum up, the PRINCE2 methodology in itself will never become a specific panacea for the problems facing the implementation. PRINCE2 can be, just like any other methodology, only a tool supporting project management and this should always be remembered.