report:prm [EPS@ISEP]

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
===== 3. Project Management =====
This chapter details the project management methodologies and organizational frameworks applied throughout the development of the project. It outlines the team's approach to structuring, executing, and monitoring the workload using an Agile framework organized into 15 distinct sprints.

It covers:

- Scope & Time Management: Definition of the product and project boundaries, alongside schedule management, key milestones, and visual timelines mapping project phases to deadlines.

- Cost & Quality: An overview of the budget allocation, financial tracking (planned versus effective costs), and the quality metrics and thresholds established to evaluate project deliverables.

- People, Stakeholders & Communications: Identification of team roles, responsibilities, stakeholder engagement strategies, and the internal communication channels that guided the group.

- Risk & Procurement: The identification, analysis (quantitative and qualitative), and mitigation of product and project-level risks, alongside sourcing strategies and make-versus-buy decisions.

- Project Plan: A structural breakdown of the project timeline, detailing the Global Sprint Plan, the comprehensive Project Backlog, and the distribution of Epics across the project lifecycle.

- Sprint Outcomes & Evaluations: A review of sprint backlogs, planned capacity versus achieved velocity, and summaries of sprint retrospectives that drove the team's continuous improvement strategy.

==== 3.1. Scope ====

Defining the scope of CONNECT is essential for keeping our efforts focused on the project's objectives: reducing digital isolation and enhancing the passenger experience within the Metro do Porto. By mapping out exactly what is included in the project, we can prevent scope creep and ensure every team member understands the roadmap from conceptualization to final development. 

The Work Breakdown Structure (WBS) seen in the Figure {{ref>WBS}} ilustrates how we have divided the project into manageable phases and specific deliverables. 


<WRAP centeralign>
<figure WBS>
{{ :report:edt.png?800 |}}
<caption>WBS </caption>
</figure>
</WRAP>



/*Table {{ref>tlabel10}} illustrates a boxed table with default column widths and Table {{ref>tlabel1x}} with specific column widths.

<WRAP centeralign>
<table tlabel10>
<caption>Boxed table</caption>
<WRAP box 400px center>
^Abbreviation ^Description ^
|EPS |European Project Semester  |
|ISEP|Instituto Superior de Engenharia do Porto  |
|USB |Universal Serial Bus  |
</WRAP>
</table>
</WRAP>

<WRAP centeralign>
<table tlabel1x>
<caption>Boxed table with specific column widths</caption>
<WRAP box 500px center>
^ <WRAP column 100px>Abbreviation</WRAP> ^<WRAP column 300px>Description</WRAP> ^
|EPS |European Project Semester                  |
|ISEP|Instituto Superior de Engenharia do Porto  |
|USB |Universal Serial Bus                       |
</WRAP>
</table>
</WRAP>

Table {{ref>tlabel11}} shows the execution time results for each API. Table {{ref>tlabel12}} lists the fruit bought at the grocery.
<table tlabel11>
<caption>Time response</caption>
<WRAP 120px>
^ API    ^ Time (s) ^
| EJML   |  26   |  
| JAMA   |  295  |  
| JBLAS  |  29   |  
| MTJ    |  18   |  
| WEKA   |  123  | 
</WRAP>
</table>

<WRAP centeralign>
<table tlabel12>
<caption>Fruit Weight</caption>
^Fruit    ^  Weight (kg)  ^
|Pears    |  2.60  |  
|Apples   |  2.95  |  
|Oranges  |  1.90  |  
</table>
</WRAP>

Figure {{ref>flabel10}} displays a magnificent owl from Lapland.
<WRAP centeralign>
<figure flabel10>
{{ :chouette.lapone.relo.4g-mocho_2.jpg?250 |}}
<caption>Owl</caption>
</figure>
</WRAP>

Figure {{ref>flabel20}} illustrates the placement of two images side by side.
<WRAP centeralign>
<figure flabel20>
<WRAP group>
<WRAP half column>{{ :chouette.lapone.relo.4g-mocho_2.jpg?250 |Image 1}}</WRAP>
<WRAP half column>{{ :chouette.lapone.relo.4g-mocho_2.jpg?250 |Image 2}}</WRAP>
</WRAP>
<caption>Images side by side</caption>
</figure>
</WRAP>

Figure {{ref>flabel30}} presents the European Project Semester (EPS) logo.
<WRAP centeralign>
<figure flabel30>
{{ :eps_logo.jpg?200 |}}
<caption>EPS logo</caption>
</figure>
</WRAP>
*/
==== 3.2. Time ====

The EPS teams have to complete a list of milestones to ensure project succes. The following Table {{ref>tab:milestones}} defines the project timeline, acting as the baseline to monitor the project's performance.


<WRAP center round box 900px>

<table tab:milestones>
<caption>Project Milestones</caption>
^ Date ^ Description ^
| 2026/02/28 | Choose and share the team's top 3 preferred project proposals |
| 2026/03/11 | Upload the "black box" System Diagrams & Structural Drafts |
| 2026/03/18 | Upload the List of Components and Materials (what & quantity) |
| 2026/03/21 | Define the Project Backlog, Global Sprint Plan, Initial Sprint Plan and Release Gantt Chart |
| 2026/03/25 | Upload System Schematics & Structural Drawings to the wiki (Deliverables) and do the cardboard scale model of the structure |
| 2026/04/12 | Upload the Interim Report and Presentation to the wiki (Deliverables) |
| 2026/04/16 | Interim Presentation, Discussion and Peer, Teacher and Supervisor feedbacks |
| 2026/04/22 | Upload 3D model video to Deliverables |
| 2026/04/29 | Upload the final List of Materials (local providers & price, including VAT and transportation) |
| 2026/05/02 | Upload refined Interim Report (based on Teacher & Supervisor Feedback) |
| 2026/05/13 | Upload packaging solution to Deliverables and Report |
| 2026/05/27 | Upload the results of the Functional Tests to the Report |
| 2026/06/13 | Upload the Final Report, Presentation, Video, Paper, Poster and Manual to Deliverables |
| 2026/06/18 | Final Presentation, Individual Discussion and Assessment |
| 2026/06/23 | Update the wiki, report, paper with all suggested corrections. Hand in to the EPS coordinator a printed copy of the poster, brochure and leaflet |
| 2026/06/25 | Demonstration of the operation of the prototype and hand in the prototype and user manual to the client |
</table>
</WRAP>

The timeline reveals a strong concentration of deliverables in April and May, particularly around the interim report and prototype development phases. This required careful sprint planning to balance documentation and technical implementation tasks.
==== 3.3. Cost ====

This section details both the anticipated and actual expenditures incurred during the
development of the Connect prototype. Tracking financial performance against initial
projections allows the team to detect inefficiencies early, justify spending decisions,
and demonstrate fiscal responsibility within the constraints set by the project brief.

=== 3.2.1. Ideal Product Cost ===
 
This section outlines the projected costs for a full-scale, production-ready deployment
of Connect across a single metro carriage: 11 handrail nodes, 7 power supply units, and
3 ceiling LED strip runs.
 
Table {{ref>tlabelIdealHardware}} presents the planned ideal product hardware costs.
 
<WRAP center round box 700px>
<table tlabelIdealHardware>
<caption>Ideal product component costs (full carriage deployment).</caption>
^ Component ^ Type / Model ^  Qty  ^  Unit Price (€) ^  Total (€) ^
| Microcontroller | Wemos C3 mini (ESP32-C3) |  11  |  6.20 |  68.20 |
| Enclosure | PA Rail (fire-resistant, 3D printed) |  2  |  69.30 |  138.60 |
| Copper tape | Conductive adhesive, 20 mm × 20 m |  15  |  8.86 |  132.90 |
| Velostat | Piezoresistive sheet (pressure sensor) |  15  |  7.90 |  118.50 |
| CAN Transceiver | MCP2551-I/P |  10  |  1.99 |  19.90 |
| LED strip (addressable RGB) | WS2813 IP65, 60 LEDs/m, 1 m |  3  |  30.49 |  91.47 |
| Power supply | DC Step-Down 36–72 V to 12 V, 10 A, 120 W |  6  |  24.67 |  148.02 |
| Wiring, resistors | Miscellaneous passive components |  1 |  10.00 |  10.00 |
| Power supply | (5 V) |  1  |  37.15 |  37.15 |
| Delivery | — |  —  |  — |  TBC |
| **Total** | | | |  **764.74** |
</table>
</WRAP>

Hardware costs per carriage total 727.59 €, with the PA Rail enclosure being the single most expensive line item at 138.60 € for two units, specified due to its fire-resistance properties required for compliance with metro safety standards. No equivalent Portuguese-based supplier was identified at the time of writing, with the current source located in France. At scale, per-unit hardware costs could be reduced through bulk procurement across multiple carriage deployments.
=== 3.3.2. Prototype Cost ===

All components were procured through a single supplier ([[https://mauser.pt/|Mauser]]) to consolidate
shipping and avoid duplicate delivery charges. The 3D-printed PLA enclosure was produced
using university fabrication facilities, so the line item covers filament material only.
Measurement and testing instruments were obtained on loan from the university laboratory,
with no associated purchase cost. Table {{ref>tlabelPlannedCosts}} presents total list and pricing of components for the prototype. Planned cost is 3.55 € below budget ceiling (100 €).

<WRAP center round box 600px>
<table tlabelPlannedCosts>
<caption>Planned prototype component costs.</caption>
^ Component ^ Type / Model ^ Qty ^ Unit Price (€) ^ Total (€) ^
| Microcontroller | Wemos C3 mini (ESP32-C3) |  2 |  6.20 |  12.40 |
| Enclosure | PLA biodegradable (3D printed) |  1 |  13.99 |  13.99 |
| Copper tape | Conductive adhesive, 20 mm × 20 m |  1 |  8.86 |  8.86 |
| Velostat | Piezoresistive sheet (pressure sensor) |  1 |  7.90 |  7.90 |
| CAN Transceiver | MCP2551-I/P |  2 |  1.99 |  3.98 |
| LED strip (addressable RGB) | WS2813 IP65, 60 LEDs/m, 1m |  1 |  11.27 |  11.27 |
| Barrel jack converter | DC female 2.5×0.6 mm, 1.5 m |  1 |  2.96 |  2.96 |
| Power supply | Universal regulated 3–12 V DC, 5 A |  1 |  26.49 |  26.49 |
| Buck Converter | JOY-IT SBC-Buck02 - Conversor step down 9..35V para 5V 5A 25W | 1 | 4,60 | 4,60 |
| Wiring, resistors | Miscellaneous passive components |  1 |  4.00 |  4.00 |
| **Total** | | | |  **96.45** |
</table>
</WRAP>


==== 3.4. Quality ====

Quality management is needed to ensure that every deliverable meets the technical requirements and the expectations of our primary stakeholders: Porto Metro passengers and EPS coordination. Following the PMBOK standards, quality is managed as a continuous process rather than a final check. By defining clear metrics and verification protocols, we minimize risks and guarantee that the final prototype is safe, functional and socially impactful. 

=== 3.4.1 Quality Requirements and Metrics ===

To quantify the success of our work, we have established specific metrics and acceptance thresholds. As seen in Table {{ref>tab:quality}} each deliverable is associated with a measurable requirement. 
The selected quality metrics focus on three dimensions: technical functionality, user experience, and project completeness. This ensures that Connect is not only operational, but also meaningful and usable in its intended social context.
<WRAP center round 100%>
<table tab:quality>
<caption>Quality Requirements and Metrics</caption>
^ WP ^ Deliverable (WBS) ^ Requirement ^ Quality Metric ^ Threshold (Acceptance) ^
| **1. Management** | 1.1 WBS | Organize tasks | Complete list of deliverables | 100% of the WBS included |
| | 1.2 Gantt Chart | Control deadlines | Approved schedule | Finalized timeline |
| | 1.3 Global Sprint Plan | Plan sprints | Sprint dates | Approved sprint plan |
| | 1.4 Weekly Sprint Plan | Weekly tracking | Weekly version | Updated weekly plan |
| | 1.5 Product Backlog | Distribute workload | Jira | 100% of tasks assigned |
| | 1.6 Stakeholder Management | Identify key people | Stakeholder map | Closed list of stakeholders |
| | 1.7 Risk Managemet Plan | Prevent issues | Response plan | Critical risks under control |
| **2. Research** | 2.1 State of the Art | Learn from others | Market analysis | Similar solutions reviewed |
| | 2.2 Ethics | Comply with the law | Ethics report | Standards met |
| | 2.3 Sustainability | Environmental care | Environmental report | Materials analyzed |
| **3. Design** | 3.1 Structural Drawings | Assembly clarity | Final version of drawings | Approved blueprints |
| | 3.2 Black Box Diagram | Define connections | Block diagram | Error-free logic flow |
| | 3.3 Detailed Schematics | Circuit design | Electronic schematic | Finished and reviewed drawing |
| | 3.4 Prototype (CAD) | 3D Design | Final digital model | Components fit correctly |
| | 3.5 Packaging | Casing protection | Casing material | 100% recyclable material |
| | 3.6 Cardboard Model | Physical 3D "twin" | Real-scale model | Design matches 3D model |
| **4. Development** | 4.1 List of Materials | Control spending | Final budget | Max. 100 € total cost |
| | 4.2 Code | System programming | Correct operation | Code runs without error |
| | 4.3 Simulations | PC Testing | On-screen results | Approved simulation |
| | 4.4 QR APP | Create the link | QR Functionality | QR code works correctly |
| **5. Marketing** | 5.1 Flyer | Create brochure | Visual appeal | Professional, non-pixelated design |
| | 5.2 Leaflet | Explain the project | Message clarity | Passengers understand it instantly |
| | 5.3 Poster | Design poster | Impact on the Metro | Visible colors and CONNECT logo |
| | 5.4 Marketing Video | Record promotion | Promo quality | Fluid image and engaging message |
| | 5.5 3D Model Video | Show the interior | Technical fidelity | Internal mechanism is clearly visible |
| **6. Testing** | 6.1 Functional Tests | Test operation | Test results | System is fully functional |
| | 6.2 User Interaction | Test with people | User opinion | Positive user feedback |
| | 6.3 KPI Definition | Set goals | Success definition | Project targets fixed |
| | 6.4 Data Analysis | Analyze results | Data charts | Analyzed and clear data |
| **7. Reporting** | 7.1 Interim Report | Mid-term report | Wiki chapters | Approved draft |
| | 7.2 Interim Pres. | Present progress | PowerPoint presentation | Presentation performed |
| | 7.3 Final Report | Final report | Final Wiki document | 100% of chapters closed |
| | 7.4 Final Pres. | Final defense | Project defense | Final presentation performed |
| | 7.5 Paper | Write article | Paper format | Finished article |
| | 7.6 Manual | User guide | Instructions for use | Easy-to-follow guide |
</table>
</WRAP>

=== 3.4.2 Verification Sheets ===
While metrics define "what" we want to achieve, our verification system ensures "how" we check it. Table {{ref>tab:verification}} presents a series of Yes/No questions for every deliverable. These sheets act as a final quality gate: if the answer to the question is "Yes", the deliverable is accepted.


<WRAP center round 100%>
<table tab:verification>
<caption>Verification Sheets for Deliverables</caption>
^ WP ^ Deliverable (WBS) ^ Necessary Steps (Checklist) ^
| **1. Management** | 1.1 WBS | Are all 35 deliverables included in the structure? |
| | 1.2 Gantt Chart | Are all the project deadlines clearly defined? |
| | 1.3 Global Sprint | Are all the sprints defined within the project timeline? |
| | 1.4 Weekly Sprint | Has the real progress of the last week been updated? |
| | 1.5 Product Backlog | Do all tasks have an owner assigned in Jira? |
| | 1.6 Stakeholders | Have all project stakeholders been identified? |
| | 1.7 Risk Mgmt | Is there a response plan for the identified critical risks? |
| **2. Research** | 2.1 State of Art | Have at least 3 similar market solutions been analyzed? |
| | 2.2 Ethics | Does the project comply with data protection regulations? |
| | 2.3 Sustainability | Has the environmental impact of the materials been validated? |
| **3. Design** | 3.1 Structural | Are the structural plans completed with all measurements? |
| | 3.2 Black Box | Are all logical connections closed and error-free? |
| | 3.3 Schematics | Has the circuit schematic been verified to avoid short circuits? |
| | 3.4 Prototype (CAD) | Has it been verified that all parts fit correctly in the 3D model? |
| | 3.5 Packaging | Is the material 100% recyclable and does it protect the product? |
| | 3.6 Cardboard | Is the real-scale model finished and approved by the team? |
| **4. Development** | 4.1 List Materials | Is the total budget under 100 €? |
| | 4.2 Code | Does the system function without any software freezes? |
| | 4.3 Simulations | Do the simulation results validate the previous design? |
| | 4.4 QR APP | Does the QR code redirect correctly to the intended link? |
| **5. Marketing** | 5.1 Flyer | Is the design professional and with high-quality imagery? |
| | 5.2 Leaflet | Is the project concept understood in less than 10 seconds? |
| | 5.3 Poster | Is the CONNECT logo clearly visible from a distance? |
| | 5.4 Marketing Video | Is the message clear and the audio quality high? |
| | 5.5 3D Video | Is the internal mechanism of the handle clearly visualized? |
| **6. Testing** | 6.1 Functional | Does the prototype respond physically as programmed? |
| | 6.2 User Test | Is the average user satisfaction score higher than 4/5? |
| | 6.3 KPI Def. | Are the success goals measurable and quantified? |
| | 6.4 Data Analysis | Are the test charts clear and properly analyzed? |
| **7. Reporting** | 7.1 Interim Report | Are all required Wiki chapters completed on time? |
| | 7.2 Interim Pres. | Does the presentation fit within the maximum allowed time? |
| | 7.3 Final Report | Is the final report reviewed and free of spelling errors? |
| | 7.4 Final Pres. | Does the prototype function correctly during the live demo? |
| | 7.5 Paper | Does the article comply with the scientific paper format? |
| | 7.6 Manual | Are the instructions easy to follow for any user? |
</table>
</WRAP>

==== 3.5. People & Stakeholder Management ====
//Enumerate all people relevant to your project, including the project team and key stakeholders. Document their roles and responsibilities. Document your stakeholder management plan and strategy.//

To make CONNECT a success, it is necessary to strategically manage all parties affected by the project. Following the PMBOK standards, this section identifies the key individuals and groups, defines their roles and outlines the management strategy.

=== 3.5.1. Project Team and Internal Dynamics ===

We operate under a structure where all members share responsibility for project management. However, as we are a team of students with diverse backgrounds, special tasks are delegated based on individual expertise. 

Using the weekly sprint plan helps us to redistribute tasks if a member is overburdened to prevent burnout and ensure quality.

=== 3.5.2. Stakeholders Identification and Roles ===

Apart from the main teams, several external entities are involved in the project. In the Table {{ref>tab:stakeholders}} below, we identified them, their roles and their responsibilities. 

<WRAP center round 100%>
<table tab:stakeholders>
<caption>Stakeholders, Roles, and Responsibilities</caption>
^ Entity / Name ^ Project Role ^ Primary Responsibility ^
| **Team Members** | Project owners | Responsible for the full development cycle and all mandatory deliverables. |
| **Coaches** | EPS Supervisors | Supervise, evaluate progress, and provide strategic feedback. |
| **ISEP Faculty** | Advisors | Offer specialized knowledge in Electronics, Sustainability, Project Management, Ethics, Marketing, among others. |
| **ISEP** | Main sponsor | Provides infrastructure and funding for the components (BOM). |
| **Metro do Porto** | External client | Provides the operational context and establishes security and infrastructure standards. |
| **Security Department (Metro)** | Regulatory body | Validates that the handle complies with fire, electrical, and physical safety regulations. |
| **Metro do Porto Users** | Target group | Live the CONNECT experience during their commutes and provide feedback. |
| **Suppliers** | Suppliers | Responsible for the timely delivery of components. |
| **Legal** | Regulatory compliance | Guarantees that the QR app and data management comply with European regulations. |
| **Maintenance Team (Metro)** | Operational stakeholder | Evaluates ease of installation, durability, and maintenance of the smart handle. |
| **Cleaning Staff (Metro)** | Operational support | Provides hygiene, accessibility, and resistance of the materials. |
</table>
</WRAP>

Among all stakeholders, Metro do Porto, the Security Department (Metro), and end users are considered critical, as they directly influence feasibility, approval, and user acceptance.
=== 3.5.2. Stakeholders Management Strategy ===

To manage these relationships effectively, we have analyzed each stakeholder based on their Power and Interest. This analysis allows us to prioritize our communication and engagement efforts.

**A) POWER/INTEREST MATRIX**

The following matrix, seen in the Figure {{ref>stakeholders}}, categorizes our stakeholders into four quadrants to determine the necessary level of engagement for each group. 

<WRAP centeralign>
<figure stakeholders>
{{ :report:stakeholder_.png?1000 |}}
<caption>Stakeholder Matrix </caption>
</figure>
</WRAP>


**B) ENGAGEMENT STRATEGY TABLE**

While the matrix identifies the "where", the following Table {{ref>tab:engagement}} defines the "how". It establishes the specific strategy for each group and assigns a point person from the internal team to manage the relationship. 

<WRAP center round box 100%>
<table tab:engagement>
<caption>Stakeholder Engagement Plan</caption>
^ ID ^ Stakeholder Group ^ Quadrant ^ Management Strategy ^ Point Person ^
| 1 | Team Members | Manage Closely | Daily collaboration, stand-up meetings, and shared decision-making | All Members |
| 2 | Metro do Porto | Manage Closely | Continuous alignment with their operational context and branding requirements | Management Lead |
| 3 | Security Department | Manage Closely | Strict adherence to fire and electrical safety rules to ensure final approval | Technical Lead |
| 4 | Maintenance Team | Keep Satisfied | Ensure the design is durable and provide a clear installation manual | Hardware Lead |
| 5 | Coaches | Keep Satisfied | Weekly progress reports, Wiki updates, and formal meetings | Management Lead |
| 6 | ISEP (Sponsor) | Keep Satisfied | Compliance with budget (BOM) and laboratory facility usage rules | Management Lead |
| 7 | Metro Users | Keep Informed | Gather feedback through surveys and haptic testing to improve the UX | Marketing Lead |
| 8 | ISEP Faculty | Keep Informed | Consulting on technical challenges (Electronics, CAD, and Marketing) | Technical Lead |
| 9 | Legal  | Keep Informed | Ensure all digital interactions and data handling follow EU regulations | Legal Lead |
| 10 | Suppliers | Monitor | Tracking component availability and lead times for hardware integration | Hardware Lead |
| 11 | Cleaning Staff | Monitor | Selecting materials that resist the Metro's chemical cleaning protocols | Hardware Lead |
</table>

</WRAP>




==== 3.6. Communications ====


To ensure CONNECT's success, communication is key. A communication strategy has been established to guarantee alignment between team members, supervisors and stakeholders.



=== 3.6.1. Communication Channels and Tools ===

The team uses multiple tools to maintain a continuous flow of information:

  * WhatsApp: Used for urgent, informal and daily communication.
  * Microsoft Teams: Serves as the primary repository for all project documentation. Also for remote meetings.
  * Jira: Used to track the backlog, manage sprints and assign tasks to team members.
  * Miro: A digital whiteboard used during brainstorming sessions.
  * Outlook: Reserved for formal communication with external stakeholders, suppliers and ISEP coordinators.


=== 3.6.2. Communication Matrix ===

<WRAP center round 100%>
<table tab:communication>
<caption>Communication Matrix</caption>
|**Activity**|**Objective**|**Frequency**|**Medium**|**Participants**|
|Daily Stand-up|Daily tasks and identify blockers.|Daily|WhatsApp / Face-to-Face|Team Members|
|Weekly Meeting|Review weekly progress and plan next Sprint.|Every Thursday|Face-to-Face|Team & Supervisors|
|Sprint Planning|Define tasks and goals for the next cycle.|Weekly|Jira|Team Members|
|Retrospective|Evaluate team performance and workflow.|Weekly|Face-to-Face|Team Members|
|Interim Demo|Present project status to coordinators.|Milestone-based|Presentation|Team & Supervisors|
</table>
</WRAP>

=== 3.6.3. Stakeholder Management ===

We maintain a specific communication frequency with external parties:

  * **ISEP Supervisors:** Weekly feedback sessions every Thursday to ensure the project meets academic requirements.
  * **Target Users:** Feedback gathered through surveys and testing sessions.

===== 3.7. Risk =====

/*Identify key risks (product and project level), evaluate them and define how they should be handled (responses) and monitored. Perform quantitative and qualitative risk analysis and use the results to define the appropriate risk responses.*/

Risk management for CONNECT involves a systematic approach to identify and address potential challenges. Following the PMBOK standards, we have performed qualitative analyses to ensure that risks are treated effectively. 

=== 3.7.1. Identification of Key Risks ===

We have identified the following risks categorized into project and product levels.

PROJECT LEVEL RISKS:
  * Delivery: Delays in receiving components
  * Financial Constraint: Exceeding the budget due to component value or price fluctuations
  * Team Synchronicity: misalignment in tasks leading to delays in the final assembly


PRODUCT LEVEL RISKS:
  * Safety Rejection: Failure to meet safety standards
  * Vandalism: Intentional damage or theft of the internal electronics
  * Environmental Durability: Material degradation
  * Cybersecurity: QR code spoofing
  * Power Supply Instability: Failure of the internal battery or power management system during long commutes
  * Ergonomic Strain: The handle design causing discomfort or safety issues for passengers
  * Privacy Breach: Unauthorized collection or exposure of user data through the interaction app.

=== 3.7.2. Qualitative and Quantitative Evaluation ===
To evaluate these risks, we adopt a 5x5 Risk Matrix seen on the Figure {{ref>fig:risk_matrix}}. The exposure score is calculated by multiplying Probability (1-5) and Impact (1-5).

Probability Scale: 1 (Rare) to 5 (Almost Certain)

Impact Scale: 1 (Insignificant) to 5 (Severe)

<WRAP centeralign>
<figure fig:risk_matrix>
{{ :report:risk_matrix.png?direct&600 |}}
<caption>Risk Matriz</caption>
</figure>
</WRAP>

EXPOSURE LEVELS:
  * Low (1-3): Acceptable; minimal monitoring.
  * Moderate (4-6): Manageable; requires routine control.
  * High (8-12): Significant; requires a specific mitigation plan.
  * Extreme (15-25): Critical; requires immediate action and response.

=== 3.7.3. Risk Analysis, Handling, and Monitoring Table ===

The risk analysis highlights that logistical and physical risks (delivery and vandalism) pose the greatest threat to project success, like it is shown in Figure {{ref>risk_analysis_final}}.

<WRAP center round 100%>

<table risk_analysis_final>
<caption>Risk Analysis</caption>
^ ID ^ Risk Description ^ Probability ^ Impact ^ Score ^ Response ^ Management (Action) ^ Follow-up ^
| R1 | Delivery (Component delays) | 4 | 4 | 16 | Avoid | Purchase from local suppliers as soon as possible. | Weekly tracking of shipment ID. |
| R2 | Financial Constraint (Budget) | 3 | 4 | 12 | Mitigate | Use recycled materials for non-critical parts. | Bi-weekly review of expense log. |
| R3 | Team Synchronicity | 3 | 3 | 9 | Mitigate | Maintain open communication and shared task boards. | Weekly stand-up progress checks. |
| R4 | Safety Rejection (Metro) | 2 | 5 | 10 | Avoid | Strictly follow the Porto Metro technical manuals. | Regular design reviews with coaches. |
| R5 | Vandalism | 3 | 4 | 12 | Mitigate | Use tamper-proof screws and a robust housing. | Physical integrity testing. |
| R6 | Environmental Durability | 2 | 4 | 8 | Mitigate | Select chemical-resistant polymers for the housing. | Cleaning agent exposure tests. |
| R7 | Cybersecurity | 2 | 4 | 8 | Avoid | Implement encryption and secure QR protocols. | Firmware penetration testing. |
| R8 | Power Supply Instability | 3 | 3 | 9 | Reduce | Implement deep sleep modes in the ESP32 code. | Log power consumption. |
| R9 | Ergonomic Strain | 2 | 3 | 6 | Reduce | Create several 3D-printed prototypes for testing. | User feedback surveys. |
| R10 | Privacy Breach | 1 | 5 | 5 | Avoid | No personal data is collected via the application. | Legal checklist verification. |
</table>
</WRAP>

=== 3.7.3. Definition of Appropriate Risk Responses ===

Based on the results, our strategy prioritizes Extreme and High risks. Delivery (R1) and Vandalism (R5) require immediate mitigation through early procurement and robust mechanical design. 

For safety and privacy risks (R4, R10) and avoidance strategy is mandatory. We ensure the project is never at risk of legal or institutional rejection by following external regulations. 

All secondary risks are monitored through iterative testing to detect any score escalation.

===== 3.8. Procurement =====


Connect and share procurement strategy balances regulated industrial components with cost-effective prototyping through centralized purchasing and institutional resource utilization.

=== 3.8.1. Sources ===

Three procurement streams are defined:

  * Primary Hardware (Buy): Electronic components (microcontrollers, LEDs, transceivers) sourced from Mauser.pt to minimize delivery costs and ensure part compatibility.
  * Specialty Materials (Buy): Nanovia PA Rail filament procured internationally to meet EN 45545-2 fire safety standards, no equivalent Portuguese supplier identified.
  * Fabrication (Make): ISEP facilities used for 3D printing and lab testing, reducing costs to raw filament only.

=== 3.8.2. Make vs. Buy Decisions ===

The following Table {{ref>tab:makebuy}} summarizes the strategic choices for key project elements.

<WRAP center round box 100%>
<table tab:makebuy>
<caption>Make vs. Buy Decision Summary</caption>
^ Item ^ Decision ^ Rationale ^
| Electronic Nodes | Buy | Wemos C3 Mini boards offer greater reliability and lower cost than custom PCBs at prototype stage. |
| Enclosures | Make | 3D printing enables rapid design iteration and custom fit to metro handrail geometry. |
| Sensing Material | Buy | Velostat is a specialized piezoresistive material with no viable in-house alternative. |
| Web Platform | Make | Custom React/Supabase implementation ensures delayed-gratification logic and anonymization requirements are precisely met. |
</table>
</WRAP>

=== 3.8.3. Cost and Schedule Control ===

Expenditure is tracked against a detailed bill of materials within program budget constraints. Component procurement is milestone-gated to ensure availability before prototype assembly. Miscellaneous parts are sourced locally where possible to reduce lead times.

===== 3.9. Project Plan =====
As detailed in the Global Sprint Plan (see {{ref>sprint_plan}}), the project is divided into 15 distinct sprints.
<WRAP center round box 600px>
<table sprint_plan>
<caption>Global sprint plan</caption>
^  Sprint  ^  Start  ^  Finish  ^  Working days  ^
|  1  |  5 march  |  12 march  |  4 days of availability  |
|  2  |  12 march  |  19 march  |  5 days of availability  |
|  3  |  19 march  |  26 march  |  5 days of availability  |
|  4  |  26 march  |  2 april  |  5 days of availability  |
|  5  |  2 april  |  9 april  |  2 days of availability  |
|  6  |  9 april  |  16 april  |  3 days of availability  |
|  7  |  16 april  |  23 april  |  5 days of availability  |
|  8  |  23 april  |  30 april  |  5 days of availability  |
|  9  |  30 april  |  7 may  |  1 day of availability  |
|  10  |  7 may  |  14 may  |  3 days of availability  |
|  11  |  14 may  |  21 may  |  5 days of availability  |
|  12  |  21 may  |  28 may  |  5 days of availability  |
|  13  |  28 may  |  4 june  |  5 days of availability  |
|  14  |  4 june  |  11 june  |  5 days of availability  |
|  15  |  11 june  |  18 june  |  5 days of availability  |
</table>
</WRAP>

The specific tasks and deliverables assigned to these periods are managed in the Project Backlog (see Table {{ref>project_backlog}}).

<WRAP center round box 900px>
<table project_backlog>
<caption>Project backlog</caption>
^ Timeline ^ Epic ^ Ticket code ^ Ticket title ^ Status ^
| Sprint 1 (5 Mar - 12 Mar) | General / No Epic | SCRUM-3 | Communication presentation | Done |
| Sprint 1 (5 Mar - 12 Mar) | INITIATION & PLANNING | SCRUM-74 | Ideation discussion | Done |
| Sprint 1 (5 Mar - 12 Mar) | SYSTEM DESIGN & DRAWINGS | SCRUM-2 | Blackbox diagram | Done |
| Sprint 1 (5 Mar - 12 Mar) | SYSTEM DESIGN & DRAWINGS | SCRUM-21 | Drawings | Done |
| Sprint 1 (5 Mar - 12 Mar) | SYSTEM DESIGN & DRAWINGS | SCRUM-48 | Structural Drafts | Done |
| Sprint 2 (12 Mar - 19 Mar) | FINAL DELIVERABLES | SCRUM-26 | Flyer | Done |
| Sprint 2 (12 Mar - 19 Mar) | General / No Epic | SCRUM-75 | Selection of Materials & Components V2 | In Progress |
| Sprint 2 (12 Mar - 19 Mar) | General / No Epic | SCRUM-76 | Presentation for Teachers | Done |
| Sprint 2 (12 Mar - 19 Mar) | INITIATION & PLANNING | SCRUM-42 | Backlog, Gantt and Sprint Plan | Done |
| Sprint 2 (12 Mar - 19 Mar) | INTERIM REPORT-WIKI CONTENT | SCRUM-55 | Background and Related Work | In Progress |
| Sprint 2 (12 Mar - 19 Mar) | INTERIM REPORT-WIKI CONTENT | SCRUM-57 | Marketing Plan | In Progress |
| Sprint 2 (12 Mar - 19 Mar) | INTERIM REPORT-WIKI CONTENT | SCRUM-58 | Eco-Efficiency Measures for Sustainability | In Progress |
| Sprint 2 (12 Mar - 19 Mar) | INTERIM REPORT-WIKI CONTENT | SCRUM-73 | Canvas | Done |
| Sprint 2 (12 Mar - 19 Mar) | INTERIM REPORT-WIKI CONTENT | SCRUM-79 | 4.1 Introduction | To Do |
| Sprint 2 (12 Mar - 19 Mar) | INTERIM REPORT-WIKI CONTENT | SCRUM-80 | 4.2 Business Idea Formulation | To Do |
| Sprint 2 (12 Mar - 19 Mar) | INTERIM REPORT-WIKI CONTENT | SCRUM-81 | 4.3 Business Model | To Do |
| Sprint 2 (12 Mar - 19 Mar) | INTERIM REPORT-WIKI CONTENT | SCRUM-82 | 4.4 Market Analysis | To Do |
| Sprint 2 (12 Mar - 19 Mar) | INTERIM REPORT-WIKI CONTENT | SCRUM-83 | 4.5 SWOT Analysis | To Do |
| Sprint 2 (12 Mar - 19 Mar) | INTERIM REPORT-WIKI CONTENT | SCRUM-84 | 4.6 Strategy | To Do |
| Sprint 2 (12 Mar - 19 Mar) | INTERIM REPORT-WIKI CONTENT | SCRUM-85 | 4.7 Marketing Programs | To Do |
| Sprint 2 (12 Mar - 19 Mar) | INTERIM REPORT-WIKI CONTENT | SCRUM-86 | 4.8 Conclusion | To Do |
| Sprint 2 (12 Mar - 19 Mar) | SYSTEM DESIGN & DRAWINGS | SCRUM-49 | Selection of Materials & Components v1 | Done |
| Sprint 2 (12 Mar - 19 Mar) | SYSTEM DESIGN & DRAWINGS | SCRUM-50 | Name and Logo | Done |
| Sprint 3 (19 Mar - 26 Mar) | General / No Epic | SCRUM-77 | Ethics Scandal PowerPoint | To Do |
| Sprint 3 (19 Mar - 26 Mar) | SYSTEM DESIGN & DRAWINGS | SCRUM-51 | Detailed Schematics | To Do |
| Sprint 3 (19 Mar - 26 Mar) | SYSTEM DESIGN & DRAWINGS | SCRUM-52 | Structural Drawings | To Do |
| Sprint 3 (19 Mar - 26 Mar) | SYSTEM DESIGN & DRAWINGS | SCRUM-53 | Cardboard Model | To Do |
| Backlog | CLOSING | SCRUM-63 | Update Wiki & MS Teams (Final Deliverables) | To Do |
| Backlog | FINAL DELIVERABLES | SCRUM-20 | Final List of Materials & Components | To Do |
| Backlog | FINAL DELIVERABLES | SCRUM-23 | Code | To Do |
| Backlog | FINAL DELIVERABLES | SCRUM-24 | 3D Model Video | To Do |
| Backlog | FINAL DELIVERABLES | SCRUM-25 | Flyer | Done |
| Backlog | FINAL DELIVERABLES | SCRUM-27 | Packaging Solution | To Do |
| Backlog | FINAL DELIVERABLES | SCRUM-28 | Manual | To Do |
| Backlog | FINAL DELIVERABLES | SCRUM-29 | Simulations | To Do |
| Backlog | FINAL DELIVERABLES | SCRUM-32 | Final Report | To Do |
| Backlog | FINAL DELIVERABLES | SCRUM-33 | Final Presentation | To Do |
| Backlog | FINAL DELIVERABLES | SCRUM-34 | Paper | To Do |
| Backlog | FINAL DELIVERABLES | SCRUM-35 | Poster | To Do |
| Backlog | FINAL DELIVERABLES | SCRUM-36 | Video | To Do |
| Backlog | FINAL DELIVERABLES | SCRUM-62 | Selection of Local Providers | To Do |
| Backlog | General / No Epic | SCRUM-30 | Interim Report | To Do |
| Backlog | INTERIM REPORT-WIKI CONTENT | SCRUM-54 | Introduction | To Do |
| Backlog | INTERIM REPORT-WIKI CONTENT | SCRUM-56 | Project Management | To Do |
| Backlog | INTERIM REPORT-WIKI CONTENT | SCRUM-59 | Ethical and Deontological Concerns | To Do |
| Backlog | INTERIM REPORT-WIKI CONTENT | SCRUM-60 | Project Developments | To Do |
| Backlog | INTERIM REPORT-WIKI CONTENT | SCRUM-61 | Conclusions | To Do |
| Backlog | PROTOTYPE DEVELOPMENT | SCRUM-69 | Figma Designs for Message Application | To Do |
| Backlog | PROTOTYPE DEVELOPMENT | SCRUM-78 | Message Application code | To Do |
| Backlog | TESTING | SCRUM-66 | Functional testing | To Do |
| Backlog | TESTING | SCRUM-67 | Non-functional testing | To Do |
| Backlog | TESTING | SCRUM-68 | User-acceptance testing | To Do |
</table>
</WRAP>


The high-level distribution of Epic responsibilities across the timeline is summarized in the Initial Sprint Plan (see Table{{ref>initial_sprint}}).

<WRAP center round box 900px>
<table initial_sprint>
<caption>Initial sprint plan</caption>
^ Sprint ^ Start ^ Finish ^ Epics ^ Responsible ^
| 1 | 5 march | 12 march | INITIATION & PLANNING | All |
| 2 | 12 march | 19 march | INITIATION & PLANNING ; SYSTEM DESIGN & DRAWINGS ; FINAL DELIVERABLES | All |
| 3 | 19 march | 26 march | INITIATION & PLANNING ; SYSTEM DESIGN & DRAWINGS | All |
| 4 | 26 march | 2 april | SYSTEM DESIGN & DRAWINGS ; INTERIM REPORT & PRESENTATION | All |
| 5 | 2 april | 9 april | INTERIM REPORT & PRESENTATION | All |
| 6 | 9 april | 16 april | PROTOTYPE CONSTRUCTION ; FINAL DELIVERABLES | All |
| 7 | 16 april | 23 april | PROTOTYPE CONSTRUCTION ; FINAL DELIVERABLES | All |
| 8 | 23 april | 30 april | PROTOTYPE CONSTRUCTION ; FINAL DELIVERABLES | All |
| 9 | 30 april | 7 may | PROTOTYPE CONSTRUCTION ; FINAL DELIVERABLES | All |
| 10 | 7 may | 14 may | PROTOTYPE CONSTRUCTION ; FINAL DELIVERABLES | All |
| 11 | 14 may | 21 may | PROTOTYPE CONSTRUCTION ; FINAL DELIVERABLES | All |
| 12 | 21 may | 28 may | PROTOTYPE CONSTRUCTION ; FINAL DELIVERABLES | All |
| 13 | 28 may | 4 june | FINAL REPORT, PRESENTATION & VIDEO | All |
| 14 | 4 june | 11 june | FINAL REPORT, PRESENTATION & VIDEO | All |
| 15 | 11 june | 18 june | FINAL REPORT, PRESENTATION & VIDEO ; FINAL DELIVERABLES | All |
</table>
</WRAP>

Lastly, the visual dependencies and duration of these tasks are illustrated in the Gantt Chart (see Figure {{ref>fig:gantt_chart}}).

<WRAP centeralign>
<figure fig:gantt_chart>
{{ :report:eps_group_5_2026-03-19_06.11pm.png?nolink&1200 | Gantt chart }}
<caption>Timeline for this project (Gantt chart)</caption>
</figure>
</WRAP>

==== 3.10. Sprint Outcomes ====

Sprints 1 & 2 were not managed in Jira and there were no specific tasks to be done. However, the idea of the project had been forming before Sprint 3 and some outcomes were achieved such as:
  * **Black Box Diagram V1**
  * **Structural Drawings V1**
  * **Selection of materials and components V1**
  * **Inicial sketches of our project idea**

Bellow, we can see Table {{ref>sprint_reports}}, where we can find all Burn Down Chart from Sprint 3, with the which was first sprint managed in Jira.

<WRAP center round box 600px>
<table sprint_reports>
<caption>Reports of sprint exported from Jira</caption>
^ Sprint ^ Report Link ^
| Sprint 3 | {{ :report:sprint_3_report.pdf | Sprint 3 Report}} |
| Sprint 4 | {{ :report:sprint_4_report.pdf | Sprint 4 Report}} |
</table>
</WRAP>

=== 3.10.1 Sprint 3 Outcome ===
In Sprint 3 we consolidated both the technical foundation of the project and the supporting documentation. The team completed all planned issues in Jira, with no carry‑over work. Key outcomes included updated structural drawings and schematics (V2), the cardboard model, and a refined selection of materials and components. We also advanced the digital side with Figma designs for the message application and progressed written deliverables such as the background/related work and eco‑efficiency measures. Routine work like daily meetings, the sprint retrospective, and logbook updates was completed, ensuring the project stayed aligned and well documented.

=== 3.10.2 Sprint 4 Outcome ===
In Sprint 4 we advanced both the written deliverables and the technical foundations of the CONNECT system. The team completed the core report chapters (Introduction, Background & Related Work, Marketing Plan, Eco‑Efficiency Measures, Ethical & Deontological Concerns) and updated the project wiki start page, ensuring the documentation is coherent and aligned with the project vision. On the technical side, we produced Structural Drawings V3 with measurements, Detailed Schematics V3, a general software flow chart, and updated the list of materials and components, while also finalizing the clickable web app prototype and the design system/brand guidelines. Routine process tasks such as daily meetings, the sprint retrospective, and logbook updates were completed, keeping communication and traceability strong. Some higher‑effort items like Chapter 3 – Project Management, Chapter 7 – Project Developments, and the Interim Presentation remained in progress and will be continued in Sprint 5.

==== 3.11. Sprint Evaluations ====
Sprint evaluations and retrospectives are fundamental to the team’s Agile workflow, allowing for continuous process improvement. Starting from Sprint 3, the team implemented formal retrospective sessions to identify bottlenecks and refine internal methodologies.

=== 3.11.1. Sprint 3 Retrospective ===
In this sprint, the focus was on establishing the technical foundation. The retrospective revealed significant gaps in task granularity and time management.

Retrospective Summary:

  *Positive (+): Effective feedback loops with professors and proactive note-taking during presentations.

  *Negative (-): Vague backlog items, inconsistent Jira updates, and poor workload distribution.

  *Action Plan: The team committed to breaking down tasks into sub-tasks (max 4h each) and ensuring Jira is updated daily.

=== 3.11.2. Sprint 4 Retrospective ===
Following the action plan from the previous sprint, Sprint 4 showed a marked improvement in organization and team morale.

Retrospective Summary:

  *Positive (+): High motivation, excellent mutual support, and a much more balanced task distribution.

  *Negative (-): No major process blockers identified; the workflow reached a stable state.

  *Action Plan: Focus on maintaining the current communication frequency and standardizing the documentation style for the upcoming deliverables.


==== 3.12. Summary ====
This chapter detailed the management strategies used to organize and track the project's progress. We established the core foundations for scope, time, and cost, while also setting up protocols for quality, risk, and procurement. Managing communications and stakeholders was also key to keeping the workflow consistent and transparent.

These management pillars are put into practice through a cycle of continuous planning and execution. The Sprint outcomes and evaluations documented here reflect our ongoing effort to refine the workflow and hit project milestones. With the management structure in place, the focus now shifts to the Marketing Plan to define the project's market strategy and value proposition.