government program offices Archives

Tag Archive for: government program offices

Welcome to Part VII of our government program offices series on contract recompetition. 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, Part III where I cover contractor requirements decomposition, and Part IV, where we discuss financial management, and Part V on test planning, and finally, Part VI on contractor deliverable management.

Welcome to the final post in this series. Give yourself a huge pat on the back for staying with me. Now, if you are a government contractor, you may not like what I’m going to have to say here. But bear with me, you are also a taxpayer (right?) and as such you should want the government to wisely spend your money.

It shouldn’t come to a shock to anyone, but not all government contracts are successful. Even for successful contracts, every contract has an existing period-of-performance which can be extended only so much. Eventually, unless there is justification for a sole source contract, the program office will need to either end the program or recompete the contract.

Now, let’s suppose that the program office didn’t want to do requirements in Jama Connect and instead just allowed the contractor to use their own systems to develop the requirements. Okay, that is the easy button for the program office and is really tempting to go this route at the beginning of a contract because you know, this time will be different and the contract will be a huge success. Unfortunately for our poor program office, life isn’t perfect and they find themselves needing to recompete the contract.

So what is the program office to do? All of the detailed requirements are inside a contractor-owned system. How does a program office get that information, which is needed for the new source selection from the existing contract. If they were smart, delivery of the requirements would have been included in the original contract. If not, they will have to either modify the contract to make that a deliverable or attempt to download or scrape the requirements from the contractor’s systems, assuming they have access to it.

Even if the program office can get the requirements from the contractor, the contractor is motivated to make this process as difficult as possible, especially if they can squeeze a contract extension out of the program office. This means unless you are really good, the contractor may deliver the requirements in the least useful format they can find, without any context or relationship information, and at the absolute last possible moment. Not all contractors are spiteful this way, but I wouldn’t be writing this if I haven’t seen this.

In a non-Jama Connect world, this is this inherent conflict between the program office and the contractor leading up to a contract recompetition. Now, let’s look at how this works in Jama Connect. The program office has full access to the requirements, deliverables, along with the comments, decisions, and discussion around all of these. They can easily export anything they need for the source selection, or export the information into a new Jama Connect project that can be directly shared with perspective bidders. Jama Connect can easily become the new bidder’s library, if you are familiar with that concept.

Now comes the most important part of this discussion. If a different contractor wins the re-competition, traditionally this is an extensive timeline associated with them coming up to speed and being able to perform the work. While Jama Connect may not fix everything, the program office can easily just remove the previous contractor personnel from having access, and granting the new contractor access to the Jama Connect project. This grants the new contractor access to all of the same material that the old contractor had, and provides critical context that will accelerate their learning curve so they can become productive on the new contract sooner.

Generally, all work products produced under a government contract have at a minimum a Government Use data rights. This legally allows the government to share contractor A’s work products with contractor B, as long as contractor B has a legitimate “need to know.” In practice and in my experience, this sharing is fairly limited and is focused on the minimum amount of material that contractor B needs to perform their work. Jama Connect automates this process and expands the scope of the material shared to a wide range of work products. If you ask contractors about the program office sharing their work products with other contractors, they generally accept that it is legal but they do not like that it happens. If you ask more questions, you will find out that one of the major concerns is that they do not want other contractors to see the quality of their work products. They are competitors not only for contracts but also for talent, and the reputation of a contractor is an important recruiting tool.

So, what happens when nearly all work products (except those that are legitimately proprietary) are shared between the original contractor and their replacement. First of all, the quality of the first contractor’s work becomes known outside of just the program office, and if the quality is bad it harms that company’s reputation. As a taxpayer, I don’t see this as bad. There are few motivators to do high quality work as knowing that your work will be shared with your competitors. In the proposal so long ago the contractor claimed that they were better than everyone else, and shining the light onto their works gives them motivation to live up to that claim. And given that that follow-on contractor knows that this will happen to them as well, they are also motivated to put forth high quality work products. The only ones that should be concerned are the companies that are not producing high quality work. Now, I will admit that I’m greatly oversimplifying the corporate politics around this, but I stand by my belief that the taxpayer deserves high quality work to be performed on their behalf.

If you are curious about how Jama Connect can handle the material that is legitimately proprietary, there are several ways. It is possible to tag or categorize everything in Jama Connect with the appropriate data rights statement, or the Jama Connect project can be segmented to have a separate access restricted area for proprietary information. In either case, it is possible to manage that concern if taken into account when Jama Connect was set up by the program office to ensure that only the data that the government has legal authority to share is shared.

Welcome to Part VI of our government program offices series where we’ll discuss how Jama Connect can help with contractor deliverable management. 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, Part III where I cover contractor requirements decomposition, and Part IV, where we discuss financial management, and Part 5 on test planning.

Welcome to the seventh blog post of this series. Congratulate yourselves on your stamina and perseverance. At this point the contractor and program office are chugging along. We have the requirements decomposed into something useful, the work packages defined, and test plans being developed. Outstanding.

I’m the first to admit that Jama Connect can do more than just shore requirements. It is basically a very fancy cloud database. The kind folks at Jama Software know this, but they don’t like admitting it. So, how else can Jama Connect help the program office? To make the folks at Jama Software happy, I’ll say that the deliverables from the contractor to the program office are “requirements.” Jama Connect is an excellent tool to enable online delivery of contract deliverables from the contractor to the program office.

Why would you want to use Jama Connect this way? Great question, and it has an easy answer. At this point Jama Connect has become the underlying program management platform for the program office. We have all of the contract requirements, the actual requirements, the test plans, and so on in this platform. Well, the deliverables can not only be tracked in Jama Connect , but they can provide useful information for those either writing, reviewing, or approving requirements within Jama. Allowing for all of this data to be stored in one location and accessible to all of the stakeholders makes everyone’s lives easier. A contract deliverable that is never read by the program office should have never been required and is a waste of taxpayer dollars.

Contractor Deliverable Management with Jama Connect

Contractor Deliverable Management with Jama Connect: It is easy to use both workflow and status indicators to ensure that deliverables are received on time and those that require program office approval are reviewed in a timely manner.

What is also really cool about using Jama Connect to track deliverables is that it is possible to ensure that the appropriate workflow is used. Deliverables may or may not be conditional on the program office’s acceptance. Sometimes the contract will state that the deliverables are automatically approved after a set number of days unless the program office responds. The problem I’ve seen is that it may be days before I know that the deliverable is there for me to review, and by the time I read it and realize that it w[as a mess, it is too late. Jama Connect reduces this issue though workflows, and notifications. Deliverables are not just delivered to the Contracting Office, but to the stakeholders that need to review them.

Better yet, the program office could require that deliverables such as reports are submitted within Jama Connect as drafts, allowing the program office to use Jama Connect Review Center to provide detailed feedback prior to the formal submission of the deliverable. This does include additional work on the part of the program office, but depending on the importance of the deliverable it may be worth it. The benefit of this is that if there are issues with the approach the contractor is taking, those can be identified early and actions can be taken to fix the issues before the situation becomes critical.

Throughout this series I’ve discussed how Jama Connect can be used by a program office. I hope that I’ve made the case that having a common requirements management platform within a program office that is shared by the contractor and other stakeholders can be a powerful tool. Life in a program office is about making decisions. The challenge has always been in having the right information at the right time to make the right decision. While no tool will solve that, Jama Connect if used effectively can certainly help both the contractor and program office leadership make decisions, and to do so in an open and transparent manner.

Stay tuned for the final post in our government program offices series!

Welcome to Part V 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, Part III where I cover contractor requirements decomposition, and Part IV, where we discuss financial management.

Welcome back to the program office blog series. You are now reading blog post six (6) on this, so congratulations on your endurance. At this point our program office and contractor have figured out the contract and the requirements. Today, we’ll dig into the test planning that happens both within the contractor and the program office (or the designated test organization).

Jama Connect has all of the requirements including the products functional and operational requirements. The contractor is responsible for building the product. As a part of that product development, the contractor will conduct a variety of unit and system level tests. Depending on the contract, the government may or may not have visibility or approval of any contractor internal testing. On the government side, there is typically both developmental (does this product meet the specifications?) and operational (can I actually use this product to do my mission?) testing.

In either case, Jama Connect can be used to build and approve the different test plans. This includes the contractor and government test plans. This allows traceability between the authoritative requirements and the testing, and allows for an easy analysis to determine if there is satisfactory test coverage of the requirements.

Jama Connect allows the creation of multiple test plans, where specific test cases can be assigned

Jama Connect allows you to document the results of the test runs within Jama Connect, allowing full visibility of whether or not the requirements were validated through testing.

One of the benefits of Jama Connect is that the contractor’s or government test teams can be independent of either the developers or the program office. Jama can be configured to limit access to or visibility of the test plans as required to ensure that independence is maintained. However, through the use of Jama Connect the testers are able to collaborate with the developers and the program office to ensure that the requirements are understood, and that the testing objective measures the products compliance to those requirements. It also allows the testings to start deriving additional requirements that are necessary to actually perform the test, and to start their own project management as required to be ready to test.

Test planning and generating test reports is a core function of Jama Connect and leveraging this capability within the program office environment is really a simple decision. The only uniqueness in this use-case is the possible need to reduce access to or visibility of the test plans, and that is easily accomplished through the built-in Jama Connect access controls.

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.

Welcome to the third post of this series, where we’ll discuss how to use Jama Connect for contractor requirements decomposition. 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 approval to release the RFP, and Part II, where I discuss source selections.

At this point, congratulations are in order. The program office has managed to build the RFI and RFP, issue the RFP, accept proposals, and finally make the contract award. That is a lot of work just to arrive at the starting point for the contract.

Now, unless the program office managed to break down the requirements sufficiently, the contractor will now take the requirements as stated in the contract and decompose those requirements into the requirements they actually build against. This is one of the earliest opportunities for a contractor to ensure vendor lock-in, but this requirements decomposition is a vendor-owned and controlled system. This makes it very difficult or impossible to transfer the decomposed requirements to a different contractor if the first contractor’s performance is unsatisfactory.

But, in this case, we have a smart program office that has Jama Connect. The contract requires the contractor to do the requirements decomposition in the Government-owned Jama Connect, and Jama Connect is provided as GFE/GFI to the contractor. This one decision ensures that the program office has visibility into the requirement decomposition process, allows improved collaboration between the program office and the contractor, and allows the program office to easily transfer what this taxpayer paid for work to a different contractor.

The contractor’s requirements decomposition of the contract requirements is standard use-case for Jama Connect, and Jama Connect is well-suited to enable the contractor to derive multiple levels and types of requirements. Jama Connect also allows the contractor to get quick reviews from the program office or other government subject matter experts on their interpretation of the requirements, so mistakes are caught early and corrective action can be taken.

Using Jama Connect’s relationships, the contractor can derive an unlimited number of requirements. Multiple relationships can be defined and monitored by Jama to ensure that the requirements decomposition is sufficiently detailed.

What works really well in this situation is Jama’s ability to automate workflows. This allows the requirements to be moved from “draft” all the way through “government approved” within Jama Connect, with the program office/contractor approving workflow and reviews. It also captures the decisions made along the processes, allowing for full accountability and traceability.

Writing the requirements and getting agreement between the contractor and the government on the requirements is only one step in this process. The system still isn’t built, tested, and who knows what issues will arise during the development process. All of these unknowns lead into cost uncertainty and tracking, which will be our next topic.

Welcome to the third post of this 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 how we got approval to release the RFP. There are some tools in use today that allow for some automation and tracking of the evaluation process. In this post, we’ll explore how Jama Connect could potentially replace those tools, or allow a program office to help automate the process where there is no existing automation.

The RFP Process for Government Program Offices

Every RFP includes a section that mandates how the contractor’s proposal must be formatted and submitted. While my ideal situation would be for contractors to build and submit their proposals in Jama Connect, I’m going to walk through a less futuristic approach. Since the program office built their requirements in Jama Connect, they now have a set of individual requirements and the ability to mandate that the contractor explains how they will meet each requirement. This is where a program office needs to think through how they want the proposals to be formatted such that they get the information they need from the contractors and get that information in a way that allows for the easiest, most objective, and most efficient source selection possible.

Having been in the middle of doing technical evaluations on proposals based on poorly worded requirements and with no thought on how the evaluation could be optimized, I can’t stress how important it is to think the source selection through before you release the RFP. If you want to avoid a successful protest or be able to recruit qualified evaluators, make it objective and efficient.

So, if the program office does this, they can have the contractors submit their proposals in a digital format that can be easily imported into Jama, and the technical evaluation can occur within Jama. This allows evaluators from across the government to participate as necessary. It also brings together the RFP requirements with the proposal so all of the context included in Jama earlier can be leveraged for the evaluation.

Proposal Submissions and Review: an Example

Here’s an example of how the proposal process might look within Jama’s Review Center.

Jama Connect for Government Program Offices

In this case, the contractor’s submission meets the requirement.

Here we have an unacceptable response from the contractor. In this case, the evaluator rejected the the contractor’s submission.

Now that the review is done, the Contracting Officer can view the results of the evaluation. It also provides insight into how much time the reviewers took reviewing the proposal, which may help ensure that the team is consistent in how they evaluate each proposal.

So, now the evaluators can review each contractor’s proposal and can grade the proposal against the established criteria. Additionally, the Contracting Officer has full transparency regarding the evaluation and is able to respond to elevator concerns within Jama Connect.

Program Office Software

If it isn’t obvious at this point, the program office is now developing the foundation for managing the program and the contractor’s performance within Jama Connect. This will continue throughout the lifecycle of the program and across multiple contracts, contractors, and both industry and government stakeholders. This establishes Jama Connect as the authoritative knowledge base regarding the program. We will continue to build on this knowledge base in the following blog posts. Stay tuned!

Welcome to the second post of this 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.

Today, we’ll be exploring the art and science of contract requirement development within federal government program offices and how Jama Connect could be used. While tailored for federal civilian and DoD program offices, many of the lessons learned here will directly apply to corporate program offices as well.

With a few exceptions, the federal government does not build anything. They negotiate contracts with civilian contractors to build things. The program office defines the contractual requirements, conducts a source selection to award the contract to the best contractor, and then manages the contractor’s performance to ensure that the requirements were met. Or at least, that is the extremely simplified version of the Federal Acquisition Regulation (FAR) process.

Today, let’s look at the two key program office requirements documents used to solicit proposals from industry, the Request for Information (RFI) and the Request for Proposal (RFP). Sometimes these documents go by different names, but I’ll stick to RFI and RFP.

The RFI is the first public requirements document used to determine if there is sufficient interest in industry such that a competitive acquisition could be done, and to solicit expert input on the initial set of requirements so the government doesn’t overlook anything that would cause problems in the acquisition later.

The RFP is the more formal requirements document used to solicit formal proposals from industry, and is the basis of the contract. It is primarily filled with boilerplate legal and contracting language, with a few tailored sections which describe the actual requirements and how the proposals will be evaluated.

The goal of the RFI is to gather information and insights from industry so you don’t screw up the RFP. The quality of the answers provided in response to an RFI is proportional to the quality of the questions asked in the RFI. The RFI is also a strong signal to industry on the seriousness and professionalism of the program office issuing the RFI, and will influence their decision to submit a well thought out proposal or not.

In general, the program office will have a set of user requirements, either generated internally to the program office or externally by the organizations the program office is supporting. It is easy to just publish an RFI with those requirements and ask the industry “can you meet these?” – but that does not provide the program office much insight. The best RFI’s are well thought out, and are asking well crafted questions to industry that not only cover the user requirements, but provide insight into gaps in the requirements, potential acquisition pitfalls that should be avoided, and to expose a range of options for how to optimize the acquisition.

So what is Jama Connect’s role in this? Jama Connect is the platform where the questions in the RFI are built, collaborated on, and optimized. For example, below is a screenshot of a sample Jama Connect project where we have the user requirements and a set of potential RFI questions. By using Jama Connect, it is now possible to effectively collaborate with stakeholders throughout the government. Jama Connect also can help organize all of the responses such that the actual lessons are learned.

The beauty of Jama Connect is that it enables continuity between the RFI and RFP. Getting input from industry is useless if it is unable to be processed and used to optimize the requirements in the RFP. The RFP is where requirements “get real,” and the set of requirements in the RFP will evolve into the formal contractual requirements. Both the program office and contractor benefit from having a well defined, objective, and easily understood requirements.

Now that industry has provided responses to the RFI, the program office, it is up to people like me to sift through all of the comments and determine what changes need to be made to the requirements prior to publishing the RFP. This is where Jama Connect shines. Jama Connect allows me to effectively evaluate each input from industry and then update the RFP accordingly. As the RFP gets closer to completion, the more scrutiny it undergoes through the wide range of government stakeholders including the program office, user representatives, test organization, legal office, contracting office, just to name a few. Jama Connect allows me to keep a single source of truth throughout this complicated review process and allows all of the stakeholders to have detailed visibility into the requirements as needed.

RELATED POST: Checklist: Selecting a Requirements Management Tool

Now is a good time to explain why Jama Connect makes a difference and why doing this in a word processor or spreadsheet just isn’t good enough. Jama Connect allows for a holistic development of the contract requirements while ensuring that only the publicly available information is released to the contracting community. This allows the program office to put everything into Jama Connect and to export only what is needed to publish the RFI/RFP, instead of spreading out this information in different documents, email traffic, memos for record, and so on.

Let’s look at one specific program office requirement, and the context that be included in Jama Connect. Remember, this isn’t just a repository of requirements, this is the place to build, collaborate, and approve requirements. In Jama Connect you write it, share it, refine it, approve it, and finally export it to the right format.

So, since I’m a former Air Force, we’ll pick on one of my favorite requirements of all time. The formally approved requirement was “The system shall provide decision quality information.” Now, as you might imagine, context is everything and thus the requirement that must be in the RFI/RFP to be useful is going to reflect the context of that higher-level requirement.

As you see, the original requirement created a lot of discussion, and was eventually replaced with more specific requirements. Not only that, we now have a way to include context related to source selection evaluation, risk, costs, and testing along with the contract. Now, this requirement in Jama Connect can be collaborated on within the government program office and other stakeholders. This means that everything is in one place, and if there is a change to the requirement, it is immediately understood as to where else that change may impact. Perhaps as important, it provides program office leadership insight into the program office’s actual understanding of the requirements and their preparation to go through a source selection.

Finally, the RFP is submitted to the acquisition authority for approval. Once approved, the contracting office will publish the RFP and the fun of source selection begins.

Stay tuned for next post in this blog series, publishing on Thursday, June 10th.

In this blog series, I’m going to discuss how Jama Connect is a potential game changer for US federal and Department of Defense government program offices. I spent 24 years in the Air Force with 17 of those years in one or another government program office, or as the Air Force likes to call them System Program Offices, or SPOs. Every three to four years, I’d move to a new base and join a new SPO.

My role within the Air Force was that of a “developmental engineer” which is unique to the Air Force. None of the other Services have a direct counterpart to that role, and the closest comparison I’ve come up with in industry is what happens when you mix a solution architect, enterprise architect, and technical project manager together. My job was to take user generated requirements and then to deliver systems that meet those requirements.

Practically all of my career in the Air Force was in dealing with requirements. Sometimes it was the Federal Acquisition Regulations, sometimes it was a Statement of Work (SOW), and other times it was the actual technical requirements for one weapons system or another. After I retired from the Air Force I joined a very large enterprise IT company and that is where I first encountered Jama Software. It didn’t take long after being exposed to Jama Connect that I realized how this cloud-based requirements management system could have improved my life in the Air Force, if we just had Jama Connect and used it effectively.

After annoying people at Jama Software that I now count as my friends for years, they have given me the opportunity to share my views with you. To put this in perspective, I am not a Jama Software employee, not paid in anyway by them, and yet I’m investing a significant amount of my time to write these blog posts. I do this because I want to make life in any government program office to be better for those today than it was for me. I don’t want it to take a full year to come up to speed for a newly assigned acquisition professional. I don’t want people to flat out forget critical requirements resulting in the waste of tens of millions of taxpayer dollars.

As the first step in any 12-step program, the government needs to acknowledge that they have a problem with requirements. I think one of the best written summaries, at least for the DoD, was done by MITRE, and is called Modernizing DoD Requirements. While they do not promote any specific technical solution or platform to support their recommendations, it is easy to understand how Jama Connect would be critical to streamline how those recommendations become reality.