Scheduling training for C-17 Globemaster III pilots and crew is about to get easier with the launch of Puckboard, a data-powered software application to plan aircrew qualification flights automatically. The tool, developed by and for Airmen, allows schedulers to rapidly match aircraft commanders, pilots, and loadmasters with available flights to complete currency requirements such as aerial refueling and tactical training events required throughout the year.
The digital interface, which will start using live data on March 20th, enables planners to visualize flight schedules and generates recommended schedules for each crew member while taking into consideration required qualifications, crew rest, and conflicting events.
Previously, the process required Airmen to shuffle ‘pucks’ around a whiteboard to determine the best match manually – often taking a 10-20 person operations team several days to produce a viable plan for the week, with changes frequently required at the last minute. With Puckboard, events are automatically populated in a matter of seconds, allowing planners to dedicate additional time to developing more individualized and dynamic training for each crew member.
That was from an Air Force article, “Scheduling training is about to get easier for C-17 crews.” The Air Force in-house software team doing the work is TRON out of Pacific Air Forces (PACAF) in Hawaii. TRON is an operations center under the BESPIN software factory, and they are taking a cue from Kessel Run which created a similar custom-built scheduling tool but for KC-135 tankers instead of C-17s. The Defense Innovation Unit has also been supporting a scheduling tool for the MV-22.
The fact that each of these legacy aircraft systems requires a completely different custom scheduling tool — that had been done primarily by hand in the past — demonstrates how defense programs are truly siloed. You would think that 60 years of enforced “jointness” from central direction would have created a set of programs that interoperate and have similar functionality. Instead, each system was built uniquely and even if it was from the same contractor couldn’t communicate with one another.
It would appear that the first step for Software Factories and other agile developing teams in the services is to first automate the ridiculous manual processes that is wasting human capital from each and every legacy system. That should free up funding and personnel time to go after more requirements that can be turned into software, creating a virtuous cycle that frees up talent and frees up budget to go do 21st century things — like building software-native networks and platforms which can take advantage of connectivity, AI, continuous updates, and so forth.
Leave a Reply