Purpose: This metric is all about measuring the expectations that IT sets with the business… and then… delivering on those expectations. This is exactly the type of thing you’d like to measure before you sit down with the business and make a Service Level Guarantee. Of course, since many times you have no choice about whether you create a Service Level Agreement, you’ll probably need to do that before you have this data. That’s very common.
External: To make this fully external, it would be necessary to use workflow that changes your planned start date to a read-only field after it has been recorded by the Change Manager (or appropriate role for your organization). So, this could be a yes or a no.
Context: This metric becomes much more powerful when a filter is used against the business service (for proper context). If you haven’t yet implemented the business service concept, it’s probably wise to start with the use of categorizations. Because, there are going to be many “Business as Usual” changes (or No Impact) that aren’t going to be particularly meaningful for management if you measure this metric against every filthy little change that occurs in IT.
Specific? Yes, provided the context strategy above is leveraged.
Objective? Careful here. If the planned start date and actual start date can be changed after the fact, someone could easily make a post-facto field change and make the numbers look rosy!