Project Management

Introduction

This document has been compiled to provide guidance in the management and completion of the Iris project. The Iris program will explore how the space environment changes the optical properties of asteroids and the Moon over time. Asteroid surfaces exposed to the space environment undergo various changes that relate to factors such as solar heating, vacuum desiccation, and solar wind bombardment. These factors are termed "space weathering" and they change the visual appearance of asteroids, which affects our ability to relate asteroids as seen by spacecraft and telescopes to meteorites as measured in the laboratory. 

Iris will investigate how space weathering affects asteroids and the Moon by exposing a variety of meteorites and lunar analogs to the space environment in low Earth orbit and monitor changes in their optical (spectral properties) over the lifetime of the mission. The results will help us improve our ability to link asteroids to meteorites and enhance the science value from the upcoming CSA-NASA OSIRIS-REx asteroids sample return mission.

The Iris program will provide valuable space heritage data for York University on their new, experimental sun sensor. By demonstrating functionality on a real space mission, it will increase the technology readiness level and provide a potential new space product for the Canadian space industry.  The Iris project is undertaken by a team of teams bringing together a wide range of knowledge and experience. To manage this project, the team will take a non-traditional approach by incorporating elements of Agile Philosophy, Lean Manufacturing, and Theory of Constraints. 

Scope Management

Project Scope: The work performed to deliver a product, service, or result with the specified features and functions. (PMBOK 6th ed.)

In order to control how the project scope is defined, validated, and controlled, the project scope will be defined by the Iris project objectives and requirements. Requirements will be reviewed every quarter and updated as needed. Based on the updated requirements, affected subsystems will update their project tasks and verification activities to reflect the current scope.

Scope validation will be completed through verification activities defined by each subsystem lead. Verification activities include 4 archetypes: Testing, Inspection, Analysis, and Document Review. Such activities will be completed throughout the life of the project and will be documented, including work done and criteria for acceptance. 

Schedule Management

Project Schedule: An output of a schedule model that represents inked activities with planned dates, duration, milestones and resources. (PMBOK 6th ed.)

Iris will be delivered to the CSA and Nanoracks in 2022. The schedule will be defined and controlled by the core Iris team. Each subsystem schedule will be controlled by its respective subsystem lead and updated as need be. The progress of each created task will be reviewed  in a weekly meeting. 

Tasks will be created by each subsystem lead, based on expected task duration, definition of done, and projected resource availability. All tasks will be created to support the completion of major milestones, and will capture the following information: Expected duration, hours of work, task description, and definition of done. For each phase, these tasks will be recorded and kept up to date on a team progress spreadsheet. Each subsystem lead is responsible to present updates on weekly basis.

As changes in schedule are expected, each subsystem lead is in charge of non-critical path tasks, taking care that changes will not cause schedule overrun. In events that there is schedule overrun, the project leads will review the schedule changes and identify all options changes.

Quality Management

Quality: The degree to which a set of inherent characteristics fulfills requirements. (PMBOK 6th ed.)

High level requirements will be verified through the verification of all its children and progeny. For the requirements without children, subsystem leads will be responsible for creating verification activities that adequately test for compliance.

For phases B, C, and non-system level activities in phase D, subsystem leads are responsible for organizing and executing verification activities, documenting all tasks in the schedule. Subsystem leads will coordinate with AIT lead to ensure that all necessary equipment is available. The team may use any available method to generate tests, including additive manufacturing, breadboard models, external test beds, etc. Frequent testing through the early phases is encouraged to identify and resolve non-conformances when change has a lower impact in schedule and budget.

For Phase D, verification activities shall be coordinated with the AIT lead for all tests that require system level testing. Verification procedures will be documented in a method that is easy to access and understand for outside observers and operators. All results shall be recorded in full detail, including time, verification ID and test deviations.

Non-conformances shall be handled in a case by case basis at different phases of the project through Request for Deviation (RFD) and Request for Waiver (RFW). For step by step instructions for filling out the forms, follow the Instructions to Create RFD's. When a non-conformance is identified, the Iris team will pursue corrective actions to amend the issue.

If the non-conformance cannot be removed before phase D, the Iris team will submit a RFD to the Canadian CubeSat Project team for CSA and Nanoracks considerations. If the RFD is rejected, Iris team is responsible for changing the design. 


RFD Flow Chart

During phase D, when a non-conformance is found, the Iris team will create a Non-compliance report detailing requirements tested, test procedures and results. The report shall address the following:

If the non-conformance can be corrected, the Iris team will exercise activities and will test again. If repair, rework or modifications are not an option but the non-conformance can be used without change, a RFW will be submitted to the CSA and Nanoracks for consideration. 

RFW Flow Chart

Resource Management

Resource: A team member or any physical item needed to complete the project. (PMBOK 6th ed.)

Team member availability shall be primarily managed through spreadsheets. Each team member will manage their tasks, and to the best of their knowledge, accurately estimate the amount of time needed for a task. Upon completion, each member will return to the task and update the expected duration with the actual amount of time for completion.

Materials will be coordinated among team members to ensure that double booking events for assembly or test equipment is not needed. Magellan Aerospace assets will be coordinated through the University of Manitoba Co-Investigator at least 24 hours in advance for any affected testing or assembly activities.  If lab equipment needs to be taken out of the lab, members will fill out the equipment sign out sheet.


Communications Management

Communication Method: A systematic procedure, technique, or process used to transfer information among project stakeholders. (PMBOK 6th ed.)

The Iris design team shall primarily communicate with agreed upon methods, including: talking, emails, texting services and skype conversations. All communication shall adhere to the Team Norms and shall be used to promote professionalism in all members. 

 Meetings will be used to coordinate Iris tasks as needed and identify resource availability, blockages, and methods to address blockages. Weekly update meetings will be used for large scale decisions, technical updates and discussing opportunities to for additional outreach and collaboration. Quarterly meetings will be made to review all requirements and risks. At the beginning of each school season (i.e. Fall, Winter, and Summer Semester) the management team will request schedules to identify new meeting times.

All technical information will be handled in an information pull system through the Iris Wiki website. Sub-system leads are responsible for maintaining their respective website entries up to date and reflective of technical information.

Communications with the other Iris stakeholders will occur through designated points of contacts by either email or telephone call. Milestone Reviews will occur at the request of the CSA or Nanoracks, all required information will be submitted one month before the review is set to take place.


Risk Management

Risk: An uncertain event or condition that, if it occurs, has a positive or negative effect on one or more project objectives. (PMBOK 6th ed.)

Risks will be identified by any member of the Iris team. All affected members, including the systems lead and project manager, will define the impact and probability of the risk event occurring. The Risk scales define the criteria for each score for impact and probability and can be found in the risk registry. Each risks will have a severity level applied to it based on the impact and probability score defined by the risk matrix. 

Risk plans will be discussed and developed by all affected parties and will be identified as one of the following definitions:

Avoid – Acts to eliminate the threat or protect the project from its impact.

Mitigate – Action taken to reduce the probability of occurrence and/or impact threat.

Accept – Acknowledge the existence of a threat, but no proactive action is taken.

When a risk mitigation or avoidance activity is agreed upon by all affected members, work tasks will be created and documented within Playbook and the risk registry. Upon completion of the risk tasks, the risk registry will be updated with the current status of the threat. If more actions are needed, all affected parties will be consulted. 

Risk Matrix

Procurement Management

Procurement Strategy: The approach by the buyer to determine the project delivery method and the type of legally binding agreements(s) that should be used to delivered desired results. (PMBOK 6th ed.)

When a member identifies material that needs to be purchased, they will request approval from the University of Manitoba co-investigator. If approved, the responsible team member will request the lab technician to make the purchase.

For commercial-off-the-shelf (CotS) components, in addition to the steps above, the purchasing team member will identify any special storage, handling, and installation information and record it into the Component Storage and Handling Instructions. Upon receiving the item, the purchasing team member will undertake acceptance testing and inspection to ensure that the purchased item operates as needed. The operator will fill out an inspection report and begin a traveler document to track travel and activities. Report templates can be found in Document Control Templates folder.

If multiples of the same component are purchased, batch acceptance testing will be undertaken.