In the knowledge that at some point in the first months we would be granted a short trip to a NASA base, we began preparatory contextual inquiries aimed at refining our understanding so as to make the best possible use of this limited window of opportunity. Chosen for their relevance to either of our foci of handhelds or problem reporting, our preparatory CIs were accessed through our own local networks of contacts.
Phase two of our contextual inquiries occurred during a visit to Kennedy Space Center. They were central to our understanding of NASA problem reporting and resolution. All prior literature reviews and early CIs were aimed at properly preparing for this event, and the consolidated KSC data was mined and exploited for the remainder of the project.
We interviewed at five different locations at KSC, including participants from three major NASA contractors as well as NASA civil servants.
Below are some key points from a few of our contexual inquiries.
We analyzed the activity involved in using a reporting book in a fixed location to enter all information about problems and problem resolution. Problems during evening shift hours are often passed on to morning shift engineers through these notations. The staff had moved to this method from a decentralized practice involving clipboards some time ago. This location of problem reporting, to which a person must return before filing a report, we came to call the "base station." The balance between centralized and decentralized problem reporting would go on to become an important theme of the project.
Our major insights from this CI came from an artifact walkthrough that communicated the general design requirements of a portable handheld built to allow reporting to a centralized database even in extreme environments.
The parcel delivery inquiry was focused primarily on the context of use of the postal service worker handheld device, specifically designed for their routine needs, catering to all possibilities of breakdowns, and providing two-way communication between devices and other postal service employees, while maximizing efficiency of the work.
Our major insights from this CI came from an artifact walkthrough that communicated the general design requirements of a portable handheld built to allow reporting to a centralized database even in extreme environments.
The parcel delivery inquiry was focused primarily on the context of use of the postal service worker handheld device, specifically designed for their routine needs, catering to all possibilities of breakdowns, and providing two-way communication between devices and other postal service employees, while maximizing efficiency of the work.
We went on location with a local HVAC contractor at a job site and were able to do an analysis of the artifacts (e.g. multi-meter, proposal documents) and work context (e.g. residential and small commercial), as well as a walkthrough of the sequence of invoice creation and repair.
An interesting issue that we came across was the integration of existing devices with other devices and reference manuals. We determined that a great deal of time was lost in checking through technical manuals, a process that could be automated.
His problem reporting system was also of interest. He would first create a list of the problems to be fixed, submit it as an invoice for approval, and then would create a list of actions to correct the breakdowns in the heating and cooling system. The invoice of breakdowns and work list were related, but distinct, a pattern we later observed at NASA.
This depot, located in the main central area of KSC, is a high-quality machine shop specializing in custom parts that have never been made before and will never be made again, frequently for installation in the ISS modules. We received a demonstration of another of their creations, the new eWAD system, or Electronic Work Authorization Document system, an online work ordering system that replaced the older paper system.
The modules of the space station are carefully assembled in a staging area used by the technicians of several different nations. During these CIs, we were able to speak with managerial personnel as well as local technician leads. One local tech lead had built himself a problem reporting program with Visual Basic and used it to communicate problem reports to the local Quality, who would either bounce it back if it was incomplete or incorrect, or forward it on to Engineering. ISS employed a two-step process of problem reporting, wherein a nonconformance report is submitted to Quality, vetted, and then submitted as a PR.
We were also able to interview two Boeing engineers involved in the design of the ISS, one with a past as a technician. Although educational, this interview was not as valuable due to being out of the scope of their work, and also out of our scope, as the engineers were not our users. However, the basis for the engineer's role was ultimately useful information. We would eventually go on to create a handheld interface for engineers.
The massive VAB is the staging area where the space shuttle and booster rockets are hoisted onto the external fuel tank before being moved to the launch pad. Although the space shuttle was originally intended to be launched during our trip, the launch was cancelled and the shuttle was returned to the VAB due to hail damage to the external fuel tank. This allowed us to observe during a period of active problem resolution.
We first visited a Test Assembly Inspection Record (TAIR) station, the USA problem reporting system, which is entirely composed of paper, including a librarian. Here we learned that technicians write their reports on a computer, print them out, and file them in the TAIR library as paper; after the shuttle has launched, these are all scanned as minimally searchable images and placed in a database. As a result, problem reports are least accessible when they are most valuable, and the entire process is extremely slow.
After return from flight, shuttles experience a great deal of degradation, and require refit. USA's Orbital Processing Facility is a facility dedicated to total space shuttle overhaul. Here, every part of the space shuttle is checked and many parts replaced.
We encountered a variety of staff checking various parts of the shuttle, and had a particularly large amount of access to those technicians and quality personnel checking the replacement of heat shield tiles along the surface of the shuttle. The problems reported in this activity were different than those of the ISS; whereas ISS problems tend to involve custom components and unusual situations, damaged tile reports come in long series of duplicates, to the point where Quality staff copy and paste older reports, saving time, but risking that some field entries will not be changed from the older forms.
Before the consolidated models are shown, one final caveat should be noted. During these CIs we encountered users who would ultimately use our system, are the most accurate that currently exist, and are far better than any other users we could find elsewhere, but even these are not our true users.
