Edition Best Practices
An edition is the mechanism through which data is collected for each reporting period. Consistent edition discipline ensures reports are accurate, comparable across periods, and produced on time.
Before creating an edition
| Practice | Description |
|---|---|
| Confirm the data date | All schedule and cost data should be based on a consistent as-of date. Confirm this with the scheduler before creating the edition. |
| Prepare source data | Export or extract data from source systems (e.g., Primavera P6, Excel cost sheets) before data entry begins. Do not enter from memory. |
| Assign contributors early | Set assignees when creating the edition so contributors receive notifications and can plan their input time. |
| Set a realistic due date | Allow sufficient time for data entry, internal review, and correction cycles. Two to three days before the external due date is typical. |
Data entry discipline
Consistency across periods
The most common cause of report quality issues is inconsistent data between periods. Avoid:
- Changing how progress is measured mid-project (e.g., switching from units-complete to duration-complete).
- Changing the scope of what activities are included in a section without updating the previous period's baseline.
- Rounding numbers differently in different periods.
Units and scales
| Field type | Best practice |
|---|---|
| Currency | Always enter values in the same unit (e.g., thousands, exact). Set the unit in the field description. |
| Percentage | Enter as a decimal (0.75) OR as a percentage (75) consistently \u2014 not a mix. The blueprint should define this. |
| Duration | Use the same unit (days, weeks) as the rest of the report. Do not mix. |
| Dates | Always use the configured date format. Copy/paste dates carefully to avoid format ambiguity (01/02 is ambiguous). |
Repeating rows (activity/record lists)
- Use Import rows from CSV or Excel for sections with many rows rather than manual entry.
- Before importing, validate that the column mapping matches the section's field order.
- Remove duplicate rows before importing \u2014 Report Forge does not automatically deduplicate.
- Include only in-scope rows. Rows that should not appear in the report should not be imported.
Review and correction cycle
Raising effective review comments
When reviewing another contributor's section:
- Refer to the specific field and row in the comment (e.g., "Row 14, Forecast Finish: this date appears to be earlier than the baseline by 3 months \u2014 please confirm or correct").
- Be specific about what correction is needed, not just that something is wrong.
- Use the comment priority (Critical/Major/Minor) consistently so contributors can triage.
Responding to comments
- Address every comment before resubmitting. Do not mark a comment as resolved without making a change or providing a written justification for leaving the value as-is.
- If a field value is correct and the comment is based on a misunderstanding, explain in the reply before resolving.
Naming conventions
| Element | Recommended format |
|---|---|
| Edition name | [Project Code] [Report Type] [Period] — e.g., PROJ-001 Monthly Progress April 2025 |
| Reporting period | Use the last calendar day of the period as the end date |
| Data date | Use the P6/schedule data date exactly as-is |
Closing and archiving
- Close an edition only after the final output has been generated and distributed.
- Do not reopen closed editions to correct data \u2014 create a new edition for the correction and mark the corrected edition as a revision.
- Keep at least 12 months of editions active (not archived) for trend comparison in outputs.