Jump to content
The Wifcon Forums and Blogs

Recommended Posts

OMB released something that they call TechFAR (http://playbook.cio.gov/techfar/), which is guidance meant "to facilitate a common understanding among [agency] stakeholders of the best ways to use acquisition authorities in making [iT] investments to level set expectations and maximize the likelihood for success." It is particular to Agile Software development, a concept that is bleeding into other parts of the federal enviornment including procurement, program development, and organizational behavior. That aside...and please tell me if I am wrong...I see this to be of limited value.

General Considerations

Most appear to be Agile specific and not related to FAR, but their main contention is that FAR does not address Agile development, therefore FAR 39 should apply as people apply modular contracting to agile software development.

Requirements Development and Acquisition Planning

The takeaway here is that it should be SOO based, not SOW based, and it is assumed that the government is compliant enough to monitor progress and identify when something is done. Further, they claim that there is no conflict of interest even when contractors are heavily relied upon and have a foothold in an operation, so long as they are not evaluating their own proposals. This part I find a bit tenuous both legally and ethically. Just appears a bit convenient and overly simple.

Contract Vehicles and Use of Existing IT Contracts

This section says nothing of importance.

Pricing Considerations

Fixed-price, T&M, and incentives are all acceptable approaches depending on the nature of the work involved. They offer some scenarios for firm fixing some CLINS under the FP scenario, and offer some vanilla advice on creating an IGCE.

Use of Competition

Competition is ample and not restricted at any point in the agile environment, the Product Vision serves as the scope (broad scoped to give flexibility...though they shift from SOO to SOW in Q#2 in this section), the risk of protest "should not be increased" because of the lack of prescription or fixed technical requirements, and small businesses can still compete.

Contract Administration

This section is just repeat and regurgitation on agile software development and project monitoring. It includes roles for the CO, COR and "Project Owner." I will take another look at what they charge the CO with in their responsibility sets later.


I am curious to hear what others think of this guidance. TechFAR as a label certainly gives connotations of something other than what I just read. I deal more with commercial IT than software or systems development, but there is nothing in this that I was enlightened by. I actually fear that this will be regurgitated without thought, and though it quotes FAR I would have to look more into the number of leaps it makes through the different parts of the regulations to make a judgement on the soundness and applicability.

By the way...they are also taking comments for anyone interested in submitting them, though I don't know many COs who use GitHub (a coding exchange and content development platform) as a communication medium. (https://github.com/whitehouse/playbook#readme)

Share this post

Link to post
Share on other sites

Coincidentally Steve Kelman has been writing abeout this recently as well. He directly addresses TechFAR in his most recent post here: http://fcw.com/blogs/lectern/2014/08/the-challenge-of-agile-development.aspx

Ever the diplomat, he is more bullish on the guidance than I. I never discount the fact that I could be wrong. He also indicates where he sees areas for improvement concerning this guidance.

Share this post

Link to post
Share on other sites
Guest Vern Edwards


The TechFAR is typical of the kind of document that agencies put out in order to show that they are doing something about a problem that they can't really do anything about. The idea that anybody will learn much that they can actually put to productive use from a 41-page document like TechFAR is simply absurd.

The quality of the content is just awful.

The definition of "Agile software development" at the top of page 2 is laughable. It could apply to any design or development process: "iterative," based on "real user needs," "constantly improves... from user feedback." The process diagram at the top of page 4 is hilariously unintelligible.

Agile development is a set of ideas -- not a well-defined process -- that currently enjoys B-school gimmick popularity. Whatever merits those ideas might have, an Agile process can be learned and put to effective use only under the tutelage of an experienced cadre. Where's the government's experienced cadre?

Of course, we get the claim, on page 7, that Agile has been used since the 1970s by "private industry" and has been used in all kinds of unnamed and undocumented programs to produce "shortened time to value," "better adaptation to changing need," and "lowered the risk of project failure." I would love to put the authors on the spot and ask them to name the programs in which Agile produced those results and to show me the documentation.

And then we get absurdities like this on page 16:

Question - Because Agile software development is heavily process-driven, must agencies only use fixed-price contracts to get the desired result?

Huh? Where did that even come from? Did somebody actually ask that question? What does "process-driven" mean and why should it prompt such a question?

And then, a true laugher on page 21:

Question - How does the Government ensure fair and reasonable prices when acquiring a process such as Agile software development?

Answer - The Government may determine whether prices are fair and reasonable in a contract utilizing Agile software development methodology by requesting and evaluating pricing of the effort as a unit of measure that is equivalent to the proposed sprint/release cycle and demonstrating the correlation between the proposed technical solution in the PWS and the pricing.

Wha-huh? "a unit of measure that is equivalent to the proposed sprint/release cycle and demonstrating the correlation between the proposed technical solution in the PWS and the pricing"? Why isn't it based on estimated costs?

And this, on page 23:

Question - FAR 11.002 states that agencies should specify needs in a manner that promotes competition. Given that requirements may not be fully defined when the agency solicits offers and that not every offeror knows how to perform Agile software development, what is the best way to ensure effective use of competition?

Answer - The Government ensures effective competition by applying a similar process used for performance-based contracting by identifying the desired outcome rather than the details of the design for [sic] how to perform the work...

If requirements are not fully defined, how can you identify the desired outcomes?

There's more, but I've contributed enough.

Honestly, Jon, somebody, somewhere, ought to be really embarrassed.

The problem with government IT software development programs is that (1) they are inherently difficult, even for super-competent people, and (2) the government's IT acquisition workforce (other than maybe CIA and NSA, etc.) is nowhere near super-competent, or even average competent for that matter.

Share this post

Link to post
Share on other sites
This topic is now closed to further replies.