===== 3. Project Management ===== ==== 3.1 Introduction ==== 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, we adopted an Agile (Scrum-inspired) methodology. This iterative approach was essential for managing the project’s high-risk components, such as waterproofing and sensor calibration. 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. ==== 3.1 Scope ==== 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. 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 illustrates how the MARIS HABITATS system is divided into its main components and subsystems. 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 {{ref>fig:Product}} presents the WBS for the product and Figure {{ref>fig:Management}} the WBS of the project.
{{ :report:wbs_product.png?nolink&600 |}} WBS of the product
{{ :report:wbs_project.png?nolink&600 |}} WBS of the project
==== 3.2 Time ==== To ensure effective time management and the timely completion of the project, the team aimed to complete as much work as possible during school hours and before weekends. This approach helped maintain steady progress and allowed time for review and adjustments when needed. The team followed the milestone schedule defined by the project supervisors. These milestones provided a structured framework to monitor progress and ensure alignment with the overall project timeline. Table {{ref>tab_labelmilestones}} presents the defined milestones. |< 100% 90px >| ^ Date ^ Description ^ | 2026-02-28 | Choose and share your top-3 preferred project proposals via email to [epsatisep@gmail.com](mailto:epsatisep@gmail.com) | | 2026-03-11 | Upload the “black box” **System Diagrams** & **Structural Drafts** to the wiki (Deliverables) | | 2026-03-18 | Upload the **List of Components and Materials (what & quantity)** to the wiki (Deliverables) | | 2026-03-21 | Define the **Project Backlog** (what must be done and key deliverables - every member should preferably participate in every task), **Global Sprint Plan**, **Initial Sprint Plan** (which tasks should be included, who does what) and **Release Gantt Chart** of the project and insert them on the wiki (Report) | | 2026-03-25 | Upload the detailed **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) ((The interim report must contain the the following chapters: Introduction, Project Management, State of the Art, Marketing Plan, Eco-efficiency Measures for Sustainability, Ethical and Deontological Concerns, Proposed Solution and Bibliography. In particular, the Project Management chapter includes the updated project progress register, the sprint report for completed sprints (tasks that were included, statuses, assignees, allocations) and the updated release Gantt chart.)) | | 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)** to Deliverables | | 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 (reserve the whole day) | | 2026-06-23 | Update the wiki, report, paper with all suggested corrections | | ::: | Place in the Shared section of the MS Teams channel of your team a **folder with the refined deliverables (source + PDF) together with all code and drawings produced** | | ::: | 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** | | ::: | Hand in the **prototype and user manual** to the client | | ::: | Receive the **EPS@ISEP certificate** | | ::: | Bring **typical food** from your country |
Milestones for the project
==== 3.3 Cost ==== //Describe your project budget and its key components. Explain how your budget was managed throughout the project. Document the planned vs. effective costs of your project.// ==== 3.4 Quality ==== Quality in this project is ensured by defining clear quality metrics for both the system and the documentation, together with acceptable thresholds and review procedures. For the product, key quality metrics include system functionality, structural stability, and sensor reliability. The system is considered acceptable when all core functions operate as intended, the structure remains stable under expected conditions, and the sensors provide consistent and reasonable data. These aspects are reviewed through testing in controlled environments and validation of system performance. For the documentation, quality is measured in terms of clarity, structure, consistency, and completeness. The report must clearly explain the project, follow a logical structure, and include all required sections. The acceptable threshold is that the documentation is understandable, coherent, and meets the academic guidelines provided. This is reviewed through internal checks within the team and feedback from supervisors. Regular reviews during sprint meetings are used to monitor progress and identify issues early. Corrections are made continuously to ensure that both the system and the documentation meet the expected quality standards. ==== People & Stakeholder Management ==== Human factors represent a significant source of uncertainty in project development, as team members may exhibit varying levels of engagement, performance, and responsibility. For this reason, it is essential to establish clear roles and responsibilities within the team, ensuring that each member understands their tasks and contributions to the overall project. This helps reduce the risk of unequal workload distribution and lack of participation. To achieve effective task allocation and maximize project outcomes, responsibilities are assigned based on each team member’s skills, field of study, and previous experience. This approach ensures that tasks are aligned with individual competencies, promoting efficiency, accountability, and overall team performance. Academic supervisors from ISEP act as a key stakeholder by providing guidance, feedback and evaluation trouhgout the project. Their role is essential in ensuring that the project meets academic and technical standards. External stakeholders include research intsitutions, NGOs and governmental organizations intressted in marine conservation and environmental monitoring. These stakeholders are potential future users or partners, as they can benefit from the data collected and the ecological impact of the solution. Although marine life cannot be considered a traditional stakeholder, it is the primary beneficiary of the project. Therefore, its needs are considered throughout the design process to ensure that the solution is environmentally safe and supportive of biodiversity ==== Communications ==== Effective communication was essential to ensure coordination and steady progress throughout the project. Communication within the team was primarily facilitated through daily Scrum meetings, where members discussed completed tasks, ongoing work, and upcoming activities. These meetings helped maintain alignment, identify challenges early, and ensure continuous progress. In addition, regular communication with key stakeholders, particularly project supervisors, was maintained through weekly meetings held on Thursdays. These sessions provided valuable feedback and guidance, supporting informed decision-making throughout the project. Furthermore, collaborative tools such as Microsoft Teams were used to support documentation, information sharing, and quick communication among team members. Altogether, this structured communication approach contributed to efficient collaboration, transparency, and timely problem-solving. ==== Risk ==== 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. 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 {{ref>tab_label6}} ). ^ Risk ^ Description ^ Probability ^ Impact ^ Risk Level ^ Mitigation Strategy ^ | Technical failure (sensors/electronics) | Failure in integration of sensors, electronics, and structure in marine conditions | Medium | High | High | Test components and validate system | | Power system failure (battery/solar) | Unstable or insufficient energy supply affecting system performance | Medium | High | High | Optimize energy use and include backup | | Integration issues (hardware/software) | Difficulties combining system components effectively | Medium | High | High | Modular design and incremental testing | | Project delays | Delays caused by time constraints and task dependencies | Medium | High | High | Sprint planning, regular meetings, and buffer time | | Limited resources | Budget constraints and limited access to equipment or testing environments | Medium | Medium | Medium | Prioritize essential features and use cost-effective solutions | | Team miscommunication | Lack of coordination or unclear communication within the team | Low | Medium | Low | Regular Scrum meetings and clear communication | | Uneven workload distribution | Some team members contribute less, affecting progress | Low | Medium | Low | Clear task allocation and team collaboration | | Loss of buoy connection (data/power cable failure) | Interruption of data or power transfer between buoy and system | Low | High | Medium | Reinforced cables and redundancy | | Corrosion of metallic components | Degradation due to exposure to saltwater | Medium | Medium | Medium | Use corrosion-resistant materials (BFRP, coatings) | | Extreme weather (storms, currents) | Harsh conditions affecting stability and performance | Low | High | Medium | Stable structure and secure anchoring | | Waterproofing failure (IP68 breach) | Water entering electronic components causing malfunction | Low | High | Medium | Seal testing and proper enclosure | | Data transmission failure | Loss or interruption of data communication | Medium | Medium | Medium | Local data storage and redundancy |
Table of different risks
To further support the risk assessment, a risk matrix based on probability and impact was used (see Figure {{ref>fig:Matrix}} figur). 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. 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.
{{ :report:matrixrisk.png?nolink&600 |}} Risk matrix
==== Procurement ==== //Document your procurement management strategy including make vs buy decisions, materials/services to be acquired, sources, costs, timings, etc.// ==== Project Plan ==== === Gantt Chart === The project schedule was visualized using a Gantt chart to illustrate the timeline and key phases of the project. As shown in Figure {{ref>fig:gantt_chart}}, the project timeline spans from March to June and includes overlapping phases such as research, prototype development, and documentation.
{{ :report:gantt_chart.png?nolink&1000 |}} Gantt chart showing the project timeline from March to June.
=== Global Sprint === 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 {{ref>tab:sprint1}} 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. ^ Sprint ^ Start ^ Finish ^ Working Days ^ Status ^ | 1 | 5 Mar | 12 Mar | 5 days | Done | | 2 | 12 Mar | 19 Mar | 5 days | Done | | 3 | 19 Mar | 26 Mar | 5 days | Done | | 4 | 26 Mar | 2 Apr | 5 days | Done | | 5 | 2 Apr | 9 Apr | 0 days | Started | | 6 | 9 Apr | 16 Apr | 3 days | To do | | 7 | 16 Apr | 23 Apr | 5 days | To do | | 8 | 23 Apr | 30 Apr | 5 days | To do | | 9 | 30 Apr | 7 May | 3 days | To do | | 10 | 7 May | 14 May | 3 days | To do | | 11 | 14 May | 21 May | 5 days | To do | | 12 | 21 May | 28 May | 5 days | To do | | 13 | 28 May | 4 Jun | 5 days | To do | | 14 | 4 Jun | 11 Jun | 5 days | To do | | 15 | 11 Jun | 18 Jun | 5 days | To do | | 16 | 18 Jun | 25 Jun | 5 days | To do |
Table of Global Sprint Plan.
=== Backlog === 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. (See Table {{ref>tab_label3}} for the backlog). ^ PBI ^ Title ^ Status ^ | A | Define project | Done | | B | System diagrams and structural plans | In progress | | C | Project backlog | Done | | D | State of the Art | In progress | | E | Gantt chart | Done | | F | System diagrams and drafts | To do | | G | Global sprint plan | Done | | H | List of components and materials | In progress | | I | Schematics and structural drawings | In progress | | J | Design development | In progress | | K | Interim deliverables | In progress | | L | 3D model and video | To do | | M | Interim report and presentation | To do | | N | Functional testing | To do | | O | Packaging solution | To do | | P | Poster | To do | | Q | Folder and manual | To do | | R | Brochure and leaflet | In progress | | S | Prototype | To do | | T | Video | To do | | V | Final report | To do | | W | Upload final deliverables | To do | | X | Final presentation | To do | | Y | Final review and submission | To do |
Table of Backlog.
=== Initial Sprint Plan === 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 {{ref>tab_label4}}). ^ Sprint ^ Period ^ Sprint Goal ^ Task ^ | 1 | 19 Mar – 26 Mar | Establish project foundation | Selection of materials | | 1 | 19 Mar – 26 Mar | Establish project foundation | Backlog, global & initial sprint plan, Gantt chart | | 1 | 19 Mar – 26 Mar | Establish project foundation | Detailed schematics ) | | 1 | 19 Mar – 26 Mar | Establish project foundation | Researching information | | 1 | 19 Mar – 26 Mar | Establish project foundation | Define project roles ) | | 1 | 19 Mar – 26 Mar | Establish project foundation | Flyer & logo presentation | | 1 | 19 Mar – 26 Mar | Establish project foundation | Cardboard model | | 1 | 19 Mar – 26 Mar | Establish project foundation | Wiki updates | | 1 | 19 Mar – 26 Mar | Establish project foundation | Daily scrum meetings | | 1 | 19 Mar – 26 Mar | Establish project foundation | Selection of components | | 1 | 19 Mar – 26 Mar | Establish project foundation | Structural drawing |
Initial Sprint Plan.
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. ==== Sprint Outcomes ==== The sprints officially started from 19 March to 26 March, as the previous weeks were mainly used to become familiar with Jira and project tools. However, the initial work began earlier, and the first weeks were structured as follows: An overview of the outcomes from the initial sprints is presented in Table {{ref>tab_labelSprint1}} and Table {{ref>tab_labelSprint2}}. ^ Sprint ^ Period ^ Objective ^ Activities ^ Outcome ^ | 1 | Week 1 | Define project scope and direction | Brainstorming of project ideas, discussion of possible approaches, evaluation of feasibility | Selection of project concept and initial understanding of project scope |
Week 1 outcome
^ Sprint ^ Period ^ Objective ^ Activities ^ Outcome ^ | 2 | 12 Mar – 19 Mar | Develop system concept and research state of the art | Continued research on artificial reefs and sensors, worked on the state of the art chapter, explored materials and structural ideas, started defining system components, followed milestone plan | Clearer understanding of technical solutions and initial system concept defined |
Week 2 outcome
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 {{ref>fig:Week3}}).
{{ :report:week3.png?nolink&600 |}} Week 3 burndown chart
==== Sprint Evaluations ==== **Second week retrospective ** **What went good** 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. **What went bad** 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** 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 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. **Summary** The team developed ideas to simplify the concept by focusing on one main solution, while also exploring sustainable materials and improving both design and functionality. They also considered ways to make the system more practical and efficient. **Third week retrospective** **What went good** 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. **What went bad** 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** 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 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. **Summary** Overall, the team made good progress in design, organization, and collaboration. However, some uncertainties and planning issues remain, and the team needs to focus on clearer decisions and more structured work moving forward. **Fourth week retrospective** **What went good** The presentations went good, and the components were selected. **What went bad** The communication presentation did not go that well **Ideas** No ideas **Actions** For the next week, the team need to finish the interim report, and deliver it. **Fifth week retrospective** **What went good** The interim report was delivered **What went bad** Should have done the report finish before the sunday. **Ideas** No ideas **Actions** For the next week, the team are prepering for the interim presentation. **Sixth week retrospective** **What went good** The prep for the presentation **What went bad** ... **Ideas** Some of the feedback from the supervisors were to have fish in the flyer/brand. The team will look in to it. **Actions** For nexts week, the team are going to research more of the smart box, to check if there are different batteries to use and how to design it in the best way. Also to create a 3D-model video of the product. ==== Summary ==== 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.