Lessons learned and best practices for military software

At one time, basic electronics were a subject for research labs, but the services now have electricians and even nuclear technicians. As the military masters this training process, they can create a pipeline for internal software developers for active-duty or reserve personnel.

This value proposition expands further if leaders use this as a nexus for leveraging teams of reservists that combine private-sector technology talent to challenges active-duty military personnel currently cannot solve. Lesson 3: Using organic talent provides asymmetric advantages that contractors cannot replicate. There is another benefit from integrated software developers that is difficult to quantify.

In practice, the time and effort to manage these contracts is overwhelming and instead units punt solving the problem and leave it to frontline workers to overcome. At scale, these decisions accumulate to a massive waste of time and effort. Worse, this creates a culture of mediocrity that accepts the status quo. At the enterprise level, building software capabilities around tactical problem statements ensures institutional investments are matched against warfighter needs.

It also creates an organic discovery process that identifies the next relevant domain for growth and budget allocations, a more agile approach than the waterfall method used to guide current development strategies. While Kessel Run partnered with Pivotal Labs for training to get off the ground, using military personnel offers several critical advantages.

First, doing so helps to develop products too small for current contracting systems. At present, servicemembers must overcome these technical problems with laborious and often inaccurate work streams, wasting time and money.

Second, utilizing military personnel accelerates code delivery. Even if a contractor is available, the project is well understood, and developers have the relevant context to solve problems, success is uncertain and can take months to deploy solutions.

This exposes servicemembers to risks and vulnerabilities during combat operations, even when they have identified capability gaps. We believe we have demonstrated the ability to continuously deliver software that adds value to the warfighter.

Third, a process that leverages uniformed personnel helps shape the development of the next generation of military leadership. Internal software development teams can address this challenge by providing experience running teams with digital tools. Kessel Run learned not only that was it possible to develop such talent, but that it was critical that coders and designers were complemented by leaders that could manage technical projects to create operational capabilities.

Since experience leading these projects supports both leader development and operational force requirements, ensuring that emerging leaders have the opportunity to compete for these assignments allows the military to capture value and experience that would be lost if we relied on external contractors.

The special-operations community can exploit this opportunity by assigning small unit leaders to bring their nuanced understanding of current operational problems to small development teams, while refining tactics based on software outputs. This trend is highlighted by changes to fields like the automotive industry, which hired three times more computer scientists than mechanical engineers in The Defense Department is long overdue for making the same pivot and modernizing in a meaningful way.

At present, modernization mainly implies simply updating or replacing platforms: new artillery, new tanks, new helicopters.

They want incremental innovation within the twentieth-century paradigm. This will require senior leaders and the organization at large to overcome blind spots and slaughter sacred cows through deep reforms. Despite what many see as an overwhelming success, there is still much resistance in other services and communities to seeing software development as a warfighting enabler or role for military personnel.

The need to correct these misconceptions and make software development an organic capability is vital to success on the modern, multi-domain battlefield.

The US military must be able to sense and respond to the adversary with new code and new algorithms faster than the adversary can develop its own. Making software development into a core competency is just one example of this. In the near term, creating teams of uniformed software developers provides the US military with critical enablers that can deploy alongside users to iterate on these tools for combat operations. At present, the lack of billeting and talent management strategies hampers efforts targeting these issues.

This is especially acute at the tactical level, where individual manning is often seen as a zero-sum game, making commanders hesitant to lose some of their best soldiers to borrowed military manpower requests. One of their recommendations involves creating a Digital Innovation Talent Management program, administered by service personnel chiefs, that provides billets for key digital talent so these individuals can be placed in separate holding pools, thereby eliminating institutional friction.

In the Long term, institutionalizing these skills creates a talent roadmap for future senior leaders to integrate emerging technologies into their strategic plans and maintain technological advantages over near-peer rivals. The need for these skills within the broader force will increase over time, as the complexity of our weapons systems and operational concepts demand levels of technology literacy that our formations often lack.

Further, as the technical competence of successive generations increases, the need to harness that talent and solve this problem will rise. It is critical that software development is perceived as a fundamental skill and enabling capability, or we will fail to manage the complex challenges at the heart of modern warfare. He served on active duty for eleven years and now works in national security cloud computing and software development.

The views expressed are those of the authors and do not reflect the official position of the United States Military Academy, Department of the Army, or Department of Defense. Your email address will not be published. Save my name, email, and website in this browser for the next time I comment.

The articles and other content which appear on the Modern War Institute website are unofficial expressions of opinion. The views expressed are those of the authors, and do not reflect the official position of the United States Military Academy, Department of the Army, or Department of Defense. The Modern War Institute does not screen articles to fit a particular editorial agenda, nor endorse or advocate material that is published.

Rather, the Modern War Institute provides a forum for professionals to share opinions and cultivate ideas. Comments will be moderated before posting to ensure logical, professional, and courteous application to article content. Share on Facebook Share. Share on Twitter Tweet. Share on LinkedIn Share. Send email Mail. Print Print. Leave a reply Cancel reply Your email address will not be published. Search Search for:. Follow Us Facebook Youtube Twitter 38, followers. Disclaimer The articles and other content which appear on the Modern War Institute website are unofficial expressions of opinion.

Upcoming Events There are no upcoming events at this time. Collection team time commitments can range from one week to six months. An indirect collection is any information gathered that was not specifically targeted in a collection plan. This could be information supplemental to the original collection plan or unsolicited observations, articles or academic papers.

Once an observation has been collected, it is analyzed and sanitized. One of the cornerstones of CALL's success is that it is a positive organization. All collection observations are cleansed of any information that could potentially damage the contributor. Experience has shown that lessons can be communicated without identifying the specific program or individual who shared the lesson. Once the observations are sanitized, they are returned along with any other potential articles or program information to the targeted Program Manager for review.

The PM has ultimate approval or disapproval before anything is either published or made available in the publicly available observation database. Historically, targeted units or programs have never refused permission to publish observations. Although the lessons learned vary widely in scope and lifecycle phase, the majority of concepts outlined apply to any program regardless of size.

First, to prepare for the broad spectrum support across all phases of the Acquisition Life Cycle Model, encompassing all Army Acquisition disciplines, so that a historical database of lessons and observations; Tactics, Techniques and Procedures; Academic Acquisition Research Reports; Program Office submissions and Acquisition Articles can be input, recalled and distributed upon request.

After reviewing all the Acquisition Branch collections to date, there is one particularly good news story that stands out from the rest. It is a story of a struggling program that had serious technical problems, schedule delays, budget changes and congressional scrutiny.

They interfaced with every major U. I will explore how one Project Manager took a struggling program and in just two years was selected the Army Project Manager of the Year.

This project's success cannot be attributed to any single individual or change. It was a hard working team that integrated a series of program management best practices, coupled with the critical enablers and motivational leadership, which turned the program around. Most importantly, this turn around was accomplished without losing sight of the Warfighter.

The first step in turning the program around started long before the project charter changed hands. The new Project Manager understood that he had to do his homework up-front if he expected a significant change. The guiding principle of the model was that the Government and Contractor's business strategies must be the central focus. The goal was maximum congruency.

These strategies drove the model's four levers of control. The first lever of control was Belief Systems and included instilling the core values of integrity, teamwork as well as a standard of excellence. It was believed that these values would help guide the organization in search of new opportunities.

Boundary Systems allowed the Project Manager to better manage risk by setting limits on opportunity-seeking behavior. This was accomplished by clearly documenting requirements, managing risks and tracking quality, budget and schedule.

The third lever of the model was the Diagnostic Control Systems. This was the measurement of critical performance variables by such methods as earned value management, critical path analysis and metrics. Using these control systems allowed management to monitor program progress while not forgetting to reward those who achieved established goals.

Lastly, Interactive Control Systems helped the organization handle strategic uncertainties. Executive Leadership Workshops and Off-sites also went a long way in stimulating organizational learning.

This learning also helped produce new strategies and ideas. Once a management model was identified, it was critical to establish a culture that embraced a variety of new program management best practices. A great deal of effort was expended initially to demonstrate that the PM culture would pay dividends.

While being fostered in small groups, change was championed by government and industry senior management. Ultimately, changes took root. Most importantly, best practices were integrated in a manner that lended strength to each other.

I will explore a few of the innovative best practices and enablers that the project integrated to be successful. The cornerstone of the project's management philosophy was extensive collaboration with contractors. This new structure was enabled by a leadership attitude that viewed contractors as partners rather than adversaries. By the nature of their business, they were constantly getting together to discuss and solve issues. They were extremely collaborative.

In some cases, government and contractors were collocated specifically to facilitate the sharing that happens best when you share the same workspace. In fact, one entire product office within the project was moved into the prime contractor's facility to facilitate communication.

Lower Level IPTs review, plan and execute software metrics, earned value data, schedules and engineering issues.

They resolve technical issues and review risk management and integrates IPT products. The Program Management Team reviews program status, metrics, contract actions, Integrated IPT actions, earned value and midterm planning.

They also provide final cost schedule issue resolution. In addition to cultural commitment invested to build the IPT process, award fees reinforced the entire procedure by including a criteria that required the contractor to publish IPT agendas 24 hours in advance of meetings and minutes 24 hours after all meetings.

This reinforced culture while enabling better communication within individual teams. A geographically dispersed IPT structure cannot be successful without a mechanism to assist collaboration. This application was a web-based application that provided nationwide coverage. Application functionality did not change based on the connection. Built to support the process, the IDE was data-centric with minimal graphics to waste bandwidth. It provided multilevel security to limit access to nonauthorized users.

Because each individual IPT had the responsibility to organize their own website, data was organized how people work. The individual team websites were used primarily for workflow and archiving. The application also provided a robust Executive Support System functionality that provided management with high-level information on noteworthy metrics while allowing them to drill down into hundreds of detailed reports.

The application was extremely intuitive allowing new team members to contribute immediately rather than having to waste precious time training. In addition to the larger project IDE, the Project Management Office also utilized an internal web-based application for government only business. Although the transition from a paper-based to electronic culture was difficult, a well thought-out, intuitive solution proved to ease the changeover.

In an attempt to fully utilize the entire pool of government talent, the Project Manager ensured all stakeholders were informed and decisively engaged in all phases of the program. This ultimately increased the reach of the Project Management Office by giving them timely visibility into sub contractor progress nationwide.

Alpha contracting represents a paradigm shift from the days of adversarial relationships between government and contractors.

All requirements were generated as an alpha contracting team. Unlike partnering, the government and contractor did not have to always agree. Instead, they had to work as a team. One way a customer uses to encourage commitment and productivity from contractors is incentivizing contracts. This project took this concept to a new level.

Award fees were earned in six-month contract cycles. The award emphasis shifted during each six-month cycle based on where the project was in development. Areas of emphasis were announced before the start of a new cycle and were alpha contracted. The contractor provided self-assessments detailing their progress against the emphasized areas.

The Government provided the contractor with mid-point and final evaluations. The mid-point evaluation promoted dialog and refocused all stakeholders. The award fee was based on the last day of the award period rather than the performance during the entire period. This encouraged the contractor to strive toward documented goals for the entire award fee period.

What is unique to this process was that two senior members of the contractor's management were also present as nonvoting members. Performance input was also submitted by every IPT. Ultimately, the Project Manager was the determining official. What made this contract approach so novel was the scope of the award fee emphasis and extensive collaboration with the contractor in determining and evaluating the award.

The identified award fee emphasis ranged from the fundamental importance of the weapon system hitting the target, while at the same time, encouraging the day-to-day tasks that instill program management culture. Finally, all stakeholders were involved from start to finish ultimately building a singular vision. This meant developing a review cycle that would allow issues to bubble-up from the lowest level IPTs to a senior management decision in less than seven days.

A rigorous decision-making process drove the collaborative environment. On Tuesdays through Fridays, lower level IPTs statused their performance and issues passing irresolvable issues to the next highest level. Chartered members of these meeting were able to speak and make decisions for their organizations. Second, the nonavailability of one key person did not stop the process.

Replacements were identified who have the background and authority to make decisions.