FFRDCs

[Anonymous]

Anonymous wrote:

Anonymous wrote:

Anonymous wrote:

Anonymous wrote:

Anonymous wrote:

Anonymous wrote:

Anonymous wrote:

Anonymous wrote:we are laying off a bunch of support staff from IDA and MITRE. Too many bloated staff with crazy overhead who just writes reports. No, thank you!!

Who is? “DoW”?

I am the PP who mentioned it. I run a very big portfolio on S&T/R&D and IDA do their thing but they have been very expensive and the performance is not good. No changes with time and just traditional way of writing reports. My management and I decided to cut down on the support contract.

The IDA team that works for my office insists on meeting every week or two and cannot make an independent decision with my approval.

Not only that but they have to spend months of several FTE hours in writing reports that we have no need for. They insist on doing that and not what we wanted. They are also very expensive compared to other SMEs out there.

What did you want them to do?

Just give me a briefing and memo. If I want an Honda Civic, I don’t want to wait more than a year for a 1978 Oldsmobile Cutlass.

Do you give them direct feedback?

Also, they are probably told they must meet with you regularly. Their management likely asks questions like “when was your last checkin” and if they were to say “a month” they would probably get in trouble.

Yes, but they insist on doing it this way.

[Anonymous]

The point is that the FFRDC is not being responsive to the stated instructions of the customer.

[Anonymous]

Anonymous wrote:The point is that the FFRDC is not being responsive to the stated instructions of the customer.

MITRE seems to do a lot of inappropriate work for FFRDCs. RAND appears littered with conflict of interest issues. CNA’s executive ranks look bloated to some. IDA sounds stuck in a very outdated way of serving clients that isn’t always helpful. If all of this is true, the whole system needs to be rebuilt and reigned in.

[Anonymous]

Anonymous wrote:The point is that the FFRDC is not being responsive to the stated instructions of the customer.

Does the COTR agree that the "stated instructions" in line with the SOW/IDA's tech response?

[Anonymous]

^are in line with^

[Anonymous]

Anonymous wrote:

Anonymous wrote:The point is that the FFRDC is not being responsive to the stated instructions of the customer.

Does the COTR agree that the "stated instructions" in line with the SOW/IDA's tech response?

I've seen IDA staff take the SOW way too literally, often avoiding work that isn't explicitly written down. The contract is like a straitjacket, and they struggle to pivot or adapt as the project evolves. It feels to me like they often care more about rigid compliance than actually meeting our current needs.

[Anonymous]

Anonymous wrote:

Anonymous wrote:

Anonymous wrote:The point is that the FFRDC is not being responsive to the stated instructions of the customer.

Does the COTR agree that the "stated instructions" in line with the SOW/IDA's tech response?

I've seen IDA staff take the SOW way too literally, often avoiding work that isn't explicitly written down. The contract is like a straitjacket, and they struggle to pivot or adapt as the project evolves. It feels to me like they often care more about rigid compliance than actually meeting our current needs.

I'd consider talking to your COR/COTR about whether the SOW/IDA's response is too restrictive/could be updated... The FFRDC projects I worked on had SOWs/responses with a combination of tasks/subtasks that were rigid and others with generic tasking that allowed for significant FFRDC autonomy and governmental redirects during the POP. The rigid ones tended to be things like progress reports, the latter, the real engineering work. The latter were fairly frequently revisited. These tasks required a close working relationship between the COR/COTR/individual Federal responsible customers and the FFRDC managers/technical leads so the Feds got what they needed and the FFRDC didn't have problems getting paid for the work we'd done when the auditors looked at it. On that front, one key issue we had to deal with regarding the flexibility/autonomy/redirects was ensuring/showing that the FFRDC work under these tasks was autonomous enought that the services shouldn't be provided by a SETA.

[Anonymous]

Anonymous wrote:

Anonymous wrote:

Anonymous wrote:

Anonymous wrote:The point is that the FFRDC is not being responsive to the stated instructions of the customer.

Does the COTR agree that the "stated instructions" in line with the SOW/IDA's tech response?

I've seen IDA staff take the SOW way too literally, often avoiding work that isn't explicitly written down. The contract is like a straitjacket, and they struggle to pivot or adapt as the project evolves. It feels to me like they often care more about rigid compliance than actually meeting our current needs.

I'd consider talking to your COR/COTR about whether the SOW/IDA's response is too restrictive/could be updated... The FFRDC projects I worked on had SOWs/responses with a combination of tasks/subtasks that were rigid and others with generic tasking that allowed for significant FFRDC autonomy and governmental redirects during the POP. The rigid ones tended to be things like progress reports, the latter, the real engineering work. The latter were fairly frequently revisited. These tasks required a close working relationship between the COR/COTR/individual Federal responsible customers and the FFRDC managers/technical leads so the Feds got what they needed and the FFRDC didn't have problems getting paid for the work we'd done when the auditors looked at it. On that front, one key issue we had to deal with regarding the flexibility/autonomy/redirects was ensuring/showing that the FFRDC work under these tasks was autonomous enought that the services shouldn't be provided by a SETA.

Or use someone else. We’re stuck with IDA because their contracting vehicle is accessible and our typical alternative (RAND) simply isn’t a viable backup these days.

anymore.

[Anonymous]

A simpler, easier fix is to send less funding and less work to a non-responsive supplier - whether that is a commercial firm, a university, a UARC, or an FFRDC.

[Anonymous]

Anonymous wrote:

Anonymous wrote:

Anonymous wrote:

Anonymous wrote:The point is that the FFRDC is not being responsive to the stated instructions of the customer.

Does the COTR agree that the "stated instructions" in line with the SOW/IDA's tech response?

I've seen IDA staff take the SOW way too literally, often avoiding work that isn't explicitly written down. The contract is like a straitjacket, and they struggle to pivot or adapt as the project evolves. It feels to me like they often care more about rigid compliance than actually meeting our current needs.

I'd consider talking to your COR/COTR about whether the SOW/IDA's response is too restrictive/could be updated... The FFRDC projects I worked on had SOWs/responses with a combination of tasks/subtasks that were rigid and others with generic tasking that allowed for significant FFRDC autonomy and governmental redirects during the POP. The rigid ones tended to be things like progress reports, the latter, the real engineering work. The latter were fairly frequently revisited. These tasks required a close working relationship between the COR/COTR/individual Federal responsible customers and the FFRDC managers/technical leads so the Feds got what they needed and the FFRDC didn't have problems getting paid for the work we'd done when the auditors looked at it. On that front, one key issue we had to deal with regarding the flexibility/autonomy/redirects was ensuring/showing that the FFRDC work under these tasks was autonomous enought that the services shouldn't be provided by a SETA.

SETA work or not but their way of working is not good for my portfolio. we had a couple of meetings and they didn't listen so I issues a stop-work order and canceled the TO.

[Anonymous]

Anonymous wrote:

Anonymous wrote:

Anonymous wrote:

Anonymous wrote:

Anonymous wrote:The point is that the FFRDC is not being responsive to the stated instructions of the customer.

Does the COTR agree that the "stated instructions" in line with the SOW/IDA's tech response?

I've seen IDA staff take the SOW way too literally, often avoiding work that isn't explicitly written down. The contract is like a straitjacket, and they struggle to pivot or adapt as the project evolves. It feels to me like they often care more about rigid compliance than actually meeting our current needs.

I'd consider talking to your COR/COTR about whether the SOW/IDA's response is too restrictive/could be updated... The FFRDC projects I worked on had SOWs/responses with a combination of tasks/subtasks that were rigid and others with generic tasking that allowed for significant FFRDC autonomy and governmental redirects during the POP. The rigid ones tended to be things like progress reports, the latter, the real engineering work. The latter were fairly frequently revisited. These tasks required a close working relationship between the COR/COTR/individual Federal responsible customers and the FFRDC managers/technical leads so the Feds got what they needed and the FFRDC didn't have problems getting paid for the work we'd done when the auditors looked at it. On that front, one key issue we had to deal with regarding the flexibility/autonomy/redirects was ensuring/showing that the FFRDC work under these tasks was autonomous enought that the services shouldn't be provided by a SETA.

SETA work or not but their way of working is not good for my portfolio. we had a couple of meetings and they didn't listen so I issues a stop-work order and canceled the TO.

Above is simpler and easier and more time efficient than trying to fix a vendor that is broken.

[Anonymous]

Anonymous wrote:

Anonymous wrote:

Anonymous wrote:

Anonymous wrote:

Anonymous wrote:

Anonymous wrote:The point is that the FFRDC is not being responsive to the stated instructions of the customer.

Does the COTR agree that the "stated instructions" in line with the SOW/IDA's tech response?

I've seen IDA staff take the SOW way too literally, often avoiding work that isn't explicitly written down. The contract is like a straitjacket, and they struggle to pivot or adapt as the project evolves. It feels to me like they often care more about rigid compliance than actually meeting our current needs.

I'd consider talking to your COR/COTR about whether the SOW/IDA's response is too restrictive/could be updated... The FFRDC projects I worked on had SOWs/responses with a combination of tasks/subtasks that were rigid and others with generic tasking that allowed for significant FFRDC autonomy and governmental redirects during the POP. The rigid ones tended to be things like progress reports, the latter, the real engineering work. The latter were fairly frequently revisited. These tasks required a close working relationship between the COR/COTR/individual Federal responsible customers and the FFRDC managers/technical leads so the Feds got what they needed and the FFRDC didn't have problems getting paid for the work we'd done when the auditors looked at it. On that front, one key issue we had to deal with regarding the flexibility/autonomy/redirects was ensuring/showing that the FFRDC work under these tasks was autonomous enought that the services shouldn't be provided by a SETA.

SETA work or not but their way of working is not good for my portfolio. we had a couple of meetings and they didn't listen so I issues a stop-work order and canceled the TO.

Above is simpler and easier and more time efficient than trying to fix a vendor that is broken.

What’s broken is the government. They cut core funding for FFRDCs, their overhead rates, refuse to increase dollar values of task orders to keep up with inflation, and increase regulatory reporting requirements over the past 2+ decades…. and then are surprised the quality and efficiency are in decline… or that places try to diversify to non-government funding streams.

[Anonymous]

Anonymous wrote:

Anonymous wrote:

Anonymous wrote:

Anonymous wrote:

Anonymous wrote:

Anonymous wrote:

Anonymous wrote:The point is that the FFRDC is not being responsive to the stated instructions of the customer.

Does the COTR agree that the "stated instructions" in line with the SOW/IDA's tech response?

I've seen IDA staff take the SOW way too literally, often avoiding work that isn't explicitly written down. The contract is like a straitjacket, and they struggle to pivot or adapt as the project evolves. It feels to me like they often care more about rigid compliance than actually meeting our current needs.

I'd consider talking to your COR/COTR about whether the SOW/IDA's response is too restrictive/could be updated... The FFRDC projects I worked on had SOWs/responses with a combination of tasks/subtasks that were rigid and others with generic tasking that allowed for significant FFRDC autonomy and governmental redirects during the POP. The rigid ones tended to be things like progress reports, the latter, the real engineering work. The latter were fairly frequently revisited. These tasks required a close working relationship between the COR/COTR/individual Federal responsible customers and the FFRDC managers/technical leads so the Feds got what they needed and the FFRDC didn't have problems getting paid for the work we'd done when the auditors looked at it. On that front, one key issue we had to deal with regarding the flexibility/autonomy/redirects was ensuring/showing that the FFRDC work under these tasks was autonomous enought that the services shouldn't be provided by a SETA.

SETA work or not but their way of working is not good for my portfolio. we had a couple of meetings and they didn't listen so I issues a stop-work order and canceled the TO.

Above is simpler and easier and more time efficient than trying to fix a vendor that is broken.

What’s broken is the government. They cut core funding for FFRDCs, their overhead rates, refuse to increase dollar values of task orders to keep up with inflation, and increase regulatory reporting requirements over the past 2+ decades…. and then are surprised the quality and efficiency are in decline… or that places try to diversify to non-government funding streams.

Is the real answer is to eliminate FFRDCs (and maybe UARCs) entirely?

[Anonymous]

Anonymous wrote:

Anonymous wrote:

Anonymous wrote:

Anonymous wrote:

Anonymous wrote:

Anonymous wrote:

Anonymous wrote:

Anonymous wrote:The point is that the FFRDC is not being responsive to the stated instructions of the customer.

Does the COTR agree that the "stated instructions" in line with the SOW/IDA's tech response?

I've seen IDA staff take the SOW way too literally, often avoiding work that isn't explicitly written down. The contract is like a straitjacket, and they struggle to pivot or adapt as the project evolves. It feels to me like they often care more about rigid compliance than actually meeting our current needs.

I'd consider talking to your COR/COTR about whether the SOW/IDA's response is too restrictive/could be updated... The FFRDC projects I worked on had SOWs/responses with a combination of tasks/subtasks that were rigid and others with generic tasking that allowed for significant FFRDC autonomy and governmental redirects during the POP. The rigid ones tended to be things like progress reports, the latter, the real engineering work. The latter were fairly frequently revisited. These tasks required a close working relationship between the COR/COTR/individual Federal responsible customers and the FFRDC managers/technical leads so the Feds got what they needed and the FFRDC didn't have problems getting paid for the work we'd done when the auditors looked at it. On that front, one key issue we had to deal with regarding the flexibility/autonomy/redirects was ensuring/showing that the FFRDC work under these tasks was autonomous enought that the services shouldn't be provided by a SETA.

SETA work or not but their way of working is not good for my portfolio. we had a couple of meetings and they didn't listen so I issues a stop-work order and canceled the TO.

Above is simpler and easier and more time efficient than trying to fix a vendor that is broken.

What’s broken is the government. They cut core funding for FFRDCs, their overhead rates, refuse to increase dollar values of task orders to keep up with inflation, and increase regulatory reporting requirements over the past 2+ decades…. and then are surprised the quality and efficiency are in decline… or that places try to diversify to non-government funding streams.

Is the real answer is to eliminate FFRDCs (and maybe UARCs) entirely?

Ah yes, because the best way to fix a broken house is to burn the neighborhood down and hope the tent you pitch instead magically manages itself.

[Anonymous]

Anonymous wrote:

Anonymous wrote:

Anonymous wrote:

Anonymous wrote:

Anonymous wrote:

Anonymous wrote:

Anonymous wrote:

Anonymous wrote:

Anonymous wrote:The point is that the FFRDC is not being responsive to the stated instructions of the customer.

Does the COTR agree that the "stated instructions" in line with the SOW/IDA's tech response?

I've seen IDA staff take the SOW way too literally, often avoiding work that isn't explicitly written down. The contract is like a straitjacket, and they struggle to pivot or adapt as the project evolves. It feels to me like they often care more about rigid compliance than actually meeting our current needs.

I'd consider talking to your COR/COTR about whether the SOW/IDA's response is too restrictive/could be updated... The FFRDC projects I worked on had SOWs/responses with a combination of tasks/subtasks that were rigid and others with generic tasking that allowed for significant FFRDC autonomy and governmental redirects during the POP. The rigid ones tended to be things like progress reports, the latter, the real engineering work. The latter were fairly frequently revisited. These tasks required a close working relationship between the COR/COTR/individual Federal responsible customers and the FFRDC managers/technical leads so the Feds got what they needed and the FFRDC didn't have problems getting paid for the work we'd done when the auditors looked at it. On that front, one key issue we had to deal with regarding the flexibility/autonomy/redirects was ensuring/showing that the FFRDC work under these tasks was autonomous enought that the services shouldn't be provided by a SETA.

SETA work or not but their way of working is not good for my portfolio. we had a couple of meetings and they didn't listen so I issues a stop-work order and canceled the TO.

Above is simpler and easier and more time efficient than trying to fix a vendor that is broken.

What’s broken is the government. They cut core funding for FFRDCs, their overhead rates, refuse to increase dollar values of task orders to keep up with inflation, and increase regulatory reporting requirements over the past 2+ decades…. and then are surprised the quality and efficiency are in decline… or that places try to diversify to non-government funding streams.

Is the real answer is to eliminate FFRDCs (and maybe UARCs) entirely?

Ah yes, because the best way to fix a broken house is to burn the neighborhood down and hope the tent you pitch instead magically manages itself.

Houses inside the beltway that are outdated and not fit for purpose routinely are torn down and then a wonderful new house gets built.