Project Management Manual

www.ProjectTemplates.co.
uk
Contents 1 Project Management Briefing.................................................................................... 3 1.1 What is a Project? ................................................................................................... 3 1.2 What is Project Management? .......................................................................... 3 1.3 Why use Project Management? ........................................................................ 3 1.4 Critical Success Factors ....................................................................................... 4 1.5 Roles and Responsibilities,................................................................................. 4 Project Management Processes ................................................................................ 6 2.1 Generic Project Stages .......................................................................................... 6 Project Key Documents ................................................................................................ 8 3.1 Project Mandate ...................................................................................................... 8 3.2 Risk Potential Assessment (RPA) .................................................................... 8 3.3 Feasibility Report ................................................................................................... 9 3.4 Project Brief .............................................................................................................. 9 3.5 Business Case ........................................................................................................... 9 3.6 Initiation Stage Plan .............................................................................................. 9 3.7 Project Initiation Document ............................................................................ 10 3.8 Project Plan ............................................................................................................. 10 3.9 Risk Log .................................................................................................................... 11 3.10 Stage Plan ................................................................................................................ 11 3.11 End Stage Report .................................................................................................. 12 3.12 Lessons Learned Report .................................................................................... 12 3.13 Follow-on Action Recommendations .......................................................... 12 3.14 End Project Report .............................................................................................. 13 3.15 Post-Project Review Plan .................................................................................. 13 3.16 Post-Project Review Report............................................................................. 13 Project MGT Deliverables.......................................................................................... 14 4.1 Checkpoint Report ............................................................................................... 14 4.2 Highlight Report ................................................................................................... 14 4.3 Work Package ........................................................................................................ 14 4.4 Project Issue ........................................................................................................... 15 4.5 Issue Log .................................................................................................................. 15 4.6 Off-Specification.................................................................................................... 15 4.7 Request for Change.............................................................................................. 16 4.8 Exception Report .................................................................................................. 16 4.9 Exception Plan ....................................................................................................... 16 Change Control .............................................................................................................. 17 Additional Resources ...................................................................................................... 19 Glossary of Terms ............................................................................................................. 20
2 3
This manual provides an overview of project management and describes the processes that should be used in managing projects and the deliverables that should be produced by the processes. 1.1 Project Management Briefing 1.2 What is a Project? A project is a unique set of coordinated activities, with definite starting and finishing points, undertaken by an individual or team to meet specific objectives within defined time, cost and performance parameters as specified in the business case. A project should have the following characteristics: Finite defined start and finish Deliverables designed to meet specific business objectives Activities to create the deliverables Defined amount of resources Organisation structure, with defined responsibilities, to manage the project. 1.3 What is Project Management? Project management is much more than the tasks carried out by a project manager. Project management is a combination of the roles and responsibilities of individuals assigned to the project, the organisational structure that sets out clear reporting arrangements and the set of processes to deliver the required outcome. Project management ensures that everyone
Project Management Manual
involved knows what is expected of them and helps to keep cost, time and risk under control. 1.4 Why use Project Management? Experience has shown that projects are inherently at risk through overrunning on time and cost and/or failing to deliver a successful outcome. Such failures are almost invariably caused by: poor project definition by the projects owner, perhaps because of insufficient consultation with stakeholders or their failure to be specific about requirements and desired outcomes lack of ownership and personal accountability by senior management inadequately skilled and experienced project personnel inadequate reporting arrangements and decision-making Inconsistent understanding of required project activities, roles and responsibilities. Project management helps to reduce and manage risk. It puts in place an organisation where lines of accountability are short and the responsibilities of individuals are clearly defined. Its processes are clearly documented and repeatable, so that those involved in the project can learn from the experiences of others. Formal project management should be adopted for all major projects. The principles are equally valuable for smaller and/or less complex projects.
Page 3 of 23
www.ProjectTemplates.co.uk
The nature of your project will determine the project management approach you need, which should be adapted as required. The approach should be fit for purpose and exhibit appropriate lightness of touch. 1.5 Critical Success Factors Successful projects have: a well-defined scope and agreed understanding of intended outcome active management of risks, issues and timely decision-making supported by clear and short lines of reporting ongoing commitment and support from senior management a senior individual with personal accountability and overall responsibility for the successful outcome of the project an appropriately trained and experienced project team and in particular a project manager whose capabilities match the complexity of the project defined and visibly managed processes that are appropriate for the scale and complexity of the project. For cross-cutting projects, there may be nominated senior owners from each area of the business involved in the project and its delivery. Where this is the case, there must be a single owner who is responsible for the whole project. 1.6 Roles and Responsibilities, Essential roles and responsibilities are:
Investment Decision Maker takes the investment decision based on affordability and cost justification. Project Executive, also referred to as the project Senior Responsible Owner (SRO) defines the scope and content of the project for delivering the benefits; personally accountable for the success of the project. A senior individual in the organisation must take this role. The Project Executive should have the status and authority to provide the necessary leadership and must have the clear accountability for delivering the project outcome. Project Manager leading, managing and co-ordinating the project team on a day-to-day basis Project Team delivers the required outputs or deliverables In addition to the essential roles described above, there will be a requirement for specialist suppliers and user representation. For larger or more complex projects there should be a Project Board chaired by the Project Executive. Membership of the Project Board, which is through formal appointment by the Project Executive, should include a role representing key user interests (the Senior User role) and a role addressing technical/supply issues (the Senior Supplier role - typically a representative from the supplier organisation). The Project Board provides the Project Executive with stakeholder/technical input to decisions affecting the project;
Page 4 of 23
ultimate authority and accountability resides with the Project Executive. There will always need to be active project assurance to assure the Project Executive that the project is employing good practice making sure stakeholders are being consulted appropriately and their needs are being addressed, for example. Project assurance is ultimately the responsibility of the Project Executive and will be included in the responsibilities of project board members, or may be fulfilled by individuals external to the project acting on behalf of the owner. In practice, some roles may be combined, subject to an overriding proviso that the person combining the roles possesses the requisite competencies, experience, expertise and time. Where roles are combined the allocation of the functions must always be absolutely clear, with delegations and responsibilities that do not overlap. The role of Project Manager should be clearly defined and implemented, and not simply another member of the project team. Where two roles are combined, the person appointed must have at least the authority and status of the higher role; however, it is important to note that the roles of Investment Decision-Maker and Project Executive cannot be allocated to a single individual.
Page 5 of 23
2 PROJECT MANAGEMENT PROCESSES 2.1 Generic Project Stages Projects can range in scale from very small (say, around 20 elapsed days) to very large (for example, more than one year in duration). The simplest project will have two stages: a planning stage and a doing stage. After the doing stage, there should be a review to confirm that the project delivered what was intended. Larger, or more complex, projects will have
multiple stages for more accurate planning and control. This is illustrated in the following diagram which shows the generic stage structure for a larger project (the project life cycle) within the overall product life cycle. The product life cycle starts with the initial idea, includes any feasibility study, project planning and project delivery, continues through to the operation of the product (when benefits are realised), and finishes with the decommissioning of the product when it comes to the end of its usefulness.
Figure 1: Project Life Cycle and Product Life Cycle At the outset of a project, the programme manager, project manager, and project executive should decide on an appropriate project stage structure commensurate with the projects scale (as a function of cost, time, scope, quality and risk). For smaller projects, stages can be combined. For example, for a small project, the Project start-Up and Initiation stages may be combined into one stage and Project Delivery may consist of just one stage.
Page 6 of 23
Generic Project Stage Structure and Key Management Products Project Stage Pre-Project Project Start Up Key Management Products Project Mandate Project Brief Project Approach Project Management Team Structure Risk Log Initiation Stage Plan Project Initiation Document (PID) Next Stage Plan End Stage Report Communication to Stakeholders Next Stage Plan Revised Project Plan Updated Risk Log Revised Business Case Lessons Learned Report Project Management Team Changes End Stage Report Communication to Stakeholders Updated Lessons Learned Report Confirmed Customer Acceptance Confirmed Maintenance and Operations Arrangements Follow-on Action Recommendations Final Lessons Learned Report End Project Report Archived Project Files End Project Notification Post-Project Review Plan Post-Project Review Report
Project Initiation Delivery Stage
Final Delivery Stage
Project Close
Post-Project
The required contents of the management products are described in Section 3 below, and templates are available @ www.ProjectTemplates.co.uk.
Page 7 of 23
3 PROJECT MANAGEMENT DOCUMENTS This section outlines the key documents that should be produced to manage and control the project, including the suggested contents for each document. The project manager should bear in mind the advice on fitness-for-purpose: the level of detail required for a given project will be commensurate with the scale of the project; it would be a waste of time and effort to produce a full set of documents for a 30-day project (where an agreed Project Mandate and a simple Work Package would probably suffice as the project control documents). This section provides advice on the information that should be provided to manage and control the project. It does not mandate the physical form of the documents. The document names and headings should be thought of logical groupings of information. For example, for a given project: A feasibility report may not be required, for example, if the purpose of the project is to produce a new version of an existing application; The PID constitutes a project brief, project plan, business case and risk log; If the project has only one delivery stage, there will not be any stage plans or related stage control documents. The project manager should also bear in mind that the PID (made up of the
project brief, project plan, business case and risk log), should contain sufficient information to allow the Project Board to give approval for the commencement of the project and for the project manager to start working on it. It does not need to explain in detail what will happen if everything goes according to plan; rather the PID should be an exposition of what could or should be done if and when the project deviates. 3.1 Project Mandate The required contents are as follows: Project Objectives Business Need and Fit with Strategy Benefits Expected Consequences of not undertaking the project Estimated Costs Target Start Date Target End Date Risk Potential Assessment (RPA) Score
3.2 Risk Potential Assessment (RPA) The RPA should be completed at the same time as the Project Mandate. The RPA is the first step in the OGC Gateway process. It provides a standard set of high-level criteria for assessing the degree of complexity of a proposed project. The RPA will calculate an overall score (the risk level) that is used to determine the form of review to be applied to the project.
Page 8 of 23
3.3 Feasibility Report The suggested contents are as follows: Prioritised list of requirements List of options considered For each option considered: o Description o Benefits o Costs o Resources o Timescales o Risks Options Appraisal Recommended Option Outline Plan for Recommended Option 3.4 Project Brief The purpose of the Project Brief is to define the project, forming the basis for its initiation and management. It is created during project start-up and may be extended during initiation. The required contents are as follows: Background Project Definition Project Organisation Structure Success Criteria Governance o Project Controls (reference to separate guidance document) o Project Quality Plan (reference to separate guidance document) Communication Plan (extended brief only)
3.5 Business Case The purpose of Business Case is to document the justification for the undertaking of a project based on the estimated cost of development and implementation against the risks and the anticipated business benefits and savings to be gained. The total business change must be considered, which may be much wider than just the project development cost. The Business Case is used to say why the forecast effort and time will be worth the expenditure. The Project Board will monitor the ongoing viability of the project against the Business Case. The suggested contents are as follows: Reasons for Undertaking the Project Options Benefits Resources and Costs Budget Source Investment Appraisal Timescales Key Risks
3.6 Initiation Stage Plan A plan for the production of the two management products: o The PID o The Next Stage Plan Reporting and control arrangements for the Initiation Stage May take the form of a Stage Plan or a Work Package.
Page 9 of 23
3.7 Project Initiation Document The purpose of the Project Initiation Document (PID) is two-fold: To define the project To form the basis for the management of the project and the assessment of overall success. The PID has two primary uses: To ensure that the project has a sound basis before asking the Project Board to make any major commitment to the project To act as a base document against which the Project Board and Project Manager can assess progress, change management issues and ongoing viability questions. The PID covers the following fundamental questions about the project: What the project is aiming to achieve Why it is important to achieve it Who is going to be involved in managing the process and what are their responsibilities How and when is it all going to happen 3.8 Project Plan The project plan forms part of the PID. It provides a statement of how and when a projects objectives are to be achieved by showing the major products, activities, and resources required on the project. The project plan shows the planned
project costs and it identifies the management stages and other major control points. The project plan is used by the project board as a baseline against which to monitor project progress and cost stage by stage. The suggested contents are as follows: Plan Description Project Prerequisites External Dependencies Planning Assumptions. Plan Information Including: o Project level Gantt or bar chart with identified management stages [For clarity, the management stages should also be listed in a separate table showing the planned start and end date of each stage.] o Project level Product Breakdown Structure o Project level Product Flow Diagram especially when there are complex dependencies o Project level Product Descriptions o Project Checklist and Quality Log o Project level activity network o Project financial budget o Project Change Budget o Project level table of resource requirements o Requested/assigned specific resources o Project level tolerances (especially for time and budget)
Page 10 of 23
Contingency plans (for dealing with the consequences of any risks that materialise) 3.9 Risk Log The purpose of the Risk Log is to provide a repository of information about the risks, their analysis, countermeasures and status. The suggested contents are as follows. Risk Identifier Description Risk Category (e.g., business, legal, technical) Impact (effect on the project/programme/organisation if this risk were to occur) Probability (estimate of the likelihood of the risk occurring) Proximity (how close in time is this risk likely to occur) Countermeasure(s) (what actions have been taken or will be taken to counter this risk) Owner (who has been appointed to keep an eye on the risk) Author (who submitted the risk) Date Identified (when was the risk first identified) Date of last update (when was the status of the risk last checked) Current Status (e.g., Dead, Reducing, Increasing, No Change) 3.10 Stage Plan The Stage Plan is the basis for project management control throughout the stage. The Stage Plan:
Identifies all the products that the stage must produce Provides a statement of how and when a stages objectives are to be achieved, by showing the deliverables, activities and resources required Identifies the stages control and reporting points and frequencies Provides a baseline against which stage progress will be measured Records the stage tolerances Specifies the quality controls for the stage and identifies the resources needed for them The suggested contents of the Stage Plan are as follows: Plan Description Plan Prerequisites External Dependencies Planning Assumptions Plan Information Including: o Gantt chart showing identified resources, activities, start and end dates o Product Breakdown Structure o Product Flow Diagram especially when there are complex dependencies o Product Descriptions for the major products o Product Checklist and Quality Log o Activity network o Financial budget o Table of resource requirements o Requested/assigned specific resources
Page 11 of 23
o Tolerances (time and budget) 3.11 End Stage Report The purpose of the end stage report is to give a summary of progress to date, the overall project situation and sufficient information for a project board decision on what to do next with the project. The contents of the report are as follows: Actuals versus current stage plan: o Actual costs versus planned costs o Actual dates achieved versus planned dates for each major milestone o Actual products versus planned products Project Plan outlook (if the project plan is revised, identify the variations between the revised plan and the previous one) Business Case Review Risk review (assess any changes to the risk situation) Project Issue situation (summary of project issues received during the stage and what has happened to them) Quality statistics (quality control activities and results) Project Managers report on any events which affected stage performance Summary of lessons learned during the current stage. 3.12 Lessons Learned Report The purpose of the Lessons Learned Report is to pass on any lessons, which
can be usefully applied, to other projects. The contents are as follows: Description of what management and quality processes: o Went well o Went badly o Were lacking Description of any abnormal events causing deviations An assessment of technical methods and tools used An analysis of project issues and their results Recommendations for future enhancement or modifications of the project management method Useful measurements of how much effort was required to create the various products Statistics on how effective quality reviews and other tests were in error trapping (for example, how many errors were found after products had passed a quality review or other test) 3.13 Follow-on Action Recommendations The purpose of the recommendations is to pass details of unfinished work or potential product modifications to the teams responsible for maintenance and support of the final product in its operational life. The contents are as follows: Date of the recommendations Requests for change that were considered to have merit, but were not implemented during the project
Page 12 of 23
Off-Specifications recording missing products or products that do not meet the original requirements Risks identified during the project that may affect the product in its operational life Any identified handover or training needs Any other activities needed to take the product to the next stage of its life. 3.14 End Project Report The End Project Report is produced by the project manager for the project board (who should pass it on to the programme sub-committee). The report describes how well the project has performed against its Project Initiation Document, including the original planned cost, schedule and tolerances, the revised business case, and final version of the project plan. The contents are as follows: Achievement of the projects objectives Performance against the planned target time and cost The effect on the original Project Plan and Business Case of any changes that were approved Final statistics on change issues received during the project The total impact of approved changes Statistics for all quality work carried out Post-Project Review date and plan
3.15 Post-Project Review Plan The post-project review plan should cover the resources, activities, costs, and timescales required to carry out the post-project review and produce the post-project review report. The activities should include Measuring benefits achievement Identification of any problems in the use of the product Interviews with users or surveys to measure user reaction to the product Production of the report 3.16 Post-Project Review Report The purpose of the post-project review is to find out: Whether the expected benefits of the product have been realised; If the product has caused any problems in use. Each expected benefit is assessed for the level of its achievement so far, or any additional time needed for the benefit to materialise. Any unexpected side effects (beneficial or adverse) are documented with explanations of why these were not foreseen. Recommendations are made to realise or improve benefits, or counter problems. The suggested contents are as follows: Achievement of expected benefits Unexpected benefits Unexpected problems User reaction
Page 13 of 23
4 PROJECT MGT DELIVERABLES 4.1 Checkpoint Report A Checkpoint Report is a progress report to the Project Manager. Its purpose is to allow the Project Manager to monitor work on an authorised Work Package by receiving a report on the status of work for each member of the team. The report is produced by the Team Manager (or team member in the absence of a Team Manager) typically at a regular checkpoint meeting. The frequency of the reports (typically weekly) and the manner of reporting (typically checkpoint meetings) is defined in the Stage Plan or Work Package. The suggested contents are: Date held Period covered Follow-ups from previous reports Activities during the period Products completed during the period Quality work carried out during the period Actual or potential problems or deviations from plan Work planned for the next period Products to be completed during the next period 4.2 Highlight Report The purpose of the Highlight Report is to provide the Project Board with a summary of the stage status at intervals defined by the Project Board. The Project Board uses the report to monitor stage and project progress. The Project Manager also uses it to advise the
Project Board of any potential problems or areas where the Project Board could help. The suggested contents of the Highlight Report are: Date Period covered Budget status Schedule status Products completed during the period Actual or potential problems Products to be completed during the next period Project Issue status Budget and schedule impact of the changes 4.3 Work Package A Work Package is a set of information about one or more required products collated by the Project Manager to pass responsibility for work or delivery formally to a Team Manager or a team member. Suggested contents are as follows: Date Team or person authorised Work Package description Product Description(s) Techniques, processes, or procedures to be used Interfaces to be satisfied by the work Interfaces to be maintained by the work Quality checking method to be used Configuration management requirements Stage Plan extract
Page 14 of 23
Joint agreement on effort, cost, start, and end dates Sign-off requirements Work return arrangements How completion is to be advised Any constraints to be observed Independent quality checking arrangements Reporting arrangements Problem handling and escalation There should be space on the Work Package to record its authorisation and acceptance of the return of the completed Work Package. 4.4 Project Issue Project Issue is a generic term for any matter that has to be brought to the attention of the project, and requires an answer. After receiving a unique reference number, Project Issues are evaluated in terms of impact on the product, effort, and cost, risks, Project Plan and Business Case. The Project Manager may make a decision on what action to take, or the Project Issue may be referred to the Project Board. A Project Issue may have a negative or positive impact on the project. Project issues include: Request for Change Off-Specification Question Statement of concern
Date Project Issue Number Description of the Project Issue Priority Impact analysis Decision Signature of decision-maker(s) Date of decision
4.5 Issue Log Project Issues may be raised by anyone associated with the project at any time. The purpose of the Issue Log is to: Allocate a unique number to each Project Issue Record the type of Project Issue Be a summary of the Project Issues, their analysis, and status The suggested contents of the Issue Log are: Project Issue number Project Issue type (Request for Change, Off-Specification, or a general issue) Author Date identified Date of last update Description Status 4.6 Off-Specification An Off-Specification may be raised by anyone associated with the project at any time. Its purpose is to document any situation where a product is failing (or is
The suggested contents of a Project Issue are: Author

Page 15 of 23
forecast to fail) to meet its specification. The contents of an Off-Specification are: Date Issue Log number Class Status Description of the fault Impact of the fault Priority assessment Decision Allocation details, if applicable Date allocated Date completed
4.8 Exception Report An Exception Report is produced when costs and/or timescales for an approved Stage Plan are forecast to exceed the tolerance levels set. It is sent by the Project Manager to the Project Board to inform the board of the adverse situation. Following receipt of the report, the Project Board will normally ask the Project Manager to produce an Exception Plan. The suggested report contents are: A description of the cause of the deviation from the Stage Plan Consequences of the deviation The available options The effect of each option on the Business Case, risks, project and stage tolerances The Project Managers recommendations 4.9 Exception Plan Following an Exception Report, the Project Manager will ask the Project Board to authorise an Exception Plan. The Exception Plan should be accompanied by an updated Project Plan, Business Case, and Risk Log. If the forecast is for the project to deviate beyond its tolerances, the Project Board must refer the matter to the Programme Sub-Committee. The Programme SubCommittee will need to consider the likely impact on the programme and take appropriate action following approval by the Programme Sub-Committee.
4.7 Request for Change Anyone connected with the project can raise a Request for Change. The purpose is to request a modification to a product or an acceptance criterion as currently specified. The suggested contents are: Date Issue Log number Class Status Description of the proposed change (including reason, benefits, consequences of not making the change) Impact of the change Priority assessment Decision Allocation details, if applicable Date allocated Date completed
Page 16 of 23
5 CHANGE CONTROL All changes that arise during a stage of a project are regarded as types of Project Issue. A Project Issue can be: A request to change the specification of requirements (Request For Change)
A suggestion to improve one or more of the projects products (Request For Change) A record of some current or forecast failure to meet a requirement (OffSpecification) A question on any project topic
Every Project Issue, whatever its type, is logged on the Issue Log. The author should indicate the priority of the issue as follows Priority Meaning A must; the final product will not work without 1 this change An important change; its absence would be very 2 inconvenient, although a work-around is possible for a while 3 A nice-to-have; but not vital 4 5 A cosmetic change; of no importance Not a change; this issue does not involve a change Moscow Rules Must have Should have Could have Would like to have M S C W
The MoSCoW mnemonic (as indicated in the Moscow Rules column above) is a useful aid in determining priorities. An Issue that is a question should be answered directly. The reply should be sent to the author, and the Issue Log should be updated to reflect the action. An impact analysis should be carried out on each of the other types of issues (Requests for Change, OffSpecifications). The impact analysis should identify the following:
What would have to change What effort would the change need What the impact on the Business Case would be What the impact on the Risks would be The Senior User should re-evaluate the priority of the issue after the impact analysis. For Off-Specifications, the Project Manager should try to solve the problem within the stage and project tolerance
Page 17 of 23
margins, making any required changes to the Stage and Project plans. Where the problem cannot be solved within tolerance levels, the Project Manager should escalate the issue to the Project Board and produce an Exception Report for the Project Board. The Project Board may decide to accept the OffSpecification without any corrective action; such a decision is called a Concession. Where the Issue is a Request for Change, the Project Manager should discuss the issue with the Senior User and Senior Supplier before arriving at a decision as to how to proceed. If the decision is to implement the change within current stage plan tolerances, the Project Manager should raise an RFC for this activity for approval by the Programme Manager in accordance with the procedures described in the Change Management Guidance document. The Project Manager cannot approve any work that would change a product that has already been approved by the Project Board. If the decision is to recommend implementation of the change and if so doing would cause stage tolerances to be exceeded, the Project Manager should escalate the issue to the Project Board and produce an Exception Report for the Project Board. Where the production of the Exception Report requires the commitment of supplier resources beyond authorised levels, the Project Manager should ask the Programme Manager to raise a supplier order.
If the Project Board asks the Project Manager to produce an Exception Plan, the Project Manager should ask the Programme Manager to raise a supplier order for this activity. The supplier order should specify that the Exception Plan should be accompanied by an updated Project Plan, Business Case, and Risk Log. If the Programme Sub-Committee approves the Exception Plan, the Programme Manager should raise a supplier order for the work.
Page 18 of 23
5.1 Additional Resources And thats it! If you complete the steps described in this manual, then youll deliver more projects on time and within budget. Hopefully youve found this manual useful, by telling you what you need to do to deliver projects successfully. If youd now like to know how to deliver successful projects, then download the Project Management Set This package includes all of the templates listed in this manual. The templates describe how to complete each step in the project lifecycle, helping you deliver projects faster and easier than before. It saves you time and effort by giving you: Templates to create deliverables Forms to resolve risks and issues Plans to schedule tasks & resources Processes to monitor project delivery Reports to communicate status Charts to control project change Procedures to improve quality Checklists to measure success. It also helps you get a head-start because: It tells you which deliverables to create
It explains how and when to create them Each template is pre-formatted It includes practical examples, tips & hints You simply open the templates in Word or Excel and fill in the gaps. Youll complete tasks faster and make your life much easier than before. By getting a head start every time you start a new project task, youll save an enormous amount of time delivering your project. So by saving you time and effort and getting a head start on projects, this unique template set will make your life much easier. Buy this kit today for only $83.95. Heres how to buy it in 3 easy steps: 1. Visit the website 2. Select the Apply Now button 3. Download the set immediately for use. Select the Apply Now button now to save time and effort on your project
The Project Management Template package gives you the complete set of templates for managing projects. Its great! 2010 Project Templates Inc. All rights reserved. Visit: www.ProjectTemplates.co.uk
Page 19 of 23
5.2 Glossary of Terms Acceptance Management The process by which deliverables produced by the project are reviewed and accepted by the customer as meeting their specific requirements Acceptance Planning The process of identifying the milestones, criteria and standards for the acceptance of project deliverables by the customer Business Case A document outlining the justification for the initiation of a project. It includes a description of the business problem (or opportunity), a list of the available solution options, their associated costs and benefits and a preferred option for approval. Change Management The process by which changes to the project scope, deliverables, timescales or resources are formally defined, evaluated and approved prior to implementation Communications Management The process by which formal communications messages are identified, created, reviewed and communicated within a project Communications Planning The process of identifying the type and regularity of information to be provided to all project stakeholders to keep them informed of the progress of the project
Cost Management The process by which costs (or expenses) incurred on the project are formally identified, approved and paid Deliverable A quantifiable outcome of the project which results in the partial (or full) achievement of the project objectives Dependency A logical relationship between two or more project activities. The four types of dependencies include: start-to-finish, start-to-start, finish-to-start, finish-tofinish Feasibility Study A document which identifies each of the solution options to a particular business problem (or opportunity) and assesses the likelihood of each options achieving the desired result Financial Planning The process of identifying the financial resources required to undertake the project. This includes a list of the types of costs to be incurred on the project (e.g. labor, equipment, materials and administration costs) and a schedule outlining when the respective costs are likely to be incurred Issue Events which are currently affecting the ability of the project to produce the required deliverables
Page 20 of 23
Issue Management The process by which issues are formally identified, communicated, monitored and resolved Job Description A document which describes a particular role and its responsibilities within a project Milestone The recognition of an important event within the project, usually the achievement of a key project deliverable Procurement Management The process by which product is actually sourced from a preferred supplier, including the on-going management of the supplier relationship Procurement Planning The process of identifying the products to be sourced externally and the methods for acquiring them Product A good or service which is acquired from an external supplier to assist with the production of a project deliverable Project A unique endeavour to produce a set of deliverables within clearly specified time, cost and quality constraints Project Activity A set of project tasks which usually results in the partial (or full) completion of a project deliverable
Project Lifecycle A series of project phases which are undertaken in either sequential or parallel order Project Management The skills, tools and management processes required to successfully undertake a project Project Office The physical premises within which Project Administration staff (e.g. the Project Manager and support staff) reside Project Phase A set of project activities and tasks which usually result in the completion of a project deliverable Project Plan A document which lists the phases, activities, tasks, timeframes and resources required to complete the project Project Schedule A series of planned dates within which activities and tasks have to be completed to achieve project milestones Project Task A specific work item to be undertaken which usually results in the partial completion of a project deliverable Project Team A collation of people who report to the Project Manager
Page 21 of 23
Quality The level of conformance of the final deliverable(s) to the customers requirements Quality Assurance The preventative steps taken to eliminate any variances in the quality of the deliverable produced from the quality targets set Quality Control The curative steps taken to eliminate any variances in the quality of the deliverable produced from the quality targets set Quality Management The process by which the quality of the deliverables and management processes is assured and controlled for the project, using Quality Assurance and Quality Control techniques Quality Planning The process of identifying the approach taken to ensure the quality of the deliverables produced by the project and of the management processes undertaken. This includes a list of the quality criteria and standards to be achieved as well as the Quality Assurance and Quality Control techniques to be undertaken Request for Information A document which is issued by a project to a wide group of potential suppliers to enable those suppliers to provide summarized information outlining how
they will meet the procurement requirements of the project Request for Proposal A document which is issued by a project to a short-listed group of suppliers to enable the suppliers to submit a detailed proposal outlining how they will meet the procurement requirements of the project Resource Planning The process of identifying the resources required to complete the project. This includes a list of the types of resources required and a schedule providing the use of and activities undertaken by each resource Risk Any event which is likely to adversely affect the ability of the project to achieve the defined objectives Risk Management The process by which risks to the project (e.g. to the scope, deliverables, timescales or resources) are formally identified, quantified and managed during the project. The process entails completing a number of actions to reduce the likelihood of occurrence and the severity of impact of each risk Risk Mitigation A set of actions to be taken to avoid, transfer or mitigate a risk, based on its priority. This includes the preventative actions to be taken during the project to reduce the likelihood of the risks occurring as well as the contingent
Page 22 of 23
actions to be taken to reduce the impact on the project should the risk eventuate Risk Planning The formulation of a document which outlines the foreseeable project risks and provides a set of actions to be taken to both prevent the risk from occurring and reduce the impact of the risk should it eventuate Scope The total aggregation of deliverables to be produced by the project Solution A set of deliverables which, once combined, solve a particular business problem (or realize a particular business opportunity) Stage-Gate A checkpoint at the end of each project phase to ensure that the project has achieved its stated objectives and deliverables as planned Statement of Work A document which defines the procurement requirements of the project in sufficient detail to enable potential suppliers to determine if they are able to meet those requirements Supplier Contract An agreement between the Project Team and an external supplier for the acquisition of a defined set of products to meet the procurement requirements of the Project
Tender Document A formal document included during the tender process which outlines the information required to provide the Project Team with the confidence that a supplier can meet the procurement needs of the project. The RFI and RFP are both examples of Tender Documents Tender Management The process, by which interested suppliers are identified, evaluated and selected for the supply of products (goods or services) to the project. This process entails formalizing the procurement requirements and tender documentation, receiving tender responses and selecting a preferred supplier Project Charter A document which outlines the purpose of the project, the manner in which the project will be structured and how it will be successfully implemented Time Management The process within which time spent by staff undertaking project tasks is recorded against the project See www.ProjectTemplates.co.uk for the complete set of Microsoft Word and Excel document templates supporting this Manual
Page 23 of 23

Project Management Manual

Uploaded by

Copyright:

Available Formats

You might also like

Project Management Manual

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Project Management Manual

Uploaded by

Copyright:

Available Formats

www.ProjectTemplates.co.