Clear Starting and End Point
(Know your CQEs and ACs - See below)

To be suitable for the use of PRINCE2® a project must have a well defined end-point at its start. Perhaps all too often a problem in many organisations!

“Well defined” means that project planning can estimate the likely project costs and benefits to perform a comparison of “Good Average and Poor estimates” of benefits and cost and schedule (known in PRINCE2® terminology as a GAP analysis[1]). For the start and end to be “well-defined” we must be able to compare costs with benefits accurately and with sufficient precision to be able to make the investment decision. “Well defined” also means with sufficient clarity to be able to define the correct level of monitoring and control given project significance and risk.

A. 7 Customer’s quality expectations

Classifies the content of fields in Project Mandate and Project Brief when considering:

  1. What elements of customer or supplier Quality Management Systems and Standards are relevant to the products of this project

  2. How will Management of Change be handled, post project, for the impact on Status Quo (staff/ procedures/ benefits assessment) of product roll-out into the business

  3. Are the Senior User and other customer’s aspirations** for what makes the project end-point acceptable as described in the Project Mandate or discovered during SU4

  4. Basis for deriving Acceptance Criteria including:

    1. Level of team & customer satisfaction

    2. Capturing expectations in whatever format best communicates customer needs & wants

A. 1 Acceptance Criteria

Contained in the Project Brief, Project Quality Plan and Product Descriptions

  1. Measurable (realistic & agreed) definition of the attributes of the project’s final product(s) critical to acceptance by customers and affected staff

  2. Realistic individually and in aggregate

  3. Often expressed as the Quality Criteria of the Product Description of the final product

  4. May be specified at multiple levels over a time-frame as benefits stream starts and improves over time

  5. May only be ultimately verifiable in post-project benefits review (eg Reliability, MTBF)

  6. Extended from A7 Customer Quality Expectations during SU4 and IP1

  7. Senior User accountable for specification of ACs

Suggested Composition includes

  1. Major functions, Operational running costs, Performance levels such as: Capacity, Accuracy, Availability, Reliability (mean & maximum time to repair, mean time between failures), Security, Ease of use or Level of personnel required to operate the product, Appearance and Timings

  2. Development costs and Target dates

*Tom Gilb writes on the topic of attribute specification and their evolution over time
**PRINCE2® view is narrower than best practice: bp is to consider all other stakeholders expectations    

PRINCE2® has a solution to poor definition at start-up: if the start-up elements of PRINCE2® that define ‘what’ we are to do and ‘how’ we will do it have difficulty arriving at a well defined end-point then we run them as a pre-project project whose sole aim is to identify the possible options, define each option’s business case, risks and (outline) project plan and then make recommendation about which option to pursue.

This pre-project project is often called a Feasibility Study. The feasibility study is constituted and executed as a PRINCE2® project that delivers to a well defined end point: “produce options and a recommendation”.

We can confirm that the project’s end is well defined at the start by inspecting the (A.2) Business Case to see if the final product(s) to be produced are stated with (A.1) Acceptance Criteria. If we know the products needed to enable the benefits stream described in the (A.2) Business Case well enough to plan tasks that will deliver the (A.1) Acceptance Criteria then we are ready to start a PRINCE2® project.

PRINCE2® tells us that we need to be clear about the end-point at the start but assumes we have the skills to elicit goals and define requirements in complete & unambiguous terms.

In general PRINCE2® assumes we are adding control to an already sound command of project management tools and techniques - ironically PRINCE2® is not aimed at beginners!

We have a range of basic project management training offerings, that fill in the gaps where PRINCE2® assumes you have the skills.

Quality

PRINCE2®’s treatment of quality is complete, mature and elegant. Quality touches every aspect of project definition, planning and execution. It binds all the parts of PRINCE2® together. The project is executed to deliver to the (A.1) Acceptance Criteria: the prioritised, agreed, measurable set of characteristics that the project’s results must meet.

(A.1) Acceptance Criteria are derived from (A.7) Customer’s Quality Expectations early in the project (SU4 and IP1 - refer to your process template to decode the names). (A.1) Acceptance Criteria  are reflected in four key fields within each (A.22) Product Description. (A.22) Product Descriptions and the (A.31) Project Quality Plan are used to ensure planning includes tasks with-in the plans that are  necessary to achieve quality before costs and schedules are compared to benefits and resources committed. The schedule of quality oriented tasks within (A.35) Stage Plans and Team plans are known as the Stage Quality Plan and Team Quality Plan - they are subsets of the schedule and quiet different in concept from the (A.31) Project Quality Plan which sets out quality policy, roles and responsibilities but is not a schedule of tasks.

Next Chunk of concept is Stages

[1]      PRINCE2® uses GAP to mean a three-point, probabilistic estimate, EG of costs or benefits. Not the commonly held definition of “Gap Analysis” being comparison between a requirement and the capabilities of a vendor’s offering.