PROJECT MANAGERS COMPANION - OVERVIEW OF PRINCE
OVERVIEW OF PRINCE
1. THE ROLE OF PRINCE IN PROJECT MANAGEMENT
2. HOW TO START USING PRINCE
3. ORGANISATION
4. PRODUCTS AND ACTIVITIES
5. PLANNING
6. STAGES
7. CONTROLS
THE ROLE OF PRINCE IN PROJECT MANAGEMENT
A project can be defined as a temporary organisation , set up to achieve a defined outcome. Projects are by nature environments of change and thus require a different organisation structure to that required in line management.
Project management teams will necessarily have different interests and priorities to their customers, users or sponsors. Therefore, it is important to have a consistent approach to planning, problem solving and communication in order to ensure a successful outcome for the project
Using PRINCE helps ensure that the project delivers quality for the user or sponsor while remaining easy to plan and control for the project team. Features unique to the PRINCE method are.
*The concentration on products (the deliverables) of the project.
Under the PRINCE method, there is a unique set of products to be delivered for each project.
*An organisation structure with defined roles and responsibilities.
This provides the project with people committed to the outcome and ensures continuity of effort.
*The sub-division of the project into stages.
A stage is a section of the project whose activities and products are managed as a unit. Each stage provides management with a focus for decision making. ...
*The focus on business justification
Throughout a PRINCE project the business case is reviewed to ensure the project meets the business need.
*Flexibility of application.
PRINCE is designed to be used on all types of project and can be easily adapted to suit smaller projects.
As well as these features, PRINCE has a number of techniques that may be used to support project objectives. These include product planning techniques (e.g. Product Breakdown Structure and Activity Breakdowns) and the Quality Review Technique.
HOW TO START USING PRINCE
*Defining a Project
To start you must identify the project - that is the process of defining the problem and the proposed solution(s).
Next you must have a mandate to go ahead. A mandate could be anything from a verbal request to a formal brief.
Projects can be identified in a variety of ways. Each organisation will have its own way of doing things, however there must be a good reason for a project and an expected outcome. The following are some questions that should be asked when identifying a project:
Why are we doing this and what do we expect to get?
Do we have the correct authority and a mandate?
Do we have sufficient information to go ahead?
Is the work for the initiation stage planned?
How or from where is the solution to be sourced?
Who will be part of the team?
Once these questions are answered, the project can be initiated. It is important to make sure the project is properly controlled from the start and this is where the main components of the PRINCE methodology start to take effect.
*Components of PRINCE
PRINCE is a structured project management method which provides a framework and set of controls to enable management and project teams to efficiently specify and implement a project. There are five inter - dependent components of PRINCE. These are:
Organisation
Products and activities
Planning
Stages
Controls
The word Framework provides a key to how PRINCE should be used. Some parts of the framework are essential because without them PRINCE would lose its effectiveness. However, other parts of the framework may be adapted to suit a variety of organisations, project types and situations. For instance:
The Project Board and Project Manager roles are mandatory. Many other roles are defined by PRINCE and these may be applied or not, depending on the nature of the project.
Likewise, the number of stages is not prescribed (apart from having a beginning and an end stage) and neither is the method of setting them. The only requirement is that there must be stages.
The use of certain controls is also at the discretion of the Project Manager and Board.
The following five sections give an overview of the main components of PRINCE and their roles throughout a project.
ORGANISATION
Under PRINCE the roles and responsibilities of project personnel are clearly defined in a set of standard job descriptions. A team structure helps to ensure that management of the project is both efficient and responsive. Quantifiable and measurable objectives are easy to set as each team has specific products to deliver.
Establishing an effective organisation structure is crucial for project success and this must be the first step in any project. Someone is needed to make decisions and approve plans and someone is needed to do the initial planning work. Under PRINCE these responsibilities lie with member(s) of the Project Board and the Project Manager.
*The Project Board.
The Project Board is appointed for the duration of the project. It takes full responsibility for the outcome and represents the project before all external bodies.
PRINCE provides for three roles on a Project Board, to reflect the major interests of the project. These are:
Executive Role - appointed by senior management and responsible for overall project integrity, guidance and control throughout the life of the project.
Senior User - represents the users of the proposed system or products to be delivered by the project.
Senior Technical - responsible for overall technical guidance within a specific technical discipline(s) e.g. specialists in office automation or bespoke development.
On projects where the relationship with a supplier is crucial it may be appropriate to have a supplier representative on the Project Board. In this situation, the Senior Supplier role could replace the Senior Technical role, as the Supplier will be addressing technical issues amongst others.
It may not always be possible to appoint all members of the Project Board at project initiation stage, as the entire scope of the project may not be known. In this instance the Executive role should be appointed along with that of the Project Manager. The other members of the Project Board should be appointed as soon as more information is known. In some circumstances roles could be combined (i.e. one person could fulfil two roles providing there is no conflict of interest).
For small projects (measured by scope, costs and impact) it may only be necessary to have a single member project board, and a project manager who is also the only project resource.
The Project Board is responsible for ensuring that technical and business integrity is maintained for each stage of the project: It approves all major plans and authorises any deviation from agreed stage plans It also approves the completion of each stage and the start of the following stage, by reviewing the project status at each stage end. In addition it has the authority to commit resources, arbitrate in any conflicts, and approves the appointments and responsibilities of the project and stage managers.
*Project and Stage Managers.
In a large or complicated project (e.g. a major system development), the management skills required may differ during the project life-cycle. Specialist knowledge may be required on certain stages of the project. However it is also important to have continuity of management throughout the project. The PRINCE methodology therefore distinguishes between the roles of Project Manager and Stage Manager.
A Project Manager is appointed to assume all day to day responsibility for management of the project, throughout its stages.
A Stage Manager is assigned the responsibility of ensuring that the products are produced for each stage, on schedule, within budget and to the agreed quality standards.
Depending upon the nature or size of the project, the resources required, and /or skills mix available, the Project Board may choose to appoint:
One project manager, supported by a stage manager or managers for each stage
One project manager who assumes the role of stage manager, for separate stages or throughout.
Assignment of roles to other project personnel is a decision for the Project Manager. The effective use of people needs to be considered from the viewpoint of both their technical skills and individual personalities. The same individual may be assigned to more than one role, or different roles at different stages of the project if need be.
*Stage teams.
A stage manager is supported by a stage team who conduct the activities during each stage. The structure of the stage team(s) will depend on the nature and complexity of a particular stage, but will generally include staff from appropriate user departments and staff with relevant skills such as systems or business analysts. On large projects there may be several teams working on a stage, for example:
A system software team(s).
Applications software team(s).
A system test team.
In this instance, each team will normally have a designated team leader who is responsible to the stage manager for the planning and control of the detailed activities of that team.
There may be situations where specialists skills are needed on an ad - hoc basis (such as consultants) or where staff are not under the direct control of the stage manager (e.g. supplier provided teams). In these cases it is important to define reporting responsibilities at the outset, this should be done by the Project Board.
*Project Assurance Team.
The Project Assurance Team is optional. It may be appointed for the entire project or only part of it. It has delegated responsibility from the Project Board and reports directly to the Project Board.
The Project Assurance Team has three defined roles:-
User Assurance Co-ordinator represents the users on a day to day basis, and is concerned with ensuring users requirements are met in terms of content, presentation, timeliness, and any additional criteria for performance security and operability.
Technical Assurance Co-ordinator to maintain technical integrity on products. Technical criteria for a product are established during the specification and design stage and are monitored through out the system development. Effective feedback on changes / variances is essential for system integrity.
Business Co-ordinator to maintain administrative assurance controls. e.g. monitoring progress against financial plans and resource plans to confirm that the project is within budget and on schedule.
However, not all roles need be represented at once an individual may have more than one role there can be more than one individual within each role (e.g. User Assurance).
*Project Support Office
There are certain situations where a central Project Support Office may be useful e.g. an ongoing programme of small projects or additional support on very large projects. A PSOs functions typically include: administrative support, project planning and extra technical support.
PRODUCTS AND ACTIVITIES
Once you have identified a project and appointed people to manage it, you must establish what products are to be delivered in order for the project to achieve its objective. Products are specified during the initiation stage and are included in the Project Plan (planning is discussed in more detail in section 3).
Under PRINCE, products are categorised into two groups, these are either:
Products to address the business need. These are the deliverables of the project. Examples of Business Products include: a piece of software (either internally or externally developed), a Feasibility Study Report, a culture change or different organisation structure.
Generic products that result from using the PRINCE method. These are called management products and are common to all PRINCE projects. Examples of management products include: Project Initiation Document, Full Business Case, End Stage Report. A list of the management products of the PRINCE methodology is at Annex B.
To help the process of defining a product PRINCE has a number of product and activity planning techniques, which are summarised below.
*The Product Breakdown Structure
This is the PRINCE technique used to define all products that must be delivered as part of the Project Plan. Put simply, it is a process of working backwards from the main product (e.g. New Accounts System) and documenting all of the products required by asking the following questions.
What products are required to solve the business need?
What management products must be generated to ensure guidance and control?
What quality products must be delivered for quality assurance?
Does the plan rely on items from external sources?
Is responsibility for these identified and agreed?
How will external products be monitored?
*Product Descriptions
What is it? What form does it take? How will quality be assessed ?
*A Product Flow Diagram
This shows the sequence of production and the interdependencies of the products listed in the breakdown structure.
*Activity Breakdowns
list the activities needed to produce each product along with their dependencies on any other products, its activities or resources.
*The Activity Network
places the activities into logical sequence, so that timescales can be calculated and work scheduled.
PLANNING
A plan describes how, when, and by whom a specific target is to be achieved. Effective planning will help to ascertain if targets are achievable and is a useful control mechanism for the project manager as actual progress can be more easily measured.
On a PRINCE project, the planning discipline starts at the point the project is initiated. PRINCE prescribes a structured set of plans to document and identify what is needed to achieve project objectives. These cover both technical, resource and quality issues.
In general, PRINCE plans should contain the following information:
Identify and define all the products to be delivered.
Define activities which will build and test products.
Identify standards and methods to be used.
Set objectives, estimate and allocate resources and responsibilities for teams.
Define timescales and delivery schedules and identify dependencies on other resources / products.
PRINCE specifies several levels of planning to reflect the needs of the different levels of management used in the project.
*A Project Plan
This is an overview of the project. It forms part of the Project Initiation Document, a major management product of the Initiation Stage.
The Project Plan identifies key deliverables, resource requirements and total costs.
It also identifies the major control points and stage boundaries within a project. The plan is updated at the end of each stage to reflect the progress made and to include revisions, if necessary.
*Stage Plans
These are required for each stage identified in the Project Plan. Each Stage Plan is produced near the end of the previous stage. Much of the work in a stage may be done by specialist teams or suppliers who will also have their own plans for the work required. This means that the Project Manager and Stage Manager will need to construct a Stage Plan from various sources in order to establish an overall resource, timing and quality picture for the stage products.
*Team Plans
These are optional and are used to breakdown activities into tasks to produce one or more of a stage plans products. They might be used for separate teams working in a stage , or work for single contractors. A team manager would use a team plan.
*Quality Plans
Quality planning is the process of identifying and resourcing the activities that will ensure the quality of the products. To do this, departmental quality criteria must be built into the Project Plan and, if appropriate, Stage Plans. In this way Quality will be reflected at each level in the process.. The following are quality issues that might be considered at the various levels of planning.
Set the overall quality strategy for the entire project.
Define the quality criteria and standards for major products.
Identify external constraints to quality assurance (e.g. products provided from external sources).
Identify the resources needed to perform the Quality Review Technique.
In a complex or highly technical project a separate detailed Quality Plan is recommended. This can be reflected at stage level when Quality is a special consideration, e.g. Acceptance Testing, or at Team Plan level if co-ordination of team activities is a major issue.
*Exception Plans
When it is predicted that a product or activity will no longer achieve the planned outcome, an Exception plan is produced. An exception plan has the same format as the plan which it will replace but the text will cover:
What has caused the deviation.
What is anticipated if no action is taken.
The available options.
The impact of the exception plan on the project plan, business case etc.
STAGES
Once the planning and product definition has been done, you will need to decide how the project might best be broken down into logical stages or events. It is sensible to do this so that a number of decision points can be established throughout the project. This allows you to decide at the end of each stage whether to continue with the project.
Every project will have at least two stages, an initiation stage and the remainder of the project.
An initiation stage may only last a few hours but is essential, in order to ensure that there is a firm basis of understanding and agreement from which to move forward.
The remainder of the project can be divided into stages depending on the complexity of the project.
One method of setting stage boundaries is to establish key events during the project. e.g. In building a system, this might result in stages covering definition of requirements, programming, implementation and testing.
Another method may be to set a stage boundary on a periodic basis (e.g. a stage end every 2 months).
CONTROLS
Under PRINCE progress is monitored against plans, however there needs to be an consistent way for the project board to control actions and make adjustments, if necessary. PRINCE prescribes a set of management of Controls (usually in the form of review meetings) to ensure that the project is:
Producing the required products which meet acceptance criteria.
Being carried out to schedule, in accordance to its cost and resource plans.
Still viable against the business case.
The appropriate level of controls is established by the Project Board during Project Initiation and will normally have some tangible output ( usually a management product).
Staff involved at control points will depend upon the level (stage) of the work reviewed. The following is a list of the main PRINCE Management Controls.
*The Project Initiation meeting
Very large projects may require more than one project initiation meeting. The objectives and products of this meeting are as follows:
To define the project organisation: The Project Manager, Stage Manager for the initial stage and Project Assurance Team are all appointed at this meeting.
To agree a formal project brief: This defines the major objectives and products of the project plus any constraints placed on the team.
To agree the project boundary e.g. how related projects interact, where output from one project forms input to another, possible IT security risks etc.
Approve the project plans and first stage plans.
Approve a formal Project Initiation Document. The Project Initiation Document becomes the Terms of Reference for the project and includes all the items above in addition to the Business Case.
*Checkpoints
These are regular internal progress meetings conducted by the Stage Manager or Project Assurance Team. They are used to check and update actual achievement against plans and to record actual resource usage against planned usage. Stage team leaders can also attend this meeting. As a result of such checkpoints the Project Manager may be required to submit Highlight Reports to the Project Board.
*Mid Stage Assessment
This meeting may be defined in the Project Plan or may be held at any point during a stage, at the discretion of the Project Manager or Project Board. An MSA may be held for the following reasons:
To approve exception plans
To authorise work to begin on the next stage before the current on is complete
As an interim control for the project manager and project board
*The End Stage Assessment
This is a mandatory control which occurs at the end of each stage. It is a formal presentation by the Project Manager, to the Project Board, of the current project status. The Project Assurance Team and current Stage Manager and next Stage Manager also attend this meeting. The objectives of the ESA are as follows:
To demonstrate to the board that the products of the current stage have been delivered within the quality criteria and tolerance levels set. this is done by compiling an End Stage Report.
To submit plans for the next stage for approval and commit the required resources.
*Quality Review Meeting
This is a formal meeting designed to ensure product completeness and adherence to the standards specified in the product description. PRINCE has a detailed technique for the review process which includes objectives, roles and responsibilities. The Project Board must choose those individuals who are most appropriate to participate. These may include people with relevant technical skills, users, members of the Project Management Team or Project Assurance Team. The main roles are as follows
The review chairperson - controls the meeting and prepares follow up action.
Reviewers to check the product for accuracy and consistency.
The presenter - is the person responsible for the product and who deals with any actions following the review.
Business Assurance Co-ordinator - checks that reviews take place as planned.
*Exception Controls
There are various ways in which an exception to planned progress can be raised. PRINCE uses three management products to identify exceptions. These can be raised at any time (though in practice it is usually the End Stage Assessment) and would be the starting point of an Exception Plan.
A Project Issue Report is used to raise any issue relating to the project. It may address a management or technical problem.
An Off Specification Report is used to highlight something that should be required by the project, but is not. This may be a missing product or one that fails to meet its specification.
Request for Change is used to notify a required change to a specification of product during its development
*Project Review
The Project Manager and the Project Assurance Team are responsible for evaluating project performance and issuing a Project Evaluation Report before the closure of the project.
*Project Closure
The completion of the project (i.e. satisfactory delivery of the required products) is certified by a series of formal letters signed by members of the Project Board. These comprise (as appropriate):
System Acceptance Letter - ensuring the quality of the system and / or products delivered.
User Acceptance letter - ensuring the system complies with user acceptance criteria
Business Acceptance Letter - informs senior management of the successful completion of the project.
Operations Acceptance letter - ensuring the system complies with operations acceptance criteria.
A Security Acceptance letter - optional and determined by the sensitivity of the project work.
As part of the Project Review, parameters for the Post Implementation Review should be set. The Post Implementation Review will usually be carried out after the system has been operating for a reasonable period.
GLOSSARY OF TERMS
*Product, Deliverable or Outcome
is used to describe everything that has to be created or changed by the project.
*Customer
the person/s who have commissioned the work and will be (hopefully) be benefiting from the outcome.
*User
those who will use or operate the product
*Supplier
the group who is providing, specialist skills, or goods and services to the project. They may be internal or external.
MAIN PRINCE MANAGEMENT PRODUCTS:
*Project Brief
a statement of terms of reference for the project, initially provided by the sponsor and subsequently refined by the Project Board to form part of the Project Initiation Document.
Project Initiation - this document is approved by the Project Board at Project Initiation. It defines the terms of reference for the project, based on the initial project brief provided by the sponsor. It has the following components:-
Business Case
Business Risk
Business system definition
Business needs
Information needs
Key Performance Factors
Organisation and Responsibilities
Project Plan
Resources allocated
Security risk
*Business Case
the information which justifies the projects existence - the estimated cost of development and anticipated gains in business benefits. Under PRINCE, the ongoing viability of the project is monitored by the Project Board against the business case.
*Project Plan
a high level plan detailing how when objectives are to be realised by showing major products, activities, resources required, stages and controls. Used to manage the project and to measure actual progress.
*Quality Plan
The definition of key quality criteria, quality controls and audit processes to be applied to products of the project.
*Stage Plan
used as a basis for control throughout a stage identifies products, how and when objectives are to be achieved, control points etc.
*End Stage Report
a summary of progress to date, prepared for each stage end assessment. The project board use the information to decide what action to take next. i.e. approve next stage, revise next stage plan etc.
*Highlight Report
to provide the Project Board with a summary of progress during a stage.
*Exception Report
produced when the outcome of a stage is expected to deviate from stage plans. Exception Report will normally result in the project board requesting an exception plan.
*Off Specification Report
to document any situation where a product is failing or expected to fail to meet its specification.
*Project Issues
a generic term for documenting any matter which must be brought to
to the attention of the Project Board.
*End Project Report
this is produced when closing a project - it is the project managers report to the board on how well the project has performed against its Project Initiation Document.
*Post Implementation Review
this is planned in the final stage of the project but produced after the final delivery of the business product . It assesses if the expected benefits have been realised or any problems arisen.
