How Jama Software Supports Government Program Offices Part IV: Financial Management

Welcome to Part IV of our government program offices series. If you haven’t already, go back and read the introduction to the government program offices series to learn more about how Jama Software supports government program offices and more about me and my qualifications. You can also read Part I, where I discuss the development of the RFI/RFP and we got approval to release the RFP, Part II on source selections, and Part III where I cover contractor requirements decomposition.

I see that you survived my earlier posts. Thanks for sticking with me. Now, government financial management is a dry topic, so I’ll try to keep this short and to the point. Depending on the type of contract issued by the program office to the contractor, different types of financial management requirements come into play.

The most complex and difficult contracts often rely on a contractor submitting earned value management (EVMS) reports to the government as the way of providing transparency into the costs of the projects. The basis of EVMS is the Work Package and, unfortunately, contractors can manipulate the definition of and type of work packages to hide or obscure financial issues during contract performance. I once had a large DoD contractor tell me that I was not allowed to see what work packages they were using on my contract, so there was no way for me to understand, much less validate that their financial performance was satisfactory. I should not have to accept a “trust me” card from any government contractor when it comes to ensuring that our taxpayers money is spent appropriately.

Here is where applications like Jama Connect can make a difference and drive that transparency. A work package is a set of work to satisfy specific requirements. I am not going to bore you with defining EVMS, but I will tell you that EVMS includes multiple cost metrics which are used to calculate the Schedule Performance Index and Cost Performance Index, which measure the contractors’ current state of meeting the requirements on time and on budget.

Jama Connect could be used to track the contractor’s work packages and where the contractor will update the financial metrics. This would provide the program office insight into how the work packages were developed and their validity.

If a program office was really ambitious, it could require the contractor to relate each work package to the government approved requirements, such that it would be now possible to identify what requirements are on the cost and schedule critical paths, introducing overruns and delays, and hopefully allow the contractor and government to put in mitigation activities. This would allow for an honest tradeoff between requirements, cost, and schedule based on actual data instead of intuition.

Jama Connect allows the contractor to document work packages and to relate the work packages to requirements, deliverables, and any other items in Jama Connect to provide context and decision quality information.

The benefit of implementing such relationships may not be worth it. It really depends on what is the best way to decompose the requirements and create a logical set of work packages. A forced alignment of those two things may just not make sense, but then again, if they do, then it opens up a lot of value to both the contractor and program office leadership. Tools can’t replace the insight of an experienced program manager, but most program offices have only a few program managers with extensive experience.

The benefit of incorporating financial management with the requirements within Jama Connect is because they are always related. Having a single place with the information needed to make a decision is critical in supporting the right decision to be made. As decisions are required, Jama Connect supports doing those trade-offs and scoping any required contract modifications. It also provides a platform to document and record these decisions.

Author
Recent Posts

John Allison

John Allison entered the US Air Force in 1991, and spent the next 24 years working primarily as an engineer and program manager across multiple Air Force acquisition programs. He was responsible for taking user generated operational requirements and delivering a product that met the requirements, while attempting to be on schedule and on budget. This involved a significant amount of requirements analysis, requirements tradeoff analysis, RFI/RFP and contract development, and contractor technical oversight. After retiring in 2015, John joined Cisco where he led their first DoD cloud collaboration effort. Today, John is at Armis Security, a leading cybersecurity startup where he leads their federal product management. John lives in Raleigh, North Carolina with his wife, son, three cats and one dog. When not working on public sector cybersecurity, John tries to convince non-traditional companies to enter into the US public sector market.