The Contracting Education Academy

Contracting Academy Logo
You are here: Home / Archives for requirements

By

DIA opens new gateway to vendors, hoping for disruptive technologies

The Defense Intelligence Agency will formally roll out its new Open Innovation Gateway, a major pillar in the agency’s push to move away from big, monolithic technology acquisitions and bring new innovations on board in small bites and in very short cycles.

Officials have not discussed many of the inner workings of the gateway prior to Wednesday’s official announcement, during which DIA will declare it has reached initial operating capability.

The agency has made clear for the past year that the intent is to give technology developers much more insight into the technical requirements that a new capability must meet before the agency will buy it.

That insight, DIA says, extends beyond publishing black and white technical standards. Via the gateway, the agency will give developers access to the actual computing environment DIA uses today — and eventually, the shared set of systems under the entire intelligence community technology infrastructure — so that they will know from the outset whether their technologies will integrate with DIA’s existing systems, and if not, what changes they will need to make.

Keep reading this article at: http://www.federalnewsradio.com/239/3650653/DIA-opens-new-gateway-to-vendors-hoping-for-disruptive-technologies

By

Shrinking budgets, acquisition workforce mistakes drive bid protests, experts say

Data from the Government Accountability Office clearly show an upward trend in the number of bid protests, and procurement analysts told BNA there several explanations for the increase.

Chief among these, they said, are smaller federal budgets that allow for fewer overall contracts, along with a shrinking, less skilled acquisition workforce prone to mistakes.

Total federal spending on contracts fell to $516.8 billion in FY 2012 from $538.6 billion in FY 2011, according to USASpending.gov. Spending rose only 19.6 percent from $432.1 billion in FY 2006.

At the same time, contractors filed 2,475 protests, cost claims, and requests for reconsideration with GAO in fiscal year 2012, a five percent increase from FY 2011 and a 94 percent increase from the 1,274 protests filed in FY 2006.

Keep reading this article at: http://www.bna.com/shrinking-budgets-acquisition-n17179873902/

By

Army acquisition must streamline requirements process

Army acquisition officials want to speed up the process to issue requests for proposals to defense companies and thus issue contract awards quicker.

Army Lt. Gen. William Phillips, military deputy to the Army’s acquisition executive, said on Feb. 20, 2013 at the Association of the U.S. Army’s Winter Symposium that the Army too often drags its feet trying to perfect the draft RFP rather than issue it to companies and receive feedback faster.

“I think in the past, looking over the last three years that I’ve been in this job, we’ve been somewhat hesitant to get the draft RFP out,” Phillips said. “We want to get it better and get it better.”

Instead, the Army needs to “take some risk in that area,” Phillips said. He explained that the Army will have to finish their requirement lists for weapons programs faster to drive down costs.

Keep reading this article at: http://www.dodbuzz.com/2013/02/21/phillips-army-must-streamline-requirements-process/ 

By

How to improve procurement: Stop talking about requirements

Requirements are the Achilles’ heel of procurement.

Ask users, managers and regulators for a program’s requirements and you will get a vague description of products and services that are currently available. They inevitably “require” what they already know could work today. And that’s a problem because by the time the request for proposals is released, the proposed solution might be overtaken by better and more affordable options.

What a program requires is a competitive procurement that complies with regulations and delivers the desired results. The challenge is determining what a program really needs. How can we define those needs in such a way that bidders can propose solutions that take advantage of what’s available today but also retain the ability to meet changing and future needs?

One answer is to ask the “What are your requirements?” question in a few different ways. Tom Love, CEO of Shoulders Corp., offers hope in this regard. He suggests we bench the term “requirements” and use other terms that will unearth real needs. In other words, pose the question to elicit more thoughtful and thorough responses.

Love has put together a list of 18 terms or concepts that can help deepen a discussion and bring real needs to the surface. For example, one idea is develop “story cards” that show how the solution might be used. Love also encourages people to incorporate refreshment plans for updating technology and decommissioning plans for bringing systems to a close. The full list of terms appears below.

This approach can help us break our reliance on known and preferred solutions and focus instead on the actual needs of users — to transform from solution understanders to user-oriented requirements understanders, as Jim Beveridge put it in his sales and marketing seminars in the 1970s.

It might also help us finally resolve what renowned software engineer Barry Boehm calls the IKIWISI problem — “I’ll Know It When I See It,” a common problem that makes it difficult to define needs.

As the needs are identified, we might prioritize them by creating three categories: needs, wants and desires.

For example, we need a payroll system. We want to include the ability to issue W-2 statements within the required period. We desire to deliver it all on the first official release day to impress our employees with our support services. Discussing perceived needs might unearth some interesting possible solutions and bring to light the readiness to accept new or revised solutions.

A lot of this comes down to semantics, but in this case, semantics matter. The ultimate solution might very well come out better if we pose the question in a different way.

What do you think?

Tom Love’s suggested terms for identifying program needs:

  • User input
  • Project charter
  • Unique security profile
  • Functional specs
  • Business cases
  • Use cases
  • Performance metrics
  • Operational scenarios
  • Transitional scenarios
  • Nonfunctional needs
  • Interface needs
  • Screen designs
  • Application mock-ups
  • Story cards
  • Validation tests
  • Acceptance tests
  • Refreshment plan
  • Decommission plan

 

— by Ray Kane, a consultant who has worked in the federal market for more than 40 years, on Oct. 15, 2010

Contracting Academy Logo
75 Fifth Street, NW, Suite 300
Atlanta, GA 30308
info@ContractingAcademy.gatech.edu
Phone: 404-894-6109
Fax: 404-410-6885

RSS Twitter