Project end dates

[duncandewhurst]

The description for project/completion/endDate is:

The actual completion date for the project (compare with the endDate in project period).

However, the description for project/period suggests that this field can be updated over the life of the project, in which case, since OC4IDS doesn't capture a change history, the original planned end date would be overwritten and lost for comparison:

The period over which this project will run. This may be updated as the project moves through each phase as more information becomes available to more accurately specify anticipated start and end dates. Implementations may vary as to whether the period is taken to run from the earliest planning to the latest monitoring report, or whether the period only represents the major construction phase.

Possible solutions:

1. Update the description of project/period to state that this shouldn't be updated beyond the end of the preparation phase of the project - in which case there wouldn't be a place for any subsequent updates to the forecast end date for the project.

2. Replace project/period with explicit properties for the originally planned start/end dates and latest estimate for the start/end dates

[jpmckinney]

Which option better conforms to IDS' model? My understanding is that the option 1 does.

[duncandewhurst]

IDS's model is inconsistent across project period, cost and scope (I'm including the last two for comparison because I think we should have a consistent approach in OC4IDS). Scope and budget/cost appear in both the preparation and completion sections of IDS, whilst period/completion date appears only in the completion section.

The relevant elements in IDS are:

Project Phase	Information	Description
Preparation	Project scope (main output)	Main outputs from the project that are being taken forward into construction (type, quantity, unit)
Preparation	Project budget	Specify the projected costs/allocated budget for the project (currency and amount). The budget includes land / property acquisition, environmental mitigation measures, H&S provisions, client, consultant & contractor costs, VAT etc.
Completion	Scope at completion (projected)	Indicate projected or actual scope of project. Aim is to show if the completed project scope differs from the original project scope. Specify main outputs (type, quantity, unit)
Completion	Completion cost (projected)	State projected or actual completion cost (currency and amount)
Completion	Completion date (projected)	State projected or actual completion date

In OC4IDS, we effectively moved the projected elements out of the completion section and described the information in the completion section as "This information is provided at project completion, and reflects the final timing and values relating to the project."

I think it makes sense to have an aligned approach across scope, cost and duration - so I'm happy with option 1.

If the need for a 'latest estimate' type field is surfaced through implementation it can be added as an additional field/extension and considered for inclusion in a future update.

Does that sound good?

[jpmckinney]

Yes. CoST's use cases require access to (at least) initial and final values. I can see latest estimates also being necessary, but for now we should at least fix the semantics to preserve initial values.

[duncandewhurst]

From a comment from Bernadine Fernz on the draft 0.9.2 release:

2. Comparing completion/endDate with project/period
   a. Agree with James that latest estimates are also necessary and we should include as soon as possible, either in this release or the next
   i. I believe it’s an oversight on CoST’s part and they are likely to agree with us. I expect that this was drafted based mainly on CoST’s experience with paper-based disclosure so by ‘updating’, they likely mean that new dates could be provided (but the old dates are obviously still accessible on the old documents).

If only the latest estimate is important, then this could be added as an additional property (either under period or at the project level), however if the history of changes is required more thought will be required about how to achieve this in OC4IDS.

[duncandewhurst]

@EvelynDinora confirmed that CoST's use case is to understand the total over/under-run for the project, for which only the original estimate and final completion date are required.

However Bernadine Fernz (OCP) and Evelyn highlighted use cases for:

1. providing a latest estimate (e.g. for groups that will benefit from the asset to know when it will be available, for groups affected by the development to know when disruption will end)
2. providing a history of changes to the estimated end date, with a rationale for each change (e.g. for monitoring groups to understand the reasons for delays to a project)

I'm moving this issue to the 1.0 milestone to consider how to address the above use cases.

@EvelynDinora, Bernadine - please add any further context

[duncandewhurst]

CoST's Assurance Manual (page 36) mentions looking at time and cost variations for in-progress projects.

[duncandewhurst]

The projected completion date has come up in CoST Uganda, so it would be good to agree on an approach for that at least (recognising that providing a history of changes is a more complex issue that will require further research and discussion).

If only the latest estimate is important, then this could be added as an additional property (either under period or at the project level)

I don't think it makes sense to add the projected end date as a property under the period object since period is restricted to the planned period during the identification and preparation phases.

I think there are two options:

• Add a field directly at the project level, e.g. projectedEndDate
• Add a field to the completion object, e.g. completion/projectedEndDate

Adding a field to completion is inconsistent with the semantics of that object and its other properties, which are all restricted to actual final values, rather than projected values. That leaves adding a field directly at the project level, which seems a bit inelegant.

[jpmckinney]

Are there any other projections (whether dates, values, etc.) that are likely to be tracked? (Edit: See #352)

We might consider:

1. Some generic solution like milestones or metrics, etc.
2. A copy (perhaps renaming some fields) of the completion structure, but explicitly for projections.

[duncandewhurst]

Are there any other projections (whether dates, values, etc.) that are likely to be tracked? (Edit: See #352)

Yep - as mentioned in that issue, also the project value and scope.

1. Some generic solution like milestones or metrics, etc.

In #287 we agreed not to put projected costs in metrics.

2. A copy (perhaps renaming some fields) of the `completion` structure, but explicitly for projections.

I think this might be most straightforward for publishers and users, instead of having the projections sitting in different places but the final values grouped under one object.