Use of 'Technical Instructions'; DoN

[PRoy12]

A single award IDIQ contract at a test range was let for a wide range of services and included within the ordering instructions is the 'ability' to issue 'TIs' (put {"}s as I am well aware there is no definition of a 'TI' within the FAR or applicable supplements and believe they are morphing what a Technical Direction Letter (TDL) and its intent is for their purposes, granted thats also not defined in the FAR or applicable supplements) within a Task Order (TO). They want to issue a TO for a requirement and then as similar requirements come up, modify the TO with a 'TI' that includes a different 'PWS/SOW' as well as funding (legal has stated that a J&A not be required as since it is a single award IDIQ, the outcome would not change/no competition is required or utilized to meet the need). Essentially they are treating a TO as the basic contract and a 'TI' as the TO. Not only is this asinine in my opinion as it just adds a layer to an already existing process (let alone its compliance with regulation/law perhaps) but I see it as one big undefinitized action. I have never seen a contract executed in this way and am trying to get insight from others on whether something similar is used/done elsewhere and/or if I am crazy to think this is one big convoluted mess. Lastly, I suspect the reason for doing it this way is perhaps when excess funds are remaining, they want to roll it over to the next 'mission/op' on the same TO and feel like this may be a sneaky way to do so and hope to not get ding'd, which, I dont see how it isnt a violation if they did/do.

 

Thanks for any insight or thoughts.

[joel hoffman]

So, simply put, they want to add similar work by modification to an existing task order for convenience,  in lieu of having to develop and issue a new task order.

Since the work is within the scope of the basic ID/IQ, they don’t have to justify an exception to competition.

At first glance, it would seem possible to do it that way.

 

[Don Mansfield]

1 hour ago, PRoy12 said:

Essentially they are treating a TO as the basic contract and a 'TI' as the TO.

That's an apt description. I'm familiar with this practice. However, I've only seen it used to get around fair opportunity rules and obligate a pool of funds. That is, competitively award a large, vaguely worded task order that is funded. Then, subsequently issue TIs that actually task the contractor to do something.

 

[PRoy12]

@joel hoffman@Don Mansfield As you seem to be in agreement on the acceptability of the practice, I guess my next question would be what, if any benefit do you see there is as again, it seems to add an unnecessary layer to an existing process? New requirements will still requires the same requirements docs/package for review and submission to the ktr for proposal and then tech eval, cost analysis, etc and then mod/award.

[Vern Edwards]

Procedural insanity.

[Don Mansfield]

23 minutes ago, PRoy12 said:

@joel hoffman@Don Mansfield As you seem to be in agreement on the acceptability of the practice, I guess my next question would be what, if any benefit do you see there is as again, it seems to add an unnecessary layer to an existing process? New requirements will still requires the same requirements docs/package for review and submission to the ktr for proposal and then tech eval, cost analysis, etc and then mod/award.

The way you described it, I don't see any benefit.

[PRoy12]

6 minutes ago, Vern Edwards said:

Procedural insanity.

Thank you for that! The customer has consistently pushed this to be the process due to 'efficiencies' yet have not explained (on their end) what they see as those efficiencies/benefits are and I have yet to come up with a single one. If there was a drastic say, savings of time in the form of less document creation on their end with minimal to no additional work on our end, I could see weighing the pros and cons and perhaps taking a hit so that they could execute missions in a more timely manner but that is most certainly not the case.

 

Background: a former PCO put this 'masterpiece' of a contract in place with certain promises and visions of execution to the customer but left shortly after award and we are now left banging our heads against a wall while trying to pick up the pieces and understand the intent and processes he has laid out...

[Don Mansfield]

Do the task orders contain all the information required by FAR 16.505(a)(7)?

[joel hoffman]

4 hours ago, PRoy12 said:

Thank you for that! The customer has consistently pushed this to be the process due to 'efficiencies' yet have not explained (on their end) what they see as those efficiencies/benefits are and I have yet to come up with a single one. If there was a drastic say, savings of time in the form of less document creation on their end with minimal to no additional work on our end, I could see weighing the pros and cons and perhaps taking a hit so that they could execute missions in a more timely manner but that is most certainly not the case.

 

Background: a former PCO put this 'masterpiece' of a contract in place with certain promises and visions of execution to the customer but left shortly after award and we are now left banging our heads against a wall while trying to pick up the pieces and understand the intent and processes he has laid out...

You aren’t bound to continue this practice with a new PCO. Issue new task orders then. I would think though that mod to an existing task order is simpler than preparing and issuing a fresh task order, especially if work on both is intermingled or otherwise concurrent .