Skip to content

Project End Report

1 INTRODUCTION

This document is the final report of the eCommerce Server Platform V1.0 project. It outlines what was done, by whom, and why. The report also discusses what went well, what challenges were encountered, how they were addressed, and what was learned during the process.

The project focused on the development and deployment of an eCommerce platform using PrestaShop, hosted on a cPouta cloud server. The primary objective was to create a stable, scalable, and user-friendly online marketplace, drawing inspiration from platforms like Amazon, aimed at delivering a seamless shopping experience.

The purpose of the project was to address diverse customer needs while ensuring the platform’s reliability, security, and ease of use. The technical environment was designed to support optimal performance, scalability, and data privacy, in alignment with the project's functional and non-functional requirements.

Core focus areas included secure service access, efficient bug tracking, and the integration of a payment gateway—addressing key business and technical requirements to enhance the PrestaShop development workflow.

The project organization responsible for the implementation consisted of students from the Jyväskylä University of Applied Sciences.

2. TASK, OBJECTIVE, RESULTS

2.1. Summary of the realization of the project

The Gates for this project were defined in the Project Plan. Each gate served as a milestone for planning, coordination, and assessment. Below is a summary of how each Gate was realized:

Gate 0: Introduction and Team Building

Objective:

Establish the project foundation and create a cohesive project team.

What had to be done:

  • Assemble the team and assign initial roles
  • Conduct team-building activities and define communication norms
  • Clarify the project’s vision and scope
  • Set up tools, workspace, and documentation templates

What was done:

The team was successfully assembled, and initial roles were tentatively assigned. We began working on the required documents and got access to the workspace and toolset. However, due to the large volume of information provided at the very start, team-building and shared understanding took a backseat.

Challenges:

The most significant challenge was the lack of dedicated time for team-building. We were immediately presented with a large amount of information and expectations without a moment to align as a team. This led to confusion regarding:

  • Our team's purpose and goals
  • Our way of working (communication, responsibilities, tools)
  • The scope and timeline of the project

Reflection:

Had we been given even one hour to establish basic communication norms and roles, we likely would have had a more effective start. Instead, we had to define our working methods while simultaneously processing the project requirements. Despite this, we eventually formed a loosely organized team with the basic structure in place, even if we hadn't yet agreed on our working model or fully understood the project vision by the time Gate 0 closed.

Suggestions for later projects:

Introducing a structured kickoff meeting or a dedicated team chartering session might help future projects establish better collaboration early on.

Gate 1: Offer and Concept Validation

Objective:

To finalize the project offer and validate the overall concept, ensuring the project has a solid foundation for design and early development phases.

What had to be done:

  • Create and review the investment proposal or offer document
  • Finalize the initial project plan, including:
    • High-level design concepts
    • Risk assessments
  • Conduct preliminary planning sprints and design workshops
  • Obtain stakeholder approval for the project’s goals and planned approach

What was done:

The team made significant progress during Sprints 1–3, turning early chaos into structured planning. We successfully produced the following key documents:

  • Project Requirement Specification
  • Project Plan
  • Communications Plan
  • Risk Management Plan
  • Investment Proposal

We also defined our Epics and Features, created the first roadmap, and drafted initial test cases. Jayani developed our public-facing team website using React.js. Our offer was ultimately approved by stakeholders, allowing us to move forward into the development phase with confidence.

Challenges:

While the turbulence of Gate 0 carried into the early part of Gate 1, our team quickly found its rhythm. The main challenge was gaining a clear understanding of the project's scope and structure while simultaneously defining our roles and working methods. Once those foundational elements were in place, we were able to work efficiently. No major technical blockers were encountered during this gate; progress was steady thanks to strong communication and collaboration.

Reflection:

Gate 1 was a phase of intense learning and coordination, during which we successfully established our project's structure, goals, and deliverables. While we had already begun exploring the core technologies such as PrestaShop and deployment environments, the experience highlighted how valuable it can be to broaden technical awareness early on. With better foresight into some of the later requirements—such as security, testing, and debugging—we could have positioned ourselves to move even faster once development began. Still, this was a natural part of the learning curve, and the planning work done during this phase laid a strong foundation for the rest of the project.

Suggestions for later projects:

  • Time for early tech exploration: Encourage teams to designate “technical scouts” in the early stages to explore required technologies while the rest focus on planning and documentation.
  • Clarify goals earlier: A clearer and more unified understanding of the project’s objectives from the start would reduce confusion and stress.
  • Structured team onboarding: Allowing time and guidance for team-building and role definition during Gate 0 could accelerate progress in Gate 1 significantly.

Gate 2: Mid-Development Status Check

Objective:

To evaluate the project's progress during the development phase and make necessary adjustments to ensure successful completion.

What had to be done:

  • Review the current progress against the project plan
  • Update work estimates based on actual progress
  • Identify and resolve bottlenecks or issues encountered during implementation
  • Assess the quality of work completed so far, ensuring it aligns with project standards
  • Reconfirm team roles, responsibilities, and resources for the rest of the project

What was done:

During Sprints 4 and 5, we transitioned into active development. Our PrestaShop service was deployed successfully in the cPouta environment using Docker containers, and core features such as secure service access and Paytrail payment integration were set in motion.

Team members took on more specialized roles:

  • Jayani focused on implementing structured bug fixing procedures.
  • Sami handled the deployment infrastructure and ensured smooth Docker-based setup.
  • Eetu began work on Security-related topics.
  • Valtteri started exploring test automation using Robot Framework.
  • Sol contributed to testing efforts and supported documentation.
  • Lassi continued in the team lead role, prepared material for the Gate 2 presentation, and began work on payment gateway integration.

We reviewed our progress against the plan and adjusted team focus where necessary to stay on track for the next gate.

Challenges:

Contrary to expectations, PrestaShop and its modules did not present significant technical challenges. The platform was relatively easy to work with. Instead, our biggest difficulties were related to:

  • The time-consuming learning curves in Robot Framework, operations, and to some extent, Security
  • Balancing study time for new technologies with implementation deadlines
  • Understanding how to integrate these tools meaningfully into the workflow

These areas consumed much of the time originally reserved for actual development, causing some strain on our sprint goals.

Reflection:

This phase highlighted the importance of balancing learning and execution. While the team worked well and showed commitment, the time needed to get up to speed with new tools and concepts (especially testing and security) challenged our sprint planning. That said, we made steady progress and maintained good team spirit and coordination throughout.

Suggestions for later projects:

  • Begin technical onboarding and tool exploration earlier, especially for testing and security tooling.
  • Schedule learning-focused tasks separately from development tasks to avoid sprint overload.
  • Maintain flexibility in sprint scope when working with unfamiliar technologies.

Gate 3: Demo Day

Objective:

To present a working prototype or near-complete solution to key stakeholders for validation and feedback.

What had to be done:

  • Prepare and deliver a demo session showcasing the core functionalities of the solution
  • Collect feedback from the management team, support group, and potential investors
  • Validate the solution’s performance, usability, and alignment with initial requirements
  • Apply final improvements or fixes based on the demo feedback to prepare for final deployment

What was done:

  • The team prepared both live and pre-recorded demo materials to showcase key features of the platform.
  • A working version of the eCommerce platform, with secure access, payment integration, and bug tracking, was finalized for the demo.
  • The solution was reviewed internally and validated against the original requirements.
  • The actual feedback collection will take place during the Gate 3 demo sessions.

Challenges:

  • No significant challenges were encountered in this phase. The focus was on finalizing documentation, preparing presentation materials, and coordinating the demo approach across the team.

Reflection:

As this documentation is submitted before the actual demo takes place, full reflection will only be possible after Gate 3. However, the team has shown good coordination in preparing for the event and aligning the demo with project goals.

Suggestions for later projects:

At this point, no major suggestions have emerged, but further insights may follow after presenting and receiving feedback during Gate 3.

Gate 4: Release

Objective:

To finalize and deploy the project into production, ensuring all deliverables are completed, tested, and quality assured.

What had to be done:

  • Conduct final testing, documentation, and quality assurance checks
  • Prepare the deployment environment and carry out the release plan
  • Officially release the service and transition into post-deployment support and maintenance

What was done:

  • Final testing and documentation tasks were completed to ensure the system met our defined requirements
  • A comprehensive Release Note was prepared to summarize new features, known issues, and instructions
  • The eCommerce Server Platform was officially released in its production-ready form and deployed to the server environment

Challenges:

There were no major challenges in this phase. The focus was primarily on wrapping up documentation, confirming deployment readiness, and ensuring the final materials were in place for delivery.

Reflection:

As this report is being submitted prior to Gate 4 presentations and post-release feedback, full reflection will take place after the final seminar. So far, the release preparation has gone smoothly, and the platform is considered stable and complete for demonstration and handover.

Suggestions for later projects:

At this stage, no additional suggestions have emerged. Potential improvement areas may arise following feedback from the Gate 4 session and the final presentation.

2.2. Project success (plan vs. implementation)

The project followed a structured, agile-based process divided into planning, development, and finalization stages. While the initial plan served as a useful roadmap, some adjustments were made as we encountered unexpected learning curves, particularly in testing and DevOps.

Process Structure

The early stages (Sprints 0–3) focused on planning, documentation, and forming a shared understanding. Development began in Sprints 2 (this was the start of creating the platform deployed of our project). The rest of the development began Sprint 4 with the bug reporting development, security enhancements, and payment integration started. Finalization (Gates 3–4) is ongoing.

Time Resources

Time was mostly used as planned, though more was spent on early alignment and technical onboarding than anticipated. Weekly effort was consistent, and team motivation remained high throughout.

External Resources

Support was received through Gate reviews, course materials, and documentation. While we didn’t consult external experts often, we made good use of available tools, mentors, and internal knowledge sharing.

Overall, despite some changes, the implementation has stayed aligned with the project goals, and the team has delivered on the planned outcomes with a strong learning focus.

3. PROBLEMS AND THEIR SOLUTIONS

Throughout the project, we encountered a number of challenges, particularly during the early phases of planning and the transition into development. While none of these issues were critical blockers, they did affect the team's efficiency and required conscious effort to resolve.

3.1. Problems in planning

Creating a Shared Understanding of the Project

  • Cause: One of the most significant challenges in the planning phase was forming a unified understanding of the project. The volume of information presented at the start was overwhelming, and at times, conflicting or unclear. With limited time for clarification or discussion, team members interpreted aspects of the project differently, leading to misalignment on goals and deliverables.
  • Solution: The team tackled this issue through persistent effort: reading and listening carefully to all available materials, participating in workshops and lectures, and most importantly—engaging in open, honest, and sometimes long conversations within the team. Through discussion and iteration, we gradually shaped a shared vision and mutual understanding of the project's direction and scope.
  • What could have been done differently: Providing a clearer, consolidated version of the project goals and expectations at the start, or facilitating a guided walkthrough of the key materials—could have helped the team align more quickly and confidently.

3.2. Problems in implementation

Balancing Learning with Execution (Gate 2)

  • Cause: The project required the use of several tools and technologies that were new to many team members (e.g., Robot Framework for testing, DevOps operations, and security configurations). The time needed to study and experiment with these tools significantly impacted the time available for actual development work.
  • Solution: We shifted expectations and sprint goals to allow space for hands-on learning, and team members began sharing findings in internal discussions to help one another. Focused task assignments also helped individuals dive deeper into specific areas (e.g., security, testing, bug reporting) without overloading the whole team.
  • What could have been done differently: Reserving time for technology exploration earlier in the project (possibly even during Gate 1) would have given the team a head start on the more technical demands of implementation.

3.3. Other problems or realized risks and their handling

Lack of Initial Team Alignment and Working Model (Gate 0)

  • Cause: At the beginning of the project, there was very limited time dedicated to team-building and establishing a shared working model. A large amount of information and expectations were presented immediately, which made it difficult for the team to align on goals, roles, and communication practices.
  • Solution: The team gradually built cohesion through regular meetings, task division, and shared documentation. As our understanding of the project improved, so did our internal communication and organization. Roles became clearer, and responsibilities were better distributed as the project progressed.
  • What could have been done differently: A dedicated session for defining ways of working, communication tools, and individual responsibilities before diving into planning documents would have helped build a stronger foundation and reduce early confusion.

Onboarding and Adapting to Agile Practices

  • Cause: While the project followed an agile model with sprints and gates, some team members were new to structured agile methodologies. This occasionally led to unclear task ownership, or difficulties estimating workload during sprint planning.
  • Solution: The team lead took responsibility for keeping the project structured, using clear documentation and presentations to realign expectations. Over time, task clarity and communication improved, and sprint retrospectives helped the team reflect and adapt.
  • What could have been done differently: A short agile onboarding session at the start of the course, or within the team, would have helped all members start on more equal footing and prevented some of the early confusion during planning phases.

4. SUMMARY

Over the course of the project, the team encountered many learning opportunities across technical implementation, project management, and team collaboration. Below are the most important lessons learned, both individually and collectively.

4.1. Key lessons

Working Methods That Worked Well (Best Practices):

Daily Scrum, the team benefited greatly from having daily check-ins:

  • An effective way to share progress and surface issues early
  • Encouraged a culture of openness—team members weren’t left to struggle alone
  • Provided a natural moment to ask for help and realign priorities

Sprint Retrospectives, each sprint was concluded with a retrospective, which proved to be both useful and rewarding:

  • Gave everyone a chance to express how things were going, both technically and emotionally
  • Helped the team improve practices incrementally over time
  • Promoted a sense of shared ownership, trust, and team cohesion

Open Discussion Culture, one of the most impactful cultural practices was encouraging discussion:

  • Asking for help was normalized and welcomed
  • Open conversations led to better understanding and better decisions
  • Enabled the team to create and maintain a shared understanding of goals and tasks

GitLab Issue Boards, the GitLab issue board turned out to be a central and powerful tool:

  • Allowed clear task division and ownership
  • Made it easy to visualize the current status of work
  • Created accountability by assigning team members to issues
  • Supported smooth transitions through phases: planning → implementation → testing → review

4.2. Self-assessment

Lassi (Team Lead):

  • Learned to guide the team using structured methods such as Scrum
  • Gained experience in organizing and facilitating daily stand-ups and retrospectives
  • Learned the importance of team morale and open dialogue in maintaining project momentum
  • Developed project communication materials and took lead on payment integration work

Sami (Team Generalist):

  • Was mainly responsible to setting up the VM environment and installing PrestaShop which was completely new
  • Faced challenges pretty much in every step in the way but managed to overcome most of them
  • Learned power of teamwork and asking help
  • And sometimes need to admit that own knowledge is not enough to complete given tasks

Valtteri (Tester):

  • Responsible for testing and setup of automated testing of Robotframework
  • New principles and technologies for testing were a great challenge without prior experience
  • Gained a great deal of knowledge on testing and understanding how important it is to actively communicate with others during testing

Eetu (Sec)

  • Took on the role of handling security-related tasks despite having no prior experience in cybersecurity
  • Gained valuable first-hand insight into identifying potential threats and understanding best practices for securing a PrestaShop environment
  • Learned to clearly document and communicate security concerns with the team
  • Realized the importance of addressing cybersecurity from the very beginning of a project, not just as an afterthought

Jayani (Dev)

  • As a dev I was responsible of the team home page and the bug fixing.
  • As a dev I faced so many challenges of understanding the context of bug fixing.
  • Learned to proactive in debugging and improving code quality.
  • Quickly learned new frameworks and technologies because php was new framework for myself.
  • Gained problem-solving mindset with a logical thinking.

Sol (Tester)

  • As a tester I worked on supporting Robot Framework implementation creating scripts for automation.
  • Learned to write robust test cases and understood the importance of clear step-by-step test logic.
  • Updated certain documents required for the workflow of the project.
  • Had to do thorough research on what my role as a tester was and how I can make an addition to the project.

4.2.1. Teamwork

Project management: This went rather well. I was able to keep people updated on information about the project. I was helped greatly by all the team members being motivated and capable.

Utilization of diversity: I think we succeeded quite well, task were divided based on peoples predefined roles and the predefined roles were based on peoples actual interests and talents. This was not perfect, but I feel this went rather well.

Problem solving: We were able to not just find solutions to technical problems, but also were able to solve team work related issues.

Division of labor: We had some problems with this. There were moments when a few of the team members did not have a lot to do while other were overworked. The nature of the project was mostly to blame, but we could have done better on this regard.

The group's own work: The group worked up to it's potential. I feel we achieved what could have been expected based on out prior knowledge and the amount of time we were given.

Other's work: I personally was happy, but on the other hand I was not really dependant on input from support group. I know that there were some problems with this, but personally I can't really comment.

Utilization of resources: Our main resources were time, time, time, ability to learn, and our prior knowledge. Time management was relatively good, we were able to use most of the hours available to us on things that mattered for the project. We could have used our prior knowledge better, if we would have been co-operating more. A big part of this course was about learning what we should do and how it can be done. I think learning things was a successes for us.

Control and its use: I don't really understand this topic.

Group process: Forming, Storming, Norming, Performing; Forming was a bit painful as we really did not have time for this. Because of lack in Forming, Storming took sime time and we had some problems (people doing things as individuals without consulting the team and making a unified decision). Thank fully we were able to find a way of working together and the Norming stage was quite painless and quick.

Crises and coping with them: We had some difficulties in the beginning as we were overwhelmed with information and absolutely no team cohesion. The solution was talk, talk, talk.

Critical development of one's own work: I set out to find a way of being a less "Management by Perkele" type of lead. I think I was able to achieve this somewhat well. I had some problems in the beginning, but as I got going I found that at least with this team I can lead with discussion. There were some moments when I needed to set a direction for the team by just stating this needs to be done, which I feel like I was able to do. There were some moments when a little less conversation would have sufficed, which I did not notice, but all in all I am happy of how I was able to transform my self. I found some real meaning to certain agile practices such as Daily and Retrospective, so I was also able to learn new thing during this course.

4.2.2. Planning (project work)

Plans: Our planning process started with a lot of uncertainty. The biggest challenge was building a shared understanding of the project, due to the overwhelming amount of information we received—some of which was contradictory. Once we aligned on the goals, our plans started to take better shape. The Project Plan and Requirement Specification were useful in setting direction.

What was done?: We produced all the required planning documents: Requirement Specification, Project Plan, Communication Plan, Risk Plan, and Investment Proposal. In addition to documentation, planning also included our initial sprint structure and roadmap, which helped guide development.

What was used/supervised (how was it reflected in everyday life of the project)?: Our planning documents acted as reference points during the early and mid-sprints. They were especially helpful for justifying our development decisions.

What was updated and why?: The project plan and scope evolved naturally as we learned more. In particular, the roadmap and workload estimations should have been revised after the fourth sprint, when we realized how much time certain technical tasks—like testing or setting up infrastructure—would actually take.

How well done?: Given the time pressure and the learning curve involved, I believe our planning was reasonably successful. The documents were clear enough to guide us, and we were able to stick to most of our self-imposed deadlines. There’s always room for improvement in terms of estimation and scheduling, but we learned a lot.

Resource management: Our most limited resource was time. While we made decent use of it, I feel we could have managed our technical expertise more deliberately—such as having specific people dive deeper into PrestaShop or Robot Framework earlier on. Still, overall, our resource allocation was balanced and flexible.

Designed: Our solution was designed iteratively. We began with a broad idea of the platform’s purpose, and gradually shaped the implementation around the features we knew we could complete. While we didn’t have a comprehensive system design from the start, our modular feature-based approach worked well.

Supervision: Most supervision came from within the team. As the team lead, I took responsibility for making sure things were progressing and people had what they needed. External supervision (support group, mentors) was more limited, though appreciated when available. The lack of frequent external check-ins may have increased our internal autonomy, which wasn’t a bad thing.

Realization: We followed through on our core plans, particularly with PrestaShop deployment, bug tracking setup, and payment integration. Not everything was completed as originally envisioned, but the key parts were realized in a working and testable way.

Documentation of the project process (e.g. memos from different meetings): We documented major decisions and created presentations for each Gate. While we didn’t keep formal minutes for meetings, we used GitLab issue tracking and shared documents to keep track of ongoing tasks and discussions, which worked effectively for our purposes.

Project process management: Our process matured over time. Early stages were a bit chaotic, but once the team roles were clear and the sprint rhythm established, our process became much smoother. Agile practices like Daily Scrum and Retrospectives helped us stay on track and learn from each sprint.

4.2.3. Interaction

Communication with stakeholders: Our primary stakeholders were the project mentors, scrum master / coach, and the support group. Most of our communication happened through scheduled reviews, Gate presentations, and GitLab documentation. While we didn’t always receive fast feedback, the interaction we had was constructive.

Information acquisition (getting information from the client): The client information was mostly provided through written materials and lectures at the start of the course. Initially, this was overwhelming and sometimes contradictory. It took time, reading, discussion, and clarification to understand what was expected. A more centralized or simplified client brief would have helped a lot early on.

Interviews and their preparation, implementation, and data processing: We did not conduct formal interviews in the traditional sense, but we did gather information and feedback through our Gate presentations and informal communications with mentors and staff. This feedback was processed collaboratively and led to adjustments in our work.

Informing: We made sure to keep the team and stakeholders informed through GitLab issues, and regular sprint summaries. The Gate presentations also served as milestones to update everyone on our progress. Internal team updates were mostly handled in daily scrums and Discord.

In the customer organization: As the investor was represented more by the course staff and mentors than a single entity, communication within the “customer organization” was less direct. However, we assumed that our deliverables and documentation would be evaluated by that audience and tried to maintain clarity and professionalism in all communications.

Special target groups: Our platform was built for a general eCommerce audience, but we did not have a clearly defined special target group during development. Future iterations could benefit from targeting a more specific customer segment.

For the University of Applied Sciences: The documentation, Gate presentations, and project results were tailored with the University in mind, as both an academic stakeholder and end reviewer of our work. We tried to ensure all materials met the expectations for academic transparency, planning, and process reflection.

Other objects and media (e.g., magazines, fairs, etc.): We did maintain a public team webpage to serve as an outward-facing presentation of our project and also some of the team members made some LinkedIn post on our project. This could be extended in future versions.

Management team work (preparation, achievement of GATEs, implementation): Gate preparations were usually led by me (as team lead), with input and slide content provided by the whole team. We treated Gate presentations as real milestones and put effort into presenting a clear picture of our progress, learning, and remaining work. This helped us stay focused and gave us useful deadlines to work toward.

Task development and limitations: Tasks were developed incrementally as we learned more. Some limitations came from lack of technical knowledge early on, which made it hard to estimate work or scope features. As the project matured, we got better at defining tasks with realistic boundaries and clearer requirements. In the end we were forced to discard some user stories due to lack of time.

How made? On whose presentation and with what information?: Most decisions and tasks were made based on group discussions or insights shared during daily scrums. When things were unclear, we looked back at the project documentation, user stories, or gate feedback. No one made decisions unilaterally; our strength was collaboration.

Support group activities (obtaining information, utilizing experts): We had some contact with the support group, though it was somewhat limited in frequency. When we reached out, the support was helpful—but more regular communication or checkpoints might have helped us engage better with their expertise.

"Feeling" and its causes (if "down-tempered", how improved?): The beginning of the project felt overwhelming—there was a lot of uncertainty and not enough time for team-building. This caused some tension and confusion. What helped us improve morale was frequent open discussion, shared laughs during calls, and the fact that progress became more tangible after each Gate. Daily scrums and retrospectives also gave everyone a chance to be heard.

Taking into account other busy schedules when communicating (forecasting, trips, etc.): People informed the team well in advance, if they could not attend sessions. We relied on people to schedule their work on this project by them selfs.

Use of communication tools: Discord and GitLab were our main tools. Discord was excellent for both real-time and async communication, while GitLab handled task tracking and documentation. Meetings were kept to a minimum and mostly centered around planning or retrospectives. We avoided long or unnecessary meetings, which was the right call.

Effectiveness of the interaction (Jory, e-mail, others): Internal team interaction was very effective—thanks to Discord and a collaborative attitude. Interaction with stakeholders was slower and sometimes unclear, but improved when we asked the right questions. For external communication, email was rarely used—Discord and GitLab comments were more practical and better suited to fast-paced work.

4.2.4. Attitude of team

To the task: The attitude of our team toward the task was consistently committed and enthusiastic. Even when things were unclear or demanding, everyone approached the project with a sense of responsibility and a willingness to contribute. I never felt like anyone was trying to do the bare minimum—there was a shared goal to create something functional and meaningful.

For learning: Our learning mindset was one of our greatest strengths. Everyone was eager to explore new tools and practices—even when the learning curve was steep. From testing and security to deployment and documentation, team members embraced new challenges as learning opportunities. It was clear that we saw this course not just as a project, but as a platform for personal and professional growth.

To problems: We approached problems with a solution-oriented mindset. Whether the issues were technical or organizational, the default attitude was "let’s figure it out together." No one got stuck blaming others or shutting down. Instead, there was open discussion, mutual support, and a real effort to move forward constructively.

Excerpt from the project in its various stages: At the beginning, we were a bit overwhelmed, but still determined. During planning, we were thoughtful and thorough. During development, we were focused and resilient. And during review stages, we were reflective and honest. Our attitude evolved with each stage, but always stayed positive, committed, and team-first.

Seeking feedback: The team was very open to feedback, whether it came from Gate presentations, retrospectives, or peer comments. We actively asked each other for input and took suggestions seriously. I was especially happy to see how feedback wasn’t seen as criticism, but as a tool for improvement.

4.2.5. Result

The primary result of the project is a functional and deployable PrestaShop-based eCommerce Server Platform, including secure access, a structured bug reporting process, and a working Paytrail payment integration. These components form the core deliverables and reflect both the technical and organizational objectives of the project.

Quality of Outputs

The outputs meet the expectations defined in the requirement specification. The platform is functional, modular, and documented—ready for demonstration and further development if needed. Although some features are still under refinement, the foundation is solid and aligns with real-world standards.

Intangible Results

One of the most valuable outcomes is the change in mindset among team members. Through this project, we gained a deeper appreciation for agile practices, communication, and collaborative problem-solving. There was noticeable growth in areas such as testing, documentation, team leadership, and the ability to adapt under pressure.

Value to the Organization

The project delivers value not only through the final platform but also by acting as a learning model for future student teams. The clear documentation, feature-focused approach, and internal processes provide a blueprint that others can learn from or build upon.

Follow-up Measures

The current version will be presented at the Final Seminar (Gate 4), and the project materials—including documentation and code—will remain accessible for future use or development. The lessons learned will be shared as part of the course’s final evaluation, contributing to continuous improvement in Future Factory (IT) course implementations.

Signing and date

22.04.2025

Burzachechi Sol, N0979

Helminen Valtteri, AF0171

Hyvärinen Sami, AF0694

Iiskola Lassi, AC8425

Kothalawala Jayani, AD9680

Suutarinen Eetu, AF0951