Two overlapping vocabularies
Project work and change work are related but not identical. A project is a temporary effort to produce something, such as a new system. Change work deals with the people side of that outcome: whether staff understand it, accept it and use it. A project can be delivered on time and still fail to change anything if nobody adopts the result, which is why both sets of words appear together here.
The definitions are general. Methods and published guides use the terms in slightly different ways, so treat these as common usage rather than a standard.
Defining the work
Project. A temporary effort with a start, an end and a specific outcome. This sets it apart from ongoing operations, which repeat.
Program. A group of related projects managed together because their combined result matters more than each piece alone.
Scope. What the project will and will not deliver. A written scope helps people agree on boundaries early, when disagreement is cheapest.
Scope creep. The gradual growth of scope without a matching change to time, budget or people. It usually happens through many small, reasonable-sounding additions.
Requirement. A statement of something the solution must do or be. Collecting these carefully before talking to suppliers is the subject of requirements gathering.
Deliverable. A tangible or verifiable output of the project, such as a document, a configured system or a trained team.
Assumption. Something treated as true for planning purposes without proof. Assumptions are worth writing down because a wrong one can undermine the plan.
Constraint. A fixed limit the project must work within, such as a deadline, a budget or a rule.
Dependency. A relationship in which one task cannot start or finish until another has. Dependencies on outside teams are a common cause of delay.
Planning and tracking
Milestone. A significant point in a project, such as approval of a design or completion of testing. A milestone has no duration; it marks a moment. It is useful for showing progress, but reaching one does not by itself show the work behind it is good.
Work breakdown structure. A way of dividing the total work into smaller pieces that can be estimated and assigned.
Schedule and timeline. The planned sequence and dates for the work.
Critical path. The longest chain of dependent tasks, which sets the shortest possible project duration. A delay to any task on it delays the finish, while tasks off the path usually have some slack.
Baseline. The agreed version of the plan, scope or budget used as a reference for measuring variance. Establishing a performance baseline before starting also lets the benefits be judged afterwards.
Variance. The difference between what was planned and what happened.
Budget and contingency. The budget is the approved funding. A contingency is an amount or time set aside for risks that are possible but not certain.
Risk and issue. A risk is something that might happen and would matter. An issue is a problem that has already happened. Risks are managed to reduce the chance of issues.
Status report. A regular summary of progress, upcoming work, risks and decisions needed.
People and governance
Sponsor. The senior person who authorizes the project, secures resources and is ultimately accountable for its value. A project with a distant or disengaged sponsor often struggles to settle disputes.
Project manager. The person who plans, coordinates and tracks the project day to day.
Stakeholder. Anyone affected by the project or able to influence it. Stakeholder mapping is a way to identify them and think about their interests before work begins.
Steering group. A senior group that oversees direction and decides on matters beyond the project manager’s authority.
Governance. The roles, decision points and reporting that keep a project accountable.
Change request. A formal proposal to alter scope, time or cost after the baseline has been agreed, so that the effects are considered before approval.
Terms from change management
Organizational change management. The structured effort to prepare, support and help people through a change so that the intended outcome is achieved. It treats the human side as work to plan, not an afterthought.
Change impact. How much a change alters someone’s daily work. High impact on a group usually calls for more support for it.
Change champion. A person within a team who helps colleagues understand and adopt a change, usually as an addition to a normal job.
Resistance. Reluctance or opposition to a change. Often it reflects real concerns, such as workload or unclear benefits, and it is better understood than dismissed. When change stalls, a careful look at the causes tends to help more than pressure.
Communication plan. A schedule of who needs to be told what, by whom and through which channel. A good change communication plan also leaves room for questions.
Training needs analysis. Working out who needs to learn what before a change goes live.
Adoption. The extent to which people actually use the new system or process as intended. It is separate from delivery, and adoption measurement looks at behavior after launch.
Moving from old to new
Go-live. The point at which a new system or process starts being used for real work. The checks beforehand are usually called go-live testing.
Cutover. The switch from the old way of working to the new. A cutover strategy decides whether it happens all at once or in stages.
Pilot. A limited trial with a small group before wider rollout.
Rollback. Returning to the previous state if a change goes badly. A rollback plan is worth agreeing before the change is made.
Hypercare. A period of extra support immediately after go-live, when problems are most likely to appear.
Handover. Transferring responsibility from the project team to those who will run and support the result.
Results
Benefit. A positive outcome that a change is intended to produce, such as time saved or fewer errors. Benefits are expected outcomes, not guarantees.
Benefits realization. The practice of checking whether the intended benefits actually appear after delivery, and assigning someone to follow them up. It often continues for months after the project formally closes, because many benefits only become visible once people have settled into new routines.
Lessons learned. A review of what went well and what did not, recorded so that later projects can use it.
A shared understanding of these words does not make a project succeed, but it removes one common source of confusion, which is two people agreeing in a meeting while meaning different things.