Project Management>Common Project Management Terms and the meanings

Term

What it means

Analysis

Assessment work carried out to establish business requirements and best solutions - process or systems.  An analysis results report is usually produced 

Approach

How you will go about the project.  A set of techniques and methods that you will use during the project

Assumptions

A statement that is taken as being true for the purposes of planning the project but may change later. Assumptions are areas that are outside of your control and are also low level risks (see About Assumptions)

Business Requirements

Is establishing the user and business needs from a process or system to help define a new process or system It’s establishing the What’s not the How’s.  (See analysis)

Business Case

Justification for doing the project and the expenditure (based on cost and benefits - Click to see Template

Constraints

The things that might prevent you from doing what you need to do

Contingency Plan

See Risks

Exception Plan

See Risks

Deliverables

the specific things (products or service) that the project will produce

Dependency

When there are logical links between activities which are directly dependent on the outputs of another (be is physical or tangible)

Gantt Chart

A chart that shows the project plan usually in shaded bars indicating milestones, dependencies and the timelines for the tasks and or stages to complete the project

Impact

The degree to which a risk or issue can affect a project’s ability to deliver its objectives

Issue

An unresolved question, a requirement to modify or change a project deliverable, or a problem which has already arisen, or which is known is certain to arise, which will impact on the project’s ability to deliver one or more of its objectives.  An Issues Registered is used to record and manage issues (see Issues Register Go To Templates) Issues are different to risks because issues are when there is 100% certainty that the event will happen or it has already happened. If there is not 100% certainty that the event will happen then the item should be managed as a risk (see Risks below)

Interfaces

The are the departments or individuals with the business that you will have to work with in order to complete the project or produce a deliverable. These individuals may not form a part of the project team but nevertheless they are integral to the overall success of the project

Lessons Learned

Details of mistakes or things that could have been handled better are recorded in a log.  A Lessons Learned Report is usually produced at the end of the project.  The project team use the results to learn how to handle future projects (see templates for lessons learned Register and report)

Milestones

Milestones are key points in the project, such as the end of a phase, a date when a major decisions needs to have been taken or a document produced and accepted. The purpose is to measure the progress of the project

Process Map

A process map (some times referred to as a flowchart) is a graphical representation of a process. It represents the entire process from start to finish, showing inputs, pathways and actions or decision points, and ultimately, completion.

Project Organisational Structure (or roles)

Lists the people involved in the project and their roles and responsibilities during the life of the project

Project Definition

See Project Definition Document

Project Initiation Document

Is a document that contains full details about the project (e.g. its scope, objectives, deliverables etc) Sometimes referred to as the Project Definitions Document (see Templates)

Quality criteria (or expectations)

Quality standards the project deliverable must achieve and how it will be measured

Resource

The individual person with responsibility to ensure some work is completed.  Or tools that will be used

Risks (risk assessment)

What can go wrong (it is usually to have a contingency plan – e.g. what you can do if the risk happens or actions that can be taken to reduce or wipe out the risk). A Risks Registers is usually maintained (see Risk Register Template) to record and manage the risks.

An exception plan may also be agreed and a person named who will be responsible for deciding what actions are to be taken if things do go wrong)

Issues are different to risks because issues are when there is 100% certainty that the issue will happen or it has already happened (see issues above). If there is not 100% certainty then the event will arise the item should be managed as a risk. 

Scope

What is and isn’t included in the project (e.g. users, geographical boundaries, depth and type of work).  It some cases Not in Scope is also included – indicating what will not be covered by the project

Scope Creep

A process where the deliverables of a project have been allowed to change without assessing the consequences e.g. whether the changes would require a change in resources or whether the project can still deliver by the target date. Scope creep is the most common cause for Project Failure

Sponsor

The individual to whom you report as project leader – usually a senior manager or customer (or appointed representative) who is accountable for the project’s success

Stage

The highest level for a group of work shown in a project plan. Some examples might be: Policy formation, Project set up, system development.  Each of these stages would be made up of a collection of tasks/activities

Stakeholder

Any individual who has an interest in the project results: the customer, other managers, finance department, contractors, suppliers, end users etc.

Task

A piece of work carried out by one person

Work breakdown structure

A graphic display of all the work of the project, showing the task lists for each key stage (see example)