第 1 章
Mastering Projects: The PRINCE2 Revolution
Ever wonder why some projects succeed brilliantly while others crash and burn despite similar resources and talent? PRINCE2 (PRojects IN Controlled Environments) might be the difference-maker you've never heard of. This methodology, once a hidden gem of UK government projects, has become a global standard embraced by organizations from NASA to small businesses worldwide. Even celebrities like Richard Branson have credited structured project approaches like PRINCE2 for Virgin Group's successful ventures across industries. Unlike rigid methodologies that prioritize documentation over delivery, PRINCE2 offers something refreshingly different: a flexible framework that adapts to projects of any size while maintaining essential control principles.
第 2 章
The PRINCE2 Framework: Structure Without Bureaucracy
PRINCE2 provides a comprehensive yet adaptable project management approach that balances structure with flexibility. At its core, the methodology consists of seven processes that guide projects from pre-project activities through execution to closure. These processes represent the chronological flow of a project-the "when" of PRINCE2-and contain activities that serve as helpful checklists rather than rigid requirements.
The framework includes seven themes that run throughout the project lifecycle: business case, organization, quality, plans, risk, change, and progress. These themes represent the "what" of PRINCE2-the disciplines or subject areas addressed throughout the project. For example, the business case theme ensures projects deliver genuine business benefits, not just occupy time. The organization theme clarifies roles and responsibilities, while the quality theme addresses the critical "third dimension" of project management beyond time and cost.
Underpinning everything are seven principles that must all be followed for a project to be considered a proper PRINCE2 implementation: continued business justification, learning from experience, defined roles and responsibilities, managing by stages, managing by exception, focusing on products, and tailoring to suit the project environment.
PRINCE2 also identifies six variables that need to be controlled and balanced: cost, time, quality, scope, risk, and benefits. These variables interact with each other, so pressure in one area (like time) may require adjustments in others (like cost or quality).
The real power of PRINCE2 comes from understanding it's a tool to be adjusted for project needs, not followed blindly. Many misconceptions arise from not grasping this fundamental nature. Common complaints include viewing PRINCE2 as additional work rather than the way to manage projects, believing it doesn't fit certain projects due to lack of flexibility, seeing it as bureaucratic, or claiming there's no time to use it. In reality, PRINCE2 is designed to help get projects done more effectively when applied intelligently.
第 3 章
Starting Right: Validating Your Project Idea
Before diving headfirst into any project, PRINCE2 insists on validating its viability through the 'Starting Up a Project' process. This crucial pre-project step helps prevent organizations from wasting resources on initiatives that aren't worth pursuing.
The process begins with appointing key roles. The Executive takes overall control from a business perspective, while the Project Manager handles day-to-day responsibilities. Together with Senior Users (representing those who'll use the project's deliverables) and Senior Suppliers (representing those providing resources), they form the Project Board-the project's ultimate decision-making body.
One of the Project Manager's first tasks is setting up the Daily Log, which serves as both a diary for recording day-to-day information and a catch-all for information not covered by other management products. This simple tool can save considerable paperwork when used intelligently, such as recording decisions that would otherwise require formal documentation.
PRINCE2 emphasizes learning from past experience through the Lessons Log. At project start, the team should review lessons from previous projects to avoid repeating mistakes and incorporate successful approaches. This might include examining previous Lessons Reports, corporate guidance, experienced personnel from similar projects, or published articles.
Rushing into projects without validation is dangerous. The UK Treasury's "Green Book" identifies "optimism bias"-managers tend to underestimate costs and timelines while overestimating benefits. Many projects begin with high expectations but end with disappointing results or premature termination. A brief upfront review estimating costs, timescale, benefits and risks can prevent costly mistakes.
The process culminates in the Project Brief-a simple document providing enough information to decide whether to proceed with detailed planning. Unlike the more substantial Project Initiation Document (PID) that comes later, the Brief contains just essential information like project definition, background, objectives, scope, constraints, and the Outline Business Case.
At the end of Start Up, the Project Board receives this package of information to decide whether to proceed with the project and authorize the Initiation Stage for full planning, or to stop because the project doesn't appear viable. If they decide to proceed, they're only committing to the Initiation Stage at this point. Only after Initiation, if things still look promising, will they commit to the entire project.
第 4 章
Building the Foundation: Project Initiation
The Initiation Stage establishes the solid foundation for your project through the Project Initiation Documentation (PID). This comprehensive document defines how the project will be run and serves as a reference point throughout its lifecycle.
During Initiation, the Project Manager develops several strategic approaches. The Risk Management Strategy defines how risk will be managed throughout the project, including decision-making authority, procedures, budgeting, and reporting mechanisms. The Quality Management Strategy establishes the appropriate level of quality for the project, recognizing that higher quality demands significantly more time and cost. In some safety-critical projects, quality activities can consume up to 85% of project effort.
Configuration Management (CM) is essentially version control-protecting project products from unauthorized changes. The CM Strategy defines procedures for access control, security measures, and document tracking systems. Special attention must be paid to integrating external suppliers' CM procedures with the project's systems to prevent conflicts.
The Communication Management Strategy identifies all communications expected within the project and between the project and external stakeholders. This helps eliminate unnecessary communications while making necessary ones efficient and appropriate-particularly important in today's environment where over-communication is often a bigger problem than under-communication. Despite PRINCE2's reputation for being document-heavy, the method actually encourages considering the most appropriate communication format for each situation, which might include presentations, podcasts, websites, or verbal reporting-not just documents.
In PRINCE2, control is primarily achieved through management stages-blocks of work that the Project Board is willing to authorize at one time. These are distinct from technical stages, which represent the teams' view of the work. Management stages represent points where the Project Board needs to meet and make decisions, not simply receive progress updates.
During Initiation, the Project Manager develops the Project Plan-a high-level overview of the entire project. PRINCE2 employs a powerful "product-based" planning approach that focuses first on identifying what the project must produce. Despite being undervalued and frequently omitted by practitioners, Product-Led Planning provides significant benefits for progress control, quality management, and risk management.
The outline Business Case from Start Up is developed into a fully detailed version during Initiation. The Executive owns the Business Case and ensures appropriate detail is included, though the Project Manager often conducts the research and Senior Users identify benefits. A Benefits Review Plan is also prepared to specify when benefits will be measured, by whom, and how.
At the end of Initiation, the Project Board makes their most significant decision-whether to commit to the entire project and authorize the first delivery stage. Unlike earlier commitment to planning, this represents the major go/no-go decision. Obtaining physical signatures on the PID and Stage Plans is important to ensure clear commitment and authority.
第 5 章
Managing Stage Transitions: The Critical Control Points
The 'Managing a Stage Boundary' process handles transitions between project stages, providing the Project Board with comprehensive information needed to make decisions about the next stage.
At the end of a stage, the Project Manager provides the Project Board with three key perspectives: a look back at how the last stage performed (including schedule adherence, change management, and quality delivery); an assessment of the current project status (examining Business Case viability and risk profile); and a look forward at whether the next Stage Plan is realistic and achievable with resources in place.
Two events can trigger End Stage work: the planned end of a stage (when the Project Manager sees the stage is approaching completion) or an exception situation (when projections show the stage may exceed tolerances). In exception cases, if the Project Board decides to run the stage differently, an Exception Plan is created as a replacement Stage Plan, forcing a new stage boundary.
Creating a Stage Plan involves similar content and techniques as the Project Plan but covers just one management stage in much more detail. PRINCE2 requires using the product-based approach to planning, breaking down the 15-30 project-level products into more detailed stage-level products. This provides greater precision for the specific stage being planned.
The Product Checklist is a simple but powerful progress monitoring tool created during stage planning. It lists the 15-30 lower-level products to be developed in the stage along with their planned delivery dates. As each product is completed, quality-checked and signed off, the actual delivery date is recorded on the checklist. This provides precise progress tracking with clear milestones that require no subjective judgment-either a product is delivered or it isn't.
A systematic review of all risks in the Risk Register is essential at stage boundaries. This involves checking if risks are still current, evaluating if probability or impact has changed, determining if risk responses remain appropriate, and identifying any new risks.
The Business Case must be thoroughly reviewed at each stage end, providing Project Board members with the latest information for their continue/stop decision. This review includes checking benefit projections and timing, updating cost and time estimates from the revised Project Plan, and reassessing risks.
The Stage or Exception Plan, End Stage Report, updated Business Case, and updated Risk Register are presented to the Project Board for an End Stage Assessment. The board must approve the completed stage and authorize proceeding with the next stage-or stop the project. This authorization checkpoint prevents projects from continuing blindly when things are going wrong.
第 6 章
Day-to-Day Project Control: Keeping Things on Track
The 'Controlling a Stage' process is where the Project Manager manages day-to-day activities, controlling work flow to teams, handling risks and issues, monitoring progress, and reporting to stakeholders.
The Project Manager controls work through Work Packages-instruction packs given to Team Managers to build specific products. These packages are distributed systematically throughout the stage, with Team Managers typically handling multiple Work Packages in sequence. When distributing Work Packages, the Project Manager and Team Manager fine-tune requirements and controls. Team Managers report progress through Checkpoint Reports, typically including time sheets and spending information.
Project Managers must handle various Issues-communications about anything project-related that can come from anyone involved. When receiving an Issue, the Project Manager decides whether to handle it informally (noting it in the Daily Log) or formally (recording it in the appropriate register and creating an Issue Report). The Project Manager analyzes each issue or risk to determine its impact on costs, timescales, Business Case, product specifications, and whether it affects just the current stage or the entire project.
Regular progress checks against the plan are essential, especially when dealing with Issues that might impact project tolerances. While the Business Case and Risk Register must be reviewed at stage boundaries, high-risk projects require more frequent systematic reviews.
Progress is reported to the Project Board through Highlight Reports as specified in the Communication Management Strategy. These reports should be concise (1-2 pages), visual, and take less than an hour to produce. They contain information about work completed in the current period, planned work for the next period, tolerance status, and any significant issues or risks.
The Product Checklist is a powerful yet undervalued control document for monitoring and reporting progress. It shows which products have been delivered and which are due in the next reporting period. Though not explicitly included in the Highlight Report format, it provides clear visibility of progress that's readily understandable for the Project Board.
When projects go off track, the Project Manager's response depends on whether the deviation can be managed within delegated authority. If adjustments can bring the stage back within tolerance limits, the Project Manager makes those changes without board approval. If the stage will exceed tolerance limits despite any actions, an Exception Report must be submitted immediately.
第 7 章
Creating Project Deliverables: The Engine Room
The 'Managing Product Delivery' process focuses on creating the project's actual products through Work Packages. This process represents the Team Manager's perspective in handling Work Packages, building products, and returning completed deliverables.
A Work Package is an instruction set from the Project Manager to a Team Manager for building one or more products. It contains the date issued, team assignment, product descriptions, development techniques, interfaces with other teams, operational requirements, configuration management procedures, agreements on resources and timescales, tolerances for acceptable deviation, constraints, reporting requirements, and approval methods.
The Team Manager's role is straightforward with just three main activities: receiving the Work Package and possibly creating a more detailed Team Plan, building and testing the products according to requirements, and reporting progress through Checkpoint meetings. Throughout development, the Team Manager maintains version control records, monitors quality through the Quality Register, and ensures all required tests and approvals are completed before final delivery.
In small projects where the Project Manager also manages the team, this interface becomes informal. However, in larger projects with multiple teams, the formal Work Package approach ensures clear communication and accountability between the Project Manager and Team Managers.
The Work Package concept creates a clear interface between management and delivery, ensuring that teams have everything they need to build products correctly. It prevents the common problem of teams receiving vague instructions and then being blamed when deliverables don't meet expectations.
第 8 章
Closing Projects Successfully: Finishing Strong
The 'Closing a Project' process ensures proper completion whether the project ends as planned or prematurely. This structured approach ensures nothing is overlooked and valuable lessons are captured for future projects.
When closing a project, the Project Manager must verify all work is complete by checking the Product Checklist, reviewing Checkpoint Reports from Team Managers, and confirming product status information shows most deliverables as "complete" or "approved." Additionally, the Project Manager must ensure all necessary acceptances and handovers have been properly documented throughout the project lifecycle.
Premature closure differs from planned closure in several key ways: it moves faster to minimize resource usage; focuses on salvaging valuable, nearly-complete products; requires notifying stakeholders about early release of resources and funds; may involve legal work if contracts are being terminated early; necessitates adjusting or scrapping the Benefits Review Plan; and includes examining whether the closure-triggering problem could have been spotted earlier.
When handing over final products, PRINCE2 requires checking that the working environment is ready for a smooth transition, ensuring adequate resources are available during the early life of deliverables when users need more support, and conducting both immediate and planned future benefits measurements. This responsible approach prevents the common problem of teams "throwing products at users and running out quickly before people discover that nothing works!"
Benefits assessment occurs in two phases: immediate benefits measurable at project end, and longer-term benefits that require later evaluation. The Project Manager reports any immediately visible benefits in the End Project Report, while planning for post-project benefits reviews through the Benefits Review Plan.
The project review evaluates performance against the original Project Initiation Documentation, producing the End Project Report that examines timing, costs, objectives, Business Case outcomes, team performance, and product quality. The Project Manager also compiles Follow-on Action Recommendations for work needed after project closure, and creates a Lessons Report documenting valuable insights for future projects.
In this final activity, the Project Manager gathers all end project documentation and submits it to the Project Board with a recommendation to shut down the project. This includes closing all logs and registers, with any continuing issues or risks documented in Follow-on Action Recommendations.
第 9 章
Effective Governance: The Project Board's Critical Role
The 'Directing a Project' process outlines how Project Boards should operate effectively. For PRINCE2 to function properly, both Project Managers and Project Board members must understand and use the method intelligently.
The Project Board's responsibilities mirror organizational management principles, with the project functioning as a temporary department. Key principles include taking ownership of the project (the project belongs to the Board, not the Project Manager), focusing on managing rather than doing the work, securing sufficient authority to make decisions, ensuring availability for project needs, and keeping board membership small and focused on essential roles.
The Project Board consists of three key roles representing different viewpoints: business, user, and supplier. The Executive represents the business viewpoint, holds ultimate responsibility for the project, and cannot share this role. The Senior User(s) represents those who will use the project deliverables and specifies business benefits. The Senior Supplier(s) represents those providing resources for the project work, with authority over supplier staff.
Project Board members collectively take responsibility for the project as part of the PRINCE2 Project Management Team. Though senior in position, they must cooperate with and support the Project Manager and Team Managers. The Board must make decisions without overstepping boundaries, listen to the Project Manager's advice, and fulfill joint responsibilities including approving plans, managing risks, monitoring progress, and making key project decisions.
Project Board members must determine appropriate control levels, balancing supervision with autonomy. PRINCE2 offers three mechanisms for setting Project Manager authority: Exception Management (setting upper and lower limits beyond which the Project Manager must report), Change Budget (allowing the Project Manager to implement minor changes without constant approvals), and Risk Budget (pre-authorizing contingency spending if identified risks occur).
Using Exception Management reduces the need for Project Board involvement during stages, but board members must remain available for informal discussions when the Project Manager needs advice. This includes situations where the Project Manager has authority to make decisions but wants guidance first.
Beyond providing ongoing advice, the Project Board has four specific decision points: authorizing project initiation after Start Up, committing to the whole project after Initiation, handling exceptions during delivery stages, and authorizing subsequent stages at End Stage Assessments.
第 10 章
The Business Case: Heart of the Project
The Business Case is a living document that justifies the project by demonstrating its value through compliance requirements, benefits delivery, or a hybrid approach. The Executive owns it, but the Project Manager develops and maintains it.
While PRINCE2 primarily focuses on business benefits, projects can be justified in various ways. Compliance projects are undertaken because they're mandatory, typically due to legal requirements. Most projects deliver business benefits, which should be measurable whenever possible. Benefits fall into three categories: direct savings (actual cash savings visible in accounts), quantifiable benefits (measurable improvements like staff time savings that don't directly reduce costs but improve efficiency), and non-quantifiable benefits (improvements that can't be easily measured but are still valuable).
The McCartney Report highlighted that a Business Case shouldn't just be created to secure funding then forgotten. Instead, it should be a "living document" maintained throughout the project's lifecycle. This ongoing monitoring is essential because changing circumstances can dramatically alter a project's viability.
A PRINCE2 Business Case includes several key sections: an executive summary that explains the overall balance of the case; reasons for running the project; business options considered; expected benefits with measurement plans; expected dis-benefits (negative outcomes); timescale estimates; costs that become more precise as the project progresses; investment appraisal using techniques like discounted cash flow; and major risks.
To verify if something is truly a benefit, ask "So what?" If you can't answer this question meaningfully, it's probably not a genuine business benefit. Technical features (like an integrated database) aren't benefits unless you can demonstrate concrete business value, such as saving 300 administrator hours monthly.
Benefits must be isolated from external factors to prove they're directly related to the project. For example, if membership in a professional organization increases 5% during a recruitment project, you must determine whether this growth resulted from the project or from other factors like positive publicity or industry trends.
The Business Case should include a Benefits Review Plan showing when benefits will materialize, when they can be measured, and who will measure them. PRINCE2 recognizes that benefits can emerge during the project, at its end, or well afterward. While the Executive ensures the Business Case is sound, Senior Users are responsible for specifying and delivering the benefits.
第 11 章
Quality, Risk and Change: The Essential Controls
PRINCE2's product-led planning approach enables precise quality control. By defining deliverables before activities, the method allows for specific quality criteria to be established for each product. Product Descriptions document what each product is, the standards it must meet, measurement methods, quality tolerances, and who performs quality checks.
PRINCE2 emphasizes delivering appropriate quality rather than universally demanding "top quality." The method helps deliver the right level of quality for each project, whether it's a quick solution or a safety-critical system. This practical approach prevents overstating quality requirements, which can increase costs, extend timelines, and potentially lead to quality being ignored altogether.
The Quality Register creates an effective audit trail for quality testing that prevents tests from being forgotten. During stage planning, all tests specified in Product Descriptions are copied into the Quality Register. As testing occurs, results are signed off in the register, with Error Sheets filed even when no errors are found.
For document products, PRINCE2 includes Quality Review as a specific technique. The review involves a structured meeting where participants examine a document section by section to identify errors and determine their severity. Four key roles participate: a Chair who runs the meeting, Presenter(s) who explain the product, Reviewer(s) who evaluate it, and an Administrator who records errors and needed corrections.
Risk management is another critical control area. PRINCE2 approaches risk management systematically, defining risk as uncertainty that could impact objectives. For effective risk management, each risk should be broken into three components: cause (trigger), event (the risk itself), and effect (impact). The probability-impact (p-i) grid visually maps risks using scales of 1-5 or 1-10 for both dimensions, revealing the overall risk landscape.
One major project killer is scope creep-the accumulation of small, seemingly insignificant changes that collectively overwhelm a project without corresponding increases in time, resources or budget. In PRINCE2, this can't happen because all changes come under formal change control. While PRINCE2 doesn't prevent change, it ensures changes are properly evaluated and resourced.
Configuration management (CM) is essentially version control-tracking which version of a product is current and managing changes. Without proper CM, confusion arises about which document version is latest or whether products are complete. CM differs from other PRINCE2 controls because it continues after the project ends, remaining necessary throughout the working life of products.
PRINCE2 offers simple but powerful controls that save time and provide clear project visibility. These controls operate at different management levels and fall into two categories: time-driven controls (scheduled reports) and event-driven controls (triggered by specific occurrences). The most important event-driven control is the stage-based approach, which provides the Project Board with excellent oversight while minimizing unnecessary meetings.
