Evaluate Project Status - PMP Visual Guide

Key Concepts

Plans are predictions, and evaluating project status is how we find out whether the prediction is holding up. It means gathering data on what is happening, comparing it against the plan, and sharing an honest picture of the gap. Status evaluation is a continuous discipline, not a single moment. It covers four threads: tracking progress, maintaining artifacts, measuring performance, and communicating results.

00:00

Plans are predictions, and evaluating project status is how we find out whether the prediction is holding up. The work involves gathering data on what is actually happening, comparing it against the plan, and sharing an honest picture of the gap. Our teams, sponsors, and other stakeholders rely on this picture to make good decisions. Without it, the project flies blind.

Status evaluation is not a single moment at the end of a phase. It is a continuous discipline running throughout the project, covering four threads: tracking progress, maintaining artifacts, measuring performance, and communicating results in forms our stakeholders can actually use.

2.9.1 Develop Project Metrics, Analysis, and Reconciliation

Before measuring anything, the project needs to agree on what to measure and why. Metrics that are chosen carelessly create perverse incentives, generate noise, and consume time without informing decisions.

Choosing the Right Metrics

The starting question is: what does success look like for this project, and what signals will tell us whether we are on track to achieve it? Metrics should track progress toward the end goal, not just activity.

Features delivered versus features remaining, for example, tells the team and sponsor whether the project is producing value at the expected rate. It focuses on the output. Hours worked, by contrast, measures effort but says nothing about whether that effort is producing results. Be cautious of tangential metrics that can generate unintended behavior: measuring lines of code, for instance, can discourage code simplification, which is often the better engineering choice.

Good project metrics share several characteristics:

They are directly connected to the project’s objectives and end goals.
They are straightforward to collect, ideally self-generating from existing tools or processes.
They show trends over time, not just point-in-time readings.
They are meaningful to the people who will act on them.

Control Charts and the Rule of Seven

A control chart tracks data from a repetitive process over time, plotting each measurement against a calculated mean and upper and lower control limits. Points outside those limits signal unusual variation requiring attention. The Rule of Seven adds a second trigger: seven consecutive data points on the same side of the mean indicate a process shift worth investigating, even if every point remains within the control limits. That pattern is statistically improbable in a stable process, which makes it a signal rather than noise.

The practical value for project managers is catching drift before it becomes a breach. Sprint/iteration velocity declining across seven iterations, defect counts running consistently above average, or schedule performance index values sitting below 1.0 for seven consecutive periods all warrant investigation. No single data point may have crossed a threshold, but the trend is telling you something has changed.

Throughput, Lead Time, and Cycle Time

Continuous-flow teams using Kanban or similar approaches track work using three related flow metrics rather than velocity. Throughput is the number of items entering or leaving the system in a given period: it measures output rate. Lead time is the total elapsed time from when a work item enters the queue to when it is delivered, covering all waiting and active work. Cycle time is narrower: only the time the item is actively being worked on, excluding any time spent waiting in a queue.

The distinction between lead time and cycle time matters in practice. A long lead time with a short cycle time tells you the work itself is not the problem; the item is sitting idle somewhere in the process. Teams use these metrics together to identify bottlenecks, set realistic delivery expectations with stakeholders, and make targeted improvements to flow.

Reconciliation

Metrics need to be reconciled with one another and with the project plan at regular intervals. A schedule metric that shows the project on track but a cost metric that shows significant overrun signals a problem that neither metric reveals alone. Reconciling the data across scope, schedule, cost, and quality produces a coherent picture rather than a collection of isolated readings.

When metrics diverge from the plan or from each other, the project manager needs to investigate the cause, not just report the number. Analysis means understanding what the data shows and what it implies for the project going forward.

2.9.2 Identify and Tailor Needed Artifacts

Project artifacts are the documents, models, plans, and designs that support the management and delivery of a project. They are living documents: they evolve as the project progresses and must be kept current to remain useful.

What Counts as a Project Artifact

Common artifacts across most projects include:

Project charter
Project management plans and subsidiary plans
Scope documents and requirements
Assumptions and constraints logs
Risk and issue logs
Change requests
Defect reports
Decision records
Lessons learned register
Acceptance criteria
Contracts

Artifacts more associated with agile projects include:

Product backlog
Product roadmap
Product vision statement
Release plan
Iteration backlog
Task boards
Product increment records
Team experiment logs

Tailoring the Artifact Set

Not every project needs every artifact. A small, low-complexity internal project does not need the same documentation rigor as a safety-critical engineering program. Tailoring means selecting the artifacts that are genuinely needed for this project’s size, complexity, governance requirements, and delivery approach, and dropping those that would consume effort without adding value.

The questions to ask when deciding which artifacts to produce are: who will use this, what decisions will it inform, and what happens if it does not exist? If the honest answers are “nobody,” “none,” and “nothing significant,” the artifact is probably not worth producing.

Agile projects often rely on lightweight, visible artifacts such as task boards, backlogs, and burn-down charts rather than extensive documentation. The principle is the same: produce what is useful, not everything that could theoretically be produced.

2.9.3 Help Ensure Artifacts are Created, Reviewed, Updated, and Documented

Identifying the right artifact set is the first step; making sure those artifacts are actually produced, kept current, and properly reviewed is the ongoing work.

Artifact Lifecycle

Each artifact has a lifecycle: it is created at a particular point in the project, updated as the project evolves, reviewed at defined intervals, and eventually archived or closed. The project manager is responsible for confirming that this lifecycle is followed, not just that artifacts exist at a point in time.

An out-of-date risk log is worse than no risk log in some ways, because it creates a false sense of security. An acceptance criteria document that was written at project start but never updated to reflect scope changes will generate disagreement at handover. Artifacts need to stay current to be useful.

Review Cadence

Artifacts should be reviewed at defined intervals appropriate to how quickly the project is changing. On a high-change agile project, the backlog might be reviewed and refined every few days. On a predictive project with a stable scope, a monthly review of the risk register might be sufficient. The schedule management plan, quality management plan, and other subsidiary plans should be reviewed at major milestones or when significant changes occur.

2.9.4 Help Ensure Accessibility of Artifacts

An artifact that exists but cannot be found or accessed by the people who need it is not doing its job. Artifact accessibility means storing information where authorized stakeholders can reach it, in a format they can use, at the time they need it.

Configuration Management

Configuration management is the process of controlling changes to project artifacts and the products being created. It tracks what changed, when it changed, and who changed it. On a project with multiple contributors to shared documents, configuration management prevents the chaos of people working from different versions of the same plan.

Configuration management tools support:

Control of review and approval steps for key artifacts
Control of product versions and iterations
Verification that specifications and plans reflect the current agreed position

Version Control

Version control systems record changes to files and allow previous versions to be retrieved. Every time a file is changed, the system saves a new version with a date, time, and record of who made the change. This creates a complete audit trail of the artifact’s history, which is particularly important for compliance-sensitive projects where demonstrating what was known and when can matter as much as the artifact content itself.

Most project management information systems include version control for key artifacts. The project manager should confirm it is enabled and in use, not just assume it is because the system supports it.

Storage and Distribution

Artifact storage systems should be:

Accessible to everyone who needs to use the artifacts
Scaled to the project’s complexity: small projects do not need enterprise document management systems
Supported by appropriate security so the right people can access what they need and the wrong people cannot
Cloud-based for geographically distributed teams, to remove location as a barrier to access

Centralized storage in a project management information system checks many of these boxes. However, it needs to be configured to give the right people access. A document in a proprietary format is not accessible to a vendor operating on a different platform.

Project Management Information System (PMIS)

The PMIS is the software environment used to store, manage, and share project information. It may include scheduling tools, cost tracking, document repositories, and communication platforms. Configuring the PMIS to match the project’s stakeholder access needs is a planning task, not an afterthought. The system needs to be set up, permissions need to be assigned, and stakeholders need to know where to find information before they need it.

2.9.5 Assess Current Progress

Knowing the plan is not enough; the project manager must continuously track whether the project is executing to it. Assessing current progress means comparing actual performance to the baseline across scope, schedule, cost, and quality, and identifying deviations before they become problems.

Traditional Progress Assessment

Predictive projects assess progress by comparing actuals to the approved baselines. The primary tools include:

Tracking Gantt charts updated with actual start and finish dates and percent complete figures, providing a visual read of which activities are on track and which are running late.

Earned Value Management (EVM) provides a quantitative view of both schedule and cost performance together. The Schedule Performance Index (SPI) shows whether the project is earning value at the planned rate; the Cost Performance Index (CPI) shows whether it is doing so within budget. Together they give a more complete picture than tracking cost or schedule independently. An SPI of 0.9 and a CPI of 0.85 tells the project manager the project is behind schedule and over budget simultaneously, which a Gantt chart alone would not reveal.

Milestone reviews assess progress at pre-defined checkpoints. Phase gates and steering committee reviews are scheduled opportunities to formally assess whether the project is on track and whether continued investment is justified.

Agile Progress Assessment

Agile projects assess progress differently, reflecting the expectation that plans will evolve as the project proceeds.

Iteration reviews hold at the end of each sprint/iteration and demonstrate completed functionality to the product owner and other stakeholders. What gets accepted by the product owner represents real, verified progress. What is not yet accepted does not count. This keeps the progress assessment honest: there is no partial credit for work that is almost done.

Release burn-down graphs show the estimated work remaining over time and project when it will reach zero at the current rate. If the actual completion line is trending above the planned line, the team can see the risk of a late finish emerging while there is still time to respond.

Cumulative flow diagrams show the rate of completion and any scope growth together. A widening gap between work started and work finished signals a flow problem; a rising total scope line signals scope is being added faster than it is being completed.

2.9.6 Measure, Analyze, and Update Project Metrics

Metrics need to be actively managed, not just collected. Measuring means gathering the data consistently. Analyzing means understanding what it shows. Updating means revising forecasts and plans based on what the analysis reveals.

Analyzing Trends

A single data point tells you where the project is right now. A trend tells you where it is heading. Project managers should present metrics with their trend lines rather than as isolated readings. A CPI of 0.92 this month is concerning; a CPI that has moved from 0.97 to 0.95 to 0.92 over three reporting periods is a deteriorating trend that demands action before it becomes a crisis.

Burn-down graphs and cumulative flow diagrams are trend tools by design: they are only useful when viewed over time. A release burn-down chart showing a single data point tells you almost nothing; the same chart with six weeks of data tells you where the project will likely finish.

Forecasting

Current performance data should be used to update completion forecasts. On a predictive project, the Estimate at Completion (EAC) uses actual cost and earned value data to project the final cost based on how the project is performing now, not how it was originally expected to perform. On an agile project, velocity or throughput data divided into remaining work gives the team a continuously updated completion forecast that reflects current reality.

Forecasts should include a confidence range, not just a single point estimate. A completion date of “end of Q2 plus or minus three weeks” is more useful than a precise date that implies certainty the project does not have.

Updating the Metrics

When analysis reveals that the current metrics are not capturing what matters, or that new dimensions of performance have become relevant, the metrics themselves should be updated. Metrics are not fixed for the life of the project. A metric that was useful in the planning phase may not be the most relevant measure during peak execution; one that becomes critical during close-out may not have been worth tracking earlier.

2.9.7 Communicate Project Status

Evaluating project status has no value unless the results reach the people who need them. Communicating project status means getting the right information to the right stakeholders, in a form they can understand, at the time they need it.

PMI research suggests communication breakdowns account for around 30% of project failures. Some discussions put the figure higher, depending on how scope and requirements failures are classified. Either way, the cost of poor communication is real, and it compounds: projects fall behind one day and one missed conversation at a time.

Push Communications

Push communications are reports, documents, and messages sent out to stakeholders. A project status report is a push communication: the project manager prepares it and distributes it. Push communications work when stakeholders need regular, formatted updates and are unlikely to seek out the information themselves.

Effective status reports are not simply a recitation of activities completed. They present progress against the plan, flag variances, explain what caused them, and describe what the project manager is doing about them. They should be honest: sharing bad news in a status report is far less damaging than having stakeholders discover it from another source.

When sharing forecasts in status reports, include a confidence range. A project manager who reports “we will finish by June 15” and misses by three weeks has a credibility problem. One who reports “current trends indicate a finish between June 8 and June 28” and finishes on June 20 has demonstrated accurate forecasting.

Pull Communications

With pull communications, stakeholders access information they need from a shared source: a project website, a shared document repository, or a project management information system. Rather than receiving reports, they retrieve data when they need it.

Pull systems work well when stakeholders have different information needs and access them at different times. They reduce the volume of distributed reports and put information in one authoritative place. They require stakeholders who are motivated to check the source, however, which is not always a safe assumption. The project manager should periodically confirm that pull information is being accessed and understood, not just assume that making it available means people are using it.

Information Radiators

Information radiators are large visible charts displayed in shared spaces or on project websites that broadcast project data broadly without requiring stakeholders to request it. Task boards, burn-down charts, impediment boards, and cumulative flow diagrams are common examples.

Information radiators are designed for transparency: they make the state of the project visible to anyone who looks. Development team members, rather than only the project manager, typically maintain them, which distributes the communication responsibility and broadens the set of people who are actively engaged in reporting on the project.

Product Demonstrations

Sometimes, the most effective status communication is showing the product rather than reporting on it. A working demonstration of what the team has built is more concrete and tangible than any chart or report. Stakeholders who see, touch, and try an increment of the product get a richer and more accurate understanding of where the project is than those who read a progress summary.

Agile projects build demonstrations into every sprint/iteration as a core practice. Predictive projects can also incorporate demonstrations, proof-of-concept reviews, and prototype walkthroughs at key points in the schedule. The communication value is the same regardless of delivery approach.

Agile Communication Practices

Agile projects do not typically produce formal communications management plans. Instead, transparency and information sharing are built into the core practices:

Iteration reviews surface project status to the product owner and stakeholders at the end of every sprint/iteration, combining a product demonstration with an update on completion forecasts and project spend.

Daily stand-ups are short team meetings, typically 15 minutes, where team members share what they are working on, what they completed, and what is blocking them. They are a team coordination tool, not a status report to management, but they surface impediments quickly so the project manager can act on them.

Kanban boards and task boards make work visible: what is planned, what is in progress, and what is done. Anyone looking at the board gets an immediate read of the team’s current status without needing a report.

Retrospectives provide teams with a forum to discuss what is working and what is not, both in delivery and in communication. If stakeholders are not getting what they need, a retrospective is a natural place for that problem to surface.

Hybrid Note: Hybrid projects often combine elements of both approaches. An agile team may conduct regular sprint/iteration reviews while also producing a formal monthly status report for a steering committee that expects a predictive format. The project manager needs to confirm that both channels are serving their audiences, and that the information they carry is consistent. Conflicting signals from different communication channels erode stakeholder confidence quickly.

2.9.8 Continually Assess the Effectiveness of Artifact Management

Having artifact management systems in place does not mean they are working as intended. The project manager should periodically check that the systems are performing as expected: that version control is capturing changes, that artifacts are stored where people can find them, and that the right people have access while the wrong people do not.

Practical Checks

Do not assume everything is configured correctly without verifying it. Test the ability to roll back a version of a key document. Check who last changed a file and what the change was. Pull an old version of the project plan and confirm it matches what was in place at that point in the project. These are not bureaucratic exercises; they are checks that the system will be there when it is needed.

Tailoring Rigor to the Project

The level of artifact management rigor should match the project. Safety-critical and compliance-driven projects require strict controls, complete audit trails, and formal review and approval processes for every change to a key artifact. A small internal improvement project may need nothing more than a shared folder with a clear naming convention and a habit of saving drafts separately from final versions.

A one-size-fits-all approach to artifact management either over-burdens small projects with unnecessary process or under-protects large projects with insufficient control. Part of assessing artifact management effectiveness is asking whether the current approach is proportionate to the project’s actual risk and governance requirements.

Spreading Artifact Management Knowledge

Artifact management only works if the whole team follows the same practices. The project manager should confirm that team members understand what artifacts are under configuration management, how to check in and check out documents, how to record changes, and what the approval steps are for different artifact types. A system that one person understands perfectly but nobody else uses is not a functioning system.

Deliverables and Tools

Deliverables and Tools
Project Metrics – Defined measures used to track and communicate progress toward project objectives. Should be directly connected to end goals and self-generating where possible.
Project Status Report – A formal communication describing progress against the plan, current variances, their causes, and the actions being taken in response.
Information Radiator – A large visible chart displayed in a shared space or on a project website, showing project data broadly to all interested parties without requiring a specific request.
Earned Value Management (EVM) – A method for measuring project performance by integrating scope, schedule, and cost data. Key metrics include SPI (Schedule Performance Index) and CPI (Cost Performance Index).
Estimate at Completion (EAC) – A forecast of the total project cost based on current performance data.
Release Burn-Down Graph – An agile tracking chart showing estimated work remaining against a projected completion rate.
Cumulative Flow Diagram (CFD) – A chart showing work in different states over time, used to track flow and identify scope growth or bottlenecks.
Configuration Management – The process of controlling and tracking changes to project artifacts and project products.
Version Control – A system that records changes to files, assigns version numbers, and creates an audit trail of who changed what and when.
Project Management Information System (PMIS) – Software tools used to plan, execute, and control project information. Typically includes scheduling, cost tracking, and document management functions.
Lessons Learned Register – A repository of knowledge from the current and past projects, maintained throughout the project and used to improve future performance.

FAQ

What is status evaluation?

Gathering data on what is happening, comparing it against the plan, and sharing an honest picture of the gap.

Is it a one-time activity?

No. It is a continuous discipline running throughout the project.

What are the four threads?

Tracking progress, maintaining artifacts, measuring performance, and communicating results.

How does this task fit into the 2026 PMP exam?

Task 2.9 sits in the Process domain of the 2026 Exam Content Outline. The 2026 PMP Exam page has the domain and task breakdown and what changed in the new exam.

Share Content

Pos.	Name	Entered on	Points	Result
Table is loading
No data available

2.9 Evaluate Project Status