Project Manager

My position in my team was that of Project Manager. This was a voluntary decision, as I expressed interest in taking up the leadership role and was given the opportunity by my teammates.

The Project Manager, as described by NASA L’SPACE official documents, acts as the team facilitator. A large portion of my responsibilities included ensuring maximum team cooperation and efficiency. I was an architect of the team’s structure and ensured that their work was progressing smoothly.

One of my opportunities was to schedule the weekly team meeting and contact my team with day and time. During weekly meetings, I went over the week’s schedule and what needed done, asked for subteam updates, facilitated conversation, and encouraged new ideas. Through these tasks, I ensured maximum participation of my team members by asking questions and asking others to share their thoughts.

Outside of weekly meetings, I connected all the different parts of the team together. I wrote weekly overviews of project progress and posted it in the team’s Discord server. I also did check-ins with team leads and team members to gather updates. I also stood as the main line of communication between the team and our mentor.

Another responsibility I upheld as Project Manager was the creation and active revision of the team Gantt Chart. This is a bar chart that exemplifies a project schedule, shows the dependency relations between tasks, and illustrates progress.  The Gantt Chart I created is split into several sections: Preliminary Research, Mission Concept Drafting, Business Deliverables, Engineering Deliverables, Science Deliverables, Safety, Final PDR, and Presentation. Each week, there were certain PDR section drafts that needed to be submitted. To successfully submit these drafts, several tasks needed to be completed across the subteams throughout the week. These tasks, found under each section, include a schedule for when they should be worked on and completed. This scheduling was aligned with deliverable deadlines set in place by L’SPACE to allow for on-time submission. It was also useful as a visual for project progress. This, in fact, was achieved by treating the Gantt Chart as a ‘living document’. This means that it was updated, revised, and worked on continuously throughout the project. I made it a living document by adding tasks, programming responsive sections using Excel, and updating “% Progress” for each task.

Skills that I exercised as Project Manager include:

• Leadership
• Outside the box thinking
• Organization
• Teamwork
• Team management
• Communication
• Empathy to other’s needs
• Providing and taking constructive feedback
• Time management
• Backward planning
• Proactivity to deadlines

Engineering Subteam

In addition to being Project Manager, I was a member of the Engineering Subteam. This team was in charge of:

“Researching currently utilized, state of the art, or new ways to solve a specific requirement as deemed necessary by the science team and the mission success criteria. Responsible for documenting the entire thought and design process. Conduct the necessary mathematical calculations to ensure it satisfies the technical requirements. Develop a plan for solutions by applying the results of the research. Design the prototype product to fit the needs of the science instruments. CAD models to ensure proper fitting and functionality. Redesign and revise if needed. Keeping track of individual budgets used and sending it to the Lead Engineer. Propose every major milestone in the process to the Lead Engineer.”

In general, the Engineering team oversaw the design of the mission payload model to satisfy the mission and scientific goals. This was achieved by the marriage of design, size/weight constraints, deployment, trajectory, materials, and budget.

My responsibilities as a member of the Engineering team varied but were all related to writing content for the PDR. The following is an outline of each section that I wrote, in order of appearance in the final PDR:

1.2.2. Mission Requirements

Mission requirements establish a path of success by directly defining what success is. When outlining requirements, one must state what is (or a characteristic of something that is) needed or wanted. These can range from requirements and constraints from the project to design requirements at a systems level.

Using resources from the NASA Systems Engineering Handbook and training from L’SPACE, I wrote out the requirements from the mission. To begin, I considered the three different methods of requirement formulation to establish lower-order requirements: flow-down, allocation, and derivation. Flow-down is a direct transfer from higher-order requirements to lower system hierarchy. Allocation is the distribution of higher-level requirements into lower-level requirements. Finally, derivation is the act of defining a known relationship between higher-order and lower-order requirements but on the same level. Then taking the mission constraints and requirements, I broke up the requirements into five sections: power, communications, movement, thermal control, and mission constraints. The later section is a simple explanation of the constraints given by NASA. The other sections were divided up by system. This establishes a traceable hierarchy, which provides a visual relationship between higher-order and lower-order requirements.

Within each system, I considered five types of requirements: system, functional, performance, constraint, and verification. System requirements define what is expected from a system. Functional requirements define what a component of a system must do. Performance requirements define and quantify to what level a function must be accomplished. Constraint requirements define the limits of the project. Verification requirements define the level of confidence that certain systems will be met in a functional environment. Using the SMART method (Specific, Measurable, Achievable, Relevant, Traceable), I wrote out the requirements for the mission.

In addition to the requirement statement, I also included rationale and verification. Rationale explains how and why this requirement has been stated. Verification defines the method in which this requirement will be tested for achievement. For example, if a requirement’s verification method is “Test”, then a test will be run to ensure that the requirement has been met.

1.2.4. Concept of Operations

The concept of operations (COO) is a user-oriented graphic that illustrates the mission from launch until end. The graphic, as required by the NASA L’SPACE PDR Requirements Document, “should show details regarding each of the major operational phases of the mission, including general science operations”. This graphic stands to help the reader more clearly understand the mission statement, the objectives, and how each corresponds to mission operations.

I used Photoshop to design the COO. I utilized a few previously created images, such as the vehicles and the Moon. Otherwise, everything else was handmade.

1.2.5. Major Milestones Schedule

 The major milestones schedule describes the most important steps of the mission and spans from conception to end. The schedule follows NASA Mission Lifecycle Phases A-E, which are described as follows:

• Phase A: Preliminary Analysis
• Phase B: Definition
• Phase C: Design
• Phase D: Development
• Phase E: Operations, Data Analysis

When scheduling the mission, several things needed to be considered. The first thing I reflected upon were the review stages that all NASA projects go through. These include Preliminary Design Review (PDR), Critical Design Review (CDR), System Integration Review (SIR), Testing Readiness Review (TRR), System Acceptance Review (SAR), Operational Readiness Review (ORR), Flight Readiness Review (FRR), and Mission Readiness Review (MRR). These must be completed at specific times in mission development. I also considered several other developmental stages, such as manufacturing, integration, testing, verification, and validation.

After a simple hierarchy of steps was created, I collaborated with the Business Subteam to discuss the budget. This was done so I could schedule the time projection, considering that costs are associated with time. Cross-referencing this information with estimated time requirements with each step, I finally put all steps into a timeline.

EDL Graphic

The Entry, Decent, and Landing procedure section of the PDR overviews the entry angle, estimated entry speed and height, and entry profile of the payload as it nears the Moon. This information, in general, describes how the rover will escape the orbiter and land. I designed the graphic illustration of how this procedure is planned to be executed to help the reader better understand it.

 I used Photoshop again to create the EDL graphic from the finalized procedure and numbers, utilizing a previously created vehicle image.

3.1.7. Performance Characteristics and Predictions 

The performance characteristics and predictions section highlight what aspects of the system prove that it can operate under the expected conditions. I focused on providing evidence to show that the descent and vehicle systems will work in the environment they would be sent to.

I also discussed how the systems are anticipated to work. This includes expected results from the descent maneuver and how the vehicle to expected to operate once at the desired altitude. I also discussed how the scientific instruments were expected to operate. The weather obstacles of the Moon, in relation to the descent maneuver, were also lightly touched upon.

3.1.8. Confidence and Maturity of Design

The confidence and maturity of design section is a summary of the most important aspects of section 3. I focused on discussing information that best proves to the reader that our design will work and meets its mission criteria.

7. Conclusion

In the conclusion, I summarized the PDR. I included crucial information such as the mission statement, vehicle and payload overview, a descent summary, and scientific instruments overview. I also discussed the future plans of the project. There were a few aspects of the design that were not covered in the PDR, such as a thermal control system. In the hypothetical situation that a CDR was made, given that the academy is over and only covered the PDR, I mentioned that the thermal system would be designed. I then concluded by giving a brief overview of the future timeline of the project.

Grammar, Formatting, Numbers, and Citations

Once the content of the PDR was written and reviewed, I put everything together into one document. I went through the entire document to look for grammar mistakes. I formatted the documents, ensuring that font, numbers, and size were all consistent. I also added citation numbers to necessary sections and compiled a citations page at the end of the document.

Skills Badges

I also took optional courses to earn skills badges. To reiterate, they are available for the following categories:

• Siemens NX
• Organizational Charts
• Gantt Charts
• Budgets
• Requirements
• Risk Management
• Functional Analysis
• And Heat Transfer

I have successfully completed the assessments for all of the skills badges:

Siemens NX

One of the L’SPACE mentors held weekly Zoom sessions to cover NX 3D-modeling software topics. These topics include:

• Basic NX user interface: location of key features and information windows
• Starting a basic modeling part: steps required to make sure the part saves correctly and is in the desired units
• Setting up the modeling space: workspace parameters that can be changed to make modeling easier
• Sketching overview: setting up sketching plane, drawing curves, sketching constraints, patterning sketch features
• Conversion of 2D sketches to 3D model

Organizational Charts

I learned how to design and build an organizational chart. This is a diagram that displays the hierarchy of a team. The reporting relationship between members can be visualized here.

Gantt Charts

I learned how to create and maintain a Gantt Chart. This is a bar chart that exemplifies a project schedule, shows the dependency relations between tasks, and illustrates progress. My application of this skill is discussed more in-depth in the Project Manager Section of this page.

Budgets

I learned how to create a budget for a team project. I learned how to apply ERE benefits rates, FTE, per diem rates, Modified Total Direct Costs (MTDC), margin, F&A, and travel to a budget to adequately plan ahead.

Requirements

I learned how to define requirements for a project. More information about requirements and my application of this skill to the PDR can be seen in the 1.2.2. Mission Requirements section on this page.

Risk Management

I learned about risks and how to properly manage them. Risks are potential events that have negative consequences and impacts. The management of such risks includes the actions and steps taken to reduce their severity. I learned how to track risks in a living document, how to review them regularly, and how to follow the risk management lifecycle.

Other risk-related skills I learned include:

• The steps to take when a risk is identified (assessment, mitigation plan, tracking, control)
• Probability characterization and likelihood
• Creating a semi-quantitative 5×5 risk matrix
• FMEA risk documentation
• Mitigation approaches and status

Functional Analysis

I learned about functional analysis and how important it is to systems engineering. Functional analysis is the process of identifying, describing, and relating the functions of a system. Top-level functions that need to be performed by the system and subsystems are assessed through functional analysis. This is important, from a systems engineering perspective, because it draws out all functions the system must perform to meet its requirements.

I learned about the greater analysis system, credited as the project process, which includes requirements analysis, functional analysis, synthesis/design, and systems analysis optimization and control.

I also learned how to draw and use an N2 chart, which is used to develop high-level system interfaces.

Basic Spacecraft Thermal Control Systems (Heat Transfer)

I gained an overview of heat transfer topics that relate to spacecraft systems. These topics include:

• Basic overview of spacecraft thermal systems
• Solar loads
• Radiation view factors
• Radiation heat transfer
• Conductive heat transfer
• Heat flow maps