This chapter presents the project management approach adopted for the development of Screen2Green. Since the project combines hardware development, software integration, user interaction, and academic reporting within a limited timeframe, it required a management strategy capable of balancing structure with flexibility.

To address this, the team adopted a hybrid project management approach combining elements of Scrum and Waterfall. Waterfall was useful for planning around fixed academic deadlines and mandatory deliverables established by the EPS programme, while Scrum supported iterative development, continuous feedback, and adaptation to technical and organizational challenges throughout the semester. This combination was considered appropriate because the project contains both predictable elements, such as milestone submissions, and uncertain elements, such as concept refinement, prototype development, and system integration.

The chapter is organized into the main areas relevant to project management: scope, time, cost, quality, people and stakeholder management, communication, risk, procurement, and project plan. Together, these sections explain how the team structured the work, allocated responsibilities, monitored progress, and responded to challenges during the project.

The scope of the project defines both the product to be developed and the work required to deliver it. In the case of Screen2Green, the main goal is to design and develop a functional prototype of a pot system that links smartphone screen-time behaviour to the condition of a living basil plant.

From a product perspective, the scope includes the development of a compact indoor plant-growing system capable of supporting basil cultivation in a small residential environment. The system is intended to include a physical pot structure, a water reservoir, an automated irrigation mechanism, a microcontroller-based control system, and a mobile application that communicates relevant information to the user. The core concept of the product is that excessive screen-time affects the watering conditions of the plant, thereby creating a physical and biological feedback loop. The prototype is expected to demonstrate the feasibility of this concept rather than function as a market-ready consumer product.

From a project perspective, the scope includes all activities (see Figure 1 for the Work Breakdown Structure for the project) necessary to research, design, develop, and document the prototype. This involves background research such as indoor herb cultivation, hydroponics, smartphone usage and mental health. It also includes concept generation, selection of materials and components, development of hardware and software, testing, evaluation, and the production of all required academic deliverables, such as the report, presentations, poster, flyer, and supporting documentation.

The scope of the project is intentionally limited. The team does not aim to develop a fully commercialized product, a large-scale production model, or a fully finished mobile application with advanced features. Similarly, the project does not include large-scale user trials, long-term biological validation, or full optimization of all environmental variables affecting plant growth, such as artificial lighting, nutrient automation, or AI-based plant monitoring. These areas are considered relevant for future development, but they are outside the scope of the current project.

Defining these boundaries was important in order to keep the project realistic and achievable within the available time, budget, and technical resources. The scope therefore reflects a proof-of-concept approach, where the team focuses on demonstrating the technical and conceptual value of the solution.

Time management was an essential part of the project due to the fixed deadlines established by the EPS programme. To ensure steady progress, the team organized the semester around milestone-based planning supported by iterative one-week sprints.

The overall project schedule followed the official EPS deadlines, which served as the main milestones for deliverables and report development. These milestones helped structure the work and ensured that the team continuously aligned its progress with the expectations of supervisors and course requirements. Key deadlines included the submission of system diagrams, structural drafts, materials lists, sprint planning documents, the interim report and presentation, the final report, and the final prototype demonstration.

In addition to milestone-based planning, the team organized the work into weekly sprints beginning every Thursday. This sprint structure made it possible to divide the project into smaller and more manageable increments. Each sprint focused on a specific set of goals, such as research, concept refinement, deliverable completion, app development, or preparation for presentations. This approach supported regular evaluation of progress and allowed the team to identify problems earlier than would have been possible with a purely linear planning model.

At the beginning of each sprint, tasks were selected and prioritized based on upcoming deadlines, dependencies, and team capacity. As the project evolved, the team improved its sprint planning process by introducing more structured meetings and clearer task organization. From sprint 3 onward, regular Scrum meetings were held three times a week, on Friday, Monday, and Wednesday. During these meetings, each member reported what had been completed, what would be worked on next, and whether any blockers had appeared. These meetings contributed to stronger coordination and better short-term planning.

The main project milestones are presented in Table 1.

Although the sprint-based structure improved flexibility, the team initially experienced difficulties with task definition, prioritization, and maintaining an overview of progress in Jira. Some tasks were completed without being updated in the system, while others were too vaguely defined to support efficient planning. Over time, these issues were reduced by reorganizing Jira, improving communication, and refining the way tasks were categorized and assigned. As a result, time management became more consistent and better aligned with the project’s pace and complexity.

The project isdeveloped as a prototype and therefore followed a limited-budget approach (100 €). The main objective of the cost management process was to ensure that the essential functionality of the Screen2Green system could be achieved using affordable and accessible components, while still maintaining sufficient technical quality for prototyping and testing.

The main cost drivers in the project are the electronic and structural components required to build the prototype. These include the microcontroller, water pump, sensors, tubing, reservoir materials, structural materials for the pot, and power-related components.

A preliminary estimate of the prototype cost is presented in Table 2 .

The estimated total cost of the current component list is 43.99 €, which can be rounded to 44.00 €. This indicates that the prototype can be developed at a relatively low direct material cost, which supports the project’s goal of creating an accessible and feasible concept for small-scale indoor use.

To manage costs responsibly, the team selected standard off-the-shelf components from accessible suppliers and aimed to reduce unnecessary complexity in the system design. This approach helps keep the prototype within a realistic academic budget while still allowing for functional testing and system integration. In a future commercial version of the product, the cost structure would need to be expanded to include manufacturing, packaging, distribution, and software development costs.

Quality management in this project focuses on ensuring that the prototype, documentation, and associated deliverables meet the expected technical and academic standards. Because Screen2Green combines both physical and digital elements, quality must be evaluated across multiple dimensions, including functionality, usability, reliability, and documentation quality.

The most important quality criterion for the prototype is functional feasibility. The system must demonstrate the intended relationship between smartphone usage behaviour and plant care through a working technical concept. This includes successful interaction between the mobile application, the control system, and the watering mechanism. In addition, the prototype must operate safely and consistently under controlled conditions.

A second important quality dimension is usability. Since the product is intended for non-technical users, the concept must remain understandable, intuitive, and manageable in a home environment. This concerns both the physical design of the pot and the communication of feedback through the app. A third quality dimension is reliability, particularly regarding the watering mechanism, communication between system components, and the prevention of water-related technical issues.

In order to assess quality, the team defined the general metrics listed in Table 3.

Because Screen2Green is a multidisciplinary project, effective people and stakeholder management was necessary to ensure coordinated progress and balanced contributions. The team consists of six students from different academic fields and national backgrounds, which provided the project with a broad range of competencies, including mechanical engineering, applied computer technology, electronics and ICT, media technology, industrial product design, and security-related technical knowledge. This diversity was a major strength of the project, as it allowed the team to approach the problem from multiple perspectives.

At the same time, differences in academic background, communication style, and preferred working methods also created challenges. Team members approached tasks with different expectations regarding structure, level of detail, and pace of execution. For this reason, it was important to define roles, distribute responsibilities, and create routines that improved alignment over time.

The main stakeholders in the project include the project team itself, the teachers and supervisors at ISEP, and the potential end users of the solution. The team members are the primary internal stakeholders, as they are directly responsible for designing, building, and documenting the system. Teachers and supervisors are key external academic stakeholders, since they provide guidance, evaluate deliverables, and influence the direction of the project through feedback. The intended end users, such as students and young adults with high screen-time usage, are also relevant stakeholders because the product is developed to address their needs and behaviour.

A stakeholder analysis helps clarify the degree of influence and interest associated with each group. In this project, supervisors and teachers can be considered key stakeholders due to their high influence and high interest. The project team also belongs to this category. Potential users have high interest but limited direct influence during the academic development process. Suppliers and external partners have lower influence and are therefore of secondary importance in the current project stage.

Communication played a central role in coordinating the project and maintaining progress across technical development, documentation, and planning activities. Since the team worked across multiple disciplines and perspectives, a structured communication strategy was necessary to reduce misunderstandings and improve collaboration.

Internal communication was primarily handled through regular meetings and digital collaboration tools. Scrum meetings were introduced to ensure that members frequently updated each other on progress, priorities, and blockers. These meetings became especially important from sprint 3 onward, when the team increased their frequency to three times per week. This helped improve shared understanding and made it easier to identify issues before they became larger delays.

Jira was used as the main project management tool for planning and tracking tasks. It allowed the team to create sprint backlogs, assign responsibilities, and monitor the status of work. Google Calendar was used to maintain an overview of deadlines, milestone dates, and meetings. In addition, Microsoft Teams served as a shared workspace for deliverables, files, articles, and general documentation.

Despite these structures, communication within the team was initially challenging. Differences in working styles and expectations sometimes led to inefficiencies, delayed responses, and incomplete coordination. In some cases, members completed tasks without updating their progress in Jira, which reduced transparency and made planning more difficult. To improve this situation, the team placed more emphasis on structured meetings, clearer task ownership, and more regular status updates.

Overall, communication management evolved during the project. While it was a challenge in the early stages, it gradually became more effective as routines were established and the team became more aligned in how information should be shared and discussed.

The Screen2Green project involves several potential risks related to both technical and organizational aspects. Due to the combination of hardware, software, and biological elements, uncertainty is present in both system functionality and project execution.

One of the main risks is technical failure, particularly related to the integration of hardware and software components. The system depends on communication between the mobile application, microcontroller, and watering mechanism. If this integration fails, the core concept of linking screen-time behaviour to plant care cannot be demonstrated. To reduce this risk, the system is to be developed in a modular way and tested incrementally throughout the project.

Another significant risk is project delays, mainly caused by time constraints and task dependencies. Since the project follows fixed academic deadlines, delays in one task may affect multiple deliverables. This risk is managed through sprint planning, regular Scrum meetings, and continuous prioritization of tasks.

There is also a risk related to system reliability, such as inaccurate sensor readings or water leakage. These issues could affect both the functionality and safety of the prototype. To mitigate this, components are tested under controlled conditions, and design decisions are made to separate water and electronics where possible.

A project-specific risk is that the plant may not respond clearly enough to changes in watering. Since the concept relies on visible feedback from the plant, limited biological response could weaken the overall impact of the solution. This risk is addressed by adjusting watering thresholds and clearly defining the prototype limitations.

Organizational risks such as miscommunication and uneven workload distribution may also affect progress. These are mitigated through regular meetings, clear task allocation, and continuous collaboration within the team.

The identified risks are summarized in Table 4.

To support the risk assessment, a risk matrix based on probability and impact was used (see Figure 2). The matrix classifies risks into low, medium, and high categories.

Based on this analysis, risks related to system integration, project delays, and system complexity are classified as high risk, as they have the greatest potential impact on project success. These risks require continuous monitoring and prioritization throughout the project.

Medium-level risks, such as sensor inaccuracies, water leakage, and plant response, are addressed through testing and design adjustments. Lower-level risks, including communication issues and uneven workload distribution, are managed through regular meetings, clear task allocation, and team coordination.

The procurement of components focuses on technical reliability within a limited budget and tight schedule to ensure that project is delivered on time. All materials are selected to ensure availability for the assembly phase.

All electrical components are ordered locally from a single website: Mauser Portugal. Sourcing from one supplier ensures that all parts arrive together and reduces costs to a single shipping fee. This is necessary due to the restricted prototype budget.

Structural parts utilize cork, which is a local material in Portugal. Using local cork supports the regional economy and reduces environmental impact from transportation.

Decisions are based on budget and time limitations. It is not possible to manufacture every part within the given timeframe, like ESP32 boards. A readymade solenoid valve was selected instead of building a custom valve with a servo motor. This choice ensures a reliable, leak-proof solution and saves time during the development phase. Specific parts needed to have certain features to ensure longevity of the product like more expensive model of anticorrosion temperature sensor.

Document how the sprint backlog was planned and managed for each of the sprints you have created in Planner.

The team utilizes Scrum and works with sprints of one week each. Every sprint is based around the project's deliverables, internally discussed tasks and internally discussed research topics. Jira is the utilized tool for managing Scrum with Avkaran as Scrum master. Since the team is using the free version of Jira, traditional story mapping is not possible. This is due to the following.

• It's impossible to assign existing tasks to features.
  • the opposite is also impossible.
• Subtasks are separate entities from tasks.
• Subtasks aren't visible on the sprint board.
• Themes don't exist.

To keep a clean and understandable sprint log, the team decided to use features and their subtasks for tasks, which are divided under epics, which are finally divided under labels. Labels replace themes in this case.

The team decided to prioritize tasks and define sprint themes based on 3 topics. These are deliverables, tasks/features with multiple dependencies and lastly, internally decided research topics. Apart from that, each sprint functions as an increment on the prior's app and microcontroller development, as well as design.

Figure 3 is a screenshot of the timeline on Jira. This timeline, including all the deadlines and chosen epic periods, decided the sprint plan for this project. Using different colors, the team separated epic periods with the same starting and ending date. Some epics have no specific starting or ending date, so these will go on until a final task or feature has been decided.

Table 5 contains the global sprint plan. Every sprint is defined by their sprint period, a theme/main focus, amount of deliverables, status and percentage of finished stories & tasks.

The first phase/sprint was solely focused on research. In order to understand the problem and define a more granular project topic, the team needed a baseline of knowledge, so the sprint consisted of only research-related tasks. The main research topics were smart farming, basil growing and the correlation between mental health and plants. The backlog included tasks for every deliverable.

The team's project idea didn't get accepted because it was too broad and didn't solve a specific problem. The team then made the idea to turn this into a project that helps increase productivity and motivation while working or studying. Using an app, the user can set focus sessions where successful productivity helps a plant grow by connecting the app to the smart plant grower. This grower is called the growth pod. The backlog gained design-related tasks for the coming sprint periods.

This sprint included research refinement tasks, research on productivity and motivation and design related tasks. Lastly, there were deliverable related tasks. The backlog gained some research topics of which we were unsure were necessary for this project.

The team's project idea got accepted. A noticeable amount of deliverables had to be finished this sprint, so most of the tasks were related to that. Apart from deliverables, there were tasks related to refining the Wiki due to a large difference in everyone's writing style. The backlog now included only deliverable related tasks and a few other tasks since most of them got transported to this sprint.

The team caught up with their missing work and everyone is on the same terms regarding the product, so now development could finally start. The sprint length was shorter than others and several members were unavailable for half the period, so there was a noticeable decrease in task weight and amount. The backlog gained a substantial amount of app development related tasks.

Due to the holidays, both the sprint backlog and the global backlog have mostly remained the same. All of the team members were unavailable for the majority of the holidays.

The global backlog

By the end of the sprint, every task was completed and the team evaluated the task weight to be a healthy number. After each member researched and reported on their given fields, the team could focus on making a sprint plan.

The backlog consisted of tasks regarding the deliverables, subject related assignments and refactoring prior research. The reason behind the latter is because the reports were written unprofessionally and were saved in a separate environment. By the end of this sprint, all the research got refactored into the Wiki. There was an exponential growth of amount of tasks done per day, but everything was finished before the retrospective.

The following sprints will have more focus on proper communication, this is because some tasks were done without having their status updated in Jira and because there was low engagement off-campus.

The team felt like they were behind on tasks and internal discussions, so the third sprint focused on lots of research, deliverables and internal tasks. Out of a total of 35 tasks with considerable weight, 32 were finished and the smallest ones were transferred to next sprint. The team is extremely satisfied with how this sprint ended. Team 1 managed to finish important discussions and decide on important factors of the project, leading to everyone being on the same basis.

Due to a shortened sprint period and several team members being unable to deliver or show progress, few tasks have been completed. This sprint was mainly focused on preparing the pre-interim presentation and starting app development. Due to the app developer being unable to work however, this got delayed to next week. Only about 60% of the tasks were completed, with the rest being transferred to sprint 5.

Due to the holidays, most tasks were left unfinished. The team underestimated the amount of tasks and assigned many of them before starting the sprint. Because of this, less than half of the sprint's backlog had been completed. The team has learned to take external factors such as holidays into accordance when deciding the sprint's backlog.

Firstly, the team had an outstanding presentation in terms of preparation, information, enthusiasm and conviction. Secondly, 31 out of 32 tasks were completed. Thirdly, the team held a very progressive retrospective.

The team has improved in several factors and has only one carry over task. However, the team had poor meeting etiquette on Sunday. This sprint has taught the team a lot about themselves as individuals and also as a whole.

The team's first project idea got rejected, so there was little time to think about the chosen topic. The team reviewed the chosen topic and decided to research topics revolving the project as well as topics that seemed important to this project.

After the team gained a better view on the project and what the teachers expect, it became easier to focus on design. The physical and ethical design were of top priority, so all research done in this week was based on these 2 topics. Apart from that, there was heavy research on growing herbs and more specifically, basil. Lastly, the team collected some foundational questions to ask before diving further into this project.

Due to miscommunication however, the team presented undiscussed topics regarding the app and so gave the teachers unconfirmed information. This was addressed accordingly in the retrospective.

Due to a lack of an agenda, the team had no meeting with the teachers. Luckily, they allowed for a small feedback round. There, the team learned that the Wiki was lacking in information and that some deliverables were incomplete.

What went well:

• Deliverables were finished in time and there was room for enough evaluation.

What didn't go well:

• Miscommunication lead to a missing agenda.

What should the team:

• Keep doing:
  • /
• Start doing:
  • Define assignees for tasks more early in the sprint.
  • Define tasks for smaller topics such as agenda creation.
• Stop doing:
  • Procrastinate task assignment.

What went well:

• Communication improved, the team engaged with each other more frequently upon finished tasks.
• The team started with a great amount of tasks and finished around 90% of them.
• The team set a stronger baseline and gained more certainty in their project scope.

What went wrong:

• Although there was more communication, this often came later than desired.
• The didn’t fix the failed deliverables in time.
• Task division happened in an unbalanced manner and tasks had no weight to them.

What the team should:

• Keep doing:
  • Improve their communication.
  • Update each other on finished tasks by sending messages.
• Start doing:
  • Reply to each other's messages/requests.
  • Review the Wiki more frequently.
  • Start using task weights and priority.
  • Improve importance ordering of tasks and features.
• Stop doing:
  • Research with insufficient efficiency and write non-qualitative reports.

Summary: In general, the team is satisfied with their progress and results this sprint. They're caught up with missing work and research and each member now shares the same ideas regarding the growth pod. There is now a strong and clear baseline.

What went well:

• Improvement in communication.
• Improvement in engagement.

What didn't go well:

• Small number of tasks were completed.

What should the team:

• Keep doing:
  • Update each other on task completion in WhatsApp.
• Start doing:
  • Put more time into planning the next sprint and focus on factors such as sprint length, holidays and unavailabilities.
  • Overestimate tasks and sprints instead of underestimating them.
• Stop doing:
  • /

There was no retrospective this sprint due to a similar sprint backlog and project backlog.

This week, the team had an interim presentation and they had to deliver an interim report. This presentation was an important moment of practice for the final product presentation and this moment was also a moment of feedback.

What went well:

• The team improved in overall communication, language skills, team confidence and individual confidence. There was minimal negative feedback on the interim report.

What didn’t go well:

• The team held a meeting on Sunday to prepare for uploading the interim deliverables. There was no engagement from certain team members and the overall energy was very low. Secondly, certain team members were unprepared.

What should the team:

• Keep doing:
  • Keep the same energy like in the interim presentation. The team was driven, they showed passion and the members were all on the same wavelength.
• Start doing:
  • /
• Stop doing:
  • Come to a meeting unprepared.

In general, the team is very satisfied with the end result and finished almost all the tasks of this sprint. The team can now focus on the next deliverables and development.

This chapter presented the project management approach used in the development of Screen2Green, combining structured planning with iterative development. The defined scope, time planning, cost control, and risk management ensured that the project remained feasible within its constraints, while continuous improvements in communication and coordination strengthened team performance.

Overall, the project management strategy provided a solid foundation for developing a functional prototype. Based on this, the next chapter focuses on the marketing plan, where the product is analyzed in terms of market potential, target users, and strategic positioning.