Effective communication is a key element of successful project management, which makes a common language essential. This glossary will help your team standardize on frequently used PM terms, from <i>critical path</i> to <i>Gantt chart</i> to <i>scope change management.</i>
This article is also available as a PDF download.
Every discipline has its own vocabulary, and project management is no exception. Part of the process of successfully deploying project management in your organization is to standardize the terminology. That way, when one person talks about risks, scope, issues, requirements, and other PM concerns, everyone else knows what he or she is referring to. This glossary contains common terms used in project management and can help start the standardization process in your organization.
There may be external circumstances or events that must occur for the project to be successful (or that should happen to increase your chances of success). If you believe that the probability of the event occurring is acceptable, you could list it as an assumption. An assumption has a probability between 0 and 100%. That is, it is not impossible that the event will occur (0%) and it is not a fact (100%). It is somewhere in between. Assumptions are important because they set the context in which the entire remainder of the project is defined. If an assumption doesn't come through, the estimate and the rest of the project definition may no longer be valid.
Client / Customers
The person or group that is the direct beneficiary of a project or service is the client / customer. These are the people for whom the project is being undertaken (indirect beneficiaries are stakeholders). In many organizations, internal beneficiaries are called "clients" and external beneficiaries are called "customers," but this is not a hard and fast rule.
Constraints are limitations that are outside the control of the project team and need to be managed around. They are not necessarily problems. However, the project manager should be aware of constraints because they represent limitations that the project must execute within. Date constraints, for instance, imply that certain events (perhaps the end of the project) must occur by certain dates. Resources are almost always a constraint, since they are not available in an unlimited supply.
The critical path is the sequence of activities that must be completed on schedule for the entire project to be completed on schedule. It is the longest duration path through the workplan. If an activity on the critical path is delayed by one day, the entire project will be delayed by one day (unless another activity on the critical path can be accelerated by one day).
A deliverable is any tangible outcome that is produced by the project. All projects create deliverables. These can be documents, plans, computer systems, buildings, aircraft, etc. Internal deliverables are produced as a consequence of executing the project and are usually needed only by the project team. External deliverables are those that are created for clients and stakeholders. Your project may create one or many deliverables.
The functional manager is the person you report to within your functional organization. Typically, this is the person who does your performance review. The project manager may also be a functional manager, but he or she does not have to be. If your project manager is different from your functional manager, your organization is probably utilizing matrix management.
A Gantt chart is a bar chart that depicts activities as blocks over time. The beginning and end of the block correspond to the beginning and end-date of the activity.
An issue is a major problem that will impede the progress of the project and that can't be resolved by the project manager and project team without outside help. Project managers should proactively deal with issues through a defined issues management process.
Lifecycle refers to the process used to build the deliverables produced by the project. There are many models for a project lifecycle. For software development, the entire lifecycle might consist of planning, analysis, design, construct/test, implementation, and support. This is an example of a "waterfall" lifecycle. Other lifecycles include iterative development, package implementation, and research and development. Each of these lifecycle models represents an approach to building the deliverables on your project.
A milestone is a scheduling event that signifies the completion of a major deliverable or a set of related deliverables. A milestone, by definition, has duration of zero and no effort. There is no work associated with a milestone. It is a flag in the workplan to signify that some other work has completed. Usually, a milestone is used as a project checkpoint to validate how the project is progressing. In many cases there is a decision, such as validating that the project is ready to proceed further, that needs to be made at a milestone.
An objective is a concrete statement that describes what the project is trying to achieve. The objective should be written at a low level, so that it can be evaluated at the conclusion of a project to see whether it was achieved. Project success is determined based on whether the project objectives were achieved. A technique for writing an objective is to make sure it is Specific, Measurable, Attainable/Achievable, Realistic, and Timebound (SMART).
A program is the umbrella structure established to manage a series of related projects. The program does not produce any project deliverables. The project teams produce them all. The purpose of the program is to provide overall direction and guidance, to make sure the related projects are communicating effectively, to provide a central point of contact and focus for the client and the project teams, and to determine how individual projects should be defined to ensure that all the work gets completed successfully.
A program manager is the person with the authority to manage a program. (Note that this is a role. The program manager may also be responsible for one or more of the projects within the program.) The program manager leads the overall planning and management of the program. All project managers within the program report to the program manager.
A project is a temporary structure to organize and manage work and ultimately to build a specific defined deliverable or set of deliverables. By definition, all projects are unique, which is one reason it is difficult to compare different projects to one another.
Project definition (charter)
Before you start a project, it is important to know the overall objectives of the project, as well as the scope, deliverables, risks, assumptions, project organization chart, etc. The project definition (or charter) is the document that holds this relevant information. The project manager is responsible for creating the project definition. The document should be approved by the sponsor to signify that the project manager and the sponsor are in agreement on these important aspects of the project.
The project manager is the person with the authority to manage a project. The project manager is 100 percent responsible for the processes used to manage the project. He or she also has people management responsibilities for team members, although this is shared with the team member's functional manager. The processes used to manage the project include defining the work, building the workplan and budget, managing the workplan and budget, scope management, issues management, risk management, etc.
A phase is a major logical grouping of work on a project. It also represents the completion of a major deliverable or set of related deliverables. On an IT development project, logical phases might be planning, analysis, design, construct (including testing), and implementation.
The project team consists of the full-time and part-time resources assigned to work on the deliverables of the project. They are responsible for understanding the work to be completed; completing assigned work within the budget, timeline, and quality expectations; informing the project manager of issues, scope changes, and risk and quality concerns; and proactively communicating status and managing expectations.
Requirements are descriptions of how a product or service should act, appear, or perform. Requirements generally refer to the features and functions of the deliverables you are building on your project. Requirements are considered to be a part of project scope. High-level scope is defined in your project definition (charter). The requirements form the detailed scope. After your requirements are approved, they can be changed through the scope change management process.
There may be potential external events that will have a negative impact on your project if they occur. Risk refers to the combination of the probability the event will occur and the impact on the project if the event occurs. If the combination of the probability of the occurrence and the impact to the project is too high, you should identify the potential event as a risk and put a proactive plan in place to manage the risk.
Scope is the way you describe the boundaries of the project. It defines what the project will deliver and what it will not deliver. High-level scope is set in your project definition (charter) and includes all of your deliverables and the boundaries of your project. The detailed scope is identified through your business requirements. Any changes to your project deliverables, boundaries, or requirements would require approval through scope change management.
Scope change management
The purpose of scope change management is to manage change that occurs to previously approved scope statements and requirements. Scope is defined and approved in the scope section of the project definition (charter) and the more detailed business requirements. If the scope or the business requirements change during the project (and usually this means that the client wants additional items), the estimates for cost, effort, and duration may no longer be valid. If the sponsor agrees to include the new work in the project scope, the project manager has the right to expect that the current budget and deadline will be modified (usually increased) to reflect this additional work. This new estimated cost, effort, and duration now become the approved target.
Sometimes the project manager thinks that scope management means having to tell the client "no." That makes the project manager nervous and uncomfortable. However, the good news is that managing scope is all about getting the sponsor to make the decisions that will result in changes to project scope.
Sponsor (executive sponsor and project sponsor)
The sponsor is the person who has ultimate authority over the project. The executive sponsor provides project funding, resolves issues and scope changes, approves major deliverables, and provides high-level direction. He or she also champions the project within the organization. Depending on the project and the organizational level of the executive sponsor, he or she may delegate day-to-day tactical management to a project sponsor. If assigned, the project sponsor represents the executive sponsor on a day-to-day basis and makes most of the decisions requiring sponsor approval. If the decision is large enough, the project sponsor will take it to the executive sponsor.
Specific people or groups who have a stake in the outcome of the project are stakeholders. Normally stakeholders are from within the company and may include internal clients, management, employees, administrators, etc. A project can also have external stakeholders, including suppliers, investors, community groups, and government organizations.
A steering committee is usually a group of high-level stakeholders who are responsible for providing guidance on overall strategic direction. They don't take the place of a sponsor but help spread the strategic input and buy-in to a larger portion of the organization. The steering committee is especially valuable if your project has an impact in multiple organizations because it allows input from those organizations into decisions that affect them.
The project workplan tells you how you will complete the project. It describes the activities required, the sequence of the work, who is assigned to the work, an estimate of how much effort is required, when the work is due, and other information of interest to the project manager. The workplan allows the project manager to identify the work required to complete the project and also allows the project manager to monitor the work to determine whether the project is on schedule.