Developing applications for the federal government differs from working with commercial clients in a few key ways. From proposal to testing to documentation, knowing what to expect from government contracts is the first step to winning and succeeding with them.
The government organizes all of the requirements for a project up front in a request for proposal (RFP), which is then sent to prospective companies. The government typically has a very specific format in which they wish to receive proposals. The format is usually comprised of three to four separate documents: cover letter, technical proposal, past experience, and pricing. The government essentially wants everything planned out ahead of time, as that makes it easier for them to budget for.
The technical portion of the proposal needs to convince the reader that the project requirements are understood. In addition, information on how the project will be executed in relation to said goals should be outlined. All points from the RFP need to be clearly addressed in order for the proposal to have the best chance at winning.
Most Government RFPs require the development shop to provide the resumes of individuals that will be working on the project. They will also often times require a shop to explain/submit relative work experience. Having up to date information on the company’s processes, technical abilities, and employee resumes already written up can make proposal creation quicker and easier.
Another important difference between the government and the private sector is the degree of security involved. Many contracts require workers to get a specific level of security clearance. Government security clearances are good for several years, similar to licenses and other legal documents issued by the government. Depending on the level of clearance requested, they can take a considerable amount of time to procure, so having one ahead of time can be very important when seeking government contracts.
In addition to trusting the personnel working on the project, it’s important for the government to be able to trust the final product. Most computers, mobile devices, etc. issued by the government are managed devices and access to the information on them is closely monitored and regulated. This is to keep unauthorized applications that could pose a security risk from being installed and gaining access to secure government networks and data.
When the government intends to start using a new piece of software or hardware, they rigorously test it before putting it into active use. Their testing is more strict and thorough than what a commercial client would perform and focuses much more on functionality than appearance.
In addition to the normal QA process, a thorough code analysis is done. The source code will be subjected to various tests to ensure its reliability and security. Code reviews will be performed by hand, and automated programs will conduct static program analysis. The intent of this is to find undocumented features and potential security risks. These can include but are not limited to bugs, debugging modes, and back doors. Regardless of what the application is intended to do, if it is being introduced to a secure environment it needs to maintain the security of that environment.
Not only does an application need to be secure, well written and tested, and it also needs to be user friendly. This is especially important for field applications. War fighters need to send and receive information without fighting with a phone. Everything from buttons, screen transitions, affordances, and iconography must be designed to clearly and easily communicate what needs to happen.
There is also an expectation that the contractor will provide detailed documentation on the structure and operation of the software when the project is completed. This can include technical manuals, database schemas, user guides, and any other information needed to meet the documentation standards specified in the contract. This can be difficult in an agile process as features and implementation can quickly change which requires frequent updates to existing documentation.
Why Choose Metova?
Our company started in 2006 and revolved around BlackBerry development. Since then we have built over 100 BlackBerry applications. Although civilian usage has dropped dramatically over the years, BlackBerry devices are still highly utilized by the U.S. Armed Forces. Our experiences with overcoming network reliability issues, encrypting and delivery sensitive data from a device to a remote server, and otherwise controlling and managing devices make us a world leader in BlackBerry app development.
Preference is sometimes given to small businesses that are owned by minorities, women, or service-disabled veterans. Metova is a Service Disabled Veteran Owned Small Business (SDVOSB). Our president, John Adams served in the military for over 23 years, culminating his last assignment as the Chief of the Information Technology Training Center, where he was responsible for all information technology training for the Army National Guard.
We also have expert security people on staff (e.g., an Information Assurance Manager with 20+ years of experience in the U.S. Army and beyond) and others with extensive military experience. 100% of our employees are clearance-eligible U.S. citizens, many of whom already have clearances.We can help bridge the gap between government needs and highly specialized mobile application developers. Contact us to get started!