Project plan (template)
| Document | Project Plan |
| Author: | Juho K. |
| Version: | 0.34 |
| Date: | 21.2.2025 |
1. Assignment
1.1 background and starting points
This project, carried out by the TechForge team, focuses on the development and implementation of PrestaShop as the core product. The project aims to define and present the system in a structured manner, often using graphical representations to illustrate its role within a broader assembly or process. This helps in understanding both the current system and the customer’s existing workflow.
The project is part of the Future Factory studies (ZZPP0920-3067) and involves analyzing, configuring, and optimizing PrestaShop to meet specific requirements. The goal is to refine its functionality and ensure it aligns with the project’s objectives.
1.2 Goals and tasks
TechForge's background, objectives, tasks, phase distribution, and recourses of the Prestashop. Each step is described in detail, aligned with the project’s phase division.
Defining the Most Important Content of the Job in This Project The tasks of the project are directly related to the total project scope as described in the project plan. The primary focus is on developing and implementing PrestaShop to meet the customer’s needs. This involves:
Analyzing the Current System:
Understanding the customer’s existing workflow and identifying areas for improvement.
Mapping out how PrestaShop can integrate into the current system.
Configuring PrestaShop:
Customizing PrestaShop to align with the customer’s requirements.
Setting up modules, themes, and plugins to enhance functionality.
Optimizing PrestaShop:
Improving performance, scalability, and user experience.
Ensuring the system is robust and capable of handling future demands.
Vision of a Future State
The vision is to create a fully optimized and customized PrestaShop system that seamlessly integrates into the customer’s workflow. This system will:
Enhance operational efficiency.
Provide a user-friendly interface for both administrators and end-users.
Support scalability to accommodate future growth.
Result of the Outcome
The concrete outcomes of the project include:
A fully configured and optimized PrestaShop system.
Documentation outlining the system’s setup, configuration, and usage.
Training materials to ensure the customer’s team can effectively use and maintain the system.
Partial or Intermediate Results
Intermediate results include:
A detailed analysis report of the current system and workflow.
A configuration plan for PrestaShop.
A prototype or demo of the customized PrestaShop system for feedback and validation.
1.3 Limitations and interfaces
Limitations
Platform Requirement: The solution must be build exclusively on the PrestaShop Platform.
Development Window: The project must be completed within a strict timeline, starting on January 14, 2025, and concluding by April 22, 2025.
Initial Release Focus: The first version will prioritize essential eCommerce features, ensuring a solid foundation for future enhancements.
Payment Gateway Support: Only standard, widely-used payment gateways will be integrated at launch, with no custom or niche solutions included initially.
Shipping Integrations: The platform will support commonly used shipping services, avoiding specialized or region-specific carriers for the initial release.
External Integrations
Payment Processing: APIs from established payment gateways will be integrated to handle transactions securely and efficiently.
Shipping service: APIs from major shipping providers will be incorporated to manage logistics and delivery tracking.
Email communication: Integration with third-party email service providers will ensure reliable customer communication, including order confirmations and promotional emails.
Analytics and reporting: The platform will connect with analytics tools to provide insights into sales, customer behavior, and performance metrics.
Customer support: Tools for customer service, such as ticketing systems or live chat, will be integrated to enhance user support and satisfaction.
1.4 Rights and IPR
Rights of the parties
The rights and responsibilities of all involved parties are governed by the project agreement. Unless otherwise specified in a separate agreement, the following terms apply:
Customer rights: The customer retains the right to use, modify, and extend the final PrestaShop implementation for their business operations.
TechForge Rights: TechForge reserves the right to utilize the knowledge and experience gained during the project for future developments, provided that no confidential customer data is disclosed.
Third-Party Rights: Any third-party tools, plugins, or integrations used in the project remain the intellectual property of their respective owners and are subject to their licensing terms.
Confidentiality: All proprietary information exchanged during the project shall remain confidential and not be disclosed to any unauthorized parties
Intellectual Property Rights (IPR)
The ownership and usage rights of intellectual property created during the project are defined as follows:
Pre-existing intellectual Property: Any pre-existing intellectual property, including software, designs, or methodologies, remains the property of the respective party that owned it prior to the project
Newly Developed Intellectual Property: Custom modules, themes, and configurations developed specifically for the project shall be the property of the customer unless otherwise agreed.
Open-Source Components: PrestaShop and any open-source modules used in the project will continue to be governed by their respective open-source licenses.
Documentation and Training Materials: The customer receives full rights to use and distribute documentation and training materials created during the project for internal use.
1.5 terms and definitions
This section presents the definitions, terms, and abbreviations used in the project plan. In different projects, terms such as "inspection" and "reviewing" may have different meanings, potentially causing misunderstandings. To prevent confusion, the project team may establish specific terminology for different types of inspections (e.g., internal, customer, or academic reviews).
- API = Application Programming Interface.
- ERP = Enterprise Resource Planning.
1.6 Challenges related to the project
To evaluate project risks and critical success factors, a SWOT analysis will be conducted. This will examine both the internal and external factors influencing the project’s execution and outcomes.
Strenghts: Key advantages such as team expertise, established workflows, and robust technology choices.
Weaknesses: Potential limitations including resource constraints, tight deadlines, or technical challenges.
Opportunities: Growth potential, market advantages, and opportunities for further system enhancements.
Threats: External risks such as changing market conditions, regulatory compliance issues, or dependency on third-party providers.
2. Project organization
2.1 Organization
Structure of Project Organization in MindMap form
2.2 Responsibilities and decision-making process
Project Group
| Name | Responsibility | Company/Community |
|---|---|---|
| Minna Holkko | Team Lead | TechForge |
| Juho Koivukangas | Admin/OPS | TechForge |
| Lasse Vääräsmäki | Service Desing | TechForge |
| Kalle Kauppila | Security | TechForge |
| Mirko Pölkki | Gen/Tester | TechForge |
| Hanh Nguyen | Product Owner | - |
Board Members
| Name | Responsibility | Company/Community |
|---|---|---|
| Hanh Nguyen | Product Owner | - |
| Minna Holkko | Team Lead | TechForge |
| Customer represemtative 1 | Representative | Customer |
| Customer representative 2 | Representative | Customer |
Support Group
| Name | Responsibility | Company/Community |
|---|---|---|
| Customer represemtative 1 | Advisor | Customer |
| Customer represemtative 2 | Advisor | Customer |
2.3.Project Steps and Financial Objectives
The project is divided into several key phases, each with specific goals and deliverables:
-
GATE 0 Project Initiation: Establishing the team and participating in the Future Factory Orientation Days 2025.
-
GATE 1 Planning and Offer: Preparing and presenting the project plan and Offer.
-
GATE 2 Implementation and Testing: Developing and testing the project deliverables.
-
GATE 3 Demonstration: Showcasing project results and gathering feedback.
-
GATE 4 Final Delivery: Completing the project and presenting it at the FF(IT) 2025 End Seminar.
2.4.Quality verification
To maintain quality throughout the project, regular assessments and adherence to predefined standards are implemented. The "Definition of Done" (DoD) establishes a shared understanding among team members regarding when a product increment is considered complete and ready for release.
Periodic review sessions are held to ensure project objectives are being met, while retrospective meetings at the end of each iteration provide an opportunity for continuous process improvement. Risk management measures and change management protocols are documented and reassessed regularly to maintain quality and mitigate potential issues.
2.5.Communication and tracking of project progress
Getting Started
At the beginning of the project, all team members will be onboarded with access to relevant documentation, communication channels, and project management tools.
Workspaces and Communication: - A designated online workspace (Gitlab) will be used for documentation and task tracking. - Regular team meetings and check-ins will be held to discuss progress, resolve issues, and align priorities. - Instant messaging and email communication will be utilized for quick updates and collaboration.
Reporting and Information Flow: - Status reports will be generated periodically, highlighting completed tasks, upcoming milestones, and potential risks. - Transparent information flow between stakeholders will be maintained through shared progress dashboards and regular updates.
2.6.The end of the project
Delivery:
- The final version of the PrestaShop system will be delivered to the customer
Documentation:
- A structured filing system will ensure that key documents remain accessible for future reference.
Final Report and Decision:
-
A final report will be prepared, summarizing the project outcomes, challenges, and key learnings.
-
The project’s official decision-making body will review and formally close the project.
3. Project's temporal Gates
3.1 Partitioning and Phase
| Sprint | Tasks | Gate | Time estimation |
|---|---|---|---|
| Sprint 00 | Familiarize with the assignment, begin exploring the target area, prepare a project plan. | Gate 0 | 1 week |
| Sprint 01 | Communicate with stakeholders and prepare the project initiation plan. | Gate 1 | 2 weeks |
| Sprint 02 | Finalize project planning and confirm all requirements. | Gate 1 | 2 weeks |
| Sprint 03 | Define the system architecture and start the initial implementation. | Gate 2 | 2 weeks |
| Sprint 04 | Implement key features based on the defined requirements. | Gate 2 | 2 weeks |
| Sprint 05 | - | Gate 3 | 2 weeks |
| Sprint 06 | Finalize development, conduct security testing, and prepare for delivery. | Gate 4 | 2 weeks |
| Sprint 07 | Deliver the final product, conduct user testing, and complete project reporting. | - | 2 weeks |
Phase Objectives
Definition Phase GATE0
- Sprint00-GATE0
- Objectives: Familiarize with the assignment, begin exploring the target area, prepare a project plan.
- Results: The group's website is up (updating needed), team is formed, meetings has been held for the project
Planning Phase GATE1
- Sprint01
- Sprint02
- Sprint03-GATE1
- Objectives: Project offer and confirming requirements with all stakeholders.
- Results: Approved project plan, signed contract and communication strategy in place.
Implementation Phase GATE2
3.2 Project preliminary cost estimate
Presenting a cost estimate with a table:
4. Quality assurance
This section outlines the methods, tools, and standards to be used in the project. Often, the commissioner will provide a set of methodologies for the project team to follow. If the client has specific requirements, these must be adhered to. However, if no particular methodology is provided, the project team will adapt a model, such as one approved by the IT Institute or another relevant template, and have it validated by the client.
-
Working methods: How tasks and processes will be carried out throughout the project.
-
Tools and instruments: The software, platforms, and devices to be used, along with their version control.
-
Instructions: Clear guidelines for the team on how to use the chosen methods and tools.
-
Standards: The technical, quality, and compliance standards that must be met.
-
Version management: Clear protocols for tracking and managing document versions
-
Roles and responsibilities: Designating individuals who will be responsible for key aspects of project management, tools, and software.
4.1 Approval of intermediate and results
Approval Process
Milestone Reviews:
-
During the project timeline, intermediate deliverables (e.g., design mockups, core functionality prototypes, or integration progress) will be presented to stakeholders for review.
-
A meeting will be scheduled to discuss the deliverables, assess their alignment with project requirements, and address any concerns or feedback.
Documentation of Feedback:
-
All feedback and requested changes will be documented in a shared repository or project management tool, ensuring clear communication and traceability.
-
The development team will address the feedback and make necessary adjustments within the agreed-upon timeframe.
Final Deliverable Review:
-
Upon completion of the project, the final deliverable (e.g., the fully functional PrestaShop-based eCommerce platform) will undergo a comprehensive review
-
This review will include testing for functionality, performance, and compliance with initial requirements.
4.2 Manage changes
The formal change management procedure is to handle any modifications to project practices, scope, requirements, or deliverables. The process ensures that changes are evaluated, approved, and implemented in a controlled manner, minimizing risks and maintaining alignment with project objectives.
4.3 Documentation
The process for creating, storing, sharing, and maintaining project documentation. Project team uses GitLab and the Open Project Framework (OPF), the team ensures that all documents are organized, accessible, and up-to-date throughout the project lifecycle. Responsibilities for documentation are clearly defined to maintain accountability.
4.4 Risk management
Listing the risks, evaluate their severity and probability and to think about thinking about how the most serious / most likely risks could be prevented in advance.It would also be good to be a plan for how to work if the risk is implemented. Books the risks to the project below and maintain them as needed.For each risk, a unique identifier is given, for example, RIS007, as this will facilitate their treatment in different situations.
4.5 Reviewing Policy
Lishes and provisionally scheduled on the project's performance review on the basis of the drawn up implementation plan.The list of reviews is presented, the preliminary time, the issues, participants and practices for the delivery of the reviewing material (what, when, how).
4.6 Complementary plans for the project plan
This paragraph mentions what complementary plans are available or will be made within the project (e.g., a communication, risk management, testing and deployment plan).
- Project Agreement
- Requirement Specification
- Release Plan
- Master Test Plan
- Communication Plan
- Risk management plan
- Other Documentation
4.7 Plans for review and updating
The project plan will be reacted to deviations and environmental changes, so it is updated during the project.To this point, the dates are recorded in which the date of updating the plan at least must be checked.
4.8 Project Suspension Criteria
The Right Project Plan also includes the project's suspension criteria.However, these are not used in student projects because projects use a certain number of hours to make a result and the result will be released as it is at the end of the course.However, the project team makes a further development plan that a potential new project continues.
5. Communication and tracking of project progression (communication plan)
5.1 Communication Plan
The purpose of the communication plan is to define the communication methods and channels used in the X project. With clear and consistent communication, it is ensured> the passage of information and influence the implementation of the project quality objectives. The plan can be drawn up as part of the project plan or can be referred to as one of the [subpages] (../10 project management / communication plan.md) List the workspaces and communication tools agreed on the project, a return policy and communication, reporting, and information.
6. The end of the project
6.1 Delivery of the end product, introduction
The final product of the project should also be documented at a sensible level. As part of the final product may be the introduction to the customer and possibly installation or commissioning service. If the role of education for the project is considerable (for example, software users have not been involved in the project and do not know how the system works) will include a plan to attach a plan to the customer's training. In addition, if necessary, the project plan also includes an installation plan and a deployment plan.
6.2 Taxation of the project produced by the project, archiving and retention period
"The disadvantaged part of the document group documentation is stored in the X system" With the assistant, you may be able to agree on which documents can be left to the next projects. Typically, different plans and final report are in the most appropriate part of such documents.
6.3 Official termination of the project
It is important to define when or how to end the project.The project's decision may be a certain date, a particular product ready-made, a certain amount of work hours, a certain consumed sum of money when the customer takes the product, the warranty period has expired or when the customer accepts the product.
"The project ends in p.k.vvvv, when the project contract expires."
6.4 Termination
Generally, the projects will be decided on a joint closure seminar.Participants and time are recorded.
- In Finland project team can arrange Sauna-event :)
6.5 Project Final Report
The final report of the project will be drawn up by the last management team meeting.