File Name: 10-1257-guidelines-for-managing-projects.pdf
File Size: 375.20 KB
File Type: Application/pdf
Last Modified: 10 years
Status: Available
Last checked: 2 days ago!
This Document Has Been Certified by a Professional
100% customizable
Language: English
We recommend downloading this file onto your computer
GUIDELINES FOR MANAGING PROJECTSHow to organise, plan and controlprojectsNOVEMBER 2010 CONTENTSSection 0: The Purpose of the Project Management Guidelines .......................... 3What is a successful project? ...............................................................................................................3Are projects different from the other work? ........................................................................................3Why use these guidelines? ...................................................................................................................3What these guidelines cover - and do not cover ................................................................................4The project lifecycle ...............................................................................................................................5Programme and Project Governance ...................................................................................................7Scaling project management to suit your project ..............................................................................8Using project management templates .................................................................................................8Section 1: Starting up a new project ....................................................................... 9The Project Brief ....................................................................................................................................9Developing a Project Brief to suit the project context .....................................................................10Defining project scope and objectives ..............................................................................................11Defining the Benefits ...........................................................................................................................15Designing the Project Organisation ...................................................................................................17Section 2: Initiating the Project .............................................................................. 21Project Initiation Document (PID) .......................................................................................................21How the Project Initiation Document (PID)is used ...........................................................................21Developing the Project Initiation Document .....................................................................................21The Business Case ..............................................................................................................................22Stakeholder analysis and management .............................................................................................24Planning the project .............................................................................................................................27The steps in planning ..........................................................................................................................27Risk management - avoiding pitfalls and managing opportunities ................................................30Approving the Project Initiation Document .......................................................................................33Section 3: Running the project .............................................................................. 34Control - the key to a successful project ...........................................................................................34Creating the right environment for control .......................................................................................34Breaking the project down into manageable stages ........................................................................35SRO/Project Board controls …………………………………………………………………………………36Project Manager's Controls ................................................................................................................37Handling significant deviations from plan ........................................................................................38Handling Issues, Problems and Changes .........................................................................................39Changing the approach to project governance ................................................................................40Document version control and configuration management ............................................................40Summary of project controls after approval of the Project Brief ....................................................42Section 4: Closing the Project ............................................................................... 43Project closure checklist .....................................................................................................................43Section 5: Realising the Benefits ........................................................................... 44The Benefits Realisation Plan ..............................................................................................................44Appendix A: Project Management Documentation templates ............................ 45 2 Section 0: The Purpose of the Project Management GuidelinesThe purpose of these project management guidelines is to help you to organise, plan andcontrol your projects. They are designed to help you to maximise the potential for yourprojects to succeed by helping you address each element of your project at the right timeand to the right level of detail for the size and complexity of your projectWhat is a successful project?To be successful a project must:• deliver the outcomes and benefits required by the organisation, its delivery partners and other stakeholder organisations;• create and implement deliverables that meet agreed requirements;• meet time targets;• stay within financial budgets;• involve all the right people;• make best use of resources in the organisation and elsewhere;• take account of changes in the way the organisation operates;• manage any risks that could jeopardise success;• take into account the needs of staff and other stakeholders who will be impacted by the changes brought about by the project
Are projects different from the other work?Projects are different from the normal operation of the organisation in that they:• have specific objectives to deliver new benefits to, the taxpayer, companies, the general public, government, the sponsoring organisation, stakeholders and/or delivery partners;• may introduce significant changes to the way the business operates;• create new outputs/deliverables that will enable benefits to be realised;• have a specific, temporary management organisation and governance arrangements set up for the duration of the project;• are susceptible to risks not usually encountered in the day to day operational work of the organisation;• involve a range of stakeholders from different parts of the organisation and beyond;• may use methods and approaches that are new or unfamiliar
Why use these guidelines?Unfortunately projects sometimes fail to deliver, for a variety of avoidable reasons, e.g.:• failure to take into account the needs and influences of stakeholders;• failure to communicate and keep the stakeholders informed of developments;• lack of attention to the impact of project work on the normal business of the• organisation;• producing expensive ‘Gold plated’ solutions when simple workable products would suffice;• failure to identify and deal with the many risks that can affect achievement of project objectives;• insufficient attention to planning, monitoring and control of the work of the project
3 This guidance will help you manage these sorts of avoidable problems. However, it shouldnot be regarded as set of standards to be followed slavishly in all circumstances. On thecontrary, there are many decisions you must take about the degree of management rigouryou feel is necessary to maximise the chances for success and minimise the likelihood ofproject failure. This guide will help you make those decisions
What these guidelines cover - and do not coverTo help you manage your projects the guidance, which can be applied to any type ofproject in the organisation and its delivery partners, provides:• the ‘what, why, who, when and how’ of project management activities;• advice on scaling project management projects of different sizes, duration and• criticality;• flowcharts and checklists to steer you through key project management tasks;• access to templates for essential project management documents/forms
The following are not addressed in the guide, but are available from a variety of othersources:• general project management theory;• the details of the PRINCE2 methodology (although the guide is fully consistent with PRINCE2);• instruction in how to apply generic project management techniques;• the soft skills necessary for effective project management 4 The project lifecycleIn order to manage effectively it helps to understand the typical lifecycle of a project and how itapplies to your specific project. You need to decide how the management activities of thelifecycle steps will be achieved, and precisely who will be involved. You must make sure youunderstand your role in making these things happen in the right way and at the right time
Much of the project management effort across the lifecycle will be driven by theowner/sponsor of the project (known as the Senior Responsible Owner (SRO) ), and theProject Manager. To achieve success they will almost certainly need to draw upon the skillsand experience of many others from within the organisation, its partners and suppliers
The BIS Project LifecycleWhile Step 3 - Running a Project is by far the most resource intensive part of the project, it isthe care and effort devoted to project start up and initiation that makes the most significantcontribution to project success. The following diagram summarises the project managementtasks at each step in the lifecycle
5 The SRO, or identifier of the potential project should: Define and justify the need for the project Starting up a Specify, quantify and agree desired outcome and benefits new project Appoint a Project Manager and if appropriate set up a Project Board Ensure the reasons for the project and its TOR are defined in a Project Brief Ensure it is aligned with strategic/business planAuthorisation to The SRO/Project Board must decide whether it is sensible and viable to proceed into the initiation stage of the project proceed toproject initiation The project management team should: Plan how to deliver the required outcomes and benefits Decide how to manage relationships with key stakeholders Initiating the Decide how to project manage the delivery process Determine resource requirements and ensure they can be made project available when required Develop Business Case to enable the SRO/Project Board to decide whether project is cost and risk justified Document the understanding of the project and how it will be managed in a PID Approval of the The SRO/Project Board must assess PID (in particular the Business Case) to decide whether the project is worthwhile,Project Initiation viable, affordable and appropriate at this time
Document The project management team should: Mobilise the staff and other resources needed to build the products and deliverables that will enable the required outcome Plan, monitor and control the work and resources of the project Manage risks and issues as they occur Running the Maintain communications with those impacted by the project and project its outcome Report progress and issues to SRO/Project Board/Stakeholders Decide ongoing viability in the light of experience and any changes in requirements Ensure deliverables are fit for purpose and will enable benefits to be realised The project management team should: Evaluate the outcome of the project against the PID Project closure Ensure that any lessons learned are shared with those who might benefit from them Release resources used by the project Review any benefits achieved by the end of the project SRO confirms The SRO should close the project and ensure that: Plans exist for a post project review to measure to what degree closure of the the benefits have been achieved in practice project Determine the need for any improvements or modifications Ensure that the project is handed over to a person who will deliver the outcomes The SRO should ensure: Post project reviews are carried out to measure the degree to Benefits which benefits have been achieved realisation The Business Case is updated to reflect operational reality Potential improvements/changes/opportunities identified in the reviews fed into the strategic planning process for consideration 6 Programme and Project Governance"Governance - the functions, responsibilities, processes and procedures that define howthe programme is set up managed and controlled" (source: OGC Managing SuccessfulProgrammes)PurposeAll projects involve decision-making and stakeholder relationship management at differentpoints in the project lifecycle and at a variety of different levels. The decision-makingelement should ensure that a new project does not start or continue unless it is:• Worthwhile• Viable• Affordable• Good value for money• Planned and controlled• Within tolerances for acceptable riskGovernance provides the framework for such decision-making. The project governancearrangements must be designed during Project Start-up and will usually be a tailored blend ofthe basic requirements mandated by your organisation and any specific arrangements to meetthe needs of a particular project. The tailoring will depend on such things as predictedbenefits, cost, urgency, complexity, risk and type/quantity of stakeholders
What Project Governance involvesProject Governance provides a framework within which to manage and should cover:• Initial and continuing justification of the project• Setting up an appropriate management organisation• Establishing a framework for decision-making (roles/responsibilities/authorities)• Ensuring sufficiently thorough plans are prepared and updated as necessary• Implementing a stakeholder management strategy• Putting in place a quality management strategy• Setting up and operating a project monitoring and control regime• Managing uncertainties (threats and opportunities)• Managing problems and changesThe basic Governance framework is established at project start up and results in a decisionbeing taken whether or not the proposal as documented in the Project Brief should goahead. This decision is taken by the Senior Responsible Owner (SRO), perhaps supportedby other key stakeholders as part of a Project Board, and is the formal start of the project
Governance arrangements should be reviewed and, if necessary, revised as the projectprogresses
7 Scaling project management to suit your projectEach project must be considered on its own merits when it comes to deciding the degree ofrigour required for project management. The factors that will contribute towards yourdecision on how extensively you will apply these guidelines include:• Criticality to the work of the organisation and/or its delivery partners• Value of benefits expected from the project• Degree of risk• Likely duration• Amount of effort required to deliver• Complexity• Likely spend• Multi-disciplinary requirements• Source of funding• Degree of impact on different parts of the organisation and beyond• Requirement to involve external suppliers and partner organisation the projectUsing project management templatesThese guidelines are supported by a set of templates and examples to help you at allstages of the project lifecycle. They are provided as separate `free-standing' documents in aform that you may use and modify as required (i.e. Word or Excel format)
A list of all suggested templates is at Appendix A
The templates and these guidelines will be updated from time to time to improve usabilityand bring in line with emerging best practice
8 Section 1: Starting up a new projectStart-up is triggered when a Senior Responsible Owner (SRO) agrees/decides to takeresponsibility for a new initiative that might best be run as a project. The trigger may comefrom business planning, an external driver (e.g. EU legislation, compliance requirement) oridentification of a significant problem that cannot be dealt with as a matter of routine
At the end of start-up a decision whether or not to move ahead is made. This decision is madein the light of the information gathered during start up and recorded in a Project Brief. Inessence, the Project Brief says why the project is needed, what it must achieve and whoshould be involved. There is no set method for conducting start up, in practice it will depend onthe size and complexity of the work and whether, for example, some form of feasibility studyhas been done
By the end of project start-up all interested parties should be satisfied that the followingaspects of the project are clearly defined and understood:• The reasons for the project• Desired benefits and who will realise them• Scope - what in and what's out• Objectives - achievable and measurable (SMART)• Background - why does this project need to be done and why now?• Constraints that must be taken into consideration during the project• Assumptions• Any known risks• Dependencies on other projects/activities/decisions• Stakeholders (internal and external)• Deliverables/outcomes• Estimated timescale• Estimates for resources required• Lessons learned from similar projects and/or from people who done similar projectsThe Project BriefPurposeThe Project Brief is an initial view of what the project is to achieve and will identify keyelements of the project and steps that will be followed to reach the objectives. It forms thebasis of agreement between the Senior Responsible Owner (SRO) and the project managerand team and sanctions moving the project forward so more detailed planning can beundertaken
How the project brief is usedAt the outset of a project there may be a mandate (often as simple as an email) from asenior manager indicating what is required. Following further discussion and a review ofhow to achieve the objectives it is useful to record this information in a project brief toensure buy-in from senior management and stakeholders before significant resources orcosts are committed
9 Completing the sections of the brief will ensure all key areas of the project havebeen thought-through and buy-in obtained
Approval of the Project Brief is the official start of the project where the SRO/membersof the Project Board must confirm that they:• understand and agree the terms of reference of the project• are willing and able to commit their time to the direction of the project• are willing to take joint ownership of the project• are willing to provide the Project Manager with the time and resources• needed to plan the project in detail and to produce the Project Initiation Document (PID)
The degree of formality of this control will vary. The members of the Project Board or SROcould use email to give the Project Manager authority to proceed to the Project Initiationstage or, on a large project they might use it as an opportunity to meet (perhaps for thefirst time all together in the same room) and ensure common understanding andcommitment to the project
ContentsThe Project Brief will cover all the key areas of the project giving details of:• Objectives• Scope• Deliverables• Business Benefits• Assumptions• Constraints• Risks• Other Areas of Business Affected• Major Dependencies• Stakeholders Resources• Outline estimates of time and costDeveloping a Project Brief to suit the project contextThe Project Brief, giving details of what is expected from the project, should bedeveloped early on in the project's life and is produced by the project SRO or by theproject manager based on information received from the SRO
For small projects this will be a very short document often with only a few sentencesfor each section; larger projects may require more detail to ensure the full scope andcomplexity of the project can be understood and recorded
For further guidance on the contents for each section please refer to thedownloadable template
If the project will be short duration, well-defined and it is absolutely certain that it mustproceed then it might be appropriate to move straight on to production of the ProjectInitiation Document (see Section 2: Initiating the Project) after a short, sharp start-up phasebut without the intermediate step of the Project Brief
10 Defining project scope and objectivesThe relationship between a project's benefits, scope and objectivesProject objectives, scope and desired benefits must all be addressed when starting up a project,and should be recorded in the Project Brief, and subsequently refined in the Project InitiationDocument (PID) during detailed project definition and planning
It is sometimes difficult to avoid some degree of overlap between what is defined in the scope,objectives and benefits - j u s t try to minimise the repetition while ensuring you retain theconsistency, clarity and measurability of what you define. The figure below may help you gain anunderstanding of the relationship between a project's objectives and the benefits arising from thatproject. The scope of the project must be defined such that the objectives can be achieved andthat realisation of the desired benefits is enabled within the scope as defined. In this way theyprovide a useful crosscheck against each other
Relationship between project objectives and benefitsWhat is meant by the ‘Scope’ of a project?By defining a project's scope you are trying to do a number of things:• ensure that the boundary between this project and other projects and programmes is clearly understood and prevents gaps or overlaps in all the work that is necessary to achieve higher-level objectives• ensure that the work that the project must do, and what it is specifically excluded from doing, are defined and agreed by interested parties• create a baseline for subsequent change control so that the damaging effects of ‘Scope creep’ can be minimisedWhen defining a project's scope there is usually no need to re-iterate the objectives orbenefits
Sometimes it is possible to express the scope as a list of deliverables, perhaps with somecovering statements of the sort shown below
11 Project A:In scope:Identification of areas of potential efficiency gains and production of a prioritised action plan
Out of scope:Implementation of the action plan
Project B:In scope:Implementation the agreed elements of the XYZ efficiency action plan Specificationof required information systems enhancementsOut of scope:Changes to information systems which will be carried out as part of project ZProject C:In scope:Changes to existing legislation to meet EU requirement X
Out of scope:Changes in Scotland or Northern IrelandProject D:In scope:Changes to staff conditions of service for purpose P
Out of scope:Staff that joined before date dd/mm/yy
You will find that spending time discussing and agreeing the scope with stakeholders during ProjectStart-up is a useful way of managing the expectations of those who find it difficult to distinguishbetween the 'Must have' elements of a project and the 'Nice to haves'. A Project Startup Workshop isan effective way to achieve this
Setting SMART project objectivesThe setting of objectives is a useful tool for management at all levels in an organisation. Itenables interested parties/stakeholders to agree at the start of a piece of work:• What they are trying to achieve• What must be done for the work to be complete• How they will know that the work has been successful• By when the work must be completedObjectives will be set at different levels with increasing levels of detail and measurability as you go fromhigh-level mission statements down to a task level objective for an individual working as part of a projectteam. Example levels are shown in fig 1 below. You may identify other areas where objective setting isuseful or it might be that some levels aren't appropriate to your project: e.g. not all projects arepart of programmes and not all projects are divided into workstreams
These guidelines are supported by a set of templates and examples to help you at all stages of the project lifecycle. They are provided as separate `free-standing' documents in a form that you may use and modify as required (i.e. Word or Excel format).
Create a project plan The first step to staying organized is getting organized. It may be tempting to push ahead, intending to organize things as you go, but good planning is essential. To lay the groundwork for a successful, organized project, invest the necessary time into making a good project plan.
Taking all the information gathered in making your project plan, identify all the activities needed to carry out your project. In the case of complex projects, it may be helpful to organize these tasks in the form of a Work Breakdown Structure (WBS), a project management chart visualizing projects, tasks, and their sub-tasks.
Rules for Planning and Organizing Rule # 1 Prioritizing Even though you can’t do everything at once, prioritizing helps you to figure out which tasks are the most important and which tasks can wait. If you know how to prioritize, you’ll be able to break up your work into smaller pieces.
After the project schedule and plan are complete, you need project management strategies and project management tools to communicate them to your team and to help everyone stay on track throughout the project.