Defining projects and programmes
It is clear that some artefacts are produced before others. For example the brief comes before the project initiation document. However, it is simplistic to imagine the brief is the first artefact to be produced overall. Ideally, the process begins with an articulation of the vision (blueprint) against which a logical strategy is produced. This strategy must be judged on its own merit and accepted, modified or rejected. There is no way of knowing at the outset, how many projects will result from a single logical strategy proposal. It is rather a question of resources, timescales, and dependencies. Generally smaller projects are to be favoured over large ones (in terms of the number of people working together). Generally shorter projects should be defined over longer ones due to people loosing focus over time. These considerations will impact on the absolute number of projects you will define - which will inform the number of project briefs that need to be written. Lastly, you must consider how projects should be grouped together into programmes. This consideration will be driven by questions of dependency.
A strategy is a suggestion as to how the vision will be satisfied. The strategy is a statement of the end-to-end sessionless problem landscape that includes high level requirements that define scope. Given the strategy is acceptable in principle, it may be divided into projects for implementation reasons. This process of division creates dependencies between projects.
If there are a great number of projects identified these may be grouped together into different programmes for management convenience.
Click here to see diagram at full size
Figure: The vision statement is satisfied by the strategy. The strategy is satisfied by projects. Projects are grouped into programmes. Once the shape and structure of the projects is known the remainder of the programme documentation can be produced.
If there is only one physical project, the process depicted in the figure above does not require a programme be defined. Otherwise, multiple projects may be combined into a single programme, or if there is a basis of commonality and strong dependencies between sets of projects, multiple programmes may be defined. In either case, a programme structure must be created to monitor progress across programmes and within projects for the purpose of reporting to senior management.