5 ideas for improving the acquisition process

When it comes to improving the IT acquisition process, there is no shortage of opportunities to shine.

There are many variables in the life cycle of an acquisition, from making the business case to launching the final system. Each could be improved to potentially great effect. Or, conversely, each represents a point at which an acquisition could go wrong.

With that in mind, members of the Federal Computer Week staff attended an event earlier this spring called “Smarter Federal IT Initiatives: High Quality, Cost-Effective and On-Time.” The event, sponsored by the Association of Management Consulting Firms, featured a panel of subject-matter experts who offered their ideas for improving each aspect of the acquisition life cycle. Ideas were offered in abundance, more than we could capture in one story. So we picked five of the more intriguing insights — some of which were offered only in passing — and asked the speakers to follow up with a brief article outlining their thoughts.

Let us know what you think.

Business case:
Financial terms ≠ business value

By Steve Cooper

Cooper is director of IT and CIO at the Federal Aviation Administration’s Air Traffic Organization. Please note that the opinions offered are those of the writer and that the writer is not speaking for FAA.

Defining business value addresses the problem of not determining in advance the value to be achieved by investing in an IT-enabled solution and then not having a way to prove the value was achieved. 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.

Data needed to address the first part of the problem — defining business value — might sometimes be found in the business case developed for an investment decision (e.g., an Office of Management and Budget Exhibit 300). But not all projects have fully developed business cases. The second part of the problem — proving we achieved the expected business value — requires a way to measure that defined value. I argue that defined business value can always be measured, although in many cases, it is difficult to find the "best" metric to use.

Part of the problem in measuring business value in the federal government arena is that often the agency is required to define value using only financial measures. Return on investment and net present value are not the only measures of business value. Other possible measures are cycle-time reduction, productivity gains, error reductions or an increase in transaction rates. Ultimately, the question is, "What value will be achieved by implementing this software?"

A tougher challenge is ensuring that business value is defined before a solution is implemented. The business — meaning non-IT professionals with a business need or requirement — can certainly define business value on its own. However, I believe there is greater good in accomplishing this objective through a partnership between the business and IT — meaning the IT professionals who are tasked with providing an IT-enabled solution.

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. It also can help identify more alternatives for consideration to achieve desired outcomes or help all parties involved make more informed decisions about the number of requirements to include in an initial release of a solution, which can dramatically improve the probability of success.

I believe we sometimes fail to define business value at the beginning of a project — or, more often, do not always take the time needed to evaluate and determine the most appropriate metric by which to measure the achievement of the expected business value. This results in no real understanding or agreement on how we will demonstrate that the solution adds value with data, rather than simply relying on a gut feeling or opinion that the solution is “exactly what we needed."

Market research:
Bad requirements = Useless research

By David Swatloski

Swatloski is major defense acquisition program manager at the Defense Department.

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.

The greatest benefit, by far, is that the requiring organization in the government learns and becomes more informed about the current state of market capabilities. The results are better solutions than if the government specified the solution or product.

However, there are a couple of big obstacles. The first is all types of malformed requirements. These include specifications for existing products or functional requirements that drive to an existing solution. Government leadership has to set the conditions to keep this from happening through education and training. Otherwise, market research will suffer, and a limited number of potential solutions will be identified.

The second obstacle is execution of the research. Government executives and managers can be overly concerned about fairness and avoiding disparate treatment of potential bidders. Often, they will limit the research to open sources and written responses. 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.

If conducted in an open manner with requirements stated as a problem statement and desired outcome, the process will facilitate robust communication between solution providers and the government, and both will gain knowledge for any follow-on acquisition. The key is that the communication and knowledge transfer go in both directions.

Openness at the market research phase allows for a better articulation of needs and solutions prior to the acquisition phase. It usually results in a better match of capability to desired outcome, thereby improving the potential solutions. Better potential solutions and knowledge transfer will lower acquisition risk.

Government/industry collaboration:
Partnership - trust = No partnership at all

By A.R. “Trey” Hodgkins III

Hodgkins is senior vice president of national security and procurement policy at TechAmerica.

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.

Both sides need the trust of the other to better understand the intended outcomes, what the challenges and pitfalls for both parties might be, and what success looks like to both partners. Partnerships without trust usually fail.

One of the biggest obstacles to trust — and success — in federal government contracting today is the lack of engagement, both internally among the government parties and externally with industry. Government acquisitions and the subsequent management of those acquisitions require internal communications between all the parties involved — from the planning and requirements phase all the way to the oversight phase — to keep the effort on track. Communications and other engagement with industry are critical to understanding the differing perspectives each side has on the task at hand.

That external engagement includes one-on-one conversations with industry — both before and after the request for proposals — to explain the problem the government is seeking to resolve thoroughly enough for solutions to be identified and for the vendors to adequately inform the government customer about the solution they would offer in order to drive the best acquisition decisions. The process could also include internships and exchange programs in which personnel from the government and industry switch places so they can see firsthand how the other side operates, what decision points they have and what factors influence the choices they make.

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.

Although I’m not saying protests would stop, there would be a significant reduction in the need to resort to them if engagement was maximized in the process and the parties to the competition trusted the others to share important information.

In a more trusting environment, the government customer gets what is needed to meet the mission in a realistic time frame and at a cost that has not become bloated through delays and performance problems; the vendor gets to perform in an environment that did not trigger delays, did not result in negative outcomes and provided profit for the undertaking; and taxpayers have a much better chance of getting the optimal outcome: the best value for their investment in the government mission.

Pilot projects:
Quick + dirty = Problem avoidance

By James Bryan

Bryan is vice president of technology solutions at the Center for Organizational Excellence.

On an all too regular basis, we witness IT projects and programs that have failed. The causes of the failures vary, but they usually include unmet expectations around scope, schedule, costs and overall value. These expectations are not usually verified or challenged early in the project life cycle, which immediately causes the effort to go off the tracks unless expectations are refocused.

In addition, 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.

Several obstacles present themselves when a decision is made to conduct a pilot. First, a poorly defined scope will cause the effort to slow down and possibly meander, with no added value. Second, the key stakeholders must be engaged and supportive of the effort. The value of the pilot is realized when everyone, including the key stakeholders, understand and leverage the lessons identified in the pilot project. Applying the lessons learned during the full-scale implementation potentially reduces the risks and increases the likelihood of success.

Although pilot projects can add tremendous value, it is important to note that there are times when they might not be the best approach. For instance, small implementations for which the requirements and expected outcomes are firmly known might not be good candidates for this approach. In addition, projects with extremely short timelines might not be good candidates, although some will argue that those are precisely the types of projects that need the extra due diligence.

Implementation:
Change Management - training budget = Workforce resistance

By Kathleen Turco

Turco is associate administrator of governmentwide policy at the General Services Administration.

At most federal agencies, change management is driving the adoption of new policies, processes and technology. The key to organizational change is to focus on our employees and the necessary training to ensure that new ways of delivering services and technology are implemented successfully.

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.

Employees must see that senior management is leading and embracing the change efforts. Training is a key component to change and requires that the organization must allocate funding for change management training to ensure employees have the right process and technology training. Generally, funding for change management is the first thing cut from the budget and yet it has the greatest impact for derailing the new technology or process implementation.

Having now lived through many organizational and IT changes, I believe the change is never about the technology and is always about the people — our employees make the change successful.

Change management can result in a more engaged and productive workforce. In the current environment of fewer resources and more results-oriented work, we must focus on change management to improve federal service delivery and operations.