In this chapter, we will develop our project management approach by describing several aspects such as the scope, time, project plan and our understanding and use of Jira, particularly with sprints.

Defining the scope of the Healing Cocoon is essential for keeping our multidisciplinary efforts focused on the project's core objectives: reducing children's anxiety and transforming clinical waiting rooms into calming, immersive spaces. The scope of our project focuses on the research and development of a solution up to the proof-of-concept stage. This involves focusing on the structure, design, materials, app, and smart devices. While the final product is intended for specialized pediatric clinics, our current technical focus is on building a working prototype to prove our technology and sensory integration work effectively.

To prevent scope creep and ensure a clear roadmap from conceptualization to final deployment, we have systematically organized our tasks. The Work Breakdown Structure (WBS), Figure 1 presented below illustrates how we have divided the project into manageable phases—Management, Research, Design, Development, Testing, Marketing, and Reporting—and their specific deliverables. This framework ensures that every team member understands their responsibilities and the steps required to deliver a safe, inclusive, and fully functional prototype.

To make sure we finish this project within the 15-week semester, we break our work down into small, weekly goals. We use task-tracking software to organize who is doing what every week. This flexible approach allows us to design the physical pod and write the software at the same time. While our weekly tasks are flexible, we make sure to always pay attention to the major deadlines and closely monitor progress over time.

Here the details of the milestones of our project:

2026-02-28 Choose and share top-3 preferred project proposals via email (epsatisep@gmail.com)
2026-03-11 Upload “black box” System Diagrams & Structural Drafts to Deliverables
2026-03-18 Upload List of Components and Materials (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 detailed System Schematics & Structural Drawings (Deliverables) and do the cardboard scale model of the structure
2026-04-12 Upload Interim Report and Presentation (Deliverables)
2026-04-16 Interim Presentation, Discussion and Peer, Teacher and Supervisor feedbacks
2026-04-22 Upload 3D model video (Deliverables)
2026-04-29 Upload 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 Packaging solution (Deliverables and Report)
2026-05-27 Results of the Functional Tests (Report)
2026-06-13 Final Report, Presentation, Video, Paper, Poster and Manual (Deliverables)
2026-06-18 Final Presentation, Individual Discussion and Assessment
2026-06-23 Update the wiki, report (suggested corrections), upload refined deliverables in shared section of MS Teams (source and PDF), printed copy of the poster, brochure and leaflet for EPS coordinator
2026-06-25 Submit prototype and user manual, prototype demonstration

We need to clearly separate two different prices: the price of the final product and the budget we have right now. While the final Healing Cocoon will be sold to clinics for about 2000 € to 2500 €, our goal right now is just to build a working test model (prototype) to prove our technology works.

For this first prototype, the EPS program gave us a 100 € budget limit. To make sure we don't spend too much, we are using affordable, easy-to-find materials for the physical frame. For the smart system, we are using low-cost electronic sensors and a basic microcontroller (ESP32).

What we need to improve: quality people/requirements; temperature limit; etc…

To make sure the Healing Cocoon is safe for children and works perfectly in a real clinic, we set clear quality goals. We constantly check our work through team reviews, teacher feedback, and physical testing.

Building & Hardware Quality

• Wheelchair access - The opening and inside of the pod must be big enough for a standard child's wheelchair to roll right in without the child needing to stand up.
• Cleanliness & Hygiene - All inside surfaces must be easy to wipe down and made of materials that stop germs from spreading. They must also survive standard clinic cleaning sprays without getting damaged. This will be done by checking the manufacturer's safety sheets and testing the materials with cleaning sprays.
• Fast Electronics - When the smart system (the ESP32) senses something, the lights, sounds, or scents must react in less than 2 seconds so the experience feels magical and natural. This is going to be tested by running the code and testing the electronics over and over to find any delays.

Structure and hardware quality

To make sure the Healing Cocoon is safe, reliable, and effective before being used in clinics or therapy spaces, our company will carry out several types of quality testing during development and before final deployment.

• Functional Testing - Every electronic feature of the cocoon will be tested repeatedly to confirm it works correctly. This includes checking the lighting system, sound system, scent diffuser, sensors, and the ESP32 smart controller. Each function must respond correctly without delays, freezing, or unexpected shutdowns.
• Stress & Durability Testing - The cocoon must remain stable and safe after long periods of use. We will test the structure, seating area, doors, wheels, cables, and electronic systems by running them continuously for extended periods. This helps identify overheating, weak materials, or components that wear out too quickly.
• Safety testing - The cocoon will undergo multiple safety inspections to reduce risks for children and healthcare workers. Tests will include: Electrical safety checks to prevent shocks or short circuits. Emergency stop testing to ensure the system can shut down immediately if needed. Stability testing to confirm the structure cannot tip over during normal use. Sharp-edge and material inspections to avoid injuries. Safe temperature control

We are also focusing on clear and consistent report for keeping the track of our progress and milestones achieved. We use a final “cross-check checklist” before submission, ensuring all numbers, part names, and deadlines match across every single chapter.

What we still need to think about: how are we going to keep the people/stakeholder satisfied?

To make sure our project runs smoothly, we have clearly defined the roles of our internal team members and identified the external groups (stakeholders) who care about the success of the Healing Cocoon.

The Project Team (Internal) Our team is made up of six international students from different academic backgrounds. Because we have different skills, we divided the project responsibilities to match our strengths:

1. Ronja Kruse (Dental Technology): Provides medical insights for the clinic environment, helps with B2B marketing, and designs the wheelchair-accessible layout.
2. Hanna Kaczmarek (Industrial Biotechnology): Focuses on ergonomic dimensions, market analysis, and the business SWOT analysis.
3. Anouc Goedhart (Industrial Design Engineering): Leads the 3D design models, branding (flyers/leaflets), and the visual identity of the Cocoon.
4. Daniel Aagaard Pérez (Informatics Engineering): Handles the smart system hardware, projector integration, and the detailed technical schematics.
5. Julie Bonnet (Packaging Engineering): Manages material selection, eco-efficiency research, and building the physical cardboard scale model.
6. Kemal Yilmaz (Electronics - ICT): Develops the software app, the user interface (UI), and database management.

Key External Stakeholders These are the people outside our team who are impacted by our project:

• EPS Supervisors & Teachers: They guide our academic progress and grade our deliverables. We manage their expectations by meeting all deadlines and updating our Wiki logbook.
• Clinic Directors (The Customers): The private dentists and therapists who will buy the Cocoon. We manage them by proving the product is easy to clean and will save their clinic time and money.
• Patients & Parents (The Users): The anxious children and their parents. We manage their needs by ensuring the final pod is safe, calming, and inclusive.
• Local Suppliers: Companies like F. Marques da Silva and Artnovion who provide our materials.

Document how your team will manage communications, describing communication channels, meetings, etc.

This chapter identifies the risks that may arise during the Healing Cocoon project and defines how they will be prevented, monitored, and managed if they occur. Each risk is assessed on two dimensions: likelihood (how probable it is) and severity/impact (how damaging the impact would be). The product of these two gives a risk score, which determines the priority for mitigation.

Risks are categorized by type to make it easier to assign ownership and response strategies:

• Project risks — affect schedule, scope, budget, or team capacity.
• Technical risks — affect hardware, firmware, software, or integration.
• Operational risks — affect day-to-day execution and infrastructure.
• Safety & environmental risks — affect user safety, child health, or clinic hygiene.

The evaluation follows a 5×5 Risk Matrix based on PMBOK standards, where the exposure score is calculated by multiplying Probability/Likelihood (1–5) and Impact/Severity (1–5).

Risk score = Likelihood × Severity. Scores are interpreted as Figure 2:

• 1–4 Low: Acceptable; minimal monitoring.
• 5–9 Medium / Moderate: Manageable; requires routine control and active mitigation.
• 10–15 High: Significant; requires a specific mitigation plan before development milestones.
• 16–25 Extreme / Critical: Must be addressed immediately before the project advances.

The table below lists all identified risks for the Healing Cocoon, their assessment based on our specific project parameters (such as the 100€ EPS budget limit, material properties, and software structure), preventive strategies, and response plans.

Identifying risks once is not enough — they must be tracked throughout the project development cycle:

1. Weekly Risk Check during Sprint Reviews: The team reviews the register inside Jira and flags any changes in likelihood, actual costs, or component delivery delays.
2. Milestone Reassessment: Before major milestones (such as the Interim Presentation, 3D Model delivery, and Final Prototype submission), the complete register is thoroughly re-evaluated.
3. New Risk Intake: Any team member can propose a new risk (e.g., new constraints found during the cardboard scale model phase or software testing). The Project Manager assesses and adds it to the register.
4. Closed Risks: Once a phase is fully completed and verified (e.g., R02 after buying all prototype components under the 100€ limit), the risk is marked closed but kept in the register for traceability.

Document your procurement management strategy including make vs buy decisions, materials/services to be acquired, sources, costs, timings, etc.

1. Description of the project schedule and its key phases using a Gantt chart

We decided to organize the tasks according to whether they belong to:

• the initiating phase of the project (Figure 3)
• the development phases of the project (Figure 4)
• the deliverables to be submitted (Figure 5)

We divided the tasks according to our strengths and areas of expertise, but some compromises had to be made to meet the needs of the project's progress. For example, marketing tasks are primarily managed by Hanna and Ronja, even though their fields of study are unrelated to this topic.

Figure 6 presents the updated Gantt Chart.

Figure 7 contains the semester schedule (before the last update of the Gantt Chart for the interim report): each purple bar represents the planned time for its completion, with the start and end dates set. The gray area indicates the progress of the task, allowing us to see if we are ahead of schedule or if we still need to do more work on the task.

We observed that the beginning of the project was lengthy in terms of identifying the problem and potential solutions. Indeed, we had several different ideas, and we were only recently able to choose and focus on the final topic of our project. This required a great deal of time for reflection, discussion, and research, some of which were successful, others not. We now have to complete numerous tasks within the same timeframe, some with imminent deadlines; these are the tasks we must focus on first.

2. Sprint backlog and sprints created in Planner on Jira:

First of all, discovering and using Jira was not easy for our team. Despite the explanations that we thought we understood, some parameters and steps were not completed successfully on time, notably the timely launch of certain sprints.

Figure 8 is one of the first sprint we organized (but forgot to launch it on time).

Figure 9 is the last sprint we launched, which takes place from April 7th to 14th.

Figure 10 is the curent backlog (edited on April 9th) with tasks that still need to be completed.

Finally, 11 is the Jira planner in which we created the Epics, Stories, and corresponding tasks.

3. Prioritization, estimation process and underlying challenges

We tried to prioritize tasks based on the deadlines and deliverables to respect, but it was also based on our estimated workload and the time it would take.

The tricky part was finding compromises based on each person's areas of expertise and the time the tasks could take.

Provide a summary of the sprints that were executed, along with sprint goals.

Include the outcomes of all sprint reviews (what was the sprint backlog, completion status, planned capacity vs. achieved velocity).

Include the summary of all the sprint retrospectives, including any actions implemented as part of the team’s continuous improvement strategy.

Provide here the conclusions of this chapter and make the bridge to the next chapter.