How do you measure Project On-Time Delivery?

[Sara B]

How do you measure whether a project met the planned go-live date and was delivered on time?

We have configured the system with an additional go-live date field and a check box for "delivered to customer" to support this measurement. However, we would like to be able to factor in approved Project Change Requests records or potential re-baselining into the metric, but have not found a way to do that (without manual analysis). 

If you are not measuring on-time project delivery, what other metrics/KPIs do you use to monitor the project portfolio?

-Sara

[juan9 · Accepted solution]

I need some more examples:

You can measure by looking at different states, and maybe adding time stamps per state.

You can also do an approval, or some attestation on the go-live date to.

You can also have the system check a set of conditions on the go-live date, then depending on that logic, it can determine if it was delivered or not. 

For example, at the end of our projects, we always do a write-off, so the system should be able to recognize that the project was completed based on some set of parameters.

The first question I ever answered here:)

[Rajesh_Singh]

Hi @sarabb 

There is no automatic way to measure whether a project met the planned go-live date and was delivered on time. However you can achieve this by little customisation.

1. Create check box field "Go-live task" on Project task form
2. Whenever any project task selected as "Go-live task" and its planned start and end date is updated then create following event notification must triggered with below conditions
• IF "Go-live task" is in "open" state and planned end date is less than system date then 2 or 3 days before notification must sent to project manager & PMO team stating this project is near go-live date.
• IF "Go-live task" is in "open" state and planned end date is more than system date then notification email must trigger to its corresponding project manager & PMO team to action stating this project has missed go-live date. 
3. But above solution will work only if your creating project task with "Go-live task". What if you do not create task at all? then in that case please new field  "Go-live date" on project form itself and use below conditions
   
   • IF Project is in "Executing" state and "Go-live date" is less than system date then 2 or 3 days before notification must sent to project manager & PMO team stating this project is near go-live date.
   • IF Project is in "Executing" or "Delivering" state and "Go-live date" is more than system date then notification email must trigger to its corresponding project manager & PMO team to action stating this project has missed go-live date. 

Please let me know if this makes sense.

[Dhiren Aghera]

Hi Sarabb,

Very valid use case and an important KPI to measure as well. You definitely need some customizations as mentioned my @Rajesh Singh  and depending on the process maturity it might be simple or complex.

We have achieved this by simply adding new fields like "Go-Live date", "Actual Go-Live date" and calculated field "On-Time Delivery".

Once the state moves from plan to implement phase the "Go-Live date" field becomes mandatory.

The "Actual Go-Live date" can be blank but becomes mandatory when the state changes from Deploy to Close.

The "On-Time Delivery" is calculated based on the above two dates. If the "Actual Go-Live date" is less than or equal to "Go-Live date" then "On-Time Delivery" is "Yes" else "No". 

Hope this helps.

[Sara B]

Hi, thank-you for you comments so far. It sounds like we are on the right track, in terms of system configuration, and doing something very similar to what you have all described.

We have an Original Go-Live Date and a Current Planned Go-Live Date field. Both fields are required once the project moves into the Executing Phase. At that point, both dates would be the same. Additionally, the Original Go-Live date field becomes read only. The assumption here is that the date is realistic based on the activities in the Planning phase. Then, if the go-live date needs to change, the project manager enters a project change request record and updates the Current Planned Go-Live Date with the new date. 

Since we measure quarterly for a rolling 12-month period, not all projects are closed at the time of reporting. To support the metric, we created a check-box to indicate that a project was Delivered to the Customer. This box is required when closing a project with the state of Closed Complete.

A project is considered "on-time" if the Current Planned Go-Live date is prior to or within 8 days after the Original Go-Live date AND the Delivered to Customer Box is checked. 

This has worked fairly well so far, but we are considering a change to the process which would allow for the original go-live date to change IF there is a valid, stakeholder approved reason. This gets a little gray in terms of how to define that, but the thought is that sometimes it is necessary to re-baseline a project and that shouldn't count against us.

How strict are others in defining or considering valid project changes, which impact the schedule, when measuring On-Time Delivery?