Asta Powerproject Schedule Review: How to Check a .pp Programme
How to review a contractor's Asta Powerproject programme: what a .pp file holds, the checks to run, and the progress and baseline traps in Powerproject.
A contractor issues the monthly update as a .pp file. Your organisation runs Primavera P6, or nothing at all, and nobody on the client side owns a Powerproject licence. The programme still has to be reviewed before the progress meeting, and the claim that arrives next quarter will be built on it.
Asta Powerproject, from Elecosoft, is a long-established construction planning tool, and its files travel further than its licences do. That leaves the person reviewing the programme with three options: ask for an export, open the file in a free viewer, or analyse the .pp directly. This guide covers what to check in a Powerproject programme, the two Powerproject behaviours that catch reviewers out (progress and baselines), and how to run the review without the software. It sits alongside our guides to reviewing a Primavera P6 schedule and checking an MS Project schedule, and within the wider discipline of construction schedule analysis.
What a .pp File Holds and How to Open It
A .pp file is Powerproject’s native project file. It holds the tasks, the logic links, calendars, constraints, progress, and, from Powerproject version 15.0.01 onwards, any baselines the planner has created, which are embedded in the project file rather than saved as separate .ppb files.
Powerproject can also export to Primavera XER and XML. The format matters: Elecosoft’s documentation notes that baselines are included in an XML export and are not included in an XER export. If you ask the contractor for an XER so you can review in P6, you lose the baseline on the way.
| Route | What you can do | What you give up |
|---|---|---|
| Powerproject licence | Full review in the native tool | Licence cost and training for the client team |
| Elecosoft’s free Project Viewer | View, navigate and print the programme (Windows) | Analysis: Elecosoft describes it as a viewing and printing tool |
| Ask for an XER export | Review in P6 if you have it | Baselines, and any confidence that the export matches the .pp |
Upload the .pp to an analysis tool | Quality checks and update comparison on the file as issued | The embedded baselines (see below) |
Caption: Four ways to review a Powerproject programme when you are not the planner who built it.
An export is also a second document. If a claim is later argued on the .pp, your review should have been done on the .pp.
The Powerproject Review Checklist
The checks are the same ones you would run on any critical path programme. The DCMA 14-Point Assessment gives the thresholds; our DCMA 14-Point guide explains each one in full.
data date] --> B[2. Logic and
open ends] B --> C[3. Constraints
and lags] C --> D[4. Float and
critical path] D --> E[5. Durations and
calendars] E --> F[6. Progress] F --> G[7. Baseline and
change since last update]
Figure 1: Review sequence for a Powerproject programme. Progress and baseline are where Powerproject differs most from P6.
| Check | What to look for | Benchmark |
|---|---|---|
| Missing logic | Tasks with no predecessor or no successor | DCMA metric 1: no more than 5% of tasks |
| Hard constraints | Dates imposed rather than driven by logic | DCMA metric 5: no more than 5% |
| High float | Float above 44 working days | DCMA metric 6: no more than 5% |
| Negative float | Tasks already late against a constraint or key date | DCMA metric 7: none |
| High duration | Tasks longer than 44 working days | DCMA metric 8: no more than 5% |
| Critical path | A continuous path from the data date to completion | DCMA metric 12 (critical path test) |
| Progress | Claimed progress consistent with remaining duration | See the next section |
Caption: Core checks for a Powerproject review, with the DCMA thresholds as the benchmark.
Settings and data date
Confirm the report date of the current progress period before anything else. Powerproject organises progress into progress periods, each with a report date, and the planner has to move the progress entry period on each week or month. An update statused against last month’s report date will show progress that doesn’t line up with the progress report.
Logic, constraints and lags
Missing logic and hard constraints do the most damage, because they decide whether the completion date is calculated or typed in. A programme that clears the logic check but carries a constraint on every key date isn’t logic-driven. Lags deserve a second look: a long lag on a critical link can hide a sequence the contractor never planned in detail.
Float and the critical path
Check that the critical path runs continuously from the data date to completion and that it passes through the work you’d expect to govern. High float on a large share of tasks usually means missing successors. Negative float means the programme already can’t meet a date it’s constrained to, and the size matters: one working day behind is a different conversation from sixty.
Durations and calendars
Long durations hide sequence. Tasks over 44 working days are hard to status honestly, because there’s no way to tell progress from time: suppose 40% of the duration has elapsed, and nothing in the task says whether 40% of the work is done. Check which calendar each critical task sits on. A seven-day calendar on critical work makes the programme finish sooner on paper than the site can deliver it.
The Powerproject Progress Trap
Powerproject records progress in two ways that can disagree. Elecosoft’s documentation explains overall percentage complete: a task planned for 10 days, with 5 days elapsed but only 20% of the work done, can be recorded as 20% overall complete while it is 50% complete by duration. The documentation also states that changes to the actual or remaining duration do not change the overall percentage complete value.
That independence is useful to a planner and a gap for a reviewer. The overall percentage is a statement about the work. The remaining duration is what drives the successors and the completion date. When a task claims 90% overall progress but still carries most of its remaining duration, one of the two figures is wrong, and the programme can’t tell you which. How the two relate depends on a project option the planner chooses, so check it before you rely on either.
Measured on a real programme: On one Powerproject programme in our test set, with about 14,700 tasks, 4,894 of the 6,621 tasks carrying an overall percentage recorded physical progress at least 25 percentage points ahead of their duration progress, with two or more working days still to run. On five unprogressed
.ppprogrammes the same check found nothing, as it should.What it means: A programme can report healthy progress in its overall percentages while its remaining durations, and therefore its dates, say the work is further behind. Test progress against remaining duration before accepting the progress narrative, and ask which figure the contractor’s earned value and forecast are built on.
The gap shows a mismatch in the file and says nothing about why. It may be optimistic statusing, a remaining duration nobody updated, or a legitimate front-loaded task. AACE International Recommended Practice 29R-03 §3.3 treats this kind of inconsistency as a schedule-integrity question to resolve before any forensic method is applied. The reviewer’s job is to put the question to the contractor on the specific tasks.
Baselines in a Powerproject File
A Powerproject file can carry as many baselines as the planner creates, with one set as current for comparison. That is convenient for the contractor and a trap for the reviewer, because the baseline shown depends on which one the planner set as current, and a re-baseline can happen quietly between updates.
For a review, treat the accepted baseline as its own file. Ask for the accepted baseline programme as a separate .pp, keep it, and compare every update against that file rather than against whatever baseline the latest update carries. If the contract names a baseline, the file you compare against should be that one. Our guide to comparing the baseline against the current schedule covers what to look for once you have both.
Review a .pp Without Powerproject
ScheduleLens reads the .pp file directly in the browser. There’s no Powerproject licence, no viewer install and no export step. Upload a single .pp for a health check, or two for a comparison between the baseline and an update.
| What ScheduleLens reads from a .pp | Status |
|---|---|
| Tasks, logic links, lags, constraints and calendars | Read |
| Progress, remaining duration and overall percentage complete | Read |
| Physical vs duration progress check | Runs when the programme carries progress |
Baselines embedded in the .pp | Not read. Upload the baseline as its own .pp and run a comparison |
| DCMA checks that need baseline dates, such as BEI | Not scored from a single .pp |
Caption: What an uploaded Powerproject file supports, measured on real .pp programmes.
A comparison of two .pp updates reports what changed between them: dates, durations, logic, constraints and progress. Tasks that can’t be matched between the files are listed in the report. The report also runs the update-integrity checks, including the progress check above. The uploaded file is deleted after processing; if you track the project over time, an encrypted copy of the parsed programme is kept for the comparison history, and the upload form asks first.
Some older Powerproject files may not open: one 2005 file among the 12 .pp programmes we test against fails to parse, and the upload reports the failure with a prompt to re-export the file. The analysis is also a review aid. It flags evidence in the file and leaves entitlement and responsibility to the people who own them.
Records and Verification
A clean programme still needs checking against the site. Compare the progress claimed in the update with the site diaries, the progress photographs and the monthly report for the same period. Where the overall percentage and the remaining duration disagree, the records usually show which one is right. The Society of Construction Law’s Delay and Disruption Protocol is built on the same expectation: an accepted, updated programme and contemporaneous records are what a later delay analysis relies on.
Key Takeaways
- Review the
.ppas issued. An XER export drops the baselines and is a second document. - Run the standard checks against the DCMA thresholds: logic, constraints, float, critical path, durations and calendars.
- Test Powerproject’s overall percentage complete against remaining duration. They are independent, and the dates follow the remaining duration.
- Keep the accepted baseline as its own
.ppfile and compare every update against it. - For how the same review runs in other tools, see the guides to Primavera P6 schedule review and MS Project schedule checks.
This article is for educational purposes. Asta Powerproject is a trademark of Elecosoft.