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.

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 1 ilustrates how we have divided the project into manageable phases and specific deliverables.

The EPS teams have to complete a list of milestones to ensure project succes. The following Table 1 defines the project timeline, acting as the baseline to monitor the project's performance.

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.

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.

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 2 presents the planned ideal product hardware costs.

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.

All components were procured through a single supplier (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 3 presents total list and pricing of components for the prototype. Planned cost is 3.55 € below budget ceiling (100 €).

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.

To quantify the success of our work, we have established specific metrics and acceptance thresholds. As seen in Table 4 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.

While metrics define “what” we want to achieve, our verification system ensures “how” we check it. Table 5 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.

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.

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.

Apart from the main teams, several external entities are involved in the project. In the Table 6 below, we identified them, their roles and their responsibilities.

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.

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 2, categorizes our stakeholders into four quadrants to determine the necessary level of engagement for each group.

B) ENGAGEMENT STRATEGY TABLE

While the matrix identifies the “where”, the following Table 7 defines the “how”. It establishes the specific strategy for each group and assigns a point person from the internal team to manage the relationship.

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

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.

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.

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.

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.

To evaluate these risks, we adopt a 5×5 Risk Matrix seen on the Figure 3. 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)

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.

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 9.

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.

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

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.

The following Table 10 summarizes the strategic choices for key project elements.

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.

As detailed in the Global Sprint Plan (see 11), the project is divided into 15 distinct sprints.

The specific tasks and deliverables assigned to these periods are managed in the Project Backlog (see Table 12).

The high-level distribution of Epic responsibilities across the timeline is summarized in the Initial Sprint Plan (see Table13).

Lastly, the visual dependencies and duration of these tasks are illustrated in the Gantt Chart (see Figure 4).

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 14, where we can find all Burn Down Chart from Sprint 3, with the which was first sprint managed in Jira.

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.

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.

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.

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.

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.

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.