Suggested Artefacts
It is not always easy to identify which artefacts are essential to support project delivery, and which are not. The table below sets out the minimum set of artefacts that all have evident stakeholder value. This is not to imply that you may find specific other artefacts useful in certain circumstances. Remember however that the test for usefulness in PrinceLite is that any artefact must have an owner, an author, and a peer reviewer. An artefact should be useful/crucial to the owner in performing their role. An artefact should be maintained or evolved; it should not be filed and forgotten. The guiding principle is that 'if no one needs it - don't produce it.'
Table: The default set of useful/crucial artefacts in PrinceLite.
| Name | Type | Stakeholder | Purpose |
|---|---|---|---|
| Blueprint | Business strategy | Chief executive officer | Define vision. Define business objectives within the planning/funding period. Used to evaluate project proposals. |
| Programme plan | Programme management | Programme manager | A summary of proposed projects and 'in-flight' projects. A summary of project state. Includes benefit realisation. Used to report progress to senior management. |
| Project brief | Project outline | Senior responsible owner | A brief description of a project. Used in the 'muted' state. Determines if a PID should be produced. |
| Project initiation document (PID) | Project outline | Senior responsible owner | Defines project scope and high level requirements. Used to secure funding. Measured against the blueprint. Mandatory |
| Business requirements specification | Requirements engineering | Senior responsible owner | Produced when project is agreed (funded). Includes an elaboration of the high level requirements from the PID. Contains mid-level requirements. Used to validate decision to fund. May be used to inform a prototype. When accepted project moves into elaboration phase. Mandatory |
| System requirements specification | Solution design | Business analyst | Produced in the elaboration phase. Includes an elaboration of the mid-level requirements to produce low-level requirements. Defines a logical system. Mandatory |
| Solution design specification | Solution design | Architect, Designer, CEO | Defines a physical system to be built by programmers based on the organisations architecture and an implementation model. |
| Project plan | Project management | Project manager | Manage progress, budget, resources. Informs programme plan. |
| Communications plan | Project management | Project manager | Define who will get what communications concerning which issues. Although the SRO may own an artefact, they do not necessarily own the entire process of artefact evaluation. The communication plan defines who is 'in the loop' and the nature of each 'loop'. |
| artefact plan | Project management | Project manager | Defines which artefacts will be produced. This table is an example of an artefact plan template. |
Click here to see diagram at full size
Figure : Populating the Prince Lite artefact taxonomy with specific artefacts aimed at identified stakeholders
One of the risks to successful project delivery is the polarisation of the business and delivery communities. The figure above introduces a bridge between the communities at the level of 'Project outline' and 'Requirements engineering'. This bridge is an innovation in Prince II that translates into there being a requirements artefact that acts as the basis of the 'contract' between the business and delivery.
The above figure maps the minimal artefact set to the community model. It introduces the Requirements engineering layer that now spans the two communities to accommodate the requirements specification set introduced in the discussion about mandatory artefacts. The PID is considered part of Project outline until a decision is taken to fund the project at which point it becomes an input to the creation of the BRS.