Project plan
| Document | Project Plan |
| Author: | Timi Lång |
| Version: | 1.0 |
| Date: | 22.02.2024 |
1. Assignment
1.1 background and starting points
We are working for on a project on the behalf of Jyväskylä University of Applied Sciences or JAMK. The goal of the project is to improve and modify the existing Tukko traffic visualizer, that works using multiple different technologies. We are working as individual project teams, with our team being InnovateForge Solutions. We consist of 6 JAMK students, all with individual skills and tasks. We are working for the customer Combitech, along with the product owner Reima Parviainen, scrum master Marko Rintamäki and Mentors representing JAMK.
1.2 Goals and tasks
Project is being implemented by a group of people working on the part of InnovateForge, and overseen by scrum master Marko Rintamäki. The customers representive is Reima Parviainen. The goal of the project is to implement new functions to the existing Tukko service. The project has been divided into a set of sprints and gates that all serve a different purpose on the big picture of the project.
1.3 Limitations and interfaces
As we are developing a existing product that we didnt make, we have to be careful modifying the original software. This means we are not the owners of the product and have to work according to the guidelines given by Combitech representives and product owner.
1.4 Rights and IPR
The rights of the various parties are defined in the project agreement.
1.5 terms and definitions
This section presents the definitions, terms and abbreviations in the project plan. For example, in different projects, there may be "inspection" and "reviewing" to be different meaning and this can cause misunderstandings. Sometimes it may be in place to agree on different names to the group's inspections (own internal, customer, in the course of the course). Abbreviations should be opened to the original language and add a brief description in Finnish.For example, Case = Computer Aided Software Engineering, Computer Assisted System Work.
1.6 Challenges related to the project (SWOT Analysis)
We have made a SWOT analysis to provide an understanding of the teams strengths, weaknesses, opportunities and threats.
Strengths:
Open communication: The team has an open communication, where everyone can say what they think without feeling ashamed of scared of other peoples opinions.
Competent team: We have a group of people that all have a wide knowledge about technologies used in the project, this means no single student has to do everything alone, but can ask fellow students.
Professional support-group: We have a group of professionals mentoring and supporting us. This means if we have a problem we can always ask them for directions and help.
Weaknesses:
Deadlines: Deadlines can be overseen if team members are not following the project everyday. We have to make sure every member knows the deadlines and works around them.
Limited knowledge: Meanwhile we do have a competent team for the experience, there can always be a subject someone knows nothing about, this means that a single student has to spend time learning something new that can compromise the deadline
Personal wellbeing: Working with tight deadlines and schedules can lead to worse personal wellbeing, students need to be able to take time off from the project and take some time for themselves.
Opportunities:
Promote yourself: Working with a real customer means you have a chance to show your professions and really make yourself seen in the industry.
Chance to improve an existing product: As we have an existing product, we have the easier part of developing the product, which means more limitations as a creator, but less limitations caused by the making up of new features.
Ability to learn new things: With a project this size, you have an ability to learn new techonologies about computer sciense and about project management.
Threats:
Time constraints: A single student may have other studies, personal goings or other events where he/she may not have time to work enough on the project. In this case we need to communicate within the team and find someone to help with the work.
Changing deadlines: If we do not look after the deadlines or the deadlines come sooner, we have to be ready to add more working hours to each team member.
2. Project organization
2.1 Organization
Project includes the team of InnovateForge solutions, scrum master Marko Rintamäki and the representative of the customer Reima Parviainen.
The innovate forge solution team members:
| Team member | Task |
|---|---|
| Timi Lång | Team Leader |
| Joonas Pölkki | Developement engineer |
| Kalle Lahtinen | Security engineer |
| Jukka Välikangas | Operations engineer |
| Eetu Savolainen | Test engineer |
| Otso Lehtiniemi | Generalist |
Structure of Project Organization in MindMap form
2.2 Responsibilities and decision-making process
The project team performs the tasks set for the project by the management team within the available resources. The management team consists of representatives of the project team, supervisors and the client selected for it. If necessary, other persons, e.g. experts, can be invited to the meetings of the management team. The composition of the management team is presented in the annex to the project agreement.
Project Group
| Name | Responsibility | Company/Community |
|---|---|---|
| Timi Lång | Team Leader | InnovateForge Solutions |
| Joonas Pölkki | Developement engineer | InnovateForge Solutions |
| Kalle Lahtinen | Security engineer | InnovateForge Solutions |
| Jukka Välikangas | Operations engineer | InnovateForge Solutions |
| Eetu Savolainen | Test engineer | InnovateForge Solutions |
| Otso Lehtiniemi | Generalist | InnovateForge Solutions |
Board Members
| Name | Responsibility | Company/Community |
|---|---|---|
| Sini Karvonen | Scrum Master | Combitech Oy |
| Jarmo Luostarinen | Scrum Master | Combitech Oy |
| Reima Parviainen | Product Owner | Combitech Oy |
| Marko Rintamäki | Scrum Master | Jamk |
Support Group
Mentors and peer coaches from JAMK
2.3.Project Steps and Financial Objectives
Team members will follow a plan nad a schedule to ensure every task are completed in time. With additional costs being recorded. The preliminary budget can be found from documentation.
2.4.Quality verification
In order to maintain consistently high quality across all project components, we will establish a comprehensive quality standard.
This standard will encompass the following operational protocols, which are central to the project team's focus:
- Select appropriate tools for project control, documentation, and issue tracking to ensure efficient project management.
- Clearly outline operational protocols that align with the project's primary objectives.
- Maintain thorough documentation throughout the project lifecycle, highlighting key activities, plans, and any alterations made along the way.
- Adhere to client and industry standards, integrating them seamlessly into the development process.
- Collaborate with available tribes and mentors to optimize operations and promote a smooth workflow.
2.5.Communication and tracking of project progress
We will be using Discord as our main communication channel within the team. Documentation and tracking of the project progress will be stored in Gitlab.
2.6.The end of the project
The project will end with the delivery of the final product and appropriate documentation. The team will finish writing the final report.
3. Project's temporal Gates
3.1 Partitioning and Phase
The progress of the project can be described as a ns.With a Gantt chart.It can be used to show the progress of different phases with a timeline, while showing the critical points associated with different tasks.
GANT using PlantUML
-
GATE0 Get to know the team and project environment.
-
GATE1 Making the offer for the customer
-
GATE2 Status check
-
GATE3 Demo day
-
GATE4 Release
The next step is each step, the time resources and results they require in briefly.The steps and their tasks are described in more detail in the phase plans.The ongoing phase of the current stage should be known precisely who is doing and how much work to perform this step.Later phases work estimates can be made at an early stage at a rough level, which is then refined to a detailed level of the project.This happens at the end of each phase to be designed in more detail the next step.
Note: The following are the startup and ending steps. Of all the phases of the project, their duration and workloads, the so-called Gantt chart (attached), which also shows the interdependencies between the steps and the main easses (e.g., the management team meeting date of the management team).
The start of the project is essentially involving project planning and design documentation and creating communication practices with the contracting company.During the phase is made For example, the Group's web pages, will be more familiar with the assignment, starting to acquire the target area, and a project plan will be drawn up in cooperation with the commissioner's representatives.During the phase Establish a management team, held the 1st Executive Team meeting and signed a project agreement. "The phase results are the creation of a group image (name, logo et al.), Web pages, etc. and project agreement with attachments."
Offer and other documents regarding it are ready to be presented to the client
First features are implemented, and testing will be started.
More features are being implemented, a developed software solution will be ready for the test audience.
Last features are being implemented. Final testing and bug fixing will also be performed. Final review of the product with team, product owner and client. Finish final report and keep last team meeting.
3.2 Project preliminary cost estimate
Presenting a cost estimate with a table:
4. Quality assurance
Ensuring product quality within InnovateForge Solutions is paramount to our success and customer satisfaction. We employ a multi-faceted approach to guarantee that our products meet and exceed the highest standards. Here's how we assure product quality within our team:
Clear Quality Standards: We establish clear quality standards from the outset of a project. These standards encompass various aspects such as functionality, performance, usability, security, and scalability.
Continuous Testing: We embrace a culture of continuous testing throughout the development process. This includes unit testing, integration testing, regression testing, and user acceptance testing (UAT). Automated testing tools are leveraged to streamline this process and catch issues early on.
Code Reviews: All code undergoes thorough review by team members. This approach ensures that the code meets coding standards, is maintainable, and is free from logical errors.
Prototyping and Mockups: Before proceeding with full-scale development, we create prototypes and mockups to validate design concepts and gather feedback from stakeholders. This iterative process helps identify and address potential usability issues early in the development lifecycle.
4.1 Approval of intermediate and results
We have a chain of approval as follows:
1. Developers: The developer implements a feature and ensures it is ready for testing.
2. Test team: The tester assures it has no major bugs and everything is functional.
3. Team leader: Team leader checks the full feature and ensures it is ready for the product owner to be looked at.
4. Product owner: Product owner makes the final check to the features, ensuring they meet expectations.
4.2 Manage changes
Identification: Document the proposed change.
Impact Assessment: Analyze its implications on schedule, budget, resources, quality, and risk.
Evaluation: Determine feasibility and alignment with project objectives.
Approval: Present to decision-making authority for approval.
Implementation Planning: Develop a detailed plan with tasks, timelines, and resources.
Communication: Inform stakeholders and address concerns.
Execution: Implement the change as per the plan.
Verification: Confirm the intended outcomes are achieved.
Documentation: Maintain records of the change process.
Review: Assess success and identify improvement opportunities.
4.3 Documentation
All documents regarding the project will be saved to gitlab, every member is in charge of their own documentation, but the team leader is responsible for any document that will be presented to stakeholders or scrum masters. Team leader should be informed of any missing information or special documentation.
4.4 Risk management
We have made some early risk evaluation, this list shall be updated as needed, the whole document is linked under.
| RISK ID | Description | Severity | Responsibility | Measures in the event of risk |
|---|---|---|---|---|
| RISK01 | Team member is sick | S4 | Team member in question | Inform team members and other relevant parties |
| RISK02 | Team member leaves the project | S2 | Team leader | Call for a team meeting and asses the situation and redistribute responsibilities |
| RISK03 | Incomplete or inadequate documentation | S4 | Team members | Recall proper documentation standards and conduct knowledge transfer sessions |
| RISK04 | Ineffective communication within the team | S4 | Team leader | Promote more frequent team engagement and communication |
| RISK05 | Incompatibility issues between different software versions | S3 | Developer/Tester | Test compatibility thoroughly, keep track of software versions |
| RISK06 | Security vulnerability | S2 | Security | Conduct security audits and follow recommended practices |
| RISK07 | Unforeseen technical challenges | S3 | Team members | Report the issue to team members or other relevant parties |
| RISK08 | Equipment failure | S3 | Team member in question | Inform team members and formulate a contingency plan to ensure the continuation of the project work |
| RISK09 | Insufficient testing and quality assurance | S2 | Tester | Review the testing process and enhance it by conducting comprehensive testing at every stage |
4.5 Reviewing Policy
Project Performance Review Policy 1. List of Reviews:
- Weekly team meeting
- Sprint review
- Monthly milestone review
- Retrospective
- Preliminary Time:
- Weekly team meeting: Every monday and friday at 9am.
- Sprint review: At the ending of every sprint.
- Monthly milestone review: At the end of the month, possibly alongside team meeting
- Retrospective: Friday after working hours
- Issues:
- Weekly team meeting: Status updates, issues faced.
- Sprint review: Unresolved issues, budget status.
- Monthly milestone review: deadlines, overall project performance.
- Retrospective: Any issues regarding project.
- Participants:
- Team leader
- Team members
- Stakeholder (if necessary)
- Scrum master (if necessary)
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
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.
The team leader will perform regural checks on all documents, project progress and objectives. More major reviews will be performed on a monthly basis. With the first date being 29.02.2024.
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 Tukko 1.1 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 found from here Communication plan
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
Any documents regarding the project will be kept in gitlab for an x amount of time after the project. Any documents needed for evaluation and final report will be archived as long as the team sees it fit.
6.3 Official termination of the project
The project is marked to end in 26.04.2024, if all requirements are met and the customer is happy with the product. With a last team meeting, and review of the project as a whole.
6.4 Termination
The project will be terminated on a joint closure seminar, with participants and times being recorded for documentation and evaluation purposes.
6.5 Project Final Report
The final report of the project will be drawn up by the last management team meeting.