How and Where to Get Started to Respond to the MEGABYTE Act

Everybody likes to exercise their frugal muscles and negotiation skills when shopping for the best deal they can get on an expensive item. Sometimes they belong to a buying consortium that has already done the legwork to negotiate the lowest price, and that pre-negotiated low price makes it seem as if the hard part is over.

In reality, that is just the beginning of the process when purchasing software. The hard part occurs after the purchase, when you need to confirm you’re getting the expected value and return on investment from that software. Determining that requires life cycle planning, even before the purchase is made. Life cycle planning includes having a strategy that looks holistically at the software from purchase to install to retirement, many years later.

To ensure agency CIOs are keeping an eye on their IT software spending, the MEGABYTE Act, which is short for Making Electronic Government Accountable By Yielding Tangible Efficiencies Act, was passed in July 2016. This Act is a follow on to the Federal Information Technology Acquisition Reform Act (FITARA) and the National Defense Authorization Act for Fiscal Year 2015 (NDAAFY2015). These previous laws were intended to be a comprehensive guide to prevent IT waste and mismanagement, but more detail was needed to support software purchases, which represented $9 billion in 2015, according to OMB.

The MEGABYTE Act follows on the 2015 legislation by mandating that agency CIOs adhere to the outlined six areas of focus that are designed to provide more visibility into purchased software and drive efficiencies. Here’s a quick summary of the six provisions:

• Establish a comprehensive inventory.
• Implement a life cycle approach to software license management.
• Analyze software usage and other data to make cost effective decisions.
• Provide training relevant to software license management.
• Establish goals and objectives for software license management program.
• Consider the software license management life cycle phases (including requisition, reception, deployment and maintenance, retirement, and disposal phases) to implement effective decision-making and incorporate existing standards, processes and metrics.

To prepare for this legislation, agency CIOs should begin by conducting an assessment of their current discovery and inventory tools. Many times agencies will have multiple tools in place and they’ll try to leverage existing tools designed for security or network monitoring. These tools are great at discovering IP-connected devices; however, inventorying and being to identify the installed software may not be a strength. By ensuring that the tool is fit for its purpose will be foundational to successful reporting. Without robust software usage monitoring and comprehensive software knowledge base, it will be difficult to achieve the timelines outlined in the legislation.

The next step is to confirm that the discovery tool is fully deployed. Many times there are so many tools that there isn’t a standard discovery tool or one that is rolled out to every endpoint. If the discovery tools can’t go cross-platform, such as inventory mainframe z/OS, look for an alternative tool. If there isn’t enough budget or mainframes to justify purchasing a platform-specific tool, consider allocating headcount or leveraging existing headcount to conduct inventory.

After the foundational discovery tool is in place, determine what needs to be measured and tracked. When it comes to software there are basic and more advanced metrics that reflect what is happening in the environment. For agencies just starting out, we recommend using the basic metrics around install and usage.

Most private sector organizations monitor software application usage on a quarterly basis to detect which applications a user has opened and closed. For expensive applications, they may decide to go to a more granular level and detect keyboard activity. Other metrics might include software that has been purchased but never deployed because funding or resources for the project were discontinued, or software that has been purchased and deployed but is no longer needed. Starting with these metrics will begin to identify opportunities where costs can be avoided or savings from discontinuing maintenance for unused applications can be gained.

In theory, implementing a software life cycle approach isn’t difficult. However, where there are a lot of legacy applications, a complex decision process requiring risk management analysis will be needed. A team of IT professionals with experience with not only tools, but also with procurement, sourcing, contracts, project and portfolio management, vendor management, performance scorecards, and enterprise architecture are needed to provide feedback into life cycle planning. CIOs should evaluate staff to determine if existing employees have the skillsets needed to meet these objectives and consider additional training where necessary.

The potential savings from an effective ITAM/SAM program in a government agency that already has some best practices in place could still be up to 20 percent of the management costs associated with the various assets in the first year of implementation. I’ve often seen ITAM/SAM programs generate enough savings to be self-funded, which frees up funds that can be allocated back to technology investment. With the proper processes, policies, and people in place, CIOs should have no problem reporting their cost savings and risk avoidance from improved software license management practices on a regular basis.