PROJECT PLAN
REBIS Project
Retail Business Information System Luomu elämä Oy
HAAGA-HELIA Sputnik
Version 1.1 Proposal
Table of Content
1 Project Definition 3
1.1 Background 3
1.2 Project Scope and Objectives 4
1.2.1 Project Scope 4
1.2.2 Project Objectives 4
1.3 Deliverables 5
1.4 Approach 6
1.5 Organization. Roles and Responsibilities 7
1.5.1 Organization chart 7
1.5.2 Roles and responsibilities 8
1.6 Risk Analysis 9
2 Work Plan 11
2.1 Phases 11
2.2 Tasks, workloads and deliverables 11
2.3 Timing 12
2.4 Working Methods and Standards 12
2.5 Project Management 12
3 Quality Plan 14
3.1 Quality Goals 14
3.2 Quality Procedures and Responsibilities 14
4 Sources and References 17
APPENDIX 1 Definition and analysis of project risks 18
1 Project Definition
1.1 Background
Luomu elämä Oy is a small grocery retail shop which lately witnessed a
remarkable explosion in sales. Covering a niche market of organic food, the shop seems to attract more and more customers from within an area of 40 km. Due to a continuously growing customer base; the company needs to deal with larger purchasing orders and more reliable product inventory. All these business circumstances called forth the need of bringing into daily use a new business information system.
Moreover, the increased consciousness’s of people to buy organic food and the awareness of health threats when buying processed food are strong economic drivers that hard-pressed Luomu Elämä Oy shop’s owner send a project request for the implementation of a new business information system.
The organization’s clear argumentation for the pressure and need of a quick and inexpensive IT solution for improving daily business operations raised the contractor’s interest and a 5 member team was assigned to deal with this customer case.
The project request contained limited information on the four main business operations: purchasing, warehousing, sales and financial administration. The critical functionalities related to daily inventory management and sales require priority to ensure the continuity of the business, its effectiveness and profitability. The major objective is to have a system in place that is able to run according to the predefined business processes which the customer will define with the project team. The
customer proposed a 4 months IT project to have a new business
information system implemented. Should there be an excess of resources the team will also provide integration with an online ordering system aimed at the web customers.
1.2 Project Scope and Objectives
1.2.1 Project Scope
The project’s main goal is to implement an ERP solution for the retailer “Luomu Elämä”. The core application must fulfill all requirements related to the following business functions:
1. Purchase process functionalities(i.e. order management) 2. Sales process functionalities (i.e. item management, sales
transactions)
3. Warehousing (i.e. inventory management)
4. Financial administration(i.e. records of purchasing and sales transactions)
1.2.2 Project Objectives
Within the overall goal as defined above the following objectives have been identified.
IT and business objectives:
1. To improve overall business performance for the customer Luomu Elamä Oy.;
3. To distinguish among clear business roles and follow-up with the responsibilities related to the respective roles;
4. To support better the decision making process for sales and purchase business functions;
5. To lower operating costs;
Beyond the main goal of this IT project, the learning process strictly linked to it aims at involving all team members in the following learning objectives:
Learning objectives:
1. Clear understanding of the development process of an information systems; 2. Positive experience of implementing a successful system project;
3. Applying earlier learned skills in understanding all aspects related to IT project management and responsibilities;
4. Creating and maintaining a positive, productive and constructive group work spirit in project team.
1.3 Deliverables
The major deliverables for the ERP solution implementation project are: 1. Project management documentation:
Documentation related to the project management (notice of meeting, minutes of meetings, status reports);
Updates and communication on the Sputnik blog;
2. System Implementation
Business system requirements analysis (core functionalities to match the business processes);
System selection report (including solution comparison table and reasoning);
QA report (test plan, issue management, test results);
Presentation of the live solution on the laptop provided by the school;
1.4 Approach
The project manager together with 2 business consultants and 2 technical specialists take charge of the Luomu Elämä Oy IT-business case and will agree on carrying out thorough business analysis where all business needs and processes have to be clearly documented and mapped in order to find the appropriate business information system solution. The working method will be paced according to the waterfall model.
The technical team will test several open source information systems that match the business needs and technical requirements and offer the best system, taking into account the required features and the possible budget limitations.
When implemented, the new system will come along with clear user instruction and special IT training, depending on the use case, for all employees.
The system will be delivered by the end of May 2015, as agreed with the customer. In case of haphazard situations which may hinder the project deliverables, an extension of one month might be negotiated with the customer.
1.5 Organization. Roles and Responsibilities.
1.5.1 Organization chart.
Figure 1. Organization chart - Sputnik Team
Project Sponsor/ Customer Luomu Elämä Oy owner Steering Group Pekka Kamaja Juha Hinkula Tuomo Ryynänen Project team members
Project manager Juho Uusitalo Technical team Aleksandr Mikheev Sergei Lapitski Business Team Riina Tõugu Doris Hollo
1.5.2 Roles and responsibilities: Steering Group Members:
Establish overall course of action for the project; Review and approve project proposal and plans; Provide guidance and decision support;
Conduct close communication with the project manager on project based issues;
Project Manager: Juho Uusitalo
Provide project management aligned with the time and objectives planning; Develop and maintain the Project plan: Gantt chart.
Communication with steering group and within the team;
Plan and delegate project tasks according to project needs, provide coordination of resources;
Monitor project tasks and prepare status reports (including time management)
Making sure all documents are archived during the project (e.g. minutes of meetings);
Provide administrative support in compiling the deliverables; Participate in acceptance testing;
Blog updates;
Project team member: Doris Hollo
Act as Product Owner and have the final say in team disputes about solution acceptance;
Participate in business process mapping and business requirements analysis and use cases;
Participate in acceptance testing; Blog updates;
Project team member: Riina Tõugu
Act as QA gatekeeper and see that that report is finalized;
Participate in business process mapping and business requirements analysis and use cases;
Participate in acceptance testing; Blog updates;
Project team member: Aleksandr Mikheev and Sergei Lapitski
System selection report;
Build the solution according to given requirements; Blog updates;
1.6 Risk Analysis
Figure 2. Risk analysis based on the description. See appendix.1 0 10 20 30 40 50 60 70 80 90 100
Machine break down
Inappropriate architecture Information loss regarding
deliverable reports Poor team expertise
Unrealistic schedule
Wrongly defined tasks or missing activities Services are not performed as described by the software
documentation. Business… System errors
Business requirements misunderstood Poor use case description
and evaluation Performance and quality
tests failure Constant alteration of
requirements Team member off-time (recurrent risk at each stage
of the project) Database design errors
Risk analysis radar chart - Sputnik project
2 Work Plan
2.1 Phases
The project consists of business management and system development tasks. The project and its development are observed by the steering group. Tasks of the project are shown in Appendix 3, Tasks and timing which also defines what prerequisites are required for different phases.
2.2 Tasks, workloads and deliverables
Different phases and tasks are preordained by number of days to complete them and show the predecessor task that must be completed before
continuing. Tasks and phases also have a completion percentage that is representing the amount of work done, which makes it straightforward to monitor progress of the project. After completion, the project manager will edit the allocated hours to the work chart. Project members need to keep track of their working hours daily. The length of the project is
approximately 106 days, which spread to 13 phases.
The project team contains five persons, which have been located to two different teams; business team and specialist team. Business team is in charge of documenting the project, business requirements and administering the project. The specialist team focuses on testing and choosing a suitable information system. The specialist team is also responsible in installing the system and expanding the functionality of the system.
Workload of the project is allocated to the teams and they work as a unit to complete different tasks and phases. The tasks and the scheduling of the phases are shown in Appendix 3, Tasks and timing.
2.3 Timing
Work for the project has been started 20.1.2015 and the estimate date for completing the project is 4.5.2015. Pedantic scheduling of the project is found in Appendix 3, Tasks and timing.
2.4 Working Methods and Standards
The project is carried out in two phases following the steps of the Waterfall model. One phase for the ERP and the other for web ordering system if applicable.
Requirements
Design
Implementation Verification
Maintenance (presentation/training to clients)
2.5 Project Management
Managerial procedures
• Project follows the project plan and is executed accordingly Project definition, implementation and status survey
• Gantt chart and status follow on subtasks using Asana system Project reporting
• Project is reported using project guidelines and the workload is recorded by team members
• Project follows the schedule as close as possible and delays are monitored Reviews
• Reviewing quality will be done by the business team • Results are approved by the steering group
• Changes in project have to be approved by steering group Meetings
• Steering group meetings will be conducted when there is a suitable time • Business team meets weekly with the timing decided beforehand
• Specialist team meets weekly with the timing decided beforehand
• Project team meets whenever it is necessarily and if the stage of the project demands it
Informing
• Informing will be done by the steering group and the project manager will be the source of information
• Fleep and Skype will be used for primary source to deliver information within the project team
3 Quality Plan
3.1 Quality Goals
The quality goals are two-fold, namely regarding the final solution and secondly also regarding the path i.e. the road to the solution.
The solution quality will have to conform to the needs specified in the requirements.
The quality of work and environment means procedures regarding team communication, documentation and work environment.
3.2 Quality Procedures and Responsibilities For quality of work:
Communication – The main means of communication to be used for this project are: team meetings and instant messaging in application Fleep. Project manager is responsible for the communication and has to make sure that the information flow is satisfactory for all stakeholders.
Documentation – the Business team is responsible for taking care of the documentation of the project. All documentation is kept in Google drive shared folder. This takes care of version control for documentation and makes sure that the availability of the latest state of the project is available to all at all time.
Project time and task management – Time and task management on is handled via a spreadsheet kept in Google drive. The Project manager is responsible for keeping that up to date.
For solution quality:
Testing – Testing is the responsibility of all team members. The tech team is responsible to test their configurations for basic functionality. The business team will need to test for compatibility with requirements, usability and also corner cases that do not follow the basic user flow. The test plan for checking compatibility with the requirements will be made once the business processes are mapped out. The Business Analyst is responsible for making sure it is done. Corner cases and usability testing will not follow a written plan but will depend on the creativity of the business team members.
Bugs or insufficiencies that are discovered by all kinds of testing will be communicated in writing to the tech team. The team will use Asana, Jira or some other tool for this kind of task management if it is deemed necessary. If the issue cannot be solved the tech team will need to comment the situation in writing and the Product Owner will decide how to proceed.
At the end of the project the test plan for business process testing and a printout from issue management from a chosen tool is added to the project report.
Development environment – The tech team is responsible for finding the best method for version control and backup. The preferred solution would involve using git. If the solution configuration can be stored as an xml file then that is kept up to date in version control. If the configuration settings are saved in database the tech team will find a way to store the info. The requirement is that the configuration needs to have a roll-back possibility.
Documents that will be made during the course of the project: Project documentation
project plan
blog – report status functionality
final project report incl. testing plan and issue management reporting
notices and minutes of meetings of project steering meetings
All documentation is written in English. For markup different standards are used when applicable (e.g. BPMN, UML).
4 Sources and References
APPENDIX 1 Definition and analysis of project risks
Phase Activities Resources involved Risks Reasons Probability Impact Mitigation
Initiation
Project planning development
Human
resources Poor team expertise
Lack of knowledge in
the ERP field 25% Medium
Members of the team should
admit their weaknesses and
seek for peer support and teachers’ guidance for relevant resources. Adapt processes to the available know-how. Project planning Human resources, time Team member off-time (recurrent risk at each stage of the project) Sickness, other personal problems 40% Low Other team members can take
over the missing member’s tasks.
Team responsibility
awareness. Balanced tasks for
each team-member. Project planning Human resources, time Unrealistic schedule Wrong evaluation of resources, inability to understand tasks complexity and their time requirements 25% Medium Clear understanding of the business case, team members’
discussion regarding tasks
distribution during the project
planning, incremental development, implementation of core functionality first, modifications of schedule. Project
planning resources All
Wrongly defined tasks or missing activities Inability to comprehend the whole IT development project, lack of experience and expertise, lack of communication 25% Medium Regular team meetings and peer-review. Adaptability in case of missing expertise. Further personal development to acquire the
communication with the steering
meeting. Planning of the IT project System requirements analysis HR and IT software (MS Office Suite) Business requirements misundersto od Communication problems with customer and future IT solution users, human error 30% High
Peer review and business process mapping double-check by two different persons; Test and questionnaires regarding common understating of business functionalities and cross-reference. System requirements HR Poor use case description and evaluation Communication problems, lack of know-how, lack of interest 30% Medium Brainstorming and argumentation of
the chosen use cases. Peer-review. System requirements analysis HR Database design errors Erroneous data dictionary or ER diagram 50% High Extra documentation and review of similar cases. Call in database expert to provide the necessary know-how. Seeking support from the
teacher. System requirements analysis All resources Constant alteration of requirements Change of functionality priority. Poor understanding of the business processes. Owner’s change of mind 35% High Change management process in place. Change control board consulting meetings. System requirements analysis Hardware, Software, HR Performance and quality tests failure
Tests are not designed in accordance with the testable functionality. Poor testing. 30% Medium Modelling, benchmarking, prototyping, reviews. Correct business scenarios. Execution of the IT project Installation of the new systems Hardware Machine break down System malfunctions, software unknown incompatibilities 10% Medium Version control and back-up procedures in place
, hardware device crash Testing of suitable solutions Software Inappropriat e architecture Wrong business scenarios and poor business requirements analysis 10% High Simulation and good benchmarking. Solution reviews and functionalities check Faulty services Software Services are not performed as described by the software documentati on. Business process performance failure Possible bugs in the chose framework 25% High Establish contact with the software development team and report bugs for possible
bug fixes and patches. System running Software, HR – technical team System errors Framework problems during configuration or testing 25% High Thorough documentation and review collection before choosing the framework. Delivery/ Close-out Deliverables HR Information loss regarding deliverable reports Poor back-up, software errors and server down-times 10% Low All members of the team should hold a local copy of all documents related to the
Figure 3. Risk probabilities Impact- Project Sputnik
0 20 40 60 80 100 120
Machine break down Inappropriate architecture Information loss regarding deliverable…
Poor team expertise Unrealistic schedule Wrongly defined tasks or missing activities Services are not performed as described by…
System errors Business requirements misunderstood Poor use case description and evaluation Performance and quality tests failure
Constant alteration of requirements Team member off-time (recurrent risk at…
Database design errors
APPENDIX 2 Tasks and timing
