5 ideas for improving the acquisition process

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, however, each represents a point at which an acquisition could go wrong.

Defining business value addresses the problem of not determining in advance the value to be achieved by investing in an IT-enabled solution and at that time 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 outset 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 and there be able to prove it.

Data needed to address the first part of the problem - defining business value - might at times be found in the business case developed for an investment decision. Nevertheless 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, though 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 previously a solution is implemented. The business - meaning non-IT professionals with a business need or requirement - can undoubtedly define business value spontaneously. But, 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 beginning of a project - or

I believe we at times fail to define business value in 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, to put it more exactly than simply relying on a gut feeling or opinion that the solution is "specifically what we needed."

This year, as agencies continue transitioning basic functions like email, cloud computing has stolen the focus from the greater goal of which it is only a part: the shared IT infrastructure. Spanning initiatives from data center consolidation to virtualization, the effort to build an elastic IT framework is then underway. This straightway-gen architecture represents a basic reevaluation of the enterprise, installing IT not as a commodity, however a service. Agencies are now looking at how they can turn hard-wired desktops into virtual workspaces, transform mobile computing into a secure reality, and deploy rapid computing power to stand up IT projects in record time at a fraction of the cost. Nevertheless, what are the implications from a research, management, and end user perspective? Join Federal Computer Week in this Editorial Webcast for an innovative look at new options for the enterprise as agencies transition to a shared IT infrastructure Read more