Home » Articles posted by James McMahon (Page 2)

Author Archives: James McMahon

Team 7 Progress Report – Week 1

Customer Interviews (11/21)


SGM Angel – Future Concepts

  • Combat Development Directorate divided into traditional acquisitions and emergent technologies.
  • Traditional acquisition units considered to have healthy acquisition process while emergent tech units struggle.
  • R&D leaders don’t necessarily want us to come to them with a list of vendors, which they might perceive as interfering with their process.


SGM Brian – R&D Section Leader – “Specialized Capabilities”

  • Noted that not all units would value a collaborative tool equally. Considers himself specialized enough that he doesn’t overlap much with anyone else.
  • Even so, it would be nice to see if anyone visited a vendor that he plans on talking to.
  • We have a process for allowing vendors to submit information over a classified network, so garnering some kind of vendor participation isn’t an impossible prospect.
  • When using trip reports on his own team, he would look for the following information: Quotes, Official Messaging, Meeting Notes, Briefing Materials, Technical Data Package, Test Reports, Significant Emails, Overall Capability Wishlist.


MSG Darrell – R&D Section Leader – Autonomous/Swarm Vehicles

  • There is a core group at the lower level that’s tech savvy and tracking what’s going on with the industry. Problems occur sometimes when we assign individuals who may not be best suited to the role to essentially go out and headhunt, and they may not fully understand the capabilities.
  • Being able to track some of our engagements would help mitigate this problem – our “highly motivated introverts” can see what is being sent back and evaluate.
  • However, there is a natural competitive nature here, and people want to solve the problem on their own. Not everyone sees the benefit of sharing, some may even see it as a detriment.
  • Would find it useful to be able to look up what’s available by vendor and who has contacted a given vendor. Sees a lot of potential problems with including points of contact on such a page.


CIV John – RTI – Former Command Science Advisor to USASOC

  • The real problem we have, (which we learned from Joe would be illegal at a vendor level but still causes problems on an interagency level) is that an agency like DARPA will talk to one person at Special Ops who requests a particular technology, which we can’t actually afford and which he doesn’t actually have the authority to request.
  • We developed the requirements process to discipline that, and the Science and Tech Components Council was meant to alleviate that. We would conduct field tests on 40-50 techs to show off capabilities and provide feedback to developers.
  • Our assessments provided a sort of visualized rating that could be quickly digested and give a rough glimpse of a tech’s performance.
  • The agency as a whole needs a more unified view of the process.
  • No database cuts across classified and unclassified networks.


MSG Matt – C4I Commodity Area SME – Comms and Data Management Systems

  • It would help to be able to see what a particular person I know to be working on a given problem has done.
  • There are three official types of paperwork you might need to file when engaging with a vendor: Request for Orders, travel vouchers, or Visitor Request Process. These essentially let the unit know what you’re doing and allow the unit to reimburse you for travel.
  • The trip report memorandum is essentially a follow up to this process and isn’t required for anything. As a result they rarely get done.


MSG Joe – C4I Commodity Area SME – Intel and Data Management Systems

  • We manage all of our projects in a portfolio but we sometimes look at capabilities not necessarily in our portfolio.
  • Our goal is to catalogue and earmark capabilities even if we’re not directly working on it.
  • We really need a basic categorization of our capabilities in order to better track how we our meeting our requirements.


MSG Tony – C4I Commodity Area SME – Specialized Comms Systems

  • I would love to be able to apply keywords to vendors to increase the likelihood that someone interested in my highly specialized techs could find it in a search.
  • I also want to avoid piling on a vendor – we can wear them out if a bunch of us visit for the same thing.
  • If I could save 2 hours of market research by checking a database, I would consider that a valuable result. None of us have enough hours in the day.


MAJ Mike – Commander Action Group Director – Special Air Operations in support of Joint Special Operations Command

  • When I’m preparing to meet a vendor I have two major questions: Has there been a previous contact from my or a related military organization and if so, what was discussed and what do you recommend for action?
  • At my level I would love to have a more sophisticated way of tracking vendors, almost like the way we map terrorist organizations.
  • The only way we can really disseminate info now is socially in things like staff meetings or point to point contacts.


MSG Paul – Technical SME – Well rounded SME supporting multiple units

  • Two things I’d like to be able to do: quickly know what our guys think of a vendor, and whether we can combine efforts into a single trip to a vendor.
  • Do NOT allow anyone to access vendor contacts. First, we don’t want just anyone calling these vendors all the time. Second, people guard their contacts jealously and this could make them reluctant to use the system.
  • Another problem that’s harder to solve is what to do when people are rotating out of their positions every 3 or so years? How is their replacement going to know who to talk to? How does the guy leaving know what information will be most important to leave behind?
  • Historical trip reports aren’t a direct help, more useful as a catalogue of who has visted who over time.
  • If it takes more than 10 seconds to understand, don’t bother.


LTC Phil – DARPA Program Manager

  • DARPA Program Managers have a lot more independent authority, nobody is really there long enough to overlap or know each other.
  • We use Trelo to track ongoing tasks.
  • It would be helpful to find ways to collaborate, but we are also concerned about the integrity of our own projects.


MSG Ryan – R&D Section Leader – Unmanned UAS

  • It’s relatively new for us to actively store trip data. I keep a personal stockpile of trips relevant to me but don’t put it anywhere central.
  • When hardware is tested, the testers produce “After Action Reviews,” which may contain more direct performance data than a trip report. However, these also come back to me and I have to hold on to them.
  • I personally believe we need to make more use of AARs in particular so we can actually learn from our mistakes.


Hypotheses Supported


People within CDD and R&D sections would like to know who has visited a vendor they are researching.  Not everyone expressed equal levels of excitement about this, but almost universally people agreed that if such a list were easy to access it would be worth checking to see if they can make any useful contacts within the organization.


People within CDD and R&D sections would like to know who plans to go on a trip. This appears to be more important to R&D section leaders, who might be able to save time visiting a vendor if someone else already has a trip planned or perhaps identify areas of operational overlap.


Hypotheses Debunked


People within CDD and R&D want to know about points of contact at a given vendor. This idea was almost universally discouraged, noting potential issues of vendor fatigue and an existing culture of guarding contacts. Such an inclusion could diminish use of a solution.

People within CDD and R&D want to know what is in the trip reports. Our interviews have forced us to reconsider the importance of trip reports to the majority of people who might use a potential solution. While some individuals are highly interested in using trip reports to coordinate research efforts, many just want to know who to speak with about a given project.


The process revolves around trips. Following a lengthy conversation with our sponsor, we had to revise one of our core assumptions: that our main point of focus was getting people to more actively share the details of these trips. Trips are only one component of the larger deployment process, and the way R&D Section Leaders approaches trips directly impacts the way CDD employees plan each year’s budget. Our future lines of questioning will need to dig into this relationship more.


Questions for this week:

  1. How does the relationship between R&D Leaders and Commodity Area specialists affect which technologies are deployed?
  2. What types of miscommunications occur between R&D sections and Commodity Area units?
  3. Do R&D section leaders believe that communicating with CDD will increase the likelihood that their techs are deployed?