Home » Uncategorized » Team 2 Week 10 Blog

Team 2 Week 10 Blog

Team 2 Week 10 Blog

 

This week our beneficiary discovery revolved around continued testing on users stemming from a more developed, more usable prototype. We also began talking to folks in the technology sector of the battalion and private sector who could help us understand the building and roll out of our program.

 

Key Takeaways

  • We will be creating a web-app. This will likely cost in the thousands unless we are able to learn how to do it completely autonomously (unlikely). Major Schubert has suggested we speak with the applied physics lab at Hopkins. We are considering options.
  • The prototype is well developed. With a few added capabilities, we are getting to the point where ODAs are excited and ready to try it out.
  • If our product is valued at under $250k, it will be able to be acquired fairly quickly using group level funds.

 

  1. Cpt. Mike D
  • Having multiple data points for each training in the shopping cart is confusing and unnecessary
  • Love the cost estimate worksheet editor
  • For next prototype, it would be useful to have a CO/XO display screen where they could see what this program would provide for them. Hopefully battalion wide aggregated data.

 

  1. Cpt. Kyle
  • program should export to complete the METL crosswalk
  • program will be helpful in constructing semi annual training brief, if we could focus on that it would be great
  • Program must export to long range training calendar, this will make ODA commanders willing to use it and could actually be a selling point.

 

  1. Eric, Duke OIT
  • Sites are hosted through a Duke server. There are some restrictions if anything is Duke-branded.
  • Building sites through a private contractor typically cost in the thousands.
  • Sites@Duke is a service to look at

 

  1. Ryan, Web Developer
  • Dropdowns (using existing data rather than searching for patterns) will be a lot easier to make.
  • Figure out where the code itself will be hosted—military? Duke? If it’s at Duke, make sure that it is compatible with their app development language.
  • This would be pretty quick for me to write—maybe a week or two. For a private firm, that would be around $7,000, but if you use Duke’s staff programmers, it is likely to be much more affordable.

 

  1. Bobby, Firefighter EMT
  • The issue most people have is that what the national EMT registry and what county certifiers will accept don’t always match.
  • There will really only be one database parameter: The national registry of EMTs or Paramedics
  • If the “big boys”– the counties, national registry, etc. were able to streamline using this tool, it would benefit the EMTs.

 

  1. SFC Gumpert
  • SFC Gumpert has not been part of any of the interviews to date or part of the design session held at Bragg about a month ago.  The most recent video did not paint a full picture for a neophyte to our product concept.
  • In discussing the wider vision for the product – specifically the team profile, he thought some people might be concerned about having their info on another database.
  • He has a great framework for differentiating skills practice from the ability to best choose and deploy skills in real-world situations. The ideas are powerful but we struggled to figure out how to translate them to an implementation that could be objectively measured.

 

  1. Tim Betts
  • Confirmed the envisioned functionality requires a robust database. Therefore a non-SaaS product – a product Special Forces could administer themselves – would at the least require they have the hard and soft infrastructure to administer some form of database server.
  • Confirmed that the data structure required access to properly scrubbed real world data to ensure proper database design and sufficient QA testing.
  • Confirmed that we could certainly design a system the Special Forces teams could input the data into and create the interrelationships. However, then the testing burden falls to them.
  • Basically, end result is that the best user experience is almost certainly a turnkey SaaS system. And whether we deliver a turnkey SaaS system or an on-premise system they customize themselves, there is going to need to be a dedicated team that possess expert database and programming skills as well as security clearance.

 

  1. Captain Mike T – Procurement 1st SFC
  • At the unit level below 250k can buy at unit level – with dollars that can reside at the group level or operations or maintenance. Takes roughly a month and strongly suggested

 

  • Factors influencing whether SFC will buy
    • Requirement for the capability(needs to be validated by a general officer
    • ROI(if you can save x time, time is one of the most precious resources in military, free them to do more training instead of planning)
    • What applications in the deployed environment(how does this help ODA fight bad guys)

 

Suggested Procurement Process(right now is fairly on track)
– Deal with Major Schubert one of the senior managers in the battalion
– Get buy in from Ryan(controls resourcing for the department)
– Get buy in from S4 and comptroller(part of demonstration of saving resources)
– Buy in from ODA leaders
– Let Ryan progress and we support
– Get support from group commander and make sure he has money left in the budget

 

  1. Major Ryan
  • Applied physics lab at Johns Hopkins can help us see the project to completion IF we want to pursue that path
  • Ryan was very impressed with the new prototype we were able to show him which was a more interactive training card that teams could use.
  • Looks like much of our program can be implemented through NIPR, making it much easier to acquire and for us to maintain.
  • Scheduled site visit for next Wednesday

Leave a comment

Your email address will not be published. Required fields are marked *