Workflows — Fighting Yesterday’s War

See the source image

In 2012 I did a job for the U.S. Navy. I was invited to a site walk to upgrade what they called their “Adaptive Planning rooms.” These were the rooms the Navy would use to model potential operations. One team would use the first room and assume the role of the protagonists (us) and the other would take the role of the antagonists.

The RFP asked for some flat panel displays with third-party interactive frames (this was 2012, remember), interactive projectors and whiteboards. It also called for any infrastructure and distribution equipment needed to make the system functional. In other words, it was fairly vague/open.

During the site walk, I asked a few questions, but none pointed enough to give away my full thought process. After the scheduled time was over, the other salespeople left, apparently satisfied with the spreadsheet of part numbers they were given to fill out pricing against.

I politely asked the captain if he had a few additional moments. We sat and discussed what actually happened in the room each week. He shared that each week the teams would get together to formulate plans. They would break out into teams based on type of fleet, submarines, commercial shipping and other facts to come up with their plans, identifying seaways used and paths of approach.

After that, the teams would all gather together, present their ideas and create a common operational picture (COP) involving all the parts and pieces. An admiral would be invited to a briefing to discuss the plan.

This is where the captain said something I’ll always remember: About fives minutes into our presentation, the admiral will usually tell us that we can’t use that sea lane because country X has a treaty with country Y, and then we have to scrap the whole PowerPoint, break out the hard copy maps using erasers for the boats and plan the whole thing out live like we did in WWII. We don’t want to fight like we did in WWII.”

And here is where the real reason for upgrading the rooms lay. They needed a way for teams to come up with individual plans, a way to share those individual plans with the other groups, a way to combine those plans into a common picture and a way to be able to adjust and modify those plans live while presenting to the admiral based on any new, changing or unknown data.

I designed a system that could do this to the best of its ability, and we won the job and implemented the systems.

It consisted of four interactive flat panels in the four quadrants of the room so each team could do their breakouts. Then, through VGA switching, each team would share their plan to a larger interactive smart board and projector on the left side of the room. While they presented, the captain would add elements of their plan to the COP on the right smartboard, adjusting as each team added new data. (I’ve obviously simplified things for the purposes of the blog, but you get the idea).

See related  A Cautionary Tale About Software

When the admiral arrived, the captain would relay the COP on the SmartBoard using animation and recording features. When given new data, he could remove animations or elements of the plan on the fly, replay and record the new movements, and then save the plan at the end of the meeting. It was a step up from the old process, and it did NOT require creating a new workflow. There was, however, a gap. That gap was in the software capabilities, though, not the hardware.

If you think about the workflow and opportunities to make it more efficient, most of the improvements needed were in reducing rework and redundancy. Take, for instance, the team plans. Each team was doing a plan independently on separate digital maps, and those plans had to be manually combined. What if there was software that allowed each team to create their plan as a layer in the same program, allowing all the layers to be saved on the same file and made visible as the team presented, much like the electrical and RCP layers of a CAD file for construction?

Or perhaps think about the elements used. A ship icon may be used to represent a destroyer, and an aircraft carrier and circle could be placed around it to show the range of its weapons systems. However, those elements were not dynamic. If you zoomed in or out, the ships and circles stayed the same size. What if there was software that could scale that circle dynamically, showing the effective range to scale when you zoomed in and out of portions of the map?

These were all things that unfortunately weren’t able to be implemented at the time, and not because they needed to change their workflow or because the hardware wasn’t there yet. It was because the software being used fell short. Now fast forward to today and shift your attention from my military application to a collaborative meeting.

How many times are we asking clients to adopt new workflows to meet the capabilities of our systems? How many gaps are there in the capabilities of a system’s software to meet the existing workflow? How many different platforms are companies using to accomplish one task, like switching from a Zoom call to Base Camp to a Slack Channel for instance?

If you really dig in, you’ll see that many of the tools are made for yesterday’s paradigm, but companies shouldn’t be investing money in fighting yesterday’s war. And in those gaps lies a huge opportunity to add value and innovate.

Stay tuned for the next blog and we’ll discuss some existing tools that may get us closer.