Interviews (10/52)

MSG Edward – Network Operations

• Available databases include: rudimentary Request for Orders forms, inventory management, CDD purchases (buy try and procurements), O&M purchases.
• Every penny of government money has a receipt. There is a document somewhere proving someone spent that money.
• O&M Log Form request goes into a database as soon as you start the process, before it is approved. Currently housed in Microsoft CRM but working on a way to integrate with financial system.

Cory – Deputy Dispersing Officer – Finance Office

• How travel works once RFO is filed: First, organization signs off on travel. Second, comptrollers assign account lines to rfo order with an estimated $ amount for trip. Third, HR creates the document (1610 form) of what you’re allowed to do/where you’re going. Many people don’t take those orders with them.
• You go to the location, do your thing, come back, use your 1610 voucher to fill out a 1351-2 voucher. That includes itinerary. Someone reviews and validates that, then it comes to finance office with your receipts and your orders.
• Plugged into system that automatically tabulates how much you are owed for the trip.
• Information shared on RFOs and 1351-2s do not necessarily include all info about trip.

Ed – Network Operations – Travel Voucher Portal

• Process handled on system called IATS. The owners will not share data necessary for integration and they can’t get another program due to red tape and cost.
• IATS is also a standalone server in the building, part of a system used throughout DoD. It can communicate with DFAS but will be hard to connect with otherwise.
• Unclear whether the primary obstacle is DFAS unwillingness to share or lack of cooperation from vendor. However, IATS was apparently an off the shelf solution (fascinating in its own right) and we suspect that this could be causing complications with current attempts at customization.

Tim – Higher Echelon

• Salesforce intent on building high level reports from data aggregates.
• Focus on capabilities rather than value provided.
• Strategic focus suggests that an entirely off the shelf solution isn’t feasible.

Natalya – Salesforce – Developer

• Uncertain how long it would take to integrate Salesforce UI into USASOC networks.
• Uncertain which data sources Salesforce would use to generate reports.

Sean – Salesforce

• Demoed potential product for us.
• Emphasized ability to track money spent with a vendor over time – unclear whether it could distinguish funding streams without additional input
• Lots of features packed into a sales oriented interface. Lots of little potential solutions that can be overwhelming when taken in all at once.

MSG Joe – C4I – Commodity Area SME

• Highly invested in finding a more efficient way to track projects – the time he spends trying to find people is time he could be spending looking into the tech.
• Insists that despite the idiosyncrasies between different teams, the core organizational workflows are well defined.
• Strong believer in leveraging existing data flows, as opposed to requiring new forms of data entry.

Gabe – Squadron Ops – Built an Engagement Tracker

• Confirmed interest in tracking “RDT&E-like activities” and that it would aid in the deployment process.
• Engagement tracker worked initially but fell out of use as people left.
• Believes there were three key problems with the program: maintaining awareness of its existence, the presence of a learning curve to use it, and the inability to turn it into an institutional behavior rather than personality reliant.
• That’s the main problem, we sometimes get the right personalities to deal with this stuff on a human level but no good institutional method.
• Noted that there was also a compartmentalized list of people who could see, use the program.

COL Mike – CDD Director

• Noted something that everyone has to do when they’re filling out a requirement – justify that there are no comparable solutions currently out there. It takes effort to do it right, most people just call a contact or two. But if they could make an effective case easily they probably would.
• Greater challenge than tracking vendors is which agencies are actively contracting with them. From my position I want to know if DARPA is working on the same thing as me. Some vendors are unscrupulous and will charge 3 different agencies for the same product without telling them what the other is doing, this at least gives us some leverage.
• Unfortunately, particularly with R&D, there isn’t a ton of incentive to share the program. R&D folks aren’t rewarded based on deployment and worry their funding will get cut if they are found to be redundant.
• If I want to see what industry is doing I can look up BAAs or SBIR initiatives and see who responded. It is much harder to find out who talked to a given company even though that data is publicly available.
• We have tried a number of CRM solutions to solve the issue of communication within the unit but it’s hard to get buy in. Would probably be more helpful to scrape that stuff automatically even if it’s not perfect.
• Sometimes people will misrepresent what they’re doing on an RFO because they don’t want you to know who they’re talking to. However, most people are just lazy.
• Everyone has to contact the vendor at some point if they’re gonna work with them, and probably file a request to visit, bring them on base, or even talk on the phone. There is some record of it at some point, even if it’s just an email in someone’s inbox.

SGM Rob – CDD

• Better clarified why informal knowledge of potential procurements would help – the budget is planned by the start of the fiscal year and anyone who comes in with new requirements after that screws up the process.
• Even worse, sometimes the way they develop the project with vendors means we have no choice but to find more money.
• The types of purchases that go through O&M aren’t necessarily the biggest threat to fly under the radar in this regard. We have some ways of tracking activity that involves an O&M request. Sometimes R&D-like guys get free samples that don’t require any kind of O&M form and decide they want to buy it, realize that they can’t do it with a log request and then take it up to procurement way later than they should have.
• We literally wouldn’t mind if people came and talked to us before they even started on a project, but there’s no forcing mechanism to get people to give us a heads up as early as possible.

Hypotheses Confirmed/Debunked

Debunked: “There is no mandatory, standardized, centrally deposited form outside of the requirements process that could indicate a future requirement.” While we brainstormed ways that less uniform methods of reporting such as trip reports and AARs could be leveraged to better track projects, we worried that we did not have a great way to account for the ‘failure to report’ problem due to the existing culture around these nonmandatory reports. A few beneficiaries at our base meeting and MSG Edward confirmed that all O&M purchases have a paper trail that starts prior to the release of funding. Properly tracking O&M expenditures to better predict potential procurements presents its own set of challenges but also an opportunity we didn’t previously think we had. We also had our original impression of RFOs challenged by Rob, who said 99.9% of the time they’ll get filled out before a trip happens.

Debunked: “All data at USASOC is readily accessible if you know where to look.” Database accessibility can depend on which networks it exists on and if it feeds back to another agency such as DFAS. It could get more difficult if we need to be able to interface with those systems at all.

Confirmed: “Most CDD budget experts can use informal knowledge of a project to appropriately plan its funding.” The real challenge comes after the budget is set because the money everyone is aware of has already been spent.

Confirmed (CDD side): “CDD budget experts believe that knowing about a project in advance will speed up the deployment process.” If a project gets reported early enough and doesn’t get funded, it’s probably not that high of a priority. So for CDD it clearly speeds the process up. Less clear is whether the time difference is meaningful to anyone outside CDD. COL Mike added that it increases the likelihood that someone at CDD can find a source of funding at another agency as well.

Somewhat confirmed: “This advance knowledge is valuable enough that CDD budget experts would seek it out if it were readily available.” It is clear from our conversations that people at CDD will go to great lengths to find this knowledge. However, that willingness does not seem to translate to a collective effort to get this information onto one of the many solutions they have tried. It seems something is blocking them from getting scaled across CDD.

Next Week:

– Do R&D cell leaders believe that CDD having advance knowledge of their projects will lead to faster deployment?

– If R&D cell leaders believed that providing CDD advance notice of projects would improve their deployment timeline, why don’t they always do it?

– Do R&D leaders associate any risks with sharing information about their project early in the process?

– If R&D leaders could be convinced that early reporting would speed up the CDD timeline, would they see value in that?

What level of detail is mandatory on RFOs? What data can’t consistently be collected from that form?