The Case for Purpose-Built Software

An Air Force Contracting Officer (CO) in Romania is tasked with developing business relationships and arranging contracts with local vendors throughout the country so that when the need arises to quickly build a temporary runway, such as to provide humanitarian support in the event of a natural disaster, contracts are already in place. The officer meets with vendors to determine the availability of locally sourced products and services such as concrete, catered food, porta-potties, etc., so that the Air Force can avoid flying everything in on transport aircraft. Why spend the money to fly in 4,000 tons of gravel if you can buy it from local vendors?

Though the CO is the person making contract agreements, it takes a team of planners, managers, contracting officers, and contract observers to make this work. Until recently, this contracting process, all done with spreadsheets and documents, was fraught with errors and duplication of effort.

Create Task-Specific Tools

Rather than a typical generalist tool with a single interface, AF CyberWorx developed 4 separate yet integrated tools for the different user types (planner, contracting manager, contracting officer, and observer) and their specific set of tasks (task-oriented design). Planner tasks demand a large workspace, such as a desktop with multiple screens. Contracting managers work from remote locations like hotel rooms and require laptop-sized screen designs. Contracting officers work in the field with tablets. Observers only need a smartphone app. 

The result is an enterprise-oriented, integrated suite of tools that focus on specific users and tasks and eliminate unnecessary data. Not only is each tool optimized for discrete user tasks, but the system also includes algorithms to perform many calculations and actions automatically, relieving much of the users’ cognitive burden. 

Reduce Cognitive Burden

This new approach is a welcome departure from traditional software designs which feature a data input paradigm. These “solutions” are simply information repositories—users perform the real work in their heads and then enter the results into a form. Form-oriented designs only address superficial aspects of a task, treating the system as a knowledge-capture tool rather than a knowledge or solution generator.

Good user research identifies the cognition occurring in the users’ heads and translates those computations into work a system needs to accomplish for users. A proven successful approach identifies best-practice knowledge or processes and builds them into the system. 

Flexibility is the antithesis of best practice or knowledge design.

Raise Users to a Best-Practice Level

For instance, when a group of users develops a more successful (best-practice) process for scheduling their assets and personnel, optimizing the task flow to promote that best-practice approach ensures that every user succeeds to that same best-practice level, often beyond their individual capabilities. In contrast, a flexible design (think spreadsheets) is a form-based solution that relies on the users doing all the work in their heads. In general, flexibility is the antithesis of best practice or knowledge design. Flexible interfaces rely on the users knowing how to use the tool as well as knowing how to perform their tasks well. A flexible tool typically requires that the users adapt their cognition to think from the tool’s perspective—how would the tool work best to do this thing—which increases the users’ cognitive load and further encumbers the task.

Stimulate Solution-Driven Actions

The ubiquitous dashboard is another common example of a design that fails to unburden the user. A typical dashboard is a compilation of static, moment-in-time data, albeit with colorful charts and graphics. What do these data incite users to do next? Users perform better with a purpose-built dashboard that displays trends and exceptions coupled with suggested actions that address the identified issues.

In a simplistic example, a company sales rep needs to meet their sales numbers to earn their maximum bonus. The company has developed best-practice formulas that suggest specific actions to successfully increase sales. A purpose-built dashboard indicates that a rep’s sales are trending below the “bonus” target and presents best-practice options to solve the problem. The suggested actions focus on actions to increase sales numbers.

Purpose-built designs standardize processes and reduce dependencies on individual user knowledge. The sales rep could determine this on their own, but then their success is dependent on highly variable levels of individual skill and knowledge. Any design that relies on such highly variable skills and knowledge cannot succeed at a level any greater than that variability. Such a user-dependent approach suffers from individual inconsistencies and fails to leverage proven, best-practice knowledge. 

Redefine the Problem, Address the Root Cause

A common but ineffective design approach to complex problems is to transform current tools and workarounds into apps—i.e., automating spreadsheets. Successful purpose-built solutions redefine the problem from the users’ perspective to address the root cause rather than solving the symptoms. User Experience research accurately redefines the problem and leads to truly purpose-built solutions. 

Though the purpose-built Air Force solution was complex to design and build, user research led to solving the right problem, saving the Air Force more than just time. This new solution is quickly earning a reputation for simplifying vendor research and eliminating user errors while achieving better results. It is quickly becoming the standard by which other software is measured. If you want to dominate a domain with a cutting-edge solution, don’t automate current solutions; invest in thorough good user research to build a task-oriented, purpose-built solution. It drives better outcomes!

NPS & AU Grassroots Distributed Innovation Sprint: An Interview with TSgt Daniel Hulter

Written by SSgt Austin Wiggins

To accelerate change within the Air Force and Space Force, we must be able to equip potential innovators with education that promotes innovation at the lowest levels. Recently, CyberWorx had the fortune of hosting representatives of; Air University (AU), Naval Postgraduate School (NPS), Army 75th Innovation Command, Defense Innovation Unit, Army Space and Missile Defense Command, U.S. Navy, MIT Lincoln Laboratory, Tecolote Research, and Lokahi LLC. Despite being from disparate groups, they had the common goal of fostering grassroots and distributed innovation through education and connecting academic initiatives to address operational problems. The common understanding in the group; something had to change.

To uncover what made this session interesting and to highlight some hopes for the future of this project, I interviewed the facilitator of the event, CyberWorx member TSgt Daniel Hulter.

What were your expectations for the group going in?

I wasn’t sure what to expect from this group. It was clear they had a lot of topics they wanted to address regarding educational institutions’ role and needs as part of the defense innovation ecosystem. What wasn’t entirely clear was which of these topics were universally felt or what the priorities were. So, I knew that one of the first things we had to accomplish was getting on the same page about what needs were shared and which were more confined to a particular group.

One thing I did expect was that the conversation needed to be driven forward in order to move from observation and analysis to action. We generally have a high appetite for exploratory discussion, especially those in academic circles, and that can make the transition to concrete action challenging. Some participants advocated for less structure to the session so that loose discussion was allowed to happen freely for longer periods while they were together, something we attempted to balance against the desire for clear courses of action. 

In what ways were those expectations positively subverted?

The group performed very well with the more structured portion of the workshop, which I won’t say subverted my expectations, but one of the things I was nervous about was whether they would appreciate being time-boxed and asked to perform very specific analytical tasks.

There were particular exercises that the group took to extremely well, for example their exploration of the defense innovation ecosystem through the lens of analogous systems. I remember feeling relieved that I wasn’t having to goad or micromanage them to do the exercises, which can be the case with certain groups.

What were your thoughts about the group’s objective to enable grassroots innovation through education?

I was slightly caught off guard by the inclusion of the “grass roots innovation” language in their problem statement. I realized that had I been more involved in the crafting of that problem statement, I might have been better prepared to speak to it. Instead I simply put it in front of participants and saw how they chose to interpret and include it in their exploration of the topics that came up.

I do think that the inclusion of that language speaks to the motivation of some of the organizers of this event to try and approach innovation education from a new angle, looking at distributed effects rather than targeted, exclusive, role-based impacts. But one thing we did run into there was that some of the individuals who helped craft that language did not join us for the session itself, which further limited the degree to which that problem statement guided participants in the direction they took.

I think there’s an opportunity in the motivation within this community to do a bit more to try and reimagine what innovation education could look like. It feels like what we accomplished in this day and a half was some broad scoping and a picture of some of the primary systemic mental models that are driving the current shape of the education system. One of the NPS hosts mentioned a paradigm shift around how we even think about innovation education and that’s really interesting.

But this wasn’t a workshop with a precise focus, it was much more exploratory. That question of how we might subvert or mutate or evolve the existing model to create something that is more aligned with the need for ground-level, grass-roots innovation is something that I think deserves significant time and attention and might be an interesting next step.

What are some outcomes you think that the group came to?

This group first achieved a few rough sketches of the current perceptual foundations of innovation education development and delivery for AU and NPS. Using that as an anchor, they thought about ailments within that existing system. They also arrived at a few measures that might surmount impediments to their primary value being delivered to more of the force. The proposed measures they came to at the end of day one can serve as launching points for experiments for these organizations to run, either together or separately.

Much of the time spent together in this session was also spent in discussions. I am confident that these interactions had a positive impact on the participants as they navigated the issues that came up during exercises on day 2, which was almost entirely unstructured. One of the common themes I heard come out was that this exact type of thing–coming together in one place and attempting to make sense of disparate and shared experiences across the defense education community–was something that ought to happen more frequently and perhaps with an even wider variety of participants. I think this may turn out to be one of the more significant outcomes, as it has the potential for continued delivery of insights, increased alignment, and sense-making, and increasing the likelihood of success for experiments that emerge from engagements like this.

What would you like to see from the organizations in this group in the future?

In the future, I would like to see these organizations do a few things:

Come together more frequently and invite more participants in, both with the type of forum that we created with this event and with more continuous connection mechanisms facilitated by platform selection/development, community building, and community management.

Spend more time thinking about and critiquing the perceptual foundations of their current organizational structures and strategies and put some dedicated time into seeing how those structures might be reimagined and redesigned.

Move forward with the experiments identified in the session as potentially high-value by giving them time and space in their own design efforts.

For those organizations who are seeking to empower grassroots innovation, do you have any recommendations?

My number one recommendation is to identify what is within the adjacent-possible for those you are expecting to innovate, for your particular context.

Every organization, unit, and team in the military has its own set of unique conditions and constraints that mean that the approach to enabling innovation and the form that that innovation takes has to be adapted to that level, a task which requires significant time and skill. Rather than seeking to identify standardized adaptations that might work for every circumstance, or even focusing on primary constraints of the larger system, I think it makes more sense to widely teach the very few underlying principles and practices that are universal. To try and affect a culture of acceptance, safety, and experimentation, and spend your remaining energy and resources on enabling that discovery and adaptation to happen in all the places it needs to happen. 

If we are talking about true ground-level innovation, speaking as someone who has spent a majority of my career at the tactical level, I think that means enabling people to be sense-makers and practitioners within their own context. Those practitioners can be plugged into more strategic and operational-level scaling and implementation efforts, so creating systems that transition and scale outcomes should be a priority for organizations as well. In my opinion, empowerment of grass-roots innovation doesn’t start with the question of “are we getting things across the finish line” from a top-level perspective. It starts with creating the opportunity for individuals to contribute and have actual impact on their immediate environment.

Another recommendation that I have is to tell more stories of failure. One thing that came up during our workshop was the fact that shame is a powerful motivator. We are never so innovative as when we are ashamed because we allowed a terrible disaster to occur. The most incredible transformations are possible when we actually reflect on the current state of things and the ways in which we are failing (either by choice or when forced by some kind of incident).

A mistake I see a lot of organizations making right now is telling too few stories about failure. We regularly identify the need to normalize and embrace failure within our culture in order to spur innovation, but we still don’t talk about it enough, especially in the context of innovation (I think largely because we feel the need to say we’re succeeding in order to keep getting funding and support from our organizations and leaders). Lots of efforts at enabling innovation are failing, and we need to be open and honest about that in order to create space and energy for the next pivot.

For the record I am guilty of this exact thing. Storytelling and marketing are crucial components of success in all ventures, especially innovation. Building coalitions requires that we convince others of our likelihood of future success, and claiming present or past success is a potential pathway to that, but it suppresses stories of failure that might allow us to be ashamed enough of the status quo enough to drive the change we need.

Do you have any closing thoughts?

It was wonderful to see disparate players from across the innovation ecosystem come together and navigate these difficult topics together, in both structured and unstructured ways, and I hope to see this exact type of thing happen more often.

Thank you Daniel Hulter, for taking your insights into the session. With your participation, we are one step closer to delivering real qualitative change to grassroots and distributed innovators throughout the Air Force.

For more information on this project, visit the NPS & AU Grassroots Distributed Innovation project webpage.

CyberWorx Newsletter 2021 Quarter 1

Team Comments

The chemical company, BASF, used to have an advertisement that said in part, “…we don’t make the cooler, we make it cooler.  We don’t make the jeans, we make them bluer,” to highlight how their company improved the experience, performance, or durability of products for the people who use them.  Much like the ubiquity of the products presented by the advertisement, information technology now underpins nearly every aspect of daily life both at work and at play.  In a corollary, AF CyberWorx exercises their human-centered/user experience design, lean startup, and agile toolsets on the application of technology to improve experience, performance, and efficiency of mission execution, preparation, and support, while helping prepare the Air Force for new/emerging technologies and aiding industry in better understanding operational needs.  

Our Cyber Risk Ecosystem, presented in previous newsletters and currently in integration/deployment with NORAD/NORTHCOM, provides cross-domain risk awareness to help commanders understand and mitigate cyber threats to missions in other domains.  The recent low/no-code initiative for 16^th AF demonstrated the efficacy of equipping unit-level Airmen with tools to automate and improve their own processes such as aircrew training and mobility readiness and awareness, network account request automation, contracting officer/small business interactive marketplace, personnel functions, and training instructor scheduling.  Our team has helped the F-35 JPMO improve mission communications planning, and we see the potential for that work to expand across multiple platforms and across the Joint Services. 

At AF CyberWorx, innovation isn’t just about technology, but a balance of meeting user needs within organization constraints with the right technology to make Airmen more effective at the full spectrum of activities needed to deliver Joint capabilities from mission support through mission preparation and execution.  At AF CyberWorx, we don’t make the Commander’s decisions, we help make them better informed and more quickly.  We don’t load the cargo, we make tracking it more efficient and accurate.  We don’t fly the mission, we make the planning easier, faster, and more precise.

–Lt Col Helgeson, Deputy Director

CyberWorx 2021 Quarter 1 Project Portfolio

The Other Airmen Spotlight

The Other Airmen experiment aims to demonstrate citizen developers from the Air Force and Army can create useful applications using low code/no code capability. The teams are transforming their use cases into working applications to present to the 16th Air Force Commander Lt Gen Timothy Haugh in March 2021.

24 Feb – The process to pull and compare information for a unit member – military or civilian – is labor-intensive.  It requires data to be cross-referenced from multiple sources including spreadsheets and specialized systems. Currently, personnel acting as Unit Deployment Managers, Unit Training Managers, Commander Support Staff, and other positions need to collect this information, compare it for accuracy and currency, and route it up to appropriate leadership.

Two Citizen Developers are collaborating on a unit-level application that imports and aggregates complex spreadsheets such as the Unit Manning Document, Unit Manpower Personnel Record, Alpha Roster, Gains and Loss rosters, and Civilian Roster pulled from personnel systems. They can also manually modify personnel records using “detail screens” which displays specific information on an individual.

The application suggests changes and allows users to manually verify where changes or inaccuracies exist. User access to system data is role-based, granted as their account is setup by an administrator. Role-based access maintains data confidentiality while still providing appropriate access for specialized personnel to gather information quickly for mission-essential tasks.

The application is currently functional with access to real data. The Citizen Developers are adding additional features from their “want to have” list. They are also gathering more information to provide a more robust example for the March presentation. They would like to import data directly from system databases, but current bureaucratic controls require manual spreadsheet imports. This application is a perfect example of individuals identifying a need for a tool that reduces time- and labor-intensive tasks to improve efficiency and accuracy. The sleek design also highlights that even amateur developers can develop relatively sophisticated applications that perform well and look professional in a relatively short span of time.

31 Dec – Today’s Spotlight focuses on a Market Research and Solicitation tool designed for contracting officers to efficiently perform market research on a company submitting for a Federal Commercial Solutions Opening. Companies could upload pitch decks including a descriptive video and whitepapers to support the submission. The tool could foster continued engagement with an organization after an event or project is done.

Currently, data in the MVP is entered manually. It includes links to the beta.sam.gov announcement and any social media platforms the company uses. The citizen developer is seeking APIs and permissions to automatically pull company information using the DUNS identification number, which is a unique nine-digit number required for any company to register with the Federal government for contracts or grants. Other potential sources for automatic information include usaspending.gov for contract identification, the Air Force Installation Contracting Center business intelligence unit for Federal Supply Codes and Product Service Codes, and ready-made prospective sheets for the company. The end goal is for the tool to minimize manual entry and provide users current information.

The citizen developer is an Air Force contracting officer currently participating as an Education and Industry fellow as her full-time position. She built the MVP on her own time on weekends after completing her training. The short time-frame from idea to MVP demonstrates how quickly a citizen developer can develop a solution that improves their productivity.

10 Dec – Of the citizen developers volunteering their time and efforts, one has accelerated the development timeline and delivered a prototype. War Skills and Military Studies instructors need a more efficient and reliable way to schedule a complex class coverage. The current process makes a team of instructors unavailable for teaching while they manually build the schedule. That draft schedule is visually compared to each instructor’s leave schedule and the class schedule. If a mistake or unforeseen change occurs, the team has to rush to make updates and disseminate the new schedule to the instructors as quickly as possible. 

The use case involves a scheduling application that allows a single user to easily add classes, instructors, and locations as well as de-conflict instructors with scheduled leave. With the push of a button, the system will process the information and assign instructors to classes. Instructors won’t be scheduled if they’re on leave, nor scheduled to teach two classes at the same time. The system accounts for travel time between class locations. The application quickly produces an equitable schedule and allows the Scheduling Office the ability to easily and quickly make changes and disseminate an updated schedule within minutes instead of days.

That is the power of Low Code/No Code that The Other Airmen experiment is assessing for wider adoption. Citizen Developers know their pain points. Given the tools to develop their own solutions, DoD personnel can quickly improve unit efficiency.

11 Nov – Personnel responsible for member training requirements need a better way to track training data to reduce overhead and create a comprehensive picture of a unit’s ability to support the mission. Currently, commander support staff, unit training managers, and unit deployment managers have to sift through information from an array of sources including ADLS, TBA, IMDS, the Army’s DTMS, and various spreadsheets to piece together an accurate report. Users deserve a more efficient way to track training than cross-referencing 10 different systems to extract required data and manually input the information into a spreadsheet.

Several citizen developers are working on training tracker prototypes to streamline the current tedious process.  An automated process will reduce the amount of time spent manually entering data, improve accuracy, and allow Airmen to focus their time and effort on other unit priorities.

The Other Airmen: Low/No Code Milestone Two

Citizen Developers participating in The Other Airmen low/no code experiment made excellent progress towards functioning minimum viable products (MVP) in December. While the second in-progress review (IPR) in December had three demos, the third IPR doubled that with six demos. 

The big rocks for the developers in December were clearing up lingering AFNet connection issues, expanding what capabilities they had available to them, and discovering APIs for data connectivity between their new applications and existing databases. The most successful capability demonstrated during the 12 January IPR was the seamless integration of DocuSign into an application for document package routing and signing. Other capabilities the developers are incorporating in their solutions include automatic account creation through CAC card registration and ranking data by confidence level. The breadth of use cases under development demonstrates the promise these platforms may hold for Airmen across the enterprise.

Several Citizen Developers are working on their solutions from home because of connection issues through AFNet. The ability to work on a solution from any location is important. We need to equip Airmen to work at their home station, while TDY, or even on deployment as long as they have an internet connection. We anticipate the barriers of going through AFNet will subside if low/no code is adopted as an enterprise approach for solution development.

As the teams pass the half-way mark of the experiment’s scheduled timespan, they transition from planning into development mode. The more mature solutions are now moving from “get it working” to “how can it be better” with more automation, a stronger user interface, or a broader range of database connectivity. The low/no code platforms and the Citizen Developers are exceeding expectations as they code future capabilities for their units.