Project plan
| Document | PrestaShop as a Service Project Plan |
| Author: | LinearB |
| Version: | 1.00 |
| Date: | 19/02/2025 |
1. Assignment
1.1 Background and starting points
This project involves the development and deployment of an e-commerce platform using PrestaShop, hosted on a cPouta server. The primary objective is to create a steady and scalable online marketplace similar to established platforms such as Amazon, focusing on delivering a seamless shopping experience for users. PrestaShop, being a highly customizable and feature-rich open source e-commerce solution, serves as the backbone of the service, ensuring flexibility in design and functionality.
This project caters to customers diverse needs while ensuring reliability, security, and user friendliness. The service environment will ensure optimal performance, scalability, and data privacy, aligning with the project's technical and operational requirements.
The approach will focus on secure service access, efficient bug tracking, and payment gateway integration, addressing key business and technical requirements to improve the overall PrestaShop development workflow.
1.2 Goals and tasks
The goal of this project is to develop PrestaShop as a Service, enabling developers and service companies operators to efficiently deploy and manage PrestaShop-based e-commerce solutions. The project will use Docker-based containerization to streamline development, ensure secure service access, and integrate necessary extensions for a fully functional PrestaShop environment.
What and How
The main task is to containerize PrestaShop and integrate it with MariaDB using Docker Compose. This will allow developers to easily mount their local code into a running container, making real-time changes visible instantly. Additionally, the project will include HTTPS support, authentication mechanisms, and efficient bug tracking to ensure security and stability.
Vision
The future state includes a fully operational and scalable PrestaShop service running in a containerized environment. This setup will support secure online transactions, easy maintenance, and seamless integrations with payment gateways, ensuring a developer-friendly ecosystem that enhances productivity and deployment efficiency, while providing the best service to customers in their shopping experiences.
Concrete Outcomes
Concrete Outcomes The concrete outcome of the project will be a Dockerized PrestaShop environment, including:
- A pre-configured Docker image with all necessary PHP extensions and libraries.
- MariaDB integration for seamless database connectivity.
- Secure service access with HTTPS and improved authentication.
- Efficient issue tracking and bug reporting to streamline maintenance.
- Support for major payment gateways to enable smooth transactions.
1.3 Limitations and interfaces
This section outlines the scope and boundaries of the PrestaShop as a Service project, defining the external factors that may impact its development and identifying functional interfaces with other systems.
Limitations
- Hosting Infrastructure
- Multi-language Support
- User Training & Documentation
Interfaces
- MariaDB Database
- Docker & Docker Compose
- HTTPS & Authentication Services
- Payment Gateways
- Issue Tracker
1.4 Rights and IPR
The rights and intellectual property (IP) ownership for the deliverables created in this project are determined by the overarching project agreement. Unless otherwise specified in a separate written contract, the following general principles apply:
Ownership of Deliverables
All custom code, documentation, and configurations developed within the scope of this project belong to the project team or commissioning party as defined in the project agreement. Third-party libraries, frameworks, or plugins (e.g., PrestaShop, Docker images, payment gateway modules) remain subject to their respective open-source or commercial licenses.
Licensing
Any newly created software components or modifications to existing open-source components will be licensed in a manner consistent with the original licenses (e.g., GPL, MIT), unless otherwise agreed. If a specific open-source or proprietary license is chosen for the project’s deliverables, it will be explicitly stated in the project agreement or final documentation.
Use of Project Outputs
The commissioning party (or investor) may use the project outputs—such as containerized PrestaShop instances and accompanying scripts—internally or commercially, subject to any third-party license restrictions. The project team retains the right to reference non-confidential portions of the work for portfolio or academic demonstration purposes, unless otherwise restricted by a confidentiality clause.
Branding and Trademarks
Any branding, trademarks, or service marks used within the project remain the property of their respective owners. The project team does not claim ownership of any external brands integrated into the system.
Future Modifications
Should the investor or any subsequent party wish to extend, modify, or re-license the project deliverables, such activities must respect the original license terms and any separate agreements in place.
In the event of conflicting interpretations or future changes, an addendum or amendment to the project agreement will clarify the allocation of rights and IPR for all parties involved.
1.5 Terms and Definitions
To be updated
2. Project organization
2.1 Organization
The PrestaShop as a Service project is managed and executed by LinearB, our structured team, ensuring efficient development, deployment and maintenance of the platform. The project includes multiple internal and external stakeholders. For more information visit our Requirements Specifications page
Structure of Project Organization in MindMap form
Get to know our Team
| Name | Description | Responsibilities in Team | Link |
|---|---|---|---|
| Burzachechi Sol | Service Design | Enhancing user experience and workflows | |
| Helminen Valtteri | Testing | Ensuring quality through rigorous validation | |
| Hyvärinen Sami | Renaissance man of the digital age | Bridging creativity, technology, and innovation | |
| Iiskola Lassi | Team Lead | Coordinating, guiding, and ensuring success | |
| Kothalawala Jayani | Developer | Building and maintaining robust software solutions | |
| Suutarinen Eetu | Cyber Security | Protecting systems, data, and infrastructure |
3. Project's temporal Gates
3.1 Partitioning and Phase
Timeline of the project
Project Gates and Milestones
Links to gates
Gate 0: Introduction and Team Building, Milestone - Gate 0 - Objective: Establish the project foundation and create a cohesive project team. - Key Activities: - Assemble the project group and assign initial roles. - Conduct team-building sessions to establish communication and collaboration norms. - Define project objectives, initial scope, and available resources. - Set up the project workspace and necessary tools. - Outcome: A fully formed, aligned team with a clear understanding of the project’s vision and initial planning documents.
Gate 1: Offer and Concept Validation, Milestone - Gate 1 - Objective: Finalize the project offer and detailed planning, laying the groundwork for design and early development. - Key Activities: - Develop and review the investment proposal or offer document. - Finalize initial project plans, including high-level design concepts and risk assessments. - Conduct preliminary planning sprints and design workshops. - Secure stakeholder approval on the project’s objectives and planned approach. - Outcome: An approved offer with a validated concept and a clear plan for moving into the development phase.
Gate 2: Mid-Development Status Check, Milestone - Gate 2 - Objective: Evaluate progress during development/implementation and adjust plans as necessary. - Key Activities: - Review progress against the project plan and update work estimates. - Identify and resolve any bottlenecks or issues that have arisen. - Assess the quality of work completed to date, ensuring adherence to project standards. - Reconfirm roles, responsibilities, and resources for the remaining phases. - Outcome: A comprehensive status report and any necessary adjustments to ensure that the project remains on track.
Gate 3: Demo Day, Milestone - Gate 3 - Objective: Present a working prototype or a near-complete version of the implementation to key stakeholders. - Key Activities: - Prepare and conduct a demo session showcasing core functionalities. - Gather feedback from the management team, support group, and potential investors. - Validate the solution’s performance, usability, and alignment with initial requirements. - Make final adjustments based on feedback received during the demonstration. - Outcome: Stakeholder validation and a refined product ready for final deployment.
Gate 4: Release, Milestone - Gate 4 - Objective: Finalize the project for production, ensuring all deliverables are completed and quality assured. - Key Activities: - Complete final testing, documentation, and quality assurance checks. - Prepare the deployment environment and execute the release plan. - Conduct training sessions and handover documentation for operational teams. - Officially release the service and transition to post-deployment support and maintenance. - Outcome: A fully deployed and operational PrestaShop-based e-commerce platform, with all project deliverables completed and approved.
3.2 Project preliminary cost estimate
The whole budget can be found from Cost-Estimation.xlsx
4. Quality Assurance
This section outlines the working methods, tools, instructions, and standards that will be applied throughout the project to ensure high-quality outcomes. The project team will adhere to established guidelines—including those provided by the IT Institute—and any additional processes approved by the client or investor. All key project documents, code, and deliverables will be versioned and stored in a centralized repository, ensuring that the latest versions are always available to stakeholders. Regular monitoring, reporting, and quality checks will be integrated into our workflow to identify and resolve issues promptly.
4.1 Approval of Intermediate and Final Results
The approval process is a critical component of our quality assurance framework. It ensures that all intermediate deliverables and final results meet the established quality standards and project requirements. The following procedures will be followed for approval:
Scheduled Review Meetings:
At the end of each project phase, the project team will present deliverables during structured review meetings with key stakeholders (project group, management board, and, where applicable, external advisors or investors). These meetings serve as checkpoints to evaluate progress and to verify that deliverables meet the pre-defined acceptance criteria.
Documentation and Version Management:
All deliverables—including design documents, source code, test reports, and project plans—will be version controlled using approved tools (e.g., Git). The latest approved versions will be archived in a central repository accessible to all relevant stakeholders.
Acceptance Criteria:
Each deliverable will be assessed against clearly defined acceptance criteria. These criteria are documented in the project plan and related specifications. Any discrepancies or issues identified during the review will be recorded, and corrective actions will be required before sign-off.
Formal Sign-off:
Deliverables will only be considered complete after receiving formal sign-off from the designated decision-makers, such as the project manager, product owner, or quality assurance lead. This sign-off process is documented in meeting minutes and tracked in the project management system.
Tools and Reporting:
Quality assurance tools (such as CI/CD pipelines, issue trackers, and automated testing suites) will support the review process. Detailed reports and logs from these tools will be reviewed during approval meetings to verify compliance with project standards.
Feedback and Continuous Improvement:
Feedback obtained during the approval process will be promptly addressed. Lessons learned and any process adjustments will be documented and integrated into future project phases to ensure continuous improvement.
4.2 Manage Changes
This section outlines the change management procedure to ensure that any modifications to project practices or the project’s results are handled in a controlled and systematic manner. The process aims to minimize disruption while ensuring that all changes are documented, evaluated, and approved before implementation.
Change Request Submission:
Any team member or stakeholder may initiate a change by submitting a formal Change Request (CR) document. This document should clearly describe the proposed change, the rationale behind it, and its expected impact on the project.
Impact Assessment:
Upon receiving a Change Request, the project management team will conduct a detailed impact analysis to evaluate how the proposed change affects project scope, schedule, budget, and quality. This assessment will include: - Risk Evaluation: Identifying potential risks and mitigation strategies. - Cost-Benefit Analysis: Determining the value added by the change versus its cost and disruption.
Approval Process:
The Change Request, along with the impact assessment report, will be presented to the project board or designated decision-making body. The board will review the documentation and decide whether to: - Approve: Proceed with the change. - Postpone: Delay the change until a later phase. - Reject: Decline the change if it is deemed non-beneficial or too disruptive.
Implementation Planning:
For approved changes, the project plan, timeline, and related documentation will be updated accordingly. A detailed implementation plan will be prepared, outlining: - Task Assignments: Who will be responsible for executing the change. - Timeline Adjustments: Revised milestones and deadlines. - Resource Allocation: Any additional resources needed for the change.
Communication and Documentation:
All changes, including the decision and implementation details, will be thoroughly documented. Updates will be communicated to all project stakeholders, and the change log will be maintained in the version-controlled repository.
Monitoring and Review:
Post-implementation, the change will be monitored to ensure it meets the intended objectives without adversely affecting other project areas. Any issues or further adjustments will be addressed in follow-up reviews.
4.3 Documentation
All project documents will be maintained in a centralized GitLab repository to ensure that the latest versions are easily accessible and properly archived. The repository will serve as the single source of truth for all documentation, including project plans, design documents, code documentation, test reports, meeting minutes, and change logs.
Storage and Archiving:
All documents are stored in the GitLab repository under structured folders corresponding to their document type (e.g., requirements, design, testing). Each document is version-controlled, ensuring that historical versions are preserved and changes can be tracked over time.
Access and Sharing:
The repository is shared among all project stakeholders, including the project team, board members, and support group, with access levels assigned according to their roles. Public sharing of non-confidential documents is possible via GitLab’s sharing features, while sensitive information remains restricted to authorized users only.
Responsibility:
- Project Manager: Oversees the overall documentation strategy and ensures that all documents are updated regularly.
- Documentation Lead (or designated team member): Responsible for organizing the repository structure, managing document versions, and ensuring compliance with documentation standards.
- Team Members: Required to update their respective documents (e.g., technical specifications, user guides) and commit changes to the repository in a timely manner.
Guidelines and Standards:
All documentation should adhere to the established project standards and templates. Regular audits will be performed to ensure consistency, completeness, and accuracy.
4.4 Risk Management
The following table outlines the key risks identified for the project, along with their unique identifiers, a brief description, an evaluation of their severity and probability, and the proposed mitigation strategies. This risk log will be maintained and updated throughout the project lifecycle.
| Risk ID | Description | Severity | Probability | Mitigation Plan |
|---|---|---|---|---|
| RIS001 | Delay in setting up the Dockerized environment and integration with MariaDB | High | Medium | Establish clear setup guidelines, assign an experienced team member to lead the configuration, and schedule early testing to catch issues promptly. |
| RIS002 | Inadequate security measures leading to vulnerabilities in the service | High | Low | Conduct regular vulnerability scanning, adhere to industry security standards, and incorporate a review process for security-critical changes. |
| RIS003 | Scope creep due to additional feature requests or changes in project requirements | Medium | Medium | Implement a change management process (see Section 4.2) and hold regular review meetings to reassess priorities and ensure scope alignment. |
| RIS004 | Insufficient documentation updates causing miscommunication and version control issues | Medium | Medium | Enforce strict documentation guidelines, assign a dedicated documentation lead, and schedule periodic audits of the GitLab repository. |
| RIS005 | Resource constraints, such as team availability or hardware limitations affecting project progress | High | Low | Plan resource allocation in advance, build in buffer time for potential delays, and consider external support if necessary. |
| RIS006 | Integration challenges with third-party services (e.g., payment gateways, version control systems) | Medium | Medium | Maintain close communication with third-party vendors, use standardized APIs, and include contingency time in the schedule for integration testing. |
| RIS007 | Communication breakdown within the project team or with stakeholders | Medium | Low | Establish clear communication channels and regular status meetings; utilize collaborative tools (e.g., Slack, Discord) to keep everyone aligned. |
Link to risk management plan: Risk Management Plan
4.5 Reviewing Policy
This section outlines the procedure and schedule for ongoing project performance reviews based on the established implementation plan. Reviews are designed to monitor progress, address issues promptly, and ensure that deliverables meet the required quality standards. The following elements are included in our reviewing policy:
Scheduled Reviews:
Reviews will be conducted at key milestones (e.g., at the end of each project phase or gate) as well as at interim points to assess progress against the plan.
Preliminary Schedule:
A provisional timeline for reviews is established based on the project’s implementation plan. Dates and review frequency will be confirmed and adjusted as necessary during the project kickoff and early planning stages.
Review Content:
Each review session will focus on: - Performance Evaluation: Analysis of work completed versus planned tasks. - Issue Identification: Discussion of any emerging risks or problems that may affect project outcomes. - Documentation Assessment: Verification that all required documents are up-to-date and correctly archived. - Stakeholder Feedback: Input from team members, board representatives, and other key stakeholders regarding project progress and challenges.
Participants:
Reviews will include the project team, management board members, and, when relevant, external stakeholders or advisors. The specific participants for each review session will be defined in the review schedule.
Review Material Delivery:
Prior to each review session, the project team will prepare and distribute the relevant documentation, including progress reports, risk logs, and any changes to the implementation plan. Reviews may be conducted in-person, via video conference, or through a shared collaboration platform, ensuring that all participants have access to the necessary materials.
Follow-Up Actions:
Outcomes from each review session, including decisions, action items, and any required changes, will be documented and tracked. This ensures that any deviations from the plan are promptly addressed and that the project remains on course.
4.6 Complementary plans for the project plan
- Project Agreement
- Requirement Specification
- Release Plan
- Master Test Plan
- Communication Plan
- Risk management plan
5. Communication and tracking of project progression (communication plan)
5.1 Communication Plan
6. The end of the project
6.1 Delivery of the End Product, Introduction
The final product of the project will be comprehensively documented and delivered at a level appropriate for its intended users. This documentation will include:
User Documentation and Training Materials:
Detailed user guides, quick-start tutorials, and troubleshooting documents. If the target users have not been involved in the development process, a structured training plan will be provided to ensure they can efficiently use the system.
Introduction and Onboarding:
A formal introduction session will be organized for the customer, covering: - An overview of the product features and functionalities. - A guided walkthrough of the system. - Q&A sessions to address any queries from the customer.
Installation and Commissioning Plan:
In cases where installation or deployment requires support, a step-by-step plan will be included. This plan will detail: - Hardware or cloud environment requirements. - Installation procedures. - Commissioning processes and any necessary post-deployment support.
Deployment Plan:
The final product will be deployed following a well-defined plan that ensures: - Minimal disruption to existing services. - A rollback strategy in case of unforeseen issues. - Clear communication of deadlines and responsibilities during the rollout.
6.2 Taxation of the Project Produced by the Project, Archiving and Retention Period
All documentation produced during the project—including plans, progress reports, final reports, and other key deliverables—will be stored in a centralized system (referred to as the "X system") to ensure proper archiving and future accessibility. The following measures have been established for document retention and archiving:
Centralized Archiving:
All finalized project documents will be uploaded to the X system, where they will be organized by document type and project phase. This centralized approach facilitates easy retrieval and review by current and future project teams.
Retention Period:
Documents will be retained for a predetermined period, as agreed upon with the project stakeholders and in line with regulatory or organizational requirements. After the retention period expires, documents may be purged or transferred to a long-term archive based on their relevance to future projects.
Transfer to Future Projects:
The project team, in collaboration with the project assistant, will review all documentation to determine which materials—such as detailed plans and the final report—should be carried forward to subsequent projects. This ensures that valuable insights and methodologies are preserved for future initiatives.
Access and Security:
Access to archived documents will be restricted to authorized personnel only. A log of document revisions and access history will be maintained to ensure transparency and accountability.
6.3 Official Termination of the Project
The official termination of the project is defined by the completion of agreed-upon deliverables, the fulfillment of contractual obligations, and the formal acceptance of the final product by the customer. Termination may be triggered by various conditions, such as:
- Reaching a predetermined project end date.
- Completion and acceptance of a ready-made product.
- Exhaustion of allocated work hours or budget.
- Expiration of the warranty period or successful resolution of any post-deployment issues.
For this project, the official termination will occur on 22th Feb 2025, when the project contract expires and the customer formally accepts the final deliverable. At that point, all project activities will be concluded, and responsibilities for maintenance and support will be transitioned according to the terms defined in the contract.
6.4 Termination
To be updated.
6.5 Project Final Report
The final report of the project will be drawn up by the last management team meeting.