Project Charter and Management Plan Project Client: Organisation:Globex corp (virtual precision agriculture) Contact:1.program manager:cocovandeweghe ([email protected]) 2.IT Manager: paul smyth ([email protected]) System Name: Network design for Globex corp Date of Charter: 25/10/2016 Document Status: Approved Document Reference: Itc306 project final documentation Version Number: Version 1.0 Prepared by: Virtucon Pty .Ltd Team Members: Ravinder pal singh, Yashik, Rajan kapoor, Gurdeep singh, Harpal singh NOTE THAT THIS CHARTER AND THIS HIGH-LEVEL PROJECT MANAGEMENT PLAN MAY BE MODIFIED AS NECESSARY WHEN DETAILED REQUIREMENTS ARE ESTABLISHED. AFTER ORIGINAL APPROVAL, CLIENT AUTHORISATION IS NEEDED FOR ALL CHANGES. 1. Change History All changes to the Project Charter must be recorded in the Change History, and a new version of the charter must be approved by the client. Date Description of Change Reason for Change Author of Change Version No. dd/mm/06 Initial draft N/A Version 1 Version 2 Version 3 2. Authorised by: <> Name: ________________________ Signature: ________________________ Date: ________________________ Table of Contents 1. CHANGE HISTORY 2 2. AUTHORISED BY: 2 3. PART 1. PROJECT CHARTER 4 3.1. PURPOSE OF THE CHARTER 4 3.2. PURPOSE OF THE PROJECT 4 3.3. BUSINESS OBJECTIVES OF THE PROJECT 4 3.4. SCOPE OF THE PROJECT 4 3.5. BUDGET AND TIMEFRAME 5 3.6. PROJECT MILESTONES AND DELIVERABLES 5 3.7. PROJECT RESOURCES 6 3.8. CLIENT RESOURCES 6 3.9. PROJECT TEAM RESOURCES 6 3.10. TECHNICAL ENVIRONMENT 7 4. PART 2. PROJECT MANAGEMENT PLAN (AN BRIEF VERSION) 8 4.1. RISK MANAGEMENT 8 4.1.1 Assumptions 8 4.1.2 Dependencies 8 4.2. CONSTRAINTS 8 4.3. RISK ASSESSMENT 9 4.3.1 Risk Rating 9 4.3.2 Risk Mitigation 9 4.4. SCHEDULE AND BUDGET 10 4.4.1 Schedule ( Microsoft Project software compulsory) 10 4.4.2 Budget 10 4.5. MONITORING & CONTROLLING MECHANISMS 10 5. REFERENCES 10 3. PART 1 - Project Charter 3.1. Purpose of the Charter Virtucon pty. Lmt. Prepare all the documents 3.2. Purpose of the Project 3.3. Business Objectives of the Project To be considered successful, the proposed project must achieve the following goals for the client: BUSINESS GOAL EVIDENCE OF GOAL ACHIEVED 1. 2. 3. 4. 5. 3.4. Scope of the Project The project team will provide the client with the following items: In Scope Includes System Functions <> System Documentation Charter, Requirements Specification, Design Specification, Test documentation. Maintenance Manual All final documentation on CD-ROM (save trees!) Training User Training sessions and a Training Manual – although it is more important that the system has a remarkably high level of useability so training documentation should be minimal. Device configuration The configuration files of all network devices and configuration parameters of the different applications provided on CD, and technical documentation for the person who will maintain the system. The project will not provide: Out of Scope Includes System support and enhancements On-going problem resolution and maintenance after the students have demonstrated the system at the end of the project in November 2006. Clients of ITC306 projects will need to consider the means by which they will obtain on-going technical support. 3.5. Budget and Timeframe There is no budget for this project. This project constitutes the assessment for the academic subject, ITC306 Project Preparation & Professional Practice, and each student is expected to apply themselves to the project for approximately 10 hours per week. There is no charge to any client for this work. The timeframe for the project is determined by the academic year. At this early stage, the relevant milestones and deliverables are seen to be as per the table below. These milestones and deliverables may be modified during the life of the project with agreement from the client. 3.6. Project Milestones and Deliverables Project Milestone Deliverable Expected Date Project Startup Charter and Management Plan <> Solution Requirements Specification of Requirements (use cases or similar) Test Strategy Updated Project Plan Solution Design Fully worked out architecture and detail of design Test Plan in detail Prototype Basic component of solution Iteration Additional functionality Test Cases Iteration Test results Iteration Test results Final Release Solution plus all documentation, on CD Project Completion Individual evaluation reports 3.7. Project Resources 3.8. Client Resources Role Name Availability 1. Client Manager <> 1 hour per month for progress reporting. 2. User Representative <> Approx 1 hours per week to help refine requirements, develop test plans and provide acceptance testing. Availability for phone calls.24 hour response to emails, if possible. 3.9. Project Team Resources Role Name/s Timeframe/s 1. Project Manager <> 2. Requirements Engineer 3. Designer 4. Network Engineer 5. Test Engineer 6. Technical Writer 7. Hardware/Network Consultant 8. Trainer 3.10. Technical Environment Students are required to work with technology that must be able to integrate with the client’s existing technical infrastructure. It is important that any unconventional requirements be discussed at an early stage in the project, to avoid unwelcome surprises when it is too late to recover. << describe the details of the technical platform that will be used a) to develop the solution and b) to implement the final solution in the client's site.>> 4. PART 2 - Project Management Plan (a brief version) The Project Management Body of Knowledge from PMI states that there are nine main areas of concern for a project. These are: • Project Integration Management (planning, etc.) <> • Project Scope Management <> • Project (Human) Resource Management <> • Project Time Management • Project Cost Management • Project Risk Management • Project Quality Management • Project Communication Management • Project Procurement Management (if purchases are needed) Some of these areas have been covered in the Charter, above. Some are covered below. Both Network and Software teams must ensure that all areas of PMBOK are continually checked by them, especially the Project Manager. 4.1. Risk Management 4.1.1 Assumptions The plans and estimates for this project are based on the following assumptions: << list items that are assumed to be already in place or provided by the client>> 4.1.2 Dependencies The project is dependent upon the following external entities/events: 1. Other computer systems - ? 2. Other teams of people - ? 3. Specific events - ? 4. Working during holiday weeks (definitely!) <> 4.2. Constraints The constraints within which the project will operate are as follows: 1. Time 2. Budget 3. Scope 4. Other limits that apply to the project (rather than the system) << list those items or situations that cannot be changed, and are limits within which the project must be run>> 4.3. Risk Assessment 4.3.1 Risk Rating (Note that the risks need to updated as the project proceeds.) Id Possible Unwelcome Event Likelihood (L) 1, 2, 3 Severity (S) 1,2,3 Ranking L * S 1 is a low risk, 9 high risk. 4.3.2 Risk Mitigation Id Event Risk mitigation or contingency (Copy the risk events from above and comment on the remedies. 4.4. Schedule and Budget 4.4.1 Schedule ( Microsoft Project software compulsory) <> 4.4.2 Budget << If relevant for your project, provide an estimated budget for your project. Consult your project supervisor for what budgetary information is required for your project.>> 4.5. Monitoring & Controlling Mechanisms The project manager will monitor progress of the project. The team will meet with the Lecturer weekly or as agreed. The team will meet regularly with the client, weekly, or as agreed. All project managers will meet together fortnightly, with the subject co-ordinator. A weekly status/progress report will be provided by the project manager, based on information supplied by individual team members. Configuration management techniques will be used to control the documents and other deliverables of the project – all versions will be kept and baselined when milestones are reached. Change management will be used to record changes in any aspect of the project. Each document will carry a Change History. All team communication and deliverables will be stored on the Forum, but also backed up by the Project Manager. 5. References <> Ecole Polytechnique Montreal, 2004, Upedu web site, viewed 20 February 2006, .