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.'
An artefact can be of type:
- Contemplation
- Progress reporting
- Software engineering
Contemplation is the activity of:
- deciding whether a project should be undertaken
- deciding whether a project should continue/be cancelled
Progress reporting
- an input to Contemplation
- a report of actual progress, supplemented with prototype demonstrations, against planned progress
Engineering
Understood as being comprised of four stages
- Stage 1 - inception (sometimes termed 'analysis')
- Stage 2 - elaboration (sometimes termed 'design')
- Stage 3 - construction (sometimes termed 'coding')
- Stage 4 - transition (sometimes termed 'testing')
Contemplation is understood as Stage 0.
Agile projects do not have the notion of stages per se. PrinceLite takes the view that within a particular stage the production of a prototype/code is managed according to Agile principles. The prototype/code needs to pass a quality threshold at some point to ensure something of value is being produced according to some planned expectation.
Table: The suggested set of artefacts in PrinceLite.
| Name | Type | Evaluator | Purpose |
|---|---|---|---|
| Blueprint | Contemplation | Senior management team | Define vision. Define the 'to be' organisation. No timescale constraints. The transformed enterprise 'wish list'. Used to evaluate project proposals. |
| Programme plan | Contemplation | 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. |
| Mandate | Contemplation | Senior management team | A short description of the proposed project before any funding is allocated. If accepted results in 'seed funding'. Seed funding used to produce the Brief |
| Brief | Contemplation |
Senior Responsible owner |
A more detailed description of the project. If accepted the project is funded and the PID is produced alongside a draft project plan. Later as a repository that provides an overview of project assumpitons. |
| Initiation document (PID) | Engineering (1) | Senior responsible owner | Defines project scope and high level requirements. Used to secure funding. Measured against the blueprint. |
| Business requirements specification | Engineering (2) | 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. |
| System requirements specification (optional) | Engineering (3) | Business analyst | Produced in the elaboration phase. Defines low level requirements. |
Solution design specification (optional) |
Engineering (3) | Architect, Designer, CEO | Defines a physical system to be built by programmers based on the organisations architecture and an implementation model. |
| Project plan | Progress reporting | Project manager | Manage progress, budget, resources. Informs programme plan. |
| Communications plan | Progress reporting | 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'. |
Artefacts in green are associated with governance, those in blue with engineering. The gap between the business and delivery community is bridged with requirements representation via the PID:BRS and Scenarios/test plan.