This position is a good example of what a lot of my employment experience has been: learning by reading and writing.  You can't write what you don't know.  You can't edit what you can't write.  So in order to write and edit the documentation for production and logistics, I had to learn a lot about production and logistics.  I asked many questions, and had some very patient people answer them for me.

   Boeing is building the SLS Core Stage.  Vehicle production was not an area I was familiar with prior to this position, but it turns our to have a very different focus from vehicle design.  Design can go anywhere, so long as the mission requirements are met.  Production has to take into account the tools needed to create and put together the pieces of the vehicle, the size of the facility in which the pieces are being built, how many pieces go together and how, if and when people have to get to them, what the pieces are made of, and how to transport those pieces for assembly.  It is a very different type of thinking, at the same time smaller in scope and more complicated in application than design.  You need to apply both a designer's perspective and the builders' perspective when planning.  Assembly must be planned more than a year in advance, including whether or not you will need to design and build new tools to do the work, and some of the metal stock and other types of materials may have to be ordered months or more in advance.  The choice of fabricators can also be limited by the level of manufacturing standard that's applied.  Tools, for instance, should have a less strict standard (industry best practices) than production parts (which will support manned spaceflight), but test parts may or may not need the same standards as production pieces.  The strictness of the production standard can increase cost and schedule significantly, so this is a decision that needs to be made early.

   The technical documentation I edited for Boeing Manufacturing, Assembly and Operations, Space Launch System Program, Core Stage (CS) included the technical requirements specifications for various tools that the manufacturing engineers were developing from the NASA requirements for the CS.  This included legal contract language as well as the more familiar design requirements.  They were developing a database that would better control how these were sent to the suppliers and when and where things got signed off, but some of the documents were still being written out.

   I moved over to work with the Logistics guys under Scott Juneac after the Core Stage Preliminary Design Review (PDR).  Management wanted a higher level of fidelity in the Logistics docs and we were working to clarify the process before the next review.  I worked through the Core Stage Logistics Support Plan to better detail what Boeing was going to supply for NASA, based on NASA's requirements in their own SLS Logistics Plan.  The NASA Logistics Plan was written at a top level and for a lot of it they were relying on the contractors to use industry best practices to handle logistics.  There was some discussion about how much to document, since the logistics best practices are pretty well known.  We ended up including more specific information for transportation, maintenance and support, packaging, handling, and shipping, among other data sets, in the last version of the document I supported.  I read through the Boeing and military standards for Logistics, as well as the systems engineering information on it, since I was studying for the CSEP at the time.  As with production, this was not an area I had more than peripheral knowledge of and it, too, encourages one to think well ahead when planning.  How items will be moved, whether there will be spares available for items that malfunction, and where such spares can be replaced and stored prior to replacement, for instance.  I was involved in several discussions on 'line replaceable units', whether they could actually be replaced without sending the vehicle from Kennedy Space Center (KSC) back to Michoud Assembly Facility, and what options had the greatest cost savings.  The order required was amazing, and very informative.  They were working to implement the PowerLOGj database (a military standard logistics database that NASA chose to use for SLS) for tracking the location and replaceability of every part on the core stage.  Logistics analysts had to write up install and replacement procedures for anything that could be replaced, from scratch, and enter it into the database, which also tracked how many of each object were on the core stage and where.

   During this time I also worked with some of the folks managed under Boeing Logistics but based out of Kennedy Space Center, who were doing spares tracking, developing the ground operations timeline and process for the vehicle once it reached KSC, the ground operations maintenance procedures (used prior to CS being integrated with the rest of the vehicle), and the launch commitment criteria for the core stage.  I reviewed, edited, and in some cases helped incorporate requests from the PDR comments that came in for various documents for this group.

   The technical performance and technical resource margins for the Ares I vehicle were particular sets of numerical padding the Chief Engineer wanted to keep an eye on.  This included the overall mass of the vehicle as well as the masses of the component parts (Upper Stage, Upper Stage Engine, etc.), the mass-to-orbit capability of the various engine iterations and combinations, stage separation clearances, stability, and the debris impact footprint (where we were going to drop the stages as they separated).  There were a few others, but those stayed fairly consistent.  We also had operations margins for which we tracked the Ares inputs, such as production schedule, launch interval (how many days there had to be between launches), stacking rates, and launch probability margins (how often were we likely to get conditions good for a launch given how often we could have a vehicle ready to go).

   My part in all this was tracking the information - I had to check with the various organizations within engineering, such as Guidance, Navigation and Control (GN&C), thermal analysis, and the orbital mechanics folks who worked the position equations, as well as the guys tracking the environments data (how often are there thunderstorms during which months in Florida) and the stages representatives who brought me the mass, energy usage, and separation data for first stage and upper stage.  I had to pull these bits into a readable format for the integration meetings with the Chief Engineer and the Constellation program folks.  The data was also summarized and included as part of the Margin Management Plan and Margin Management Reports.

   The energy usage was actually part of the technical resource margins, margins that were tracked because the vehicle had specific requirements for where those numbers needed to be.  They included a lot of basics, like structural, electrical, thermal, bandwidth, and memory usage - resources that had to be used very carefully because you start out with a limited amount and it only gets smaller by launch day.

   This was interesting for me because I got to watch the give and take of management.  Engineers are incredibly conservative - they want to leave themselves a lot of margin so they know they aren't risking their design.  Managers can't let them overdo this because its not just the structures guys adding margin...its the structures guys, the thermal guys, the mass folks, and the avionics designers.  If everybody adds enough margin to make themselves comfortable, the vehicle never gets off the ground.  The give and take in the discussions was fascinating, as was learning from the various groups how they calculate their margins so I could explain them if anyone asked.

   The Ares I Project was farther into its schedule than most of the rest of the Constellation Program.  This put us on the cutting edge of process development for all sorts of integration tasks that would later expand to the program level and other projects like Orion and the ground operations groups.  This task began while I was with the Design Analysis Working Group.  We were the data integrators for the engineering design analysis being done for Ares I, which meant we began to understand very quickly how much data there was going to be and the issues with making and keeping it accessible while tracking the versions.  I began learning what was required, systems engineering wise, for the data to be archived, how to limit who had access to update it, and still make it available to the fairly extensive group of users who needed to access it for their own analyses, both within the Ares I Project and across the Constellation Program.

   We set up a series of folders on ICE Windchill, the document management tool NASA was using for the Constellation Program and I was the project manager for the folder.  This meant I tracked permissions for both read and read/write access and which versions of the data was available at any given time during the design analysis cycle (DAC).  This setup was eventually expanded to include a folder for the review boards, which meant less actual time in the review boards and more up-to-date reporting of information, since it could be synced with the folder as it was available and the analysts didn't have to work up a presentation.  I also provided the training for the Windchill site.  During this time I also worked with the Constellation Program office to establish their integration data folder and processes.

   Later in the process a Data Architecture Working Group was established and I acted as the integration branch's representative and coordinator with them.  This made sure that the support folks understood how much and what kind of data was being developed by the engineers so that they could plan for archiving it.  Some of the data sets (such as the structural loads sets) were in the petaflop range - so large they had to delete a prior set before starting a new run.  We worked to find additional storage space and establish standards for which data sets you archive permanently and which ones could be deleted after a certain design milestone was reached.

   The Windchill folders were moved with me to the integration branch in one of the reorganizations, and were renamed the Ares Analysis Data Library.  I wrote a series of recommendations for these, including the data organization outline and the processes for access and storage.  Management of the library was eventually moved to another contractor, but I was reassigned to the task a year or so later.  By this time the library had added a logbook, to track what was included, when it had been uploaded, what data sets it referenced, and who the contact person was.  I reviewed, updated, and documented the logbook process requirements so that someone coming behind me would have an easier time with the task.

   The last updates I provided were the inclusion of an Ares V logbook and the setup of the folders for that project, and a preliminary review of data management processes for non-text data files, which usually require specific software to properly read.

   Ascent debris analysis was something of a latecomer to the design analysis plan for Ares I.  Given that the design of the vehicle called for the manned capsule to sit atop the rocket (as opposed to the side mount of the STS shuttle), the risk of damage from debris released from the vehicle during ascent was considered minimal, at least to the astronauts.  It was finally decided that there was still some risk to the rest of the vehicle and a hazard analysis should be done to assess and recommend mitigation as necessary.

   I was brought in to support this task after the first round of data analysis, which had been limited and proved inconclusive as to the risk but somewhat of a wakeup call for the first and upper stages as they realized their vulnerability to debris shaken lose from higher on the vehicle by the pressure and vibration of launch.  I worked with the civil servant in charge to establish a process for analyzing the data, which it turns out had never been done before.  Debris analysis for shuttle was an ad hoc affair working with a system that was reasonably well known.  No one had ever set up a debris analysis for a brand new vehicle and the process wasn't documented at all.

   We started by figuring out what data to get.  We worked with the organizational representatives to set up a system whereby they determined their interfaces: where they might lose something that could become debris (nozzle covers, ice, or insulation) and what they had that might be vulnerable to impact from above (nozzles for the vector controls, for example).  We then worked with the aerodynamics group to do a debris transport analysis on each possible piece of debris to see where it could impact and how strong that impact could be.  This analysis was based on the air flow around the vehicle through the thicker parts of the atmosphere (debris doesn't remain an issue once the air is too thin to catch it or there aren't any stages left to hit).  The impacted stage would then do a debris tolerance assessment and the whole thing went into the hazard analysis before starting again with a better fidelity of data.

  This was all put into the Ares I Ascent Debris Document.  We included the analysis plan we developed, the configuration and data management support documentation, detailed descriptions of the debris transport analysis data products, element tolerance models, risk assessment activities, comments from the Preliminary Design Review, and the coordination we did with the aerodynamics group at NASA Langley Research Center to get the correct vehicle data for the analysis (using computational fluid dynamics or CFD).  This was all coordinated with the Constellation program as well, since it affected both Orion (which had now become a possible source of debris) and the ground operations team (who would be dealing with the most debris).  Results were also reported to the Ares project office for refinement of the liftoff and ascent debris requirements at the vehicle level.

  The document and supporting data, including the CFD analysis, was set up with a data management folder on Windchill which was my responsibility.  This was the first time we'd dealt, as a project, with non-text data being required for the data drop location.  I worked with the data management folks to get the basics for that and initiated a process review to better handle it in the future.

   This was a interesting task for me because I got to help establish the workflow from the bottom up (there was a general understanding of what was needed but nothing written down) and work through the iterations as the data fidelity increased.  I also worked closely with the safety and hazard folks, who were quite patient in explaining what they needed and helping me set up the workflow to match their input requirements.

   Originally called the Constellation Analysis Integration Tool and later renamed to show its application across other programs, CAIT was my project from the start.  In late 2005, I was handed the job of documenting the data analyses being done so that we could create an integrated master schedule (IMS).  The IMS was considered critical for tracking potential problems, and what I was to set up was considered critical to get the links necessary for a true project schedule.  A full project schedule doesn't just track how long something takes and when it is due, it tracks the inputs to each item and when THEY are due, which allows you to see quickly how a delay will cascade through a project or program.

   So the Constellation Program suggested that, since this information was going to need to be coordinated across all levels of the program, we use something people were already familiar with, in this case a task description sheet (TDS).  These were used on the International Space Station (ISS) to track the experiments coming on board, what resources including astronaut time were needed to work them, how long they were going to be active and on station, and who needed the data in what format.  All told, there were about 30 basics fields on the form, and that ballooned rather quickly if your task had multiple inputs, or multiple deliveries in various formats.  There had been some discussion of creating a database for this project.  It got put on the fast track when I sent them the first 350 or so TDS's from Ares, averaging 70 fields per task.

   Becky Farr sat me down when the word came down to help produce a database.  I had the only thing close to a process for this type of data tracking, so Becky informed me that I had some work to do and she would show me how.  Thus did I come to truly appreciate Becky's skills.  She introduced me to workflows and process documentation, showed me how to document what I was already doing, streamline it as best I could, and then she and Dan Hicks, another member of the DAWG, helped me put together requirements that would let the programmers automate it.

   This is when the guys from Analytical Mechanics Associates (AMA) came in.  They were brought on board to build a database.  I was skeptical, since my experience up to this point was that programmers tended to be disablers - people who liked the perception of their craft as an arcane field unknowable to the masses.  Thankfully, I was quickly and pleasantly surprised.  They were consummate and skilled professionals who were accomodating and a pleasure to work with.

   I'm not sure who was more stunned by the outcome, the programmers who suddenly had well-written numbered process requirements to build their database with, or me, who got a working database in a little over a month.  They even figured out how to take the text files I'd been using and import the information into the database, so I didn't have to transfer the data from 350 or so documents by hand.  Thus was created the CAIT database.

   CAIT was in use for six years, until I was laid off at the end of the Ares project.  During that time it was expanded to include the Constellation program level data, information from Orion, and better integration with the IRMA risk database and the CRADLE requirements database.  The interfaces were refined, additional reports and links were added, and schedule coordination was improved.  We held several LEAN kaizan events to streamline the process to fit better with engineering needs, which both significantly improved the process and introduced me to the LEAN process.  CAIT was moved into the ICE REMEDY software environment about half way through this time, as were the other databases in use by Ares.  This was to increase security and ease access across the NASA program environment, but it required some background work and training of the ICE administrators.  CAIT was being updated for use with verification and validation data and Ares V when I was laid off.

   I was the CAIT project manager during this time.  I directly interfaced with the AMA programmers as a super user, database administrator, and primary documentation specialist.  I wrote the two iterations of the user guide for CAIT, made update requests, and worked with the users to improve the usability of the system across all levels of the Constellation Program.  I represented the Ares Project at workshops and meetings dealing with CAIT and the TDS process at the Constellation Program level.  I created training materials (both online and for meeting presentations) for all user aspects of CAIT at all levels of the program.  I also provided a white paper to the Constellation Design Integration Office regarding the lessons learned from CAIT's design and implementation, which was much smoother than other such projects had been.  It was a lot of work but taught me a lot about managing a project and working with end users (of hardware or software) so that everyone understands that the product is there to make their lives easier.

   Despite several months working on the Ares I System Requirements Document (SRD),  the Design Analysis Working Group (DAWG) was my first true plunge into the world of systems engineering.  My first tasks included searching out the key design requirements (located in a presentation from 2003) for the Ares SRD, Ares to Orion Interface Requirements Document (IRD), and the Ares to Ground Operations IRD for the Constellation program.  I helped review and update the Systems Engineering Management Plan (SEMP), and researched the Apollo/Saturn integration documentation.  The latter was fascinating, as I'd never been in the archives at Marshall Space Flight Center (MSFC) before; I also went through the documents stored at the US Space and Rocket Center, which has a significant collection.

   Then I was handed the task description sheets (TDS) (see the description under Cooperative Analysis Integration Tool (CAIT) for more).  I worked out a process for using the TDS to track our data analyses and trade studies, including schedule, risk and requirements integration; wrote a new set of instructions for the TDS form; helped the Constellation program adapt the TDS for their level of usage; and added a section to the Design Analysis Cycle (DAC) Guidance Documentation on using the TDS.  Once we realized the extent to which the TDS would be used, Becky Farr set up a LEAN kaizan even to help us streamline the process, something in which I'd never participated but found very enlightening not only for the improvements it made to the process, but the insight it provided into how to set up a process, including involving everyone who will have a hand in it and documenting every single step, every time information of any kind moves from one person to another.  We took the results from this and Becky worked with me to set up a workflow that could be automated.  We handed that over to the programmers who a little over a month later returned a working database.  I spent the next five or so years updating and refining the process and database to improve its usability and adapt it to the changing project environment.

   Other tasks I worked during this time included documenting DAWG product definitions with the DAC planning manager, so we had a better idea of those items for what we were responsible; a lot of these were tracked within the TDS system as well.  I also served as the Ares Integration point of contact for the Constellation Program Integration Office and the Orion and Ground Operations engineering groups, both for data they needed and data we needed from them.  Crew Safety and Reliability, Modeling and Simulation, and Aborts were introduced into the TDS process late and I provided the support to document their activities including collection of specific data sets they needed.  I also served as the integration point of contact for the Risk Management group, helping to coordinate access for them with the engineering disciplines.  I served as the Data Archive manager for the DAWG, working with our Project Coordinator Kristin Bigham to develop a data archiving process and administer the Windchill locations so that the disciplines and project groups could easily and quickly access the most current information they needed from each other.  This later became the Data Logbook.

   I also kicked off a trade study to determine vibration mitigation for the Ares I vehicle during rollout and on the launch pad.  We held technical interchange meetings (TIM) with Kennedy Space Center (KSC) to get their first-hand knowledge of shuttle launch operations and vehicle stabilization, both for the trade study and to use for vehicle design input.  I identified the proper people in the various stakeholder groups to participate in the trade study and presented the initial information to the DAWG before turning it over to one of the engineering disciplines for completion.

   I provided support for the Constellation Integrated Stack Technical Interchange Meeting at JSC in support of the DAC Planning Splinter, and the Constellation DAC Integration TIM also at JSC.  I also provided editing, writing, and review for the various DAC plans and documentation, including the SEMP, Ares System Analysis Plan (SAP), Modeling and Simulation Support Plan, and guidance documents.  Other documentation I worked on at this time included a table comparing and crosschecking the CAIT database and the Integrated Master Schedule (IMS), and the initial development on the Design Requirements Compliance Matrix (DRCM) for the Ares System Design Review (SDR) baseline.

   In 2005, NASA and Marshall Space Flight Center (MSFC) were going through a significant changeover.  The Shuttle program was officially going to end and the new vehicle was going to be designed by the engineers at MSFC. The scientists with whom I'd been working for five years were moving to the National Space Science and Technology Center (NSSTC), a cooperative effort between MSFC and the University of Alabama Huntsville.  So I was moved to engineering support.

   The first task upon which I found myself working was the Ares I System Requirements Document (SRD).  I had no idea what I was looking at, having never seen requirements this complex before, but I could run a computer and picked up the new CRADLE requirements software fairly quickly.  After several weeks working with the engineers and analysts, I was also offering suggestions for edits - as it turned out I picked up systems engineering pretty quickly, too, especially requirements writing which has few rules that try to focus each requirement to one concept, easily verified and validated. My vocabulary began a major expansion during this time - I added engineering to my professional lexicon, to go with radiation shielding, materials science, spaceflight and biology.

   While working with the requirements group, I helped edit and proof the SRD's first draft (both in the CRADLE database and as a released document), worked with the folks updating the vehicle's first stage and upper stage engine requirements (next project level down), learned how and why to link the two levels of the requirements, and was good enough with the software to be sent to support a Constellation level review at Johnson Space Center (JSC).

   My last task for the Science Directorate was with the Advanced Materials for Exploration organization led by Beth Cook.  She oversaw a number of researchers with relatively small (monetarily) projects that had good potential for further development.  I started out helping her develop the schedule, metrics, and comment support documentation for a proposal review.  I also gathered up and distributed the proposals for review, created quad charts for the actual review, then collected and sent out the results notices and comments to the researchers.

   Our next project was a technical memorandum archiving the research that the AME group was funding.  I created a basic outline and extracted preliminary information from the archived files.  Using the preliminary information, the researchers then created reports for inclusion in the document, which I edited to match the NASA style guide per NASA Publications instructions and the newly updated export control requirements for documents.  The document was sent to NASA Publications for final editing before being released as 'Advanced Materials for Exploration Task Research Results' (see Publications page).

   During this time we also put together and worked a booth at the 2006 National Space and Missile Materials Symposium (NSMMS), advertising the research projects AME supported.  This was fun, since I'd helped prepare many sets of materials for conferences but rarely got to attend to see how they were received.  We used several digital presentations and had beautiful handouts created by one of MSFC's graphics folks for each project.

   I also planned and coordinated the task review meeting forum for the researchers, including the schedule and presentation templates.  It was a short tell-us-what-you've-been-up-to review, but it always helps to keep people informed and get your name in front of folks.  I provided technical and administrative support during the forum and compiled the presentations for release to attendees afterwards.

   My first full job after leaving the incubator of Marian's laboratory was with Charles Baugher's research support group in the Science Directorate at Marshall Space Flight Center (MSFC).  I was brought on originally to complete the Spacelab Results Study (see Spacelab Science Assessment below), a technical peer review of the research performed on the 36 Spacelab Shuttle missions.  This document would eventually be published by NASA in 2009.

   One of the primary projects Charlie's group was in charge of was organizing and putting on the Materials Science Principal Investigator (PI) Conferences.  I worked the ones in 2000 and 2002.  We brought together for a peer reviewed conference all the folks doing research for which the NASA Materials Science group provided funding, and published a conference document of presentations (see Publications).  I also provided conference and publications support for the Biological and Physical Space Research Laboratory Science Review in 2002; the In-Space Fabrication and Repair Research Technical Forum in 2003; the Advanced Space Propulsion Materials Workshop in 2003; and several workshops for the Radiation Shielding Group: a Non Advocate Review,  Revolutionary Concepts for High Energy Dynamic (HEDS) Radiation Shielding Workshop in 2000, the PI meeting in 2004, the Deep Space Test Bed Conference, the Active Radiation Shielding Workshop in 2004, and the Radiation Effects Team Working Group 2003 Meeting.  We also supported a Lunar Simulant Research Workshop in 2005, and I was tapped to organize the External Tank Foam Materials Properties Workshop in February 2003, after Columbia broke up on re-entry.  That workshop brought home to me the importance of not letting dismissive language dissuade you from asking questions.  In 2004 we supported the Nuclear Propulsion and Aerocapture Workshops, and 2005 was the World Year of Physics, with the Physics in the Third Millennium Conference held in Huntsville, Alabama, and sponsored in part by MSFC.  In 2005 I helped write and edit two presentations based on some of the work being done at MSFC on advanced materials, “Research Opportunities Supporting the Vision for Space Exploration from the Transformation of the Former Microgravity Materials Science Program” for the Exploration Science and Technology Division Manager at the AIAA Exploration Meeting in January 2005, and “Materials Requirements for Advanced Propulsion Systems” for the Project Manager at the AIAA Meeting in January 2005.

   Aside from supporting the documentation and processes around the conferences and workshops, I also helped the researchers, usually with internet or library searches.  I provided research support and data archiving for the In-Situ Resource Utilization and In-Space Fabrication and Repair research efforts, which included research for proposals.  I also was the multimedia support for researchers needing presentation materials.

   This was a massive project to wrap up the end of the Spacelab Program.  Spacelab was actually a set of hardware designed by the European Space Agency for use on the STS Space Shuttle.  There were 36 shuttle missions that used Spacelab hardware and the program asked researchers at the University of Alabama in Huntsville's Center for Materials Development in Space (CMDS) to provide a peer review of the research done with that hardware.  My boss and mentor, Dr. Marian Lewis,  was asked to provide the section on the biology experiments.  She decided to get me involved and sent me out to the Redstone Arsenal library to see just what experiments were done with the hardware.  There turned out to be a lot.  Working with the librarians, who were intrigued at the question, we found over 1000 pages of research papers, projects and mission data, which Marian culled down to a significant review of the data.  With the biological sciences, physical sciences, astrophysics, solar physics, space plasma physics, atmospheric sciences, and earth observations research, this became the most comprehensive review of science results from the STS Shuttle Program to date.  There ended up being several editions of this data published.  I worked on all of them.  I can say with some amusement that I wrote the book on Spacelab (and an encyclopedia entry, too).

   The Spacelab Accomplishments Forum was the international conference held to give the initial presentations of the overview data.  I had this as my very first job at MSFC - finishing the conference document.  It was also my first full edit and layout of a document for publication.  I thought it came out well.

   Next up was the Spacelab Science Assessment Executive Summary (see Publications).  Dr. Robert Naumann, who headed up the effort at UAH and wrote (very well, too) the physical sciences section, put together a short version that summarized the various sections and had it published as the deliverable for the contract.  It was the only reference to the document for years until I managed to get the paperwork for the main document through.

   The Spacelab Science Results Study (see Publications) ended up being my baby.  I am the only editor to have my name on this document, in part because Marian was kind enough to list me as a co-author on her section, but also because I updated the papers published and researcher data in the appendices over the years.  For various reasons this document would not be published by NASA until 2009, ten years after I was first brought in to work on it.  I worked for all of those years to get it completed, approved and finalized.  Originally there was some question over which organization would publish it, so Charlie had me hold off until the issue could be resolved.  On his untimely death in 2004, no one but myself really knew where and in what condition the document stood.  I went to the new head of the science directorate who agreed that it should be published and was promptly reassigned to Texas before he could sign the releases.  I had no idea what to do with the document for several more years, until I mentioned to someone in the engineering group that it had been languishing.  She took me to the head of engineering who heard me out and agreed to sign the paperwork to have it moved to release.  After another few months working with NASA Publications, it was finally released in March of 2009 with over 1000 pages of review, publications, hardware, research subjects, and mission data.