Jump to content

Digital Services Training and Development - Challenge.gov


Recommended Posts

Someone had brought this to my attention:

https://www.challenge.gov/challenge/digital-service-contracting-professional-training-and-development-program-challenge-2/#_edn1

I find this a bit amusing. Here is an article that describes it: http://www.nextgov.com/cio-briefing/2015/05/teaching-contracting-officers-about-agile-could-net-you-360000/113419/

My thoughts are:

#1. The money is far, far too low and wouldn't be worth anyone's time. To do so successfully you would need an acquisition SME (who has actually bought stuff), a technical SME (who has actually designed software), and an educational training SME (who has actually designed training and coursework to accomplish an end result rather than just slapped information into a power point or collecting and regurgitating white papers, Gartner "reports", and federal guidance (often based on the Gartner reports...so hell, why bother with the middle man?).

#2. The nextgov article is a bit misleading. The content developed would be provided to DAU and FAI....you wouldn't actually be teaching the course, just developing the content. You would not make money on the backend as would be the case with DARPA projects and their commercialization goals.

#3. It assumes that training is one of the issues for the federal government's inability to conduct agile development.

#4. It assumes that agile is applicable to contracting rather than simply as a software development function.

Agile contracting appears to me to be the latest buzz word without thinking this through. What is it? It is simply a step by step approach to the development of something that accounts for changes in design based on certain stages of the design process. I don't know why this is being applied to a particular contracting method because there may be a very easy way to address this: Lead System Integrator with FAR 51 authority. My guess is that the end result will be a cumbersome training that complexifies the process in a way to make it unworkable.

The government has a very difficult time with requirements definition when there is ambiguity or a high probibility for a change in direction. Rather than embedding this in a contracual sense why not just allow for the contractual rules to allow for it, let experts design a system in stages, and monitor them to ensure that things are occuring above board and when things were promised? A milestone is met, the next step now is this, this is why, therefore we will do this. "Agile Contracting" seems to me to be an overly though, needlessly complexified solution for an approach that can be done much more simply and cleanly without the need for establishing training. As always...I could be wrong.

Link to comment
Share on other sites

The primary focus is on training. The focus on training speaks volumes about the assumptions that are driving this. Throwing the training blanket over raging fires underneath sometimes just sets the blanket on fire.

Everyone who actually buys things is well aware of the need for a sophisticated understanding of how the government works and why things go wrong in acquisitions, which is usually systemic, rather than a lack of training. When you have the same outcome over and over again, (IT acquisition outcomes that are in some way inferior), isn't it time to look at the systemic issues, and solve for those? Solutions to those would involve changing some laws, rules and policies, and management approaches, rather than calling for more training, which sounds like a euphemism to me.

If the course were taught by someone or some group of people who have actually done these things successfully in the government, perhaps drawing on their experience with past large-scale, complex projects, then that could have some value. As a starting point. Understanding what's in the Tech FAR is not at all remarkable. Implementing is what is remarkable.

Link to comment
Share on other sites

Hello, ji,

Can you enlighten me? I always have trouble describing the work prior to soliciting, other than some sort of 'we'll agree to agree later'-type statements. Am I over-emphasizing the learn-as-you-go characteristic the Agile nerds describe?

Link to comment
Share on other sites

Guest Vern Edwards

apsofacto"

Read this: "Agile Contracts Primer" Version 5, by Arbogast, et al. (2012). You can find it here: http://www.agilecontracts.org. With respect to contract pricing, see pages 25 - 29. See also the discussion of "fixed-price fixed-scope" contracts that begins on page 29. The authors do not like traditional FFP contracts for agile software development, but other varieties of fixed-pricing are acceptable to them.

Link to comment
Share on other sites

Do you remember the project management triangle? Cost, quality, and time -- we can fix any two of these, and have to accept the consequence on the third. For example, if we insist on a certain outcome or quality within a certain amount of time, we might have to consider a cost-reimbursement approach. However, if we want to fix the cost to the Government and the time, and we don't insist on a certain outcome or quality, a fixed-price approach might work. The TechFAR gives some thoughts on contracting for Agile software development on a fixed-price basis. For some software development efforts, we might want to fix the cost to the Government and the time and work closely with the contractor to try to maximize the outcome or quality but knowing that we will have to be satisfied with whatever outcome or quality we get -- in such a case, a fixed-price approach might be workable -- and in such a case, neither the Government nor the contractor knows upfront exactly what will be achieved in terms of outcome or quality, but they agree on a general statement of purpose and the process they will use.

Below are some extracts from the TechFAR thatr might be helpful to people trying to understand Agile (all emphasis is mine):

"Agile is not a method of procurement, but a methodology on how the contractor performs the work." TechFAR, p. 6.

"With Agile software development, requirements and priorities are captured in a high level Product Vision, which establishes a high level definition of the scope of the project, specifies expected outcomes, and produces high level budgetary estimates." Ibid., p. 10.

"When issuing a solicitation, it should explain the Agile software development process." Ibid., p. 11.

Sample Solicitation Description of an Agile Process

"The contractor will work in a team-based Agile environment. The Agency will create and maintain system roadmaps, project plans, and product and release backlogs that will be the basis for the contractor’s work. The Product Owner will specify high-level requirements to the Agile team. As in typical Scrum-based Agile processes, the Agency Product Owner will work together with the team to develop and estimate user stories and establish acceptance criteria. These acceptance criteria will specify expected functionality for a user story, as well as any non-functional requirements that must be met in the development of the story. The Agency Product Owner, supported by SMEs and business analysts, will determine whether or not acceptance criteria have been satisfied."

Ibid., p. 12.

"Under Agile software development, the Government retains the responsibility for making decisions and managing the process; it plays a critical role in the IPT as the Product Owner by approving the specific plans for each iteration, establishing the priorities, approving the overall plan revisions reflecting the experience from completed iterations, and approving deliverables. As part of its responsibility, the Government is involved, at a minimum, at critical decision points in each sprint cycle – at the requirements development phase and sprint cycle review, but it is preferable to have daily involvement from the Government Product Owner, and frequent involvement from end-user representatives." Ibid., p. 13.

"Contractors are not involved in establishing the Product Vision or determining what overall contractual requirements are included in solicitations. They do not decide what supplies or services are acquired by the Government, which is inherently Governmental per FAR 7.503©(12)(i). Their focus is on helping the Government refine the software requirements (or detailed requirements) for the system through a highly defined and disciplined process that is driven by user needs established by the Government." Ibid., p. 13.

"A contractor being used in Agile software development to help refine technical requirements – a typical feature of Agile software development – would not be free to propose solutions to meet its own business interests over the Government’s interest. The contractor’s expertise is being used only to help refine technical requirements in accordance with a highly defined and disciplined process that is driven by user needs established by the Government. The needs are initially set forth in a Product Vision by the Government, which is supplemented through user stories and Government customer testing until an MVP is achieved. In other words, the contractor is not involved in establishing the Product Vision that frames the procurement, determining what overall contractual requirements are included in the solicitation, or determining if work products meet the contract terms. The Government retains the responsibility for making these decisions, including approving the specific plans and acceptance criteria for each iteration, as well as the overall plan revisions reflecting the feedback from completed iterations and priority changes." Ibid., p. 14.

"To ensure results, the Government must ensure that the 'definition of done' is clear, comprehensive, and objective. This definition is established post-award at the beginning of each sprint." Ibid., p. 18.

Link to comment
Share on other sites

The following extract comes from Vern's reference:

Avoid…Fixed-price, fixed-scope (FPFS) contracts

Fixed-price, fixed-scope—and worse, with fixed duration—contracts and projects tend toward

lose-lose situations for both the customer and supplier; customers often do not get what they

really need, and suppliers can easily lose money. And in an effort to deliver something within

the constraints of price and scope, suppliers will often degrade the quality of their work—

reduced code quality, less testing, and so forth. All this leads to an increase in future costs for

customers, who will eventually have to pay for the sins of the past, as follow-on change

requests to get what they truly need and as increased maintenance costs for software of low

quality and high “technical debt.”

Note that the counsel is to avoid fixed-price, fixed-scope contracts -- but you can use fixed-price if the scope is flexible.

Link to comment
Share on other sites

Guest Vern Edwards

ji:

While agile is not a procurement method, it is an approach to software development that could affect pricing.

There are many varieties of "fixed-price." The question is: What kinds of fixed-pricing are suitable for use with agile? "Fixed-price, fixed-scope" strikes me as "firm-fixed-price," but maybe not.

By the way, the document to which I referred apsofacto, while informative, just reflects the opinions of a particular set of authors. I don't mean for it to be taken as gospel. I wouldn't take the TechFAR as gospel, either.

Link to comment
Share on other sites

Guest Vern Edwards

Agile development is an old idea now. There is more gospel than some realize. The term was coined in 2001, so it's been around for 15 years, and its roots go back to the 1950s. It is typical that the government became excited about it only after it became more or less mature. Unfortunately, I'm in the advanced maturity phase of my career and tend toward cynicism about the government's latest fad. I've seen it all before. If past is still prologue, something new will come along soon enough. In the meantime, we'll be lucky if the government does a good job with agile. Time will tell, I suppose.

Link to comment
Share on other sites

Thank you both for those references. One fixed-price technique in particular jumped out at me: the practice of fixed-pricing an "iteration" or "sprint".

I'm aware of one disadvantage of T&M- that it incentivizes ineficiency because you are fixing the price for the contractor's time, or one man-hour. When you fix the price of an iteration, three team-weeks, don't these disadvantages still exist?

Ji,

is this why you state above that (emphasis added):

For some software development efforts, we might want to fix the cost to the Government and the time and work closely with the contractor to try to maximize the outcome or quality but knowing that we will have to be satisfied with whatever outcome or quality we get . . .

The 'fixed price, fixed scheule, variable scope' concept seems to have more in common with T&M than what I normally think of as firm-fixed price. You are just fixing team-weeks rather than man-hours.

Since you are not specifying outputs, you are requiring inputs and specifying a process- aiming in a general way for certain outputs but not tying yourself to the mast.

Thanks again- I'll continue to poke through these materials . . .

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...