Optional artefacts
To test whether a particular artefact should be employed it must be of sufficient importance to a stakeholder who will consume it in order to achieve one of their primary goals. Not producing the artefact should represent a project risk. The artefact must be non-trivial, implying it cannot be satisfied in a few words. Lastly the artefact should benefit the project by being maintained throughout at least one phase of the project lifecycle (implying that it will not be immediately 'filed' and forgotten).
PrinceLite can be as 'lightweight' or 'heavyweight' as the artefact plan[1] suggests. One approach to evaluating whether a particular artefact should be included is to apply the tests suggested in the table below.
Table: When deciding which artefacts will be produced in any particular project, it is helpful to do a document review and then test the results with the stakeholders to ensure the team produces only what is deemed helpful in project delivery terms.
| Trivial | Maintainable | Identified owner | Produce artefact | |
|---|---|---|---|---|
| Project brief | no | yes | Senior responsible owner | Yes |
| Quality plan | yes | no | - | No |
| Risk register | no | yes | No |
In the example above, the Quality plan would not be produced because it is not maintained and no one can be identified as owning it. Projects are expected to deliver a high quality deliverable, there is little need for a plan to state the obvious. In the case of a risk register, there is no point in producing one unless somebody is tasked with doing something about it. It is probably better to solve the problem then record it on a risk register. The risk register can too quickly descend into 'covering ones back' (for which there are more colourful alternative descriptions).
[1] An artefact plan is a list and evaluation of the artefacts that have been selected to support project delivery. Obviously if the project chooses to use the minimal set no artefact plan would be necessary.