QuickPay-Operational-Performance / Data-and-code

Data and code for econometric analysis
0 stars 0 forks source link

Alternative metrics #16

Closed vob2 closed 3 years ago

vob2 commented 4 years ago

One can argue that we need to control for the size of the project (in terms of time). So, in addition to raw numbers for our analysis we should also look at percentage of the originally budgeted time that a project has been delayed.

More exploratory: it could be interesting to look at the uncertainty about projects' completion. The argument is that with more resources, firms might be able to manage the uncertainty better. For this, something like S.D. of project delay (raw or %) might be good. Or the coefficient of variation.

Can we articulate the economic significance of project delays? A quick google search brings up papers that link delays with $ losses. Maybe we can pick somewhat related categories of projects and guesstimate.

vob2 commented 4 years ago

In addition to project delay, we should be able to say by how much projects overran their initial award amounts.

vob2 commented 4 years ago

A reason for modifying contract can be "terminate for default" How often does this happen? Is there a change after QuickPay for Small and Other suppliers?

vibhuti6 commented 4 years ago

A reason for modifying contract can be "terminate for default" How often does this happen? Is there a change after QuickPay for Small and Other suppliers?

Hi Vlad, just documenting that we don't have enough data to meaningfully capture this effect. See details here where most entries for "action type" are null. Thanks.

vob2 commented 3 years ago

This is also an issue under https://github.com/QuickPay-Operational-Performance/paper/issues/19

Other metrics mentioned here are the Variance of project delays. This should be on the firm level, where we compare the variance of delays before QP Law and after QP Law. However, we do not have enough observations before and after QP Law to make this meaningful. The cross-sectional variance would not make sense here (I think)

Using some $ value per unit of delay to give economic significance to the average delay increase is a good idea. I created a separate issue for it: https://github.com/QuickPay-Operational-Performance/paper/issues/20

Budget overruns is in a separate issue.

I am closing this issue, to avoid duplications