Improving the IT Acquisition Process

Federal Computer Week ran an interesting article recently on the many ideas and suggestions for improving the IT acquisition process. Their report was the result of the “Smarter Federal IT Initiatives: High Quality, Cost-Effective and On-Time” event sponsored by the Association of Management Consulting Firms in March. This event, featuring a panel of subject-matter experts, offered ideas for improving each aspect of the acquisition life cycle. Their ideas were certainly intriguing, from both a perspective of what was said, and what was not said.

Steve Cooper, director of IT and CIO at the Federal Aviation Administration’s Air Traffic Organization, discussed business value and how it is measured, or not measured, in federal technology programs.

…What often occurs with many projects delivering IT-enabled solutions is a lack of agreement at the beginning of the project on what business value will result from the project and how best to measure it. A worst case might be no discussion of business value occurs at all. With every project, we need to respond to the question, “Was this the best use of taxpayer dollars?” and then be able to prove it…

…The toughest challenge is agreeing on how to measure and prove the realization of that expected value. Discussion upfront can prevent the use of a metric that will require inordinate amounts of effort to collect…

How on Earth are projects getting approved with no business cases, or poorly defined business cases without a discussion of return on investment? I agree that a project does not always have financial returns, but those benefits need to be addressed, along with a plan on measuring during the execution phase. This in itself is one of the main concerns; the poor quality of data across government. Office of Federal Procurement Policy Administrator Dan Gordon recently issued a memo concerning this issue, along with guidelines on how to improve data quality, and more importantly, accountability for ensuring its viability. The government is drowning in data, and most of it is of such poor quality that good decision-making is stunted, or impossible.

David Swatloski, a major defense acquisition program manager at the Department of Defense (DoD), seemed to be speaking from recent experience in the poor state of requirements development process at DoD:

…Market research allows the government to determine what potential solutions are available that might meet the government’s needs. This is not an insignificant problem to address properly. If the government need is communicated in terms of a problem statement with a desired outcome, business can respond with more potential solutions. In a great number of cases when this approach is used, more solutions and capabilities are disclosed…

Leveraging industry’s knowledge of technology is critical to the pre-acquisition phase, but it first starts with an acknowledgment from the DoD that they no longer have the institutional knowledge they once had. Only through an outcome-based approach to developing requirements can DoD have the opportunity for the innovation and the variance in solutions and competition it desires.

…The federal acquisition regulations do not preclude hands-on, face-to-face discussion and open communication to understand capabilities during market research. Face-to-face discussions, demonstrations and visits to see capability are the best ways to conduct market research. These methods improve communication and understanding…

The risk-averse nature of government, coupled with the lack of leadership and support for risk taking have created a calcified environment where treating industry fairly means not to deal with industry at all. This is a significant cultural issue that needs to be rectified to have the two-way knowledge transfer take place to improve requirements, and thus the likelihood of successful programs. Failed programs always fail at the beginning of their life-cycle; the pre- and acquisition phases. It has ultimately developed into a seemingly caveat emptor environment.

A.R. “Trey” Hodgkins III, senior vice president of national security and procurement policy at TechAmerica, discussed the importance of trust and how communications can go a long way to improving the entire arena of government contracting

…Building trust is about building relationships, and success can be found in good relationships. When government and industry enter into the kinds of large IT contracts that are the intended beneficiaries of the Office of Management and Budget’s 25-point plan for IT management and acquisition reform, they become partners that are mutually joined in the success or failure of the undertaking…

…The impact of better trust — and the communication and engagement that builds that trust — is a better outcome for the government acquirer, industry and the taxpayer. A perfect example would be a lessening of the use of bid protests. Industry frequently feels that the lack of communications in the lead-up to an RFP, in the competition phase or after an award leaves them little choice but to file a bid protest in order to get information about the government’s decision…

This is one focal point of the Better Government IT project that I co-chair with ACT-IAC. Communication is the cornerstone of any successful relationship, and government contracting is no different. Building a strategic partnership with the contractor is ultimately what should be established to ensure mutual success by the government. However, the government wrongly assumes ethics and integrity issues where they do not exist. How exactly can a program be successful if communication and information is not exchanged properly? Making the contractor submit yet another report is not the answer. Creating an environment where government and industry can discuss issues openly and honestly is part of the solution.

James Bryan, vice president of technology solutions at the Center for Organizational Excellence, discussed the use of pilot projects and the need for prototypes in large-scale technology efforts.

…Most agencies realize that the day of major technology implementations that produce a “big bang” outcome after a prolonged development cycle are coming to a close. But that doesn’t mean the need for agency-transforming technology disappears. In order to meet the need for change and increase the likelihood of successful IT implementations, agencies should consider pilot implementations, combined with agile development methodologies, whenever possible.

With pilot projects, agencies have an opportunity to test or prototype a solution on a small scale in order to validate the requirements and expected outcomes prior to making a large investment. Pilots are designed to be small but focused efforts to test the potential effectiveness of a solution. They also afford the agency an opportunity to gather lessons learned and later apply them to the large-scale implementation. In most pilot projects, the project owners and the project teams come to the realization that some of the requirements established at the outset need to be modified in order to produce an IT solution that will actually meet their needs…

A pilot is a great way to test capabilities on a smaller scale to ensure a properly defined scope, and to have better grasp on outcomes and metrics to achieve success. These capabilities can then be expanded for further expand requirements and continue success through lessons learned and continuous learning. However, it is imperative that pilots be treated as projects, which means they have clear objectives and end-points. Too many pilots or prototypes simply continue in perpetuity, which not only defeats the purpose but creates the “big-bang” and does not allow for any learning. Further, not all projects should be made into pilots. Just like requirements should not be forced into a certain contract type, not all projects are pilot candidates. Value must be carefully weighed against the chances of success, the ability to develop through agile means and lessons learned, and total value and risk.

Kathleen Turco, associate administrator of government-wide policy at the General Services Administration, discusses one of the most difficult issues facing government management; change management.

…We must begin with the end in mind: What do you want to change? The change management effort should focus on the employee requirements and not just the technology if we are to successfully transition our work processes, procedures and behaviors to adapt to new technology…

…The most significant obstacle is that our nature is to avoid change rather than embrace change. Senior managers must be aligned across the organization to ensure that all are in lockstep on change management and employee training. Otherwise, the transition is doomed from the beginning…

As Ms. Turco mentioned, training is a key component to change and requires that the organization fully understand and make resources available. Regretfully, training is one of the first things that get cut during fiscal belt-tightening, which is unfortunate as having empowered, knowledgeable, and trained employees can have major impacts on success through new technology or process implementation.

These issues are of even greater importance now that one of the chief architects of IT acquisition reform, Vivek Kundra, has resigned. Only through continuing the momentum that Kudra helped spearhead, along with a continued focus on government/industry collaboration, can improvements be achieved. The adversarial nature of the relationship needs to be rethought, as only through working together can taxpayers get better results.

Original post