Questions for this Week

Can we fully confirm/debunk our hypotheses from last week that required more feedback?

For the forms that were confirmed useful – are we able to take the steps necessary to actually pull that data from its source?

What will our first deployment test look like?

Who will help us deploy the program?

What other opportunities exist to deploy this program in other units?

What We are Testing

• Beneficiaries see value in being able to see informal problem statements to which comments, updates, and trip reports could be attached. Our program can collect this data.
• Beneficiaries wish to share informal information sources such as news articles. Our program can collect this data.
• Beneficiaries want email notifications for Requests for Orders. Our program can collect this data.
• Beneficiaries want to look up O&M Log Form purchases to identify potential procurement problems. Our program can collect this data.

Key Insights

From a product standpoint, much of this week was about ensuring the technical viability of the functions we’ve discussed up to this point and further confirming the value of collecting certain kinds of data with different beneficiaries. The trouble with collecting trip reports is well established and it seems AARs and SITREPs will require a similar system to collect, so we will know for sure if we are gathering those appropriately once we do a live test. O&M Logs and Travel Vouchers will be easy to collect and can be tied to system reminders to submit things like trip reports and AARs. RFOs are also easy to collect and the form could even be modified so that we can easily identify which trips apply to tech scouting.

From a deployment standpoint, we spoke with signal squadron about exactly how the process would work. They would first deploy it in a test environment with test users to understand the configurations and in the meantime set up a Change Advisory Board to determine the configuration for actual deployment. Due to the complexity of configurations on government systems, it’s unclear exactly how long such a process would take.

From a partnership standpoint, we spoke with a representative from Decisive Analytics, who saw the immediate value in our data gathering system working in tandem with their data processing system. We also opened up the prospect of speaking to other firms in the tech scouting world through our AFWERX contact. While such talks are preliminary, it appears that our concept is capable of stirring interest outside the context of our problem sponsor.

Interviews (10/102)

Brian – Signal Squadron

• Believes squadrons should be able to state or describe their problems in AARs.
• Sees value in CDD being able to look at all AARs and see how many people are complaining about the same capability gap. [noteworthy – he is the first person outside CDD to say this]
• Hopes that the program will enable a back and forth between groups that doesn’t require a ton of additional meetings or sifting through paperwork.

MAJ Tony – AFWERX

• Proposed connecting us with companies working in the tech scouting/tech adoption space that are not as sophisticated in the execution of software development.
• Acknowledged that security clearances could be a challenge. Did not think we could just get them on the possibility of the program being successful.
• Suggested that the best way forward is to make the MVP for unclassified activities. If our MVP is successful in an unclassified environment and could be useful for classified information, that can “prove” your need for clearance to take the project to the next level.

SGM Angel – CDD – Future Concepts

• Holds the general belief that squadrons should handle scouting for emerging tech that is currently available in industry.
• Was surprised to hear that some squadrons believed CDD should handle those kinds of activities. [worth noting that we did not use Angel’s distinction of tech that is currently available on the market when talking to squadrons]
• Thinks preferences may be personality dependent. But hopefully the unit reorganization will manage the difference in personalities – the Squadron rep and CDD rep will be side by side making decisions on who should go where under what circumstances.

Brian – Signal Squadron – Network Operations

• Trip reports are out there but not in one place that’s easy to find.
• RFO forms can be pulled. Will include dates, may be vague on trip details. We are trying to implement the use of a code to classify the kind of trip. Two categories in particular pertain to the tech scouting element. O&M log forms could also be pulled pretty easily.
• Travel Vouchers, AARs, and SITREPs are out there as well and we can get to them, but we kind of have to know what we’re looking for. Won’t just be able to pull from one place.
• We already have a database of vendors you can pull from as well.

MSG Dave – H/A Squadrons

• Does not believe CDD reorganization plan will solve the unit’s problems.
• Current job is to locate with A squadron to report their needs back to H squadron, and even though he’s there it’s a challenge to get in tune with what they are doing.
• Suspects that problem would repeat itself between CDD and the specialty squadrons.

MSG Joe – CDD – C4I

• Thinks challenges associated with RFO could be fixed with a vendor field and knows they already have the database.
• Sees our program, the Decisive Analytics program, and a new project management database for CDD as “the trifecta.”
• Eventually, you might be able to pull some of the data you need from that PM database.

Josh – Amazon R&D

• Works upstream from development teams.
• Amazon is highly decentralized – this comes with some inefficiencies but it could be more costly to take too much time thinking about a centraliezd policy.
• That said, his role is to risk assess a wide range of projects, then send the appropriately derisked ones down to R&D.
• Believes he is generally up to speed with the teams but the effort is active and informal. Holds tech “speed dating” meetings twice a year.

SGM Katie – CDD – Tech Targeting

• RFO descriptions are generally vague and not particularly informative.
• Does not think this is on purpose and could probably be changed to an extent, but unsure they could affect all elements in the building.
• Inevitably there will be some blind spots on the description itself, but knowledge of the trip itself and some of the other details on the form can be valuable.

Mark – Decisive Analytics

• Already worked with several other DoD agencies, achieved necessary clearances.
• Liked the idea of bouncing some of the data we would collect, particularly trip reports, off web services.
• Suggested there were other ways of working together if this particular project did not work out.

Chris – Signal Squadron – Network Operations

• To deploy a piece of software like yours, we would have a team of engineers deploy it in a test environment first to figure out configurations.
• Then we can bring in users to test it, push it through the Change Advisory Board (implementation) process while that is happening.
• Government networks have a lot of configuration, CAB is just there to make sure it all happens functionally.
• Should be workable to allow access based on roles within unit and clearances.

Hypotheses Confirmed/Debunked

• Confirmed: Beneficiaries see value in being able to see informal problem statements to which comments, updates, and trip reports could be attached. Interviewees have consistently expressed interest in being able to see problem statements. Partially confirmed: Our program can collect this data. Beneficiaries suggested such data could be pulled from the After Action Report process, though these forms suffer from the same inconsistency challenges of trip reports.
• Partially Confirmed: Beneficiaries wish to share informal information sources such as news articles. Beneficiaries do not consistently express interest in this but some are highly interested. Partially Confirmed: Our program can collect this data. It could be challenging for our program to incorporate this kind of information by itself but Decisive Analytics seems to have a better handle on the elements that make this data challenging to collect. As such, it’s more within the realm of possibility.
• Debunked: Beneficiaries want email notifications for Requests for Orders. There are certain kinds of info on RFOs that could be valuable and help to make building out trip reports more easy. As such, beneficiaries see them as helpful within the system. However, they do not want to look at them directly as they’re not informative enough on their own. Confirmed: Our program can collect this data. Not only are RFOs readily available for collection, we could slightly alter the existing form to easily categorize trips relevant to our system and set up reminders to submit trip reports.
• Debunked: Beneficiaries want to look up O&M Log Form purchases to identify potential procurement problems. Beneficiaries again identified some information on the forms that could be useful, but would not want to look them up directly. Confirmed: Our program can collect this data. The database itself is readily available. If the information on the forms were to be configured appropriately it could yield some helpful information. However, given the general lack of enthusiasm it is low priority.

Questions for Next Week

What would a test run of the program look like outside USASOC?

Who among our existing contacts can help us with another kind of test run?

What does USASOC need from us to have a more complete timeline on deployment?

To what extent will we need to be involved with USASOC once we reach the deployment stage?