Control
In PRINCE2, control of the technical work is exercised through the authorization of Work Packages. The Work Package is used to control the allocation of work to individuals or teams. "It includes controls on quality, time and cost and identifies reporting and hand-over requirements." The individuals or teams report back to the project manager via Checkpoint Reports or other identified means such as Triggers, and by updating the Quality Log.[26] Likewise, of course, the project manager reports back to the project's Executive.
The purpose of the Work Package is to:[27]
- Ensure the project remains viable against the Business Case
- Produce the required products, meeting the defined quality criteria,
- Carry out the work according to schedule, resource and cost plans
We have some concern over the first item because in PRINCE2 the Business Case is a "dynamic"[28] document because "It is updated at key points, such as end stage assessments, throughout the project."[29] True, this is to ensure that the business justification for the project is still valid, but there could be a tendency to match the Business Case to the current project reality rather than adjusting the project to satisfy a modified Business Case justification.
In PRINCE2 a project must get from a "basic business requirement" to the start of work on the actual outcome, or product, that is the objective of the project. We attempted to follow the flow through the prerequisite processes and their respective control document outputs to arrive at this start of work. This path is neither straightforward nor very clear. We counted eleven processes or sub-processes[30] and sixteen output documents in one form or another.[31]
It would be a good idea for PRINCE2 to heed its own advice by displaying a "product-based flow diagram" such as that advocated under "Product-based Planning".[32] It would be better still if it also showed how responsibility for the various document products flowed between the different levels of responsibility for the project. Then considerable simplification might be found possible.
It is true that PRINCE2 says that for small projects the two processes of Starting up a Project (SU) and Initiating a Project (IP) can be combined.[33] But in our view, for the majority of average projects, all of this could be consolidated into just two major documents. First is the Business Case, prepared by a business analyst or someone with similar skills, approval of which would authorize the necessary more detailed planning work. Second is the Project Brief (also known by others as Project Charter), approval of which would authorize the project manager to start production work.
26. Ibid, p229
27. Ibid, p227
28. Ibid, p376, the Business Case is listed as one of the "dynamic" contents of the Project Initiation Document.
29. Ibid, p329
30. Prerequisite processes to starting production work: Ad hoc source of Project Mandate (DP4); Preparing a Project Brief (SU4); Defining Project Approach (SU5); Planning Initiation Stage (SU6); Authorizing Initiation (DP1); Planning a Project (IP2); Refining the Business Case ((IP3); Assembling a (draft) Project Initiation Document (IP6); Authorizing a Project (DP2); Authorizing a Stage (DP3); Authorizing a Work Package (CS1).
31. Documents associated with the prerequisite processes to starting production work: Basic business requirements; Project Mandate; Outline Business Case; Project Brief; Project Approach; Draft Initiation Stage Plan; Authorization to Proceed (to initiating a project); Project Plan; Stage Plan; Updated Business Case; Draft Project Initiation Document (PID); Authorization to Proceed (to project); Approved PID; Approved Initiation Stage Plan; Authorization to Proceed (to work package); Authorized Work Package.
32. PRINCE2, p293
33. Ibid, p49
|