Roles defined
Stakeholders in a typical project are divided into the business and the delivery communities. The boxes around the different groups indicate that they are isolated in silos: dependent on the interface between the project manager and the senior responsible owner (SRO). This 'human interface' is crucial to project delivery. Prince2™ identifies the roles of SRO and project sponsor as being important, but is ambiguous on the subject of exactly how they carry out their job functions. This is an oversight, as the success of the project is dependent on the relationships between the individuals who fulfill these roles. PrinceLite, on the other hand, highlights the SRO as the cornerstone of delivery success, and defines the skills any individual playing that role must possess to succeed. Too often the role of SRO is not supported with training. This is surprising, given the degree of training and formal qualifications that are required of the other roles. The SRO must have developed a 'locus of evaluation': the ability to differentiate between a sufficient unambiguous requirements specification and a wordy, bloated document, full of equivocation.
This diagram shows how the business and delivery communities are generally organised. It makes plain that the 'bridge' between the communities is primarily reliant on the relationship between the Senior Responsible Owner (SRO) and the Project manager. Other relationships exist such as that between the Business analyst and the users. In PrinceLite the relationship between the Project manager and the Business analyst is extremely important to success.
Typical stakeholder goals
- Senior managers: Interested in the big picture; in the vision and the strategy necessary to deliver the vision. Interested in budgets.
- Project sponsor: responsible for representing the strategic vision to the tactical business, and the progress of the project to the senior management team. A role that gets uncomfortable when progress is slow and difficult as budgets swell.
- Middle manager: Responsible for 'business as usual' and the management of programmes (groups of related projects)
- Senior responsible owner: in PrinceLite, the most important single role in ensuring project delivery success
- Users: Individuals who directly provide goods and services to the organisation's customers. During projects, users are called upon to cooperate with business analysts to help articulate business requirements
- Project manager: the role that provides the interface between the business via the SRO and the technologists working on the project
- Technologist: Technical people responsible for the delivery of projects. Includes business analysts, architects, designers, programmers and testers.
- Business analyst: another critical role in PrinceLite. The BA is responsible for producing unambiguous business requirements with the Unified Modelling Language.
The business community have a different perspective on the lifecycle of projects to that of the technologists. In the above diagram, blue states represent the project from the business perspective. Business project state reflects the state of funding.
- A mooted project is a suggestion that is being discussed and has no budget.
- A proposed project requires some initial funding. The output from the proposed state is a Project Brief.
- The proposed business state triggers the engineering inception state.
During inception, the Project Initiation document (PID) is produced. The quality and persuasiveness of the PID determines whether the project proceeds. The PID is a milestone. In PrinceLite, the PID contains 'high level' business requirements. High level business requirements are defined as those which are accurate but which are imprecise. Provided the PID is accepted, the project obtains funding (enters the business state 'funded') and moves into the engineering state elaboration.
- In elaboration the PID is transformed into the Business Requirements Specficiaton (BRS).
- The BRS contains mid-level requirements in terms of precision.
- If the project continues to be funded (satisfy stakeholders as to progress), the BRS is transformed into the Software Requirements Specification (SRS). The SRS contains low-level requirements.
- At any time funding can be withdrawn due to insufficient progress, or loss of faith.
In summary: The notion of project state from the business perspective is different from the software engineering notion of project state. Before a project reaches the first engineering state (e.g. inception) it must have secured some funding for the production of the PID. Further progress depends on the quality of the artefacts produced as milestones that trigger passage from one software engineering state to the next.