report:prm

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision		 Previous revision
report:prm [2026/05/21 16:28] – [People & Stakeholder Management] team6report:prm [2026/06/03 15:43] (current) – [Quality] team6
Line 3: Line 3:
 ==== Scope ==== ==== Scope ====
  
-The scope of our project focuses on the research and development of a solution up to the proof-of-concept stage. Indeed, in this project, we are following the demonstration process to prove that the solution we propose can be developed and be viable in the future. \\+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 {{ref>fig:WBS}} 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. 
 + 
 +<WRAP centeralign> 
 +<figure fig:WBS> 
 +{{ :report:texto_1_.png?1000 | WBS }} 
 +<caption>WBS</caption> 
 +</figure> 
 +</WRAP> 
 + 
  
-__Boundaries of the project__: We are studying and developing the idea of a Healing Cocoon to reduce children's anxiety in the waiting room before a medical appointment. We are focusing on the structure, design, materials, app and devices. 
- \\ 
  
-__Product scope__ //(extent of what the project will produce)//: Throughout the project, deliverables will be produced, such as: flyer, leaflet, 3D models, drawings, designs, detailed schematics. \\ 
  
-__Project scope__ //(summary of the work needed to produce it = WBS still to do)// \\ 
  
 ==== Time ==== ==== Time ====
Line 52: Line 60:
  
 ==== Quality ==== ==== Quality ====
-<color #ed1c24>What we need to improve: quality people/requirements; temperature limit; etc...</color> 
  
 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. 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+**__1. 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.   - 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.   - 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.   - 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.
 +
 +**__2. 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. 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.
  
 ==== People & Stakeholder Management ==== ==== People & Stakeholder Management ====
-<color #ed1c24>What we need to think about: how are we going to keep the people/stakeholder satisfied?</color>+ 
 + 
 +__**  1. Definition of the people and stakeholders of the Healing Cocoon:**__
  
 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. 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.
Line 84: Line 100:
   * Patients & Parents (The Users): The anxious children and their parents. We manage their needs by ensuring the final pod is safe, calming, and inclusive.   * 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.    * Local Suppliers: Companies like F. Marques da Silva and Artnovion who provide our materials. 
 +\\
 +**__  2. Stakeholder Satisfaction Strategy:__**
 +
 +The success of the Healing Cocoon depends on meeting the expectations of all stakeholders involved. To keep stakeholders satisfied, we will maintain regular communication, gather feedback throughout the project, and ensure that their needs are reflected in the final design.
 +
 +**Project Team Members**
 +Team satisfaction will be maintained through clear role allocation, weekly meetings, and shared project planning tools. Regular progress reviews will help identify challenges early, distribute workload fairly, and ensure that all team members can contribute according to their expertise.
 +
 +**EPS Supervisors & Teachers**
 +We will keep supervisors and teachers satisfied by meeting deadlines, maintaining an up-to-date Wiki logbook, attending scheduled meetings, and actively implementing their feedback. Draft reports and design updates will be shared regularly to ensure the project remains aligned with academic requirements.
 +
 +**Clinic Directors (Customers)**
 +Clinic directors are primarily concerned with safety, practicality, and return on investment. We will address these expectations by demonstrating that the Healing Cocoon is easy to clean, reliable, wheelchair-accessible, and capable of improving the patient experience. Feedback from clinic professionals will be incorporated into design decisions whenever possible.
 +
 +**Patients & Parents (End Users)**
 +The needs of children and parents are central to the project. Their satisfaction will be supported through a safe, calming, and inclusive design. User feedback sessions, observations, and surveys will be used to evaluate comfort, accessibility, and overall experience. Any concerns regarding safety, hygiene, or usability will be addressed during the design process.
 +
 +**Local Suppliers**
 +Strong relationships with suppliers will be maintained through professional communication, clear specifications, and timely requests for materials. Keeping suppliers informed about project requirements and deadlines will help ensure reliable deliveries and consistent material quality.
 +
 +\\
 +**__  3. Measuring Stakeholder Satisfaction:__**
 +
 +To evaluate whether stakeholder expectations are being met, we will use:
 +
 +- Regular feedback meetings with supervisors and project mentors.
 +- Surveys or interviews with potential users and healthcare professionals.
 +- Progress reviews against project milestones and deadlines.
 +- Testing sessions to collect comments on usability, safety, and comfort.
 +- Documentation of stakeholder feedback and the actions taken in response.
 +
 +By continuously collecting and acting upon feedback, the project team can ensure that the Healing Cocoon remains aligned with stakeholder expectations and delivers value to all groups involved.
 +
 +
 +
  
 ==== Communications ==== ==== Communications ====
Line 91: Line 142:
 ==== Risk ==== ==== Risk ====
  
-//Identify key risks (product and project level), evaluate them and define how they should be handled (responses) and monitored. Perform quantitative and qualitative risk analysis and use the results to define the appropriate risk responses.//+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. 
 + 
 +=== Risk Classification === 
 + 
 +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.  
 + 
 +=== Likelihood and Severity Scales === 
 + 
 +The evaluation follows a 5x5 Risk Matrix based on PMBOK standards, where the exposure score is calculated by multiplying Probability/Likelihood (1–5) and Impact/Severity (1–5). 
 + 
 +^ Level ^ Likelihood / Probability ^ Severity / Impact ^ 
 +| **1** | Improbable / Rare | Negligible / Insignificant | 
 +| **2** | Remote | Marginal | 
 +| **3** | Possible | Moderate | 
 +| **4** | Likely / Almost Certain | Critical | 
 +| **5** | Frequent | Catastrophic / Severe | 
 + 
 +**Risk score = Likelihood × Severity.** Scores are interpreted as Figure {{ref>fig:risk}}: 
 +  * **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. 
 + 
 +<WRAP centeralign> 
 +<figure fig:risk> 
 +{{  :report:matrix_risk.png?800 | Risk Matrix 5x5}} 
 +<caption>Risk Matrix</caption> 
 +</figure> 
 +</WRAP> 
 + 
 + 
 +=== Risk Register === 
 + 
 +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. 
 + 
 +^ ID ^ Risk Description ^ Category ^ Likelihood ^ Severity ^ Score ^ Prevention Strategy ^ Response Plan ^ Owner ^ 
 +| **R01** | **Tasks not completed on time / Sprint delays** | Project | 3 | 3 | **9** | Realistic planning with buffer; strict weekly sprint reviews in Jira; early flagging of blockers. | Replan sprint; reprioritize backlog; reallocate resources. | Project Manager | 
 +| **R02** | **Budget overrun** (Exceeding the 100€ prototype limit) | Project | 2 | 4 | **8** | Component pricing confirmed before purchase; source affordable local materials (e.g., F. Marques da Silva, Artnovion). | Substitute cheaper components; deprioritize non-essential features. | Project Manager | 
 +| **R03** | **Team synchronicity & communication issues** | Project | 3 | 3 | **9** | Weekly standups; shared tools (Jira, Teams, Miro); strict adherence to the final cross-check checklist. | Address in retrospective; adjust communication rhythm; redistribute tasks. | Project Manager | 
 +| **R04** | **Cross-contamination / Hygiene rejection** (Surfaces transmit germs) | Safety & Env. | 3 | 4 | **12** | Explicitly use medical-grade, easily sanitizable antimicrobial textiles (e.g., Monteiro Fabrics MEDIFLEX collection). | Stop session; immediately wipe down with standard clinic sprays; review safety sheets. | Technical Lead | 
 +| **R05** | **Claustrophobia / Panic inside the Cocoon** | Safety & Env. | 2 | 4 | **8** | Keep the structure semi-enclosed (not fully closed) so parents maintain visual contact. | Press the physical or digital Emergency Stop button; immediately move the child out. | Technical Lead | 
 +| **R06** | **Wheelchair accessibility failure** (Inability to enter or fit) | Safety & Env. | 2 | 4 | **8** | Ensure the structural opening and footprint (165 cm x 110 cm) comply with barrier-free dimensions and design layout. | Utilize the removable seat feature and deploy the integrated ramp to facilitate immediate access. | Hardware Lead | 
 +| **R07** | **Smart system responsiveness lag** (ESP32 latency) | Technical | 2 | 3 | **6** | Write clean, non-blocking asynchronous JavaScript/C++ code; minimize data overhead. | Run code profiling; optimize loops; optimize LocalStorage and data structures. | Technical Lead | 
 +| **R08** | **Power Supply Instability / Overload** (High-draw components) | Technical | 2 | 4 | **8** | Dedicate direct power lines from the supply to high-draw components (projector, speakers) instead of drawing current through the ESP32. | Isolate affected unit; check schematics; replace the 5V 2A USB power adapter. | Hardware Lead | 
 +| **R09** | **Sensor calibration drift / Environmental false readings** | Technical | 3 | 2 | **6** | Use high-quality reference digital sensors (BH1750 for lux, DHT22 for air) rather than basic analog options. | Implement tolerance thresholds in firmware; clean sensor housings; replace faulty sensors. | Hardware Lead | 
 +| **R10** | **Scent diffuser essential oil allergy / Irritation** | Safety & Env. | 2 | 3 | **6** | Use strictly certified, organic, pediatric-safe diluted essential oils (lavender/orange); provide low-stimulation mode settings. | Shut down the ultrasonic atomizer immediately via the 5V relay module; activate airflow ventilation. | Technical Lead | 
 +| **R11** | **Loss of code or UI prototype data** | Operational | 2 | 3 | **6** | Continuous Git version control updates; regular backups of HTML/CSS/JS frontend files on cloud drives. | Restore from the most recent GitHub repository backup; document lost sprint items. | Technical Lead | 
 +| **R12** | **Acoustic foam toxicity / Poor indoor air quality** | Safety & Env. | 2 | 3 | **6** | Avoid standard petroleum-based foams; prioritize eco-efficient recycled textile-based acoustic panels or PET felt. | Replace with certified low-VOC alternative panels; test air quality via the integrated MQ-135 sensor. | Hardware Lead | 
 + 
 +=== Risk Monitoring and Review === 
 + 
 +Identifying risks once is not enough — they must be tracked throughout the project development cycle: 
 +  - **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. 
 +  - **Milestone Reassessment:** Before major milestones (such as the Interim Presentation, 3D Model delivery, and Final Prototype submission), the complete register is thoroughly re-evaluated. 
 +  - **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. 
 +  - **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.
  
 ==== Procurement ==== ==== Procurement ====
  • report/prm.1779377309.txt.gz
  • Last modified: 2026/05/21 16:28
  • by team6