This chapter presents the project management approach used to organize and guide the development of Maris Habitats. It briefly explains how the team managed scope, time, cost, quality, stakeholders, communication, risk, procurement, and planning. The chapter also describes how Scrum and sprint evaluations were used to support progress and adapt to challenges during the project

Managing a project that intersects marine ecology, hardware engineering, and software development requires a framework that balances rigid constraints with creative flexibility. This chapter details the management strategy employed by the group, organized across key knowledge areas including scope, risk, and procurement.

Due to the unpredictable nature of environmental hardware testing, an Agile methodology (SCRUM based) was adopted. This iterative approach was essential for managing the project. By prioritizing continuous feedback loops and adaptive planning, the team was able to pivot in response to technical challenges without compromising the project's primary milestones or budgetary limits.

The scope of this project is the design and development of a functional prototype of a smart marine habitat intended to support seafloor biodiversity and enable environmental monitoring in underwater conditions. The project focuses on creating a concept that combines an artificial habitat structure with a basic sensor system, while taking into account sustainability, durability, and ecological compatibility [1].

From a product perspective, the project includes the development of a modular underwater habitat structure designed to provide shelter, attachment surfaces, and spatial complexity for marine organisms. In addition, the product includes an integrated monitoring concept based on selected sensors capable of collecting environmental data relevant to the surrounding habitat, such as temperature, pH, turbidity, or depth, depending on technical feasibility and component availability. The solution also includes a basic embedded electronics system for sensor integration, power management, and data handling, as well as a conceptual approach for transmitting or presenting the collected data. The overall product is intended to demonstrate how habitat restoration and environmental monitoring can be combined into a sustainable solution.

From a project perspective, the scope includes the research and analysis required to understand the environmental problem, existing artificial reef solutions, suitable structural materials, and underwater sensor technologies. It also includes the definition of requirements, concept development, design selection, structural modelling, component selection, and prototype integration. The project covers the testing and validation of the prototype under limited and controlled conditions, together with the assessment of market, sustainability, ethical, and project management aspects. The preparation of all academic deliverables, including the report, presentation, poster, flyer, and supporting documentation, is also part of the project scope.

The main outcome of the project is a functional prototype that demonstrates the technical feasibility and conceptual value of a smart artificial marine habitat. The prototype is intended to serve as a foundation for future development, testing, and scaling in real-world marine applications.

The Work Breakdown Structure (WBS) presented in the figures 1 and 2 illustrates how the Maris Habitats system is divided into its main components and subsystems [2]. The diagram provides an overview of the product architecture, showing how the habitat structure, sensor system, energy and communication, deployment, and maintenance elements are organized.

Each main component is further broken down into smaller elements, representing the key functionalities required for the system to operate. This visual representation helps clarify the scope of the project by identifying all relevant parts of the system and their relationships.

Figure 1 presents the WBS for the product and Figure 2 the WBS of the project.

To ensure effective time management and the timely completion of the project, tasks were scheduled to be completed during school hours and before weekends. This approach helped maintain steady progress and allowed time for review and adjustments when needed [3].

The team followed the milestone schedule defined by the project supervisors over a total project duration of 118 days, from 2026-02-28 to 2026-06-25. These milestones provided a structured framework to monitor progress and ensure alignment with the overall project timeline. Table 1 presents the defined milestones.

When estimating the total cost of the project, two main factors must be considered: employee salaries and the cost of materials and components.

The average salary for a junior engineer in Portugal is approximately 1 500 € per month, and the project duration is five months. With a team of six employees, the total salary cost is calculated as: 6 employees × 1 500 € × 5 months = 45 000 €.

The material costs are divided into two categories: components and sensors. The total cost of the electronics and components is 2215.66 €.

A detailed overview of the individual component and sensor costs is provided in Table 2.

In addition to the component costs, supplier shipping costs for the electronic components and sensors must also be taken into account. These are presented in Table 6. Including shipping, the total cost of these components increases to 2526.11 €.

The project includes the cost of structural materials used for the habitat modules. Each block/module is composed of approximately 30 kg of concrete (C) and 70–90 g of basalt fiber (BF). These are shown in Table 4.

Based on current market prices, concrete costs 89 € per 1000 kg, while basalt fiber costs 34.16 € per 1.36 kg. This results in an estimated material cost of 2.67 € for concrete and 1.76 € for basalt fiber per block.

Therefore, the total material cost per block is approximately 4.43 €.

It should be noted that this estimate is based on small-scale purchasing prices. For larger production volumes, the cost per unit is expected to decrease due to bulk pricing and supplier agreements.

The total cost of the project, including labor, electronics, components, sensors, transportation and shipping, is estimated to be 47 526.11 €, excluding the structural material cost of the habitat blocks. The structural material cost is estimated at 4.43 € per block, depending on the number of blocks produced.

It is important to note that this cost estimate represents the final product configuration, and not the prototype.

Prototype list

When selecting electronic components for the prototype, efforts were made to replicate the final product as closely as possible within the constraints of a 100 € budget. In addition, components were sourced from as few suppliers as possible in order to minimize transportation and shipping costs.

The selected electronics used in the prototype are presented in Table 6.

The estimated total cost of the electronics is 102 €, including shipping, as summarized in Table 7.

For the remaining component selection, suppliers offering local pickup were prioritized in order to avoid additional transportation costs.

These materials are summarized in Table 8.

The different prototype cost scenarios are summarized in Table 9, showing how additional materials such as concrete and 3D printing filament affect the overall cost.

The impact of procurement strategy on shipping costs is shown in Table 10, where the difference between in-store pickup and online ordering is highlighted.

Although the estimated total cost exceeds the budget, some components and materials may already be available at the university, reducing the need for additional purchases. Furthermore, transportation costs may be avoided if other groups are also ordering from the same supplier and the total order exceeds the free shipping limit. Consequently, the actual cost is difficult to determine precisely but is expected to be lower than the estimated 136 €.

The materials that were actually provided for the prototype were similar to the components and materials originally requested by the team. Although some parts differed slightly from the initial list, they fulfilled the same basic purpose and were suitable for building and testing the prototype. The total cost of the provided prototype parts was approximately 90 €.

Quality in the project is ensured by defining measurable quality metrics for both the product and the documentation. These metrics help the team evaluate whether the system works as intended, meets the project requirements, and is clearly documented.

For the product, the main quality areas are sensor performance, waterproofing, structural stability, data logging, energy efficiency, maintainability, and environmental compatibility. For the documentation, quality is evaluated through clarity, completeness, structure, and consistency. The metrics are reviewed through prototype testing, design reviews, sprint meetings, and supervisor feedback [4] (See Table 11).

The prototype will be checked by testing the main parts one by one. First, the team will confirm that the smartlogger starts correctly and that the sensors give values in the Serial Monitor. Then the SD card file will be opened to check that the values are stored with the correct time interval. The physical prototype will also be checked by measuring the structure, testing that it stands stable. The results from these checks will show whether the prototype is good enough for the final demonstration.

The prototype is good enough when it can run the logging program, read the sensors, and save data to the SD card without stopping during the test. The structure must also be stable and possible to handle without loose parts or damaged connections. Since this is only a prototype, the goal is to prove that the concept works, not to prove that it is ready for long-term underwater use.

People involved in a project can create uncertainty if responsibilities, communication routines and workload are not clearly defined. For this reason, people management is important in the Maris Habitats project. The project requires collaboration between team members from different academic backgrounds, including design, electronics, software, documentation, sustainability and project management.

The team does not have one permanent project manager. Instead, all team members share responsibility for project progress, decision-making and following the project scope. Tasks are distributed based on skills, availability, workload and interest in order to make the work more efficient and balanced.

The key factors considered when assigning tasks are:

Skills and expertise

Each team member has different knowledge and technical strengths. Tasks are therefore assigned according to individual skills, such as design, electronics, software, research, communication or documentation. This helps improve the quality of the project outcome.

Roles and responsibilities

Clear roles and responsibilities are important to avoid confusion, duplicated work and missed tasks. Each team member is responsible for completing assigned tasks and communicating progress to the rest of the group.

Availability and workload

The workload should be distributed fairly between team members. Since the project includes many different deliverables, such as the report, prototype, poster, video, manual and presentation, the team must make sure that no member is overloaded.

Interest and motivation

When possible, tasks are assigned according to each member’s interests. This increases motivation, engagement and productivity, while also helping the team produce better results.

Collaboration and team dynamics

Since Maris Habitats is a multidisciplinary project, collaboration is essential. Team members must share information, support each other and communicate regularly to make sure that the structure, smartlogger, documentation and prototype development remain aligned. See Table 12.

The purpose of this structure is to ensure that all team members understand their responsibilities and contribute to the overall progress of the project. By combining different skills and distributing tasks clearly, the team can reduce uncertainty and improve collaboration throughout the project.

Stakeholder management is used to identify, analyze and communicate with the people, groups and organizations that can affect or be affected by the project. For Maris Habitats, this is important because the project combines academic requirements, technical development, marine restoration, environmental monitoring and potential future users of the system.

The stakeholders were divided into internal and external groups. Internal stakeholders are directly involved in the project development, such as the team members, EPS coordinator, supervisors and professors. External stakeholders are not part of the daily project work, but they may influence the project or benefit from the final solution. These include suppliers, research institutions, environmental NGOs, public authorities, potential customers and marine life.

To understand how the team should communicate with each stakeholder, a power-interest matrix was created. This matrix shows which stakeholders need close involvement, which should be kept informed, and which only require limited monitoring. Figure 3 presents the stakeholder matrix for Maris Habitats.

The project team, supervisors, coordinator and client/project owner are placed in the high-interest and high-power category because they are directly connected to project decisions, evaluation and progress. These stakeholders must therefore be managed closely through regular meetings, feedback, documentation and continuous communication.

Stakeholders such as ISEP and project supervisors have strong influence on the academic framework, but they are not involved in every daily task. They should be kept satisfied through formal deliverables, progress updates and clear communication. Future users, research institutions, NGOs and possible investors have high interest in the final product, but limited influence during the current prototype phase. These stakeholders should be kept informed through reports, presentations and future collaboration opportunities. Stakeholders with low power and low interest, such as logistics partners and the general public, only need to be monitored when relevant.

The stakeholder overview in Table 13 gives a more detailed explanation of each stakeholder’s role, interest and engagement strategy.

The main engagement strategy is based on regular communication and clear documentation. Internal stakeholders are involved through weekly supervisor meetings, team meetings, Jira updates and wiki documentation. Feedback from supervisors and professors is used to improve the design, prototype, report and final deliverables.

For external stakeholders, the engagement strategy is more focused on presenting the value and feasibility of the concept. This includes explaining how Maris Habitats can support marine restoration, collect environmental data and reduce disturbance through the removable smartlogger.

Stakeholder-related risks include unclear communication, delayed feedback, supplier delays and misunderstandings about project expectations. These risks are reduced through regular meetings, defined responsibilities, updated documentation and early procurement planning.

Stakeholder management helps the team keep the project aligned with academic expectations, technical requirements and future user needs. It also supports better decision-making and improves the feasibility of Maris Habitats as a marine restoration and monitoring solution [5].

Effective communication is important to ensure coordination, transparency and steady progress throughout the Maris Habitats project. Since the team consists of members from different academic backgrounds and nationalities, clear communication routines are necessary to avoid misunderstandings, distribute tasks effectively and keep all project work aligned [6].

Guidelines for Meetings

Meeting agenda

For the weekly supervisor meetings, a meeting agenda is prepared before the meeting. The agenda includes the main topics to be discussed, current progress, challenges, questions for the supervisors and tasks that need clarification. This helps the team use the meeting time efficiently and ensures that important issues are addressed.

Meeting minutes

Meeting minutes are written after the weekly meetings and uploaded to the wiki or shared with the team. The minutes summarize the topics discussed, feedback received, decisions made and new tasks or agreements. This makes it easier for all team members to follow up on responsibilities and keep track of project progress.

Pitch

One person is responsible for leading the pitch and making sure that the agenda is followed. This role can change between meetings depending on the topic being discussed and the team member responsible for that area.

Note taker

The note taker documents the main points discussed during the meeting. This includes supervisor feedback, decisions, action points and deadlines. The note taker is also responsible for helping update the meeting minutes.

Time keeper

The time keeper helps the team stay within the planned meeting time. During supervisor meetings, this responsibility is usually supported by the supervisors or professors, while in internal meetings the team members manage the time together.

Table 14 shows the type of communications during the project.

Communication Tools and Means

Microsoft Teams is used as the main platform for receiving information, resources and announcements from professors and supervisors. It is also used to access shared project material.

Outlook is used for formal communication with professors, supervisors and external contacts. This includes meeting-related communication, questions and supplier contact when needed.

WhatsApp is used for fast internal communication between team members. It is mainly used for daily updates, quick questions, reminders and urgent issues that need to be solved quickly.

Jira is used as the main project management tool. The team uses Jira to organize tasks, update progress, manage sprint work and track responsibilities.

The wiki is used as the main documentation platform. Project information, report content, deliverables, meeting minutes and progress updates are uploaded there throughout the project.

This communication structure helps the team maintain a clear workflow, follow deadlines and solve problems early. Regular meetings, shared documentation and continuous task updates support collaboration and ensure that all members remain informed about the development of Maris Habitats. See 15 table for the communication approaches with stakeholders.

The project involves several potential risks related to both technical and organizational aspects. One of the main risks is technical failure, particularly in the integration of sensors, electronics, and structural components in a marine-like environment. To reduce this risk, the system is tested in controlled conditions and components are selected based on reliability and compatibility.

Another significant risk is project delays due to time constraints and task dependencies. This is managed through sprint planning, regular meetings, and the use of buffer time to accommodate unforeseen issues.

There is also a risk related to limited resources, including budget constraints and access to specialized equipment or testing environments. This is addressed by prioritizing essential features and selecting cost-effective solutions [7].

Team-related risks such as miscommunication or uneven workload distribution may affect progress. These risks are mitigated through regular Scrum meetings, clear task allocation, and continuous collaboration among team members (see Table 16).

To further support the risk assessment, a risk matrix based on probability and impact was used. The matrix classifies risks into three categories: low, medium, and high, depending on their likelihood of occurrence and potential impact on the project.

Based on this matrix, risks such as technical failure, power system failure, integration issues, and project delays are classified as high risk, as they combine medium to high probability with high impact. These risks require priority attention and mitigation (see Figure 4).

Risks such as limited resources, corrosion, extreme weather conditions, and data transmission failure fall into the medium-risk category. These are monitored and addressed through preventive design measures and planning.

Lower-risk factors, including team miscommunication and uneven workload distribution, are classified as low risk, as they have limited impact and can be managed through regular communication and task organization.

The use of this risk matrix provides a clear and structured way to prioritize risks and supports more effective decision-making throughout the project [8].

The procurement plan is presented in three tables. Table 17 provides an overview of the electrical components required for the habitat, while Table 18 presents the material composition and cost of the concrete blocks used in the habitat structure.

Each item includes both a primary supplier and a designated backup supplier, ensuring supply reliability and reducing the risk of delays due to stock shortages or delivery issues.

The project schedule was visualized using a Gantt chart to illustrate the timeline and key phases of the project.

As shown in Figure 5, the project timeline spans from March to June and includes overlapping phases such as research, prototype development, and documentation.

The global sprint plan provides an overview of the project timeline, including the duration of each sprint, start and end dates, and the number of available working days. Its main purpose is to ensure a realistic distribution of workload based on the team’s availability throughout the project period. See Table 19 for the global sprint plan.

By defining how long each sprint lasts and how many working days are available, the team can better plan tasks and avoid overloading specific periods. Variations in working days reflect differences in availability, such as holidays or other commitments, which allows for more accurate and achievable planning.

The project backlog contains all identified tasks required to complete the project. Tasks are continuously updated and prioritized based on project needs, deadlines, and dependencies. Completed tasks are marked as “Done”, while ongoing and future tasks are labeled accordingly. Table 20 lists the backlog.

Sprint 1 (Week 3: 19 Mar – 26 Mar)

Sprint Goal: Establish the project foundation by defining roles, conducting initial research, and setting up key project documentation (see Table 21).

The tasks in the sprint were divided into smaller activities, including research, documentation, design, and planning, in order to ensure efficient progress. Responsibilities were distributed among team members based on their respective roles, with a focus on areas such as research, documentation, and design. By the end of the sprint, key project elements such as clearly defined team roles, initial research, and planning documents had been completed, providing a solid foundation for the subsequent sprints.

The sprints officially started from March 19th to March 26th, as the previous weeks were mainly used to become familiar with Jira and project tools.

An overview of the outcomes from the initial sprints is presented in Table 22 and Table 23.

Sprint 3

The burndown chart for sprint 3 shows that additional tasks were identified and added at the beginning of the sprint, resulting in an increase in the total amount of work. This reflects a better understanding of the project requirements as the team moved from concept to design.

During the middle of the sprint, progress remained relatively stable, indicating that fewer tasks were completed in that period. Towards the end of the sprint, a significant decrease in remaining work can be observed, showing that most tasks were completed close to the deadline.

This pattern indicates that the team made substantial progress during sprint 3, particularly in the final phase, where key design elements and system components were defined. It also highlights the need for improved task distribution to ensure more consistent progress throughout the sprint (see Figure 6).

Sprint 4

The burndown chart for Sprint 4 shows a noticeable increase in workload at the beginning of the sprint, indicating that additional tasks were identified as the project scope became clearer. This reflects an ongoing refinement of requirements and system definition. Shown in Figure 7.

Throughout most of the sprint, progress was relatively slow, with only minor reductions in remaining work. A more significant decrease occurs towards the end, suggesting that many tasks were completed close to the deadline.

This pattern indicates that work was concentrated in the final phase of the sprint. Although the planned objectives were achieved, this approach suggests a need for better time management and a more even distribution of tasks across the sprint.

Sprint 5

The burndown chart for Sprint 5 shows no significant changes in the remaining workload throughout most of the sprint. This indicates that tasks were not actively tracked or completed within the sprint period. Week 5 is shown in Figure 8.

This sprint coincided with the Easter holiday, during which no substantial work was carried out. Additionally, the project management tool (Jira) was not updated during this period, resulting in a lack of visibility and progress tracking.

The sprint did not function as intended and cannot be considered effective from an Agile perspective. The absence of recorded progress highlights the importance of maintaining consistent engagement and updating project management tools, even during periods of reduced activity.

Sprint 6

The burndown chart for Sprint 6, shown in Figure 9, indicates limited progress during the initial phase of the sprint, suggesting that relatively little work was carried out at the beginning of the period.

An increase in the remaining workload can also be observed on April 14th, when new tasks were added after the sprint had already started. This was partly caused by incomplete tasks from Sprint 5 being carried over into Sprint 6. As a result, the workload appears to increase rather than decrease at that stage.

Towards the end of the sprint, a noticeable reduction in remaining work is observed, indicating that several tasks were completed before the sprint was concluded.

This pattern reflects an improvement in task completion compared to the previous sprint. However, it also highlights the importance of maintaining consistent progress and timely updates in order to ensure accurate tracking and effective sprint execution.

Sprint 7

The burndown chart for Sprint 7 shows that little or no progress was recorded during the first part of the sprint. No significant task completion was registered until April 20th, when a new task was added to the sprint. Most of the remaining work was then checked off on the final day of the sprint. This indicates that tasks were either completed late or not updated continuously in Jira. As a result, the burndown chart does not show a steady reduction in workload. This sprint demonstrates the importance of updating tasks more regularly and ensuring that work is distributed more evenly throughout the sprint. The burndown chart for Sprint 7 is shown in Figure 10.

Sprint 8

The burndown chart for Sprint 8 shows that the sprint was started before all tasks had been properly added and assigned story points. This made the initial sprint planning less accurate and reduced the reliability of the burndown chart.

During the sprint, the workload was adjusted again. On April 28th, story points were added or changed, which affected the chart after the sprint had already started. Despite these changes, all tasks were completed by the end of the sprint.

Although the final outcome was positive, the chart shows that the sprint was not planned according to Scrum principles, since tasks and story points should ideally be defined before the sprint begins. The burndown chart for Sprint 8 is shown in Figure 11.

Sprint 9

The burndown chart showed a more positive development during sprint 9 shown in shown in Figure 12. This was mainly because no new tasks were added throughout the week, and completed tasks were checked off regularly. However, the sprint contained relatively few tasks, and several of the tasks that were completed were finished early in the sprint. The remaining tasks were more extensive and required more time than expected, which resulted in them being moved to the next sprint.

Sprint 10 Sprint 10 was a short sprint with only two working days. The sprint contained relatively few tasks, and most of them were completed steadily during the sprint period. However, one task was added after the sprint had already started. This is not ideal according to Scrum principles, because the sprint backlog should normally be defined before the sprint begins. Adding tasks during the sprint can make the burndown chart less accurate and affect the team’s ability to evaluate progress correctly.

Despite this, the sprint was mostly successful because the planned workload was limited and the tasks were completed within the short sprint period. The burndown chart for Sprint 10 is shown in Figure 13.

Sprint 11 The burndown chart for Sprint 11 shows that no significant progress was recorded until the final day of the sprint. This indicates poor workload distribution, as most tasks were either completed late or not updated in Jira during the sprint. The lack of progress during the earlier part of the sprint made it difficult to track whether the team was on schedule. It also reduced the usefulness of the burndown chart as a project management tool. This sprint highlights the need for better time management, earlier task completion, and more regular updates in Jira. The burndown chart for Sprint 11 is shown in Figure 14.

Sprint 12 The burndown chart for Sprint 12 shows that limited progress was made at the beginning of the sprint. As in previous sprints, a new task was added after the sprint had already started, which changed the sprint scope during the sprint period. At the same time, one task was completed and checked off, resulting in some reduction in remaining work. By the end of the sprint, only two incomplete tasks remained. This shows that the team made progress and completed most of the planned work, even though the sprint planning was not fully stable from the beginning. Sprint 12 shows an improvement compared with earlier sprints, but it also demonstrates that tasks should be added and estimated before the sprint starts to improve planning accuracy. The burndown chart for Sprint 12 is shown in Figure 15.

Sprint 13 The burndown chart for Sprint 13 shows that no significant progress was recorded until June 1st. On this date, a new task was added to the sprint and assigned story points, which increased the total workload after the sprint had already started. The sprint was also closed one day earlier than planned. As a result, several tasks were not completed during Sprint 13 and had to be transferred to the Week 14 sprint. This affected the accuracy of the sprint outcome and shows that the planned workload was not fully achieved. On June 3rd, a significant part of the sprint work was completed or closed. However, because several tasks had already been moved forward, the sprint does not show a steady or fully successful workflow. Sprint 13 highlights challenges related to late task creation, incomplete sprint execution, and early sprint closure. It also shows the importance of completing and updating tasks within the correct sprint period to ensure accurate progress tracking. The burndown chart for Sprint 13 is shown in Figure 16.

Sprint 14 The burndown chart for the sprint from June 3rd to June 11th shows that the remaining work did not decrease steadily according to the ideal guideline. During the first part of the sprint, progress was limited, as the number of remaining story points stayed almost unchanged. A clearer reduction can be seen around June 8th, indicating that several tasks were completed or updated at the same time. Towards the end of the sprint, more progress was made, but the sprint still ended with remaining work. This shows that the team made progress, but task completion and Jira updates were not evenly distributed throughout the sprint. Sprint 14 is shown in Figure 17.

Positive Aspects During this week, the team worked well together and showed good coordination in roles and responsibilities. The wiki and Jira were kept relatively updated, and the team made solid progress in research and design. There were also strong ideas developed for the project’s features, structure, and overall concept, along with progress on the ethics work. Overall, the team showed improvement in both collaboration and organization.

Challenges During this week, the team faced several challenges. There was a lack of clear discussion about project expectations, which led to some uncertainty. Task division was not always effective, and deadlines were not used efficiently. The wiki and report structure were somewhat disorganized, with resources not properly organized or uploaded. Additionally, the team could have shown more initiative and been more critical of their work. Overall, better structure, clarity, and efficiency are needed moving forward.

Ideas for Improvement During this week, the team developed ideas to improve the project by focusing on one main “smartblock” with simpler supporting blocks. They also explored sustainable materials, clearer separation between prototype and final product, and ways to improve functionality, such as adding sensors and using 3D printing.

Actions for Next Week For the next week, the team should focus on finalizing the structure and deciding on the materials for the project. It is important to continue and complete the necessary research while also developing the product design. The team should create a few sketches and present them for feedback. Additionally, roles and tasks need to be clearly defined, and the wiki should be properly updated with sources and kept organized. Work on communication materials such as a flyer, key facts, and an elevator pitch should also be continued.

Positive Aspects During this week, the team made strong overall progress and showed improved organization. The wiki was well maintained, and Jira was used effectively to keep track of tasks. The product design became clearer, supported by good structural drawings and a successful cardboard model. There was also progress in marketing, and the team had good planning for the upcoming weeks. Overall, collaboration was strong, with everyone showing up on time and contributing to steady progress.

Challenges During this week, the team faced challenges due to missing components, which slowed progress and led to some waiting time. There were still uncertainties regarding materials, sensors, and electronics, and decisions about these were not finalized. Parts of the wiki were disorganized, and project management could have been more structured. Additionally, the team had not clearly defined a target customer and needed to improve consistency in updating and sharing progress.

Ideas for Improvement During this week, the team developed ideas to improve planning and analysis. This included visualizing the market analysis more clearly and creating a risk matrix to better understand potential challenges. The team also focused on preparing for the interim presentation in order to improve communication and confidence.

Actions for Next Week For the next week, the team should focus on deciding on materials and further developing the technical aspects, such as weight and water flow. Each member should take clear responsibility for specific parts of the project and break tasks into smaller subtasks if needed. The team should also create a plan for the upcoming period to stay organized and maintain steady progress.

Positive Aspects During this week, the team successfully delivered the scheduled presentations, and key project components were selected. This contributed to clarifying the technical direction of the project and ensured alignment among team members.

Challenges The communication presentation did not meet expectations. The content and delivery could have been better structured and more effectively communicated.

Ideas for Improvement No specific improvement ideas were identified during this period.

Actions for Next Week The team will focus on completing and submitting the interim report. Emphasis will be placed on ensuring that all required sections are finalized and meet the expected quality standards.

Positive Aspects The interim report was successfully completed and submitted, marking an important milestone in the project timeline.

Challenges The report was finalized later than planned, indicating inefficiencies in time management and task distribution. Ideally, the report should have been completed before the final deadline to allow time for review and refinement.

Ideas for Improvement No additional improvement ideas were identified during this week.

Actions for Next Week The team will begin preparing for the interim presentation, focusing on improving content clarity, structure, and delivery.

Positive Aspects The team made good progress in preparing for the interim presentation, demonstrating improved coordination and focus on communication aspects.

Challenges Some challenges were encountered during the week; however, they were not clearly identified or documented.

Ideas for Improvement Based on feedback from supervisors, the team identified the need to improve the visual identity of the project, particularly by incorporating marine elements such as fish into the flyer and branding materials.

Actions for Next Week The team will further develop the technical aspects of the smart system, with a particular focus on evaluating alternative battery options and improving the design of the smart module. In addition, work will continue on creating a 3D model video of the product to support visualization and presentation.

Positive Aspects The team identified a more suitable battery for the project, and the wiki was further improved. In addition, a meeting was held with Manuel, the project supervisor, to discuss the project and develop a more concrete plan moving forward.

Challenges The team was not able to create the 3D video as planned.

Ideas for Improvement No specific improvement ideas were identified during this sprint.

Actions for Next Week The team will finalize the selection of sensors, continue improving the wiki, and complete the 3D video.

Positive Aspects The team conducted a meeting with a professor, which provided valuable clarification on how to approach the project. The list of components and materials was finalized, and the smartblock of the product was completed.

Challenges The team has not yet completed the 3D video and continues to face challenges in effectively distributing tasks among members.

Ideas for Improvement

Improved task allocation and clearer responsibility distribution should be implemented to ensure steady progress. In addition, intermediate deadlines may help avoid delays in deliverables such as the 3D video.

Actions for Next Week The team will prioritize completing the 3D video and establish a more structured task distribution plan to improve workflow efficiency.

Positive Aspects The team started working on the scientific paper and completed the renders of the 3D model.

Challenges Due to vacation, limited progress was made during the sprint.

Ideas for Improvement Future sprint planning should take vacation and reduced availability into account to ensure that the workload is realistic and achievable.

Actions for Next Week Next week, the team should focus on completing the leaflet and the packaging solution.

Positive Aspects Despite the shortened working week, several key deliverables were completed, including the leaflet, packaging solution, 3D model, and user manual.

Challenges The sprint did not begin as originally planned, which reduced the available time for completing the sprint tasks.

Ideas for Improvement Future sprints should start according to the planned schedule to ensure that tasks are distributed more evenly throughout the sprint period. It may also be useful to account for vacations or reduced availability when planning sprint goals.

Actions for Next Week Next week, the focus will be on refining the 3D model, starting the prototype, and completing the scientific paper.

Positive Aspects During this week, the team made important progress by figuring out how to produce the 3D mould. The 3D video was also completed, and work began on both the testing phase and the prototype.

Challenges The main challenge was that not all prototype components had arrived or were available. This limited the team’s ability to continue with the full prototype assembly and testing as planned.

Ideas for Improvement No specific improvement ideas were identified during this sprint.

Actions for Next Week Next week, the team will focus on completing the scientific paper, starting the concrete part of the prototype, and carrying out all planned tests.

Positive Aspects
During this week, the team made good progress. The smartlogger was successfully made to work, which was an important step for the prototype. The scientific paper is also close to being finished. In addition, both the poster and the user manual were completed.

Challenges
The main challenge this week was that the 3D print drawing needs to be changed. This means that some adjustments must be made before the 3D printed part can be produced or used in the final prototype.

Ideas for Improvement
No specific improvement ideas were identified during this sprint.

Actions for Next Week
Next week, the team will focus on completing the prototype and making sure all parts are ready and working as planned.

Positive Aspects
During this week, the team made good progress with the prototype, and the prototype is now working. The first part of the 3D printing was completed, which was an important step toward finishing the physical model. The team also received feedback on the user manual, which will help improve the final version.

Challenges
One challenge this week was the name change from Smartblock to Smartlogger, which required updates in the documentation and project material. In addition, the scientific paper is still not finished. The team is also waiting for the final part of the 3D mould before the prototype can be fully completed.

Ideas for Improvement No specific improvement ideas were identified during this sprint.

Actions for Next Week Next week, the team will focus on completing the concrete prototype and making sure all parts are working as planned. The team will also work on finishing the wiki and updating the remaining documentation.

Positive Aspects During this week, the team delivered the scientific paper, completed the 3D print mould, finalized the wiki, finished the video, and prepared the final presentation. These tasks were important steps toward completing the final project deliverables.

Challenges One challenge during this week was that the flowchart still needed to be finished. In addition, the team did not start the concrete part of the prototype as planned, which means this task must be prioritized next.

Ideas for Improvement No specific improvement ideas were identified during this sprint.

Actions for Next Week Next week, the team will focus on completing the concrete prototype and practicing the presentation. The team will also make sure that the remaining documentation and final corrections are completed before submission.

The project has been managed using an iterative and structured approach, allowing the team to balance technical challenges with continuous development. Through defined scope, milestone planning, and Agile methods, the team has made steady progress in both design and implementation. While some challenges remain, particularly related to decision-making and organization, the project is moving forward with a clearer direction and improved collaboration.