This is the process where things actually get produced. It is very simple but very context sensitive. The principles of the development process can be applied to any scope of work and in essence it is simply a process for delegation from one level in the organisation structure to another.
In some contexts this may be replaced with a specialised approach, e.g. in agile projects, it may be replaced with a scrum development process.
The goals of the process are to:
- transfer responsibility for a package of work;
- execute the package of work;
- transfer ownership of the finished products.
A work package can take many forms. It could be an entire project delegated by a programme management team to a project management team; a sub-project delegated by a project management team to a supplier; a single work package delegated to a small team.
Whatever the scale of the work package the principles remain the same. It must be adequately defined in terms of scope and performance criteria. Both parties to the transfer must be clear on what the work package is and the recipient’s ability to perform it.
Where the transfer involves a project being delegated by a programme, the authorise work activity may be the issue of a project mandate or the issue of a project brief. In the latter case, the authorise work activity is effectively the same as the identification process.
Where the transfer involves a project or programme team delegating work to a supplier, there will usually be contractual implications including negotiation of contract terms covering scope and performance.
As the scale of the delegation becomes smaller, it becomes a more personal activity. It depends upon the manager understanding the skills and availability of the team members accepting the work package.
Whatever the context, the team or individual receiving the work package have a responsibility to make sure they understand what is required and have the means to perform the work. A formal acceptance avoids misunderstandings later on.
Back to diagram
This activity is primarily about the creation of products. Most of the effort will be about technical functions and processes rather than anything uniquely P3 management. The important thing here is the two way link with co-ordinate and monitor progress.
The person with primary responsibility for the work package will need to plan the work and will have managerial duties appropriate to the scope of the work package. As the work is performed this person will monitor some or all of quality, schedule, resources, cost and risk as specified in the acceptance of the work package. Progress information must be fed back to the level above for consolidation with information from other work packages.
This is a two way exercise with information coming from the higher level that may affect the performance of the work, e.g. approved changes, delays in connected work, changes in priority and so on.
This connection between monitoring and control at different levels of a project, programme or portfolio is the heartbeat of the management organisation.
Back to diagram
The delivery of the products in the work package by the developer is subject to the same contextual variations as the initial delegation. In some cases, the deliver products activity may actually be the entire closure process. In others it will involve concluding a contract or perhaps simply receiving, testing and accepting a product created by a single person.
Records should confirm that the product has been satisfactorily completed and hand over.
Back to diagram
Projects and programmes
The project and programme processes in Praxis are designed to be used in different contexts. In small projects a separate development process may not be required. In larger projects, the delivery process can represent work delegated to a team or an external contractor. In a programme the delivery process is, in effect, a summary version of the project life cycle as shown below.
Click on the components of the diagram for more detail
In this context the authorisation of work at the programme level may be the same as the identification and/or definition process for the component project. Once this has been accepted by the project management team, they start to perform the work, i.e. the delivery process. Finally, the project delivers its products, which are accepted by the programme, and performs the closure process.
This demonstrates that the basic sequence of life cycle phases and their associated processes are common to all contexts. The difference is that in complex work there are more nested levels of life cycles.
Back to top