Sign-off and the Project Board
What exactly is the project board for? The project board is an important concept in Prince2, but it is an example of a top down, command and control structure that makes it harder to deliver projects. For that reason the formal ‘project board’ is rarely constituted. It often exists only its omission.
In P2, the project board is a forum for problems to be escalated, rather like the United Nations for projects. In reality, this is not what happens. Presumably issues for the board’s attention are supposed to arise from the risk register. However the real risks to a project never make it onto the risk register. Writing a risk down on a register is, in effect, failing to deal with it, and escalating its resolution to someone else. It has to be assumed that the ‘someone else’ is meant to be the project board; the ultimate arbitrator of project disputes. Yet the type of risk that appears on a risk register is seldom a clear cut dispute between project stakeholders that lends itself to a simple resolution. One major risk I have experienced on a recent project was that the project manager was incompetent. How would that look on the risk register? In the end the ‘risk manager’ was sending emails stating the greatest risk to the project, was that there were no risks on the risk register, and consequently he had nothing to manage.
It is unclear where the senior informed individuals are going to come from to sit on the project board, how they have the necessary knowledge of project detail to make intelligent decisions in a timely way, how often they should meet, or the nature of the project board structure.
Instead of adopting this approach, the default PrinceLite position is to do without any structure or artefact that does not demonstrateably add to project delivery. Where a project board is deemed necessary for reasons of governance, the board should be informally comprised of project stakeholders who have other roles already and so are in a position to know what is going on in the project. A project board meeting could then be convened prior to a senior management board meeting to ensure the progress update reported to senior management is a true and agreed reflection of actual progress. However, in PrinceLite the primary role of the project board is to provide a forum for performing sign-offs. There are four formal sign-off functions defined at: business requirements specification, wireframe simulation, functional prototype and after user acceptance testing.
As a pragmatic framework, PrinceLite defines the sign-off process as having an informal and a formal stage. The informal stage of each sign-off is performed by the ‘power user’ who reports to the operational business unit manager (in P2 the ‘senior user’). The formal sign-off is undertaken by the senior responsible owner (SRO) once informal sign-off has taken place and in consultation with the other members of the project board.
In this way sign-off, which is always an elusive commodity in a project, can be sensibly addressed. It is only the power user who really is close enough to the operational nerve centre of the business to put their hand on their heart with conviction and say the system under consideration, being built, tested and deployed is suitable for the purpose to which it is intended. The power user is a very important role in many respects, not least in performing the informal sign-off, which is the seal of approval the SRO can rely on to report to the senior management team that all is well and they can have confidence in the ultimate project’s success.