There seems to be some things that don't quite add up, obviously if you have chosen BT as your provider , they rely on Openreach to provide the infrastructure to enable your property to receive BT's 'services', and any 'network construction' is down to OR not BT ( they are not one and they same entity ) but obviously BT should keep you advised with progress and chase OR if necessary, but if you had used Sky or Talk Talk ( for example) the same issues would exist.
There should be no excess construction cost complication if it's only one pole and its within the USO, ( so , no way this one pole could get into excess construction costs, its way below the £3400 threshold) , that seems to be an area that should be challenged, so why are they even mentioning costs ?.
If the pole is to be sited in your own land, then even though it's primarily to serve your address , you would still need to give a PTW ( permission to work) and to agree to an OR wayleave, ( and not expect any payment for it) ....a wayleave granting access to the pole is required, so that should access be required in the future , it wouldn't be refused...is it possible that it's this that is causing the delay rather than a 'costs' issue ?.
If the pole isn't even installed yet, then even if BT gave you a date of 24/12/18 for the install, then that date for service was never going to be achievable, in fact any date offered needs to be judged on the basis ' is this new pole installed yet' .
Is there more to your install than what's been posted here ?, a problem unable to achieve the required height over a road from an existing pole , requiring a new extra pole , is quite a common issue and one that is usually easily resolved within a couple of weeks maximum , and possibly much less time than that, issues that take time are conflict over pole position, expecting a payment when the pole is for the applicants own service , or refusal to grant a wayleave.
If this new pole is to change the entry position of the service ( when an existing entry point is already available ) this then becomes 'chargeable' work and not USO work, as OR's cheapest solution would be to use what already exists, but you seem to suggest that isn't the issue