In the United States today, there are approximately 22 million people employed in some capacity through federal government funding [1]. This is almost double the number of people who are still left in U.S. manufacturing jobs. Of those working under government funds, 2.7 million people are direct civilian employees of the U.S. government and approximately 1.3 million people are active-duty military service personnel [2]. The rest are federal contractors who provide systems and services through close working relationships with federal agencies, vendors who provide commercial products to federal buyers, researchers at federally funded research and development centers (FFRDCs), analysts at some not-for-profit companies, universities with federal grants, and even individual consultants. Some politicians and social activists have argued that the U.S. federal government has become too big and with too much waste of resources. However, governments of modern democratic nations have a responsibility to manage large, complex societal operations that offer social services, national defense, infrastructure sustainment, law enforcement, monetary control, and other benefits for their citizens.
To fulfill its responsibilities, the government of the United States spends approximately $3.7 trillion each year. Over two-thirds of the money go towards nondiscretionary obligations (mandatory spending) such as Social Security, Medicare, and interest payments on the national debt. However, the United States also spends more than $1 trillion per year on discretionary activities involving the purchase of systems and services [3]. Maintaining national security alone requires more than $500 billion in spending. These facts make the U.S. government one of the largest buyers in the world. Its buying process has evolved over the years to reflect the needs of government agencies and advancing national priorities, and a massive federal workforce has grown to execute this process for each government agency.
Contractors wishing to receive money through the federal systems and services acquisition process must therefore gain a deep understanding of federal statutes and regulations; policies within the departments, agencies, and organizations; and approaches adopted by different acquisition communities. Despite all the layers of constraints on how acquisition must be done, the government still needs solutions. This is because the functioning of the government generates performance issues, new operational needs, and new performance-enhancement opportunities. Complying with the federal acquisition process will reduce the likelihood of oneâs proposal being disqualified. However, it is having the right solution that will help one to win contracts. The right solution is not just about formulating the best idea and having good technical writing. It includes knowing the federal customer, having the correct team members, selecting low-risk technologies, getting clear and complete business intelligence, designing the most optimal processes, having the right price, and presenting the end-to-end plan for supporting the user community. This book is designed to help readers find the right solutions and win federal contracts with the right solutions.
We start the discussion with the topic of knowing the customer, those people working directly for the government with influence over the procurement and management of the systems or services that we wish to provide. When the acquisition is substantial, a government program management office (PMO) is sometimes established to execute the entire procurement and management process. Alternatively, the acquisition can be managed as a project with more process flexibility. Either way, the management philosophy of most government leaders tends to focus on identifying risks and maintaining control. Government staff tasked with acquiring capabilities often wants to be a part of the solutioning process. This is reflected in PMOs and their support contractors developing detailed requirements, formulating initial concepts of operations (CONOPS), analyzing technology alternatives, and even creating in-house prototypes. This underlying government desire for participation amplified by established processes can sometimes be interpreted or misinterpreted as the government not calling for solutions but instead calling for compliance. Thus, there are many books written about how to create winning proposals to the federal government through compliance and presentation style. Techniques upon techniques have been developed on how to read request for proposals (RFPs) and figure out how the government will evaluate them. Armies of government business development (BD) professionals have worked over the decades on building relationships so that they can gain competitive insights. Countless teams of proposal managers, technical writers, and subject matter experts (SMEs) have labored repeatedly on proposal after proposal based on business intelligence, identified win themes, and projected probability of win.
All the endeavors of the BD and RFP winning strategy analysis are very important. However, the need to develop coherent solutions cannot be lost in the endeavor or else the immediate proposal wins will face difficulties in contract execution and long-range prospects of winning more proposals will diminish as the lack of solutions become apparent. Proposals without coherent solutions will, in many cases, become eloquent words that (1) mirror government language in the performance work statements (PWS) or statement of work (SOW), (2) state in detail what occurred in past contract endeavors as qualification for the future work, or (3) describe in detail the current state of technologies and processes as validation of technical know-how. Unfortunately, none of these proposal elements are actual solutions. Government source selection evaluation teams (SSET) may nevertheless score such proposals highly through checklist evaluation processes. When contract performance has declined, we then see the government either being more specific about communicating what they perceive as solutions or being more analytical about the solutions content of future proposals.
Government direct involvement in formulating solutions can be a problem; because internal quests have also garnered a spotty record in the age of information technology (IT). For example, we have seen the U.S. government ambitiously trying and failing to build mass enterprise IT systems, and we have seen the government shifting toward building smaller, more compartmentalized systems as a reaction to major program failures. We have seen mandates to use commercial technologies, and we have seen failures in adapting commercial technologies to government requirements during blind attempts at following mandates. In solutions for providing IT services, we have seen years where some government organizations only want to rely upon contractor expertise. Then, we have seen years where the government tried to build up capabilities within the federal civilian workforce. So, the best path is still for contractors to have complete solutions from the start and then inspire government confidence through successful implementation of solutions. The alternatives of no one developing solutions and everyone (government and contractor) developing solutions each has its challenges.
The governmentâs attentiveness to commercial trends has attracted the attention of many contractors. So, we will periodically hear a call for transformation. The term transformation can have significant meaning, but this too is not a substitute for having solutions. Solutions can transform and solutions can stably maintain the current state. When a transformation does not have a specific solution, however, people tend to end up repackaging standard operations research and business process improvement techniques into branded general solutions. When these general solutions are applied, old processes are sometimes torn down with an unclear understanding of how to reach objective states. Thus, transformations detached from specific solutions are risky in terms of process stability, continuity of operations, preservation of key information and functionalities, and user adoption. The philosophy of this text is to focus on the specific solutions and let others determine whether such can be considered transformations.
In the current environment of federal contracting, there are great financial opportunities, complex processes, and competing forces. Thus, there is a great need for a book dedicated to the fundamentals of developing operational solutions. This book seeks to guide you in winning proposals by innovatively solving the governmentâs problems. In this context, BD is a part of the solutioning process and the idea of tactically gaming the government acquisition process is superseded by the idea of strategically gaining the trust of government leaders. This book adopts two paths in achieving this objective. One path is to create a framework for thinking about government problems and opportunities so that innovations can be promoted and solutions can be formulated. The other path is to establish a deep understanding of government activities through the discipline of operations research. This understanding enables the endeavor of formulating solutions to be placed in precise context for government implementation. There are massive tomes dedicated to the theories and mathematical models of operations research. This book is devoted to making operations research techniques simple enough for professionals to apply in the course of developing proposals and delivering systems and services. Introducing methods and techniques for quickly developing solutions that are implementable within the constraints of government statutes/regulations/policies and government requirements is thus the central focus of this book. The timing for this book is appropriate given highly publicized contract performance failures such as with the healthcare.gov portal. The government turning away from traditional federal contractors to seek help from Silicon Valley experts should have been a wake-up call. Now, the words innovation and solution are starting to become more prominent in RFP language.
The following chapters on developing solutions assume a basic knowledge of acquisition history and processes within the U.S. government. For those newly acquainted with systems and services acquisition by the United States, this book offers three useful appendices. The reader may wish to first review these appendices before proceeding.
Appendix A presents the history of the U.S. Department of Defenseâs (DoD) systems and services acquisition activities. Through this history, we see changes in acquisition policies, organizations, and capabilities over the decades, and we see great successes as well as some major failures that remind us of the challenges in being a government contractor. This history takes us to todayâs DoD acquisition process, and we can, through lessons learned from history, create solutions for future RFPs that are free from the mistakes of the past.
Appendix B presents a summary of the federal governmentâs basic requirements formulation and source selection processes. This summary is comprehensive and written for contractors planning to bid on government RFPs. The objective is to bridge the knowledge divide between contractors and government acquisition career field professionals who have received formal training in Federal Acquisition Regulations (FAR) and agency-specific acquisition policies. The limited and controlled interactions between these two communities, as required by regulations, has only served to emphasize the knowledge divide. Even when federal acquisition professionals have decided to join contractor organizations, their roles are often stove-piped within the BD communities to further hinder knowledge dissemination. When those involved in BD and developing proposals gain an understanding of how the government source selection teams will evaluate proposals, the probability of winning will be dramatically enhanced. At the very least, those responsible for the formulation of solutions must understand how their solutions will be received by government evaluators.
Appendix C presents government expectations on how contractors will manage and report on their work after being awarded contracts. Developing and delivering solutions is still the objective for supporting the government. However, this appendix explains the equally important day-to-day tasks and process of doing business with the U.S. government. It explains how the government wants to see the contractorâs program management organization, established development methodologies for solutions involving new systems, and quality control and risk management mechanisms.
Based on the understanding of the government established in the appendices, the chapters of this book then take the reader from understanding how to work within the government processes to how to innovative and develop solutions for the government processes. It may appear strange that we cannot jump straight into developing solutions. The reality is that the complexity of interacting with the government should be mastered in a way that enables us to gradually step into developing solutions. Solutions architects have tried to bend the government to their solutions, to no avail. This is because only those companies that have a monopolistic hold in key product areas, such as Microsoft, have ever succeeded in such endeavors. If you are one of those commercial industry-dominant companies, then do not bother reading this book and go straight to imposing your solutions on the customer. All you then need is a good number of lawyers to handle the government contracts. For the rest of us who do not dominate a commercial technology sector, we need to bend our solutions to the government, and that is how this book must begin.
Regarding who should read this book, we presented the idea of dedicated solutions development teams for proposals and other BD activities with the government. The members of this team need to have subject matter expertise in relevant technical areas, and they must also have the ability to think broadly about the systems and processes within the overall government operational environment. If we call these people solutions architects, they must be more than those solutions architects who specialize in one collection of technologies and products. Instead, they must be able to learn quickly about all new technologies, conduct comparative analysis, and conceptually explore new paths of utilization. This is why we cannot just pull experts from narrowly defined programs and ask them to write pieces of a proposal. Such experts can write about what they know, but may struggle with the totality of the government problem. In a solutioning endeavor, it is perhaps better to have a solutions development team reach back into the company workforce to gather expert knowledge and then let the team integrate the knowledge within the context of the required solution.
For members of the solutions development team, the abilities to decompose problems and integrate technologies, processes, human skills, and system architectures are far more important than subject matter knowledge. Thus, those in the field of systems analysis and operations research will have an advantage in solutioning endeavors. Business leaders who are skilled at strategically solving current customer problems could also be contributors in the solutions development team. As solutions are ineffective if people cannot understand them, communications is an equally valued capability. Team members must be able to write and effectively express ideas. They must be able to develop diagrams using common tools to express concepts, workflows, and architectures. And, they must be able to read and work with financial spreadsheets on labor categories and rates because price is a component of all solutions.
Last, before we proceed to the next chapter, success in solutions development is a matter o...