Project Management Plan

Changelog

Introduction

This document has been compiled to provide guidance in the management and completion of the ArcticSat project. ArcticSat will help scientists and northern communities understand the rapidly changing environment of northern Canada. Specifically, ArticSat will contain tools capable of measuring the quality and quantity of ice in Canada's north.

ArcticSat Project Objectives

The stated objectives ArcticSat are as follows (ArcticSat CUBICS Application, pg. 9):

1. Train the next generation of space systems engineers, remote sensing specialists, and Arctic climate change researchers in the potential for CubeSats as Arctic remote sensing tools.

2. Engage with the communities of Chesterfield Inlet, Nunavut and Churchill, Manitoba to learn about the changing ice conditions and incorporate this local and traditional knowledge into the ArcticSat Mission.

3. Design, build, and operate a miniature passive microwave radiometer for use on a 3U CubeSat for Arctic remote sensing.

4. Lead educational outreach activities in museums, high schools, and elementary schools to promote STEAM education and the potential for CubeSats in an accessible space industry.

5. Design, build, and test a 3U CubeSat (ArcticSat) for Arctic ice and glacier remote sensing.

6. Collaborate with northern Inuit and Indigenous community members to operate ArcticSat and disseminate its data freely among Canadian communities.

Scope Management

Scope: "The work performed to deliver a product, service, or result with the specified features and functions."

• (PMBOK 6th ed.)

The project scope will be defined and validated via the ArcticSat objectives and requirements. Requirements will be reviewed every quarter and updated as needed. Subsystems will update their project tasks and verification activities based on requirement updates.

Preparation of Scope Statement

TBD

Work Breakdown Structure

TBD

Scope Validation

Scope validation will be achieved via verification activities defined by subsystem leads. There are 4 verification activity archetypes: 

1. Testing

2. Inspection 

3. Analysis 

4. Document Review

Verification activities will be completed throughout the life of the project and will be properly documented, including a description of work done and criteria for acceptance. Verification activities will be reviewed every quarter and updated as needed. Verification activities should be marked as complete in Valispace when the criteria for acceptance is formally met and validated by a team member.

Requirements Management

Requirement: "A condition or capability that is necessary to be present in a product, service, or result to satisfy a business need."

• (PMBOK 6th ed.)

Requirement Hierarchy

The requirements for ArcticSat will be categorized as shown in the figure below. Mission-level requirements (MIS) are at the top level, further distilled into the following subsystems:

• (AIT) Assembly, Integration, and Testing

• (ADC) Attitude Determination and Control System

• (CDH) Command and Data Handling

• (COM) Communications

• (FSW) Flight Software

• (GST) Ground Station

• (PLD) Payload

• (MEC) Mechanical Structure

• (POW) Power

• (THE) Thermal

Requirement Management Tools

The team will use Valispace to manage requirements and verification activities. Valispace requirements and verification activities will be integrated into the wiki for access where appropriate or necessary.

Verification Roll-Up

All lowest level requirements will have an associated verification activity which will describe an actionable activity deemed valid enough to verify associated requirement(s). By completing verification activities, requirements will become verified. Requirements will be written top-down such that once children requirements are verified (and any same level verification activities are complete), parent requirements will also be verified, referred to as verification roll-up.

Schedule Management

Schedule: "An output of a schedule model that represents linked activities with planned dates, duration, milestones and resources."

• (PMBOK 6th ed.)

ArcticSat will be delivered to the CSA at the very beginning of 2025. The schedule will be defined and controlled by the core ArcticSat team. Each subsystem schedule will be controlled by its respective subsystem lead and updated as needed. The progress of each created task will be reviewed  in a weekly meeting.

Task Scheduling

Tasks will be created by each subsystem lead, based on expected task duration, definition of complete, 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

• Definition of complete

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 a 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 the event that there is schedule overrun, the project leads will review the schedule changes and identify all options changes.

Level of Accuracy

TBD

Cost Management

Cost Management Plan: "A component of a project or program management plan that describes how costs will be planned, structured, and controlled." 

• (PMBOK 6th ed.)

Level of Accuracy

TBD

Ordering and Reporting Procedures

TBD

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 children and progeny. Subsystem leads will be responsible for creating verification activities for requirements without children.

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 the AIT lead to ensure that all necessary equipment is available. Frequent testing through early phases is encouraged to identify and resolve non-conformance when such changes have a lower impact on schedule and budget.

In 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-conformance shall be handled on a case-by-case basis utilizing a Request for Deviation (RFD) and a 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 team will pursue corrective actions to amend the issue.

If a 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 the team is responsible for changing the design. 

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

• • Analyze all root causes of the non-compliance

  • Identify if non-conformance can be fixed through rework/repair

  • Identify if modification is a possibility

  • If rework, repair or modification are not an option, identify impact on safety review  

If the non-conformance can be corrected, the team will exercise the required activities and 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. 

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.

Resource Control

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.

Identification of Resources

TBD

Acquiring Resources

TBD

Team Development

TBD

Communications Management

Communication Method: "A systematic procedure, technique, or process used to transfer information among project stakeholders."

• (PMBOK 6th ed.)

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

 Meetings will be used to coordinate 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 ArcticSat wiki. 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.

Escalation Process

TBD

Glossary of Common Terminology

ADCS: Attitude Determination and Control System

AIT: Assembly, Integration, and Testing

CDH: Command and Data Handling

CSA: Canadian Space Agency

Comms: Communications System

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 team. All affected members, including the systems lead and project manager, will define the impact and probability of the risk event occurring. The risk scale defines the criteria for each impact score and probability and can be found in the risk registry. Each risk will have a severity level applied to it based on the impact and probability score defined by the risk matrix.

A formal risk assessment meeting will occur quarterly to keep information up-to-date.

Risk plans will be discussed and developed by all affected parties and will be identified with 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. 

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.