Group 5 - Project Plan

PROJECT PLAN Group Five Design Or de lAcadie British Side Document Revision #: 1.
.0 Date of Issue: January 31, 2012 Project Manager: Ryan MacLeod
Project Plan
Or de lAcadie British Side
Approval Signatures
Approved by:
Business Project Leader
Approved by:
IM/IT Project Leader
Prepared by:
Business Project Manager
Prepared by:
IM/IT Project Manager
Reviewed by:
Quality Assurance Manager
Version 1.0 January 31, 2012
Page i
Project Plan
Table of Contents
1. Project Overview.....................................................................................1
1.1 Purpose, Scope, and Objectives............................................................................1 1.2 Assumptions, Constraints and Risks......................................................................1 1.3 Project Deliverables................................................................................................1 1.4 Schedule and Budget Summary.............................................................................2 1.5 Evolution of the Plan...............................................................................................2 1.6 References.............................................................................................................2 1.7 Definitions and Acronyms.......................................................................................3
2. Project Organization...............................................................................4
2.1 External Interfaces..................................................................................................4 2.2 Internal Structure....................................................................................................4 2.3 Roles and Responsibilities.....................................................................................4
3. Managerial Process Plans......................................................................5

3.1 Start-up Plan..........................................................................................................5
3.1.1 Estimates....................................................................................................................5 3.1.2 Staffing.......................................................................................................................5 3.1.3 Resource Acquisition..................................................................................................6 3.1.4 Project Staff Training..................................................................................................7
3.2 Work Plan...............................................................................................................7

3.2.1 Work Breakdown Structure........................................................................................7 3.2.2 Schedule Allocation....................................................................................................8 3.2.3 Resource Allocation...................................................................................................9
3.3 Project Tracking Plan...........................................................................................10

3.3.1 Requirements Management.....................................................................................10 3.3.2 Schedule Control......................................................................................................10 3.3.3 Quality Control..........................................................................................................10 3.3.4 Reporting..................................................................................................................10 3.3.5 Project Metrics..........................................................................................................10
3.4 Risk Management Plan........................................................................................11 3.5 Project Closeout Plan...........................................................................................11
4. Technical Process Plans.....................................................................12

4.1 Process Model.....................................................................................................12 4.2 Methods, Tools, and Techniques.........................................................................12 4.3 Infrastructure.......................................................................................................12
Organization Group Five Design Owner RM
Title/Subject Or de lAcadie British Side Approved by SP
Date January 31, 2012
Number 1.0 Version
Page ii
Project Plan
4.4 Product Acceptance............................................................................................12
5. Supporting Process Plans.................................................................14

5.1 Configuration Management.................................................................................14 5.2 Verification and Validation...................................................................................14 5.3 Documentation....................................................................................................14 5.4 Quality Assurance...............................................................................................15 5.5 Reviews and Audits.............................................................................................15 5.6 Problem Resolution.............................................................................................15 5.7 Process Improvement..........................................................................................16
6. Additional Plans..................................................................................17 7. Project Evolution.................................................................................18

7.1 Project support and maintenance........................................................................18 7.2 Follow-up projects...............................................................................................18 7.1 Project Support and Maintenance...................................................................................17 7.2 Follow-up Projects..........................................................................................................17
Number 1.0 Version
Page iii
Project Plan
Document Change Control

This section provides control for the development and distribution of revisions to the Project Charter up to the point of approval. The Project Charter does not change throughout the project life cycle, but rather is developed at the beginning of the project (immediately following project initiation approval, and in the earliest stages of project planning). The Project Charter provides an ongoing reference for all project stakeholders. The table below includes the revision number (defined within your Documentation Plan Outline), the date of update/issue, the author responsible for the changes, and a brief description of the context and/or scope of the changes in that revision. Revision Number 1.0 Date of Issue Jan. 31, 2012 Author(s) RM Brief Description of Change First Edition
Number 1.0 Version
Page iv
Project Plan
1. Project Overview
This section of the IM/IT Project Management Plan provides an overview of the purpose, scope and objectives of the project for which the Plan has been written, the project assumptions and constraints, a list of project deliverables, a summary of the project schedule and budget, and the plan for evolving the IM/IT Project Management Plan. 1.1 Purpose, Scope, and Objectives The British characters currently have minimal interaction within the game. To enhance game play for all characters, this project looks to increase the game play for the British side characters by adding more interactions within the game world. This will be accomplished by attempting to incorporate NPCs (Non Player Characters) that will help in communication between British characters. As well as a puzzle system, that allows the players to translate French clues into English, which helps the British characters find treasure. There will be a limited number of words included in the translation system to make it less tedious for the players. Weaponry and fighting will be left out of any of the enhancements as we try to add to the British game play experience. The interaction between characters other than British ones will be left for a different development team. Upon completion of the project it will be integrated into the pre-existing framework for Or de lAcadie. The project will be stand alone from additional add-ons being developed by other teams. The success of the project will depend on the complete integration of at least one of the planned features. Failure to have a working enhancement will be considered a failure of the project. 1.2 Assumptions, Constraints and Risks A key assumption is that the British characters in the game have basic movements, such as walking around. Another assumption is that the current game is working and easily modifiable. The assumption is that the game is robust and flexible to change. A major constraint is the unfamiliarity with the openwonderland framework and with only two months to become familiar with it. Also, the projects process could be longer than what was initially planned, so this may cause delays or possibly incomplete parts. Also, working with the code that is already in place may cause problems if it is not intuitive and robust. 1.3 Project Deliverables The project will deliver software written in Java in conjunction with the framework of openwonderland. The software will contain add-on enhancements for the British characters in the game. Hard copies of the following documents will be given to Dr. Reilly:
Organisation Group Five Design Owner - RM
Project Plan Or de lAcadie British Side Approved by
Date - January 31, 2012
Number 1.0 Version
Page 1
Project Plan Project Charter SRS & Project Plan Design sketches and evaluation notes System Design & Detailed Design Docs Documented Code Base Test Plan Test Reports User Manual Deployment Guide Minutes of Project Meetings All reviews (both given and received)
The list of items will be delivered no later than March 29, 2012 along with a working demo of the project. 1.4 Schedule and Budget Summary No money will be spent over the duration of the project.
Milestone/Deliverable Planned Completion Date
Project charter Project plan, requirements document Prototype 1: throwaway Design documents Prototype 2: implementation steel thread Updated documents User manual Deployment guide Demo
January 20, 2012 January 31, 2012 February 14, 2012 February 28, 2012 March 13, 2012 March 27, 2012 March 27, 2012 March 27, 2012 March 29, 2012
1.5 Evolution of the Plan Each stage of the process will come with a review of the plan to ensure that it matches the current flow of the project. An unscheduled update will be done with the consent and knowledge of the customer. If changes are made to the plan a new version number will be issued, the original version starts at 1.0 and will increase accordingly. 1.6 References Project Charter Group Five Designs, Version 1.1, January 27 2012, Stu Penner, Group Five Design
Number 1.0 Version
Page 2
Project Plan
1.7 Definitions and Acronyms openwonderland An open source virtual world. Written in Java, it comes with a large support network of already created add-ons and features. IM/IT Information Management/Information Technology SRS Software Requirements Specification
Number 1.0 Version
Page 3
Project Plan
2. Project Organization
2.1 External Interfaces The customer, Dr. Derek Reilly, will be informed of any changes to the organization that occur over the course of the project. He will also contribute any suggestions for changes he feels are necessary for a successful completion of the project. 2.2 Internal Structure Given that our team consists only of four members, there will be a small portion of separated tasks taken on by each team member. For example, the following tasks will be handled by all members of the team; documentation, development, quality assurance, testing, and validation of the final product. Project management will be given to a specific individual. 2.3 Roles and Responsibilities
Sponsor
Project Manager
Software Engineer
Role
Software Engineer
Responsibilities
Software Engineer
Software Engineer
Project Manager Software Engineer Sponsor
Ensures project is on track, interacts with sponsor, delegates tasks to software engineers Planning through all stages, software development, software testing Provides guidance and direction to ensure project is on track.
Number 1.0 Version
Page 4
Project Plan
3. Managerial Process Plans

This section of the IM/IT Project Management Plan specifies the project management processes for the project. This section defines the plans for project start-up, risk management, project work, project tracking and project close-out. 3.1 Start-up Plan 3.1.1 Estimates The estimate of time required for each stage is based on the time given to complete the stage and on the description of the stage itself. The confidence level ranges from low-high and is high for completed documents simple updates.
Milestone/Deliverable Estimated Time (person-days) Confidence Level Planned Completion Date
2 5 5 4 8 3 4 4 10
High High Low Low Low High Medium Medium Low
The total estimated time scheduled for the project is: 45 person-days. The re-estimation of effort will be done on the project milestones. This will be done based on project description and from an estimate given by the customer, as they will expect a certain task completed in a specific time frame. 3.1.2 Staffing
The project will require four staffed individuals, including the project manager. The skill level of each individual is equivalent, since the framework being used is unfamiliar to all staff at the moment. The personnel are required to be on hand ready to take on tasks from January 2, 2012 to March 29, 2012.
Number 1.0 Version
Page 5
Project Plan
Milestone/Deliverable Number of Staff Required

Planned Completion Date
2 3 4 3 4 2 2 3 4
3.1.3
Resource Acquisition
All personnel are already acquired as part of the Group Five Design team. There are no other projects currently on the go that require attention from any of the staff. Any software or hardware resources are available free of cost courtesy of the Dalhousie Computer Science Department. Personal computers will also be used for work from the home or at any time an employee is out of the office. Facilities to work on the project have been supplied by the customer Dr. Reilly and in conjunction with Dalhousie University. Software and hardware will not be required until the coding stage of the project and will involve the following: Eclipse IDE, Java SDK
Number 1.0 Version
Page 6
Project Plan
Openwonderland Server OSX, Linux or Windows Operating System Computer with 3D graphics card and a minimum of 128MB of video memory
3.1.4
Project Staff Training
Each staff member on the project (all four) will be required to go through the openwonderland tutorials provided at openwonderland.org. This will be all the training necessary to ensure that the team is up to speed. Any specific problems that arise after this initial training will be looked at on a case-by-case basis. This approach is being implemented since it is a very large framework to learn and only specific parts are necessary for the success of the project. The project manager will specify any training necessary well ahead of the required date to ensure ample time for completion. 3.2 Work Plan 3.2.1 Work Breakdown Structure The project charter requires group input and approval by the customer. This section has been completed and will be updated as the project moves forward. The resources necessary will be small, one-person hour every two weeks or when required. The project plan and requirement documents will identify the requirements and plan for the entire project. This milestone requires three staff and to have the fourth on standby for editing and consultation. This portion will be completed within a week and will provide the customer with insight into our view of the project. The project plan builds off of the project charter. Design documents will describe the details of the build structure for the project; along will the resources and frameworks needed. This document should validate the SRS. This is one of the last steps before the project moves into the coding phase and is a chance to analyze the design to prevent delays in the future. This section requires seventy-five percent of the teams man-power and will require four-person days. The first prototype (Throwaway) will build off the requirements to create an overall design for the project. This prototype will attempt to meet the requirements and will be delivered to the client to critique. This stage will require the full team resources and will take approximately 5 person-days to complete. Upon completion and receiving the customer review, the SRS will be updated to match the new set of requirements if necessary. Prototype (Steel Thread) is a direct implementation of the design documents. This prototype is a means to validate each of the design choices made in the
Organisation Group Five Design Owner - RM Project Plan Or de lAcadie British Side Approved by Number 1.0 Version
Page 7
Project Plan
previous step. This stage will ideally show the customer that the design process we choose is correct and that the team is ready to move forward to completion. Test cases will in drawn up in conjunction with this prototype. Final documentation, presentation, and demo are the final deliverables for the project. This section is used to gather all the appropriate documents and to present the final product to the customer. The requirements need to be traced through each of the design stages to see where they are implemented in the final product. This will require the longest amount of time to create and will require the full team working at near capacity to ensure that this section is completed on time. This stage will be the final gauge of if the project was successful or not. 3.2.2 Schedule Allocation
Each milestone must be completed before the project is able to continue to the next stage.
Milestone/Deliverable Planned Completion Date
Number 1.0 Version
Page 8
Project Plan
3.2.3
Resource Allocation
Number of Staff Required
Milestone/Deliverable
Computer Resources Microsoft Word Microsoft Word
Other Requirements
Planned Completion Date
Project charter Project plan, requirements document Prototype 1: throwaway Design documents Prototype 2: implementation steel thread Updated documents User manual Deployment guide
2 3
Approval by Customer Approval by Customer
January 20, 2012 January 31, 2012
4 2 4 1 2 2
Microsoft Word Microsoft Word Eclipse Open wonderland Microsoft Word Microsoft Word Microsoft Word Microsoft Word Eclipse Open wonderland Microsoft PP Microsoft Word
Approval by Customer Approval by Customer Simulation Facilities Administrative Support Approval by Customer Approval by Customer Approval by Customer Approval by Customer Simulation Facilities Administrative Support Approval by Customer
February 14, 2012 February 28, 2012 March 13, 2012 March 27, 2012 March 27, 2012 March 27, 2012
Demo
March 29, 2012
Number 1.0 Version
Page 9
Project Plan
3.3 Project Tracking Plan 3.3.1 Requirements Management Requirements will be managed through the SRS (Software Requirements Specification) document. The changes to the requirements can be traced through the version control implemented on each document. Assessing the impact of requirement changes will be done on a case-by-case basis during development. Risk management will be applied at the start of the project to help identify any potentially high-risk changes that could occur. 3.3.2 Schedule Control
The schedule will be controlled by the progress that has been completed at each milestone. If the schedule is off at a particular milestone the customer will be contacted and a meeting will be called to discuss how to move the project forward. The calendar system will be set up to mark the days to the next milestone depending on the stage of the project. This will be compared to the person-days on the milestone completed and those still remaining against the amount of time left to complete that section. 3.3.3 Quality Control
Quality control will be measured by the completion of the project with zero critical errors. Minor bugs will be allowed but anything that causes a system failure will be studied and corrected. Portions of the requirements and design will be reviewed by a third party and by the customer to ensure the best implementation. 3.3.4 Reporting
E-mail and two weekly meetings with the customer will be used to communicate any changes that will occur to the project. Any project critical communication may take on both forms of communication to get the issue resolved. Otherwise communication will be kept to the weekly meetings if possible. The detail of these communications will depend on the size and scope of the issue. 3.3.5 Project Metrics
Weekly group meetings will be used to track progress within the group on each individual task. These will be stored in the weekly minutes with concerns and ideas about the project. Milestones will be used as a baseline for tracking the progress of the overall completion of the project. Discussion with other groups
Organisation Group Five Design Owner - RM Project Plan Or de lAcadie British Side Approved by Number 1.0 Version
Page 10
Project Plan
working on similar projects will be used to roughly analyze our own progress data to see where we stand. The customer throughout the project will validate the metrics. 3.4 Risk Management Plan Risk management will be done at the start of the project and before major milestones. It will involve identifying, analyzing, management planning, and reviewing the risk. Looking at the weak areas of the project will identify the risks and what is critical to make the project successful. An analysis will give a detailed list of the weak areas and critical success elements. Management planning will look at the specific ways to minimize the impact if any of the defined risks occur. This process will be reviewed throughout the project to ensure the progression of the project. Staff members will be responsible for alerting the group of any risk factors that may be occurring or have not mentioned. Each milestone might bring with it a different set of risks and upon completion those risks may no longer be relevant to the project. Each weekly meeting the group will run through the risks, make additions and changes as necessary. Emergency issues can be brought to the attention of the project manager at any point. Some of the major risks of the project revolve around the technology and time constraints that have been put of the project. The fact that unfamiliar software is being used by each of the staff member increases the chance of an extended development time. Since the project is on a strict timeline this could cause unsatisfactory deliverables. Since the complexity of the tasks is unknown there could bring a change to the scope of the project at a later date. 3.5 Project Closeout Plan Upon completion of the project, hard copies of all communications and project documents will be handed over to the customer, Dr. Reilly. They may also be stored electronically on each of the staff members personal computers for use in their portfolios. Each staff member is required to provide a post-mortem analysis of the project and their experiences. The staff members do not need to be reassigned to a future project, as there is none currently in the works. The customer will do analysis of the completion of project objectives.
Number 1.0 Version
Page 11
Project Plan
4. Technical Process Plans

4.1 Process Model The customer will dictate information and work products whenever a section of the project is due. This is outlined in the project timeline on the basis of milestones. Information within the group will be shared via e-mail and weekly meetings. The major milestones are project plan and requirements, design documents, prototyping, final product documents, and a live demonstration of completed British enhancements. These will all be in the form of deliverables to the customer who will approve them based on their set of defined criteria for success. Minor reviews will be conducted weekly to ensure up to date information in documents. A major review will take place before starting to work on the final demo product and after completion of all milestones. The standard by which we review will be based on the expectation and criteria set out by the customer. Project initiation occurred when Dr. Reilly awarded us a contract to develop a section of Or de lAcadie. This process will terminate upon successful completion of the project, or at the end of the timeline for the project, whichever comes first. 4.2 Methods, Tools, and Techniques Development will be done using Java in the IDE Eclipse. This will be integrated with subversion software to track and document changes to the deliverable. The coding will be broken down to allow each member of the team the ability to work on sections most suited to their strengths. Group input through all steps will keep the ideas flowing so no one person gets stuck on a specific implementation. 4.3 Infrastructure Eclipse, Java, and openwonderland are compatible with all operating systems and network setups. Testing will be done across OSX, Linux and Windows operating systems to ensure this assumption holds. Dalhousies computer science department is equipped with hardware that implements all of these operating systems. Dalhousie also has a free to access network that openwonderland can be tested on during the verification stages. Each staff member is responsible for there own working area if they do not wish to use that provided by Dalhousie University. 4.4 Product Acceptance The customer will receive the final deliverables on March 29, 2012. They will be reviewed by the customer and critiqued on the following basis as defined by the customer in the project details:
Completeness Consistency Correctness
Number 1.0 Version
Page 12
Project Plan Level of specificity Clarity Organization Format, spelling, grammar Use of diagrams
These criteria will be used along with meeting of critical success factors outlined in the project charter.
Number 1.0 Version
Page 13
Project Plan
5. Supporting Process Plans

5.1 Configuration Management Any changes to internal documentation will be met with a signature, time stamp, and comments on why the changes were made. This requires approval of the customer. Progress will be tracked weekly at the groups meeting and will be built into the minutes for each meeting. Any changes required to the project will be communicated via e-mail or in person to the customer whenever the need arises. 5.2 Verification and Validation Analyzing the finished product against the scope stated in the project character will be the verification for the project. Creating a more realized gameplay experience in the opinion of the players will validate the process. Demoing the final product will be a part of the validation. Peer reviews will be done to ensure the requirements and project details are complete and outline all the parts necessary to have a successful project. The customer will be reviewing each milestone and giving the group feedback based on a numerical score. This along with comments will verify any choices we made and allow us to change them if necessary before reaching any critical points. There will be multiple implementations in the form of a throwaway model and a steel thread model. Each document created will be reviewed as part of a milestone to ensure they are correct and up to date. Automated tools such as SVN, wiki, and Dropbox give version control and will give each group member, as well as the customer, access to the latest version. 5.3 Documentation Documentation is will be generated as part of the milestones, reviews, and during the weekly meetings. Generating and reviewing the project documents is the responsibility of all the members of the group. The reviews for a specific week will be designated at the beginning of that week and are to be completed by the same time the following week. The customer has the responsibility to give input into the project documentation and provide guidance in areas that are incorrect. The following table contains information about all the documents that will be presented at the end of the project.
Number 1.0 Version
Page 14
Project Plan

Person(s) Responsible
Document
Creation Date
Review Date
Project charter Project plan, requirements document Design Sketches and Evaluation Notes System Design & Detailed Design Docs Documented Code Base Test Plan Test Reports User Manual Deployment Guide Meeting Minutes All Reviews
January 20, 2012 January 27, 2012 February 28, 2012 February 28, 2012 March 27, 2012 March 12, 2012 March 27, 2012 March 27, 2012 March 27, 2012 March 27, 2012 TBD
January 27, 2012 February 7, 2012 TBD TBD March 29, 2012 March 29, 2012 March 29, 2012 March 29, 2012 March 29, 2012 March 29, 2012 March 29, 2012
Stu Penner Ryan MacLeod Travis Russell Stu Penner TBD All Group Members All Group Members TBD TBD TBD Ryan MacLeod All Group Members
5.4 Quality Assurance The product must in its final form implement at least one of the features stated in the scope of the project. This implementation must have a workable demonstration that can be repeated on multiple occasions. During the course of the project the milestones must be completed by the date that they are due. The customer may decide to deem the project a success or a failure depending on his or her own criteria even if the project does not match the scope initially stated. An effort will be made to communicate with the customer to ensure quality is maintained. Constant review of the documentation and project plan and design will ensure the project is in the green zone each step of the way. 5.5 Reviews and Audits Reviews will be performed after the deliverables have been handed in at each milestone stated in section 2.1 of the project charter. The customer can retain the right to review and make changes, as he or she seems fit during any point of the process. In house reviews will be done in respect to the documentation processes highlighted in section 4.3 of this document. 5.6 Problem Resolution Emergency meetings can be called in the event of a major problem that needs to be resolved. These will be done in conjunction with communication to and from the
Number 1.0 Version
Page 15
Project Plan
customer. The project manager will be in charge of contacting the customer and finding an appropriate time for the team to meet. Problems will be tracked during the weekly meetings and stored in the minutes. These can be reviewed and analyzed at a later point and time. More effort should be placed on solving the problems rather than on the reporting of them. 5.7 Process Improvement The project will be assessed at each milestone. This will allow the group to decide if the method in which they handled the last section was appropriate. Since the group is small, implementation of process improvement will require little upfront planning. In the case of a problem, a processed improvement assessment will occur to minimize the chance of the same problem reoccurring during the project. In the case of uneven workload distribution the project manager must decide how to divide the work more evenly.
Number 1.0 Version
Page 16
Project Plan
6. Additional Plans
No additional plans are required to fulfil contractual obligations.
Number 1.0 Version
Page 17
Project Plan
7. Project Evolution
7.1 Project support and maintenance Openwonderland has an assortment of online resources that can be used to troubleshoot and debug any future issues with the software. This can be found at openwonderland.org. Java also has an online help center that can be found online at www.java.com. 7.2 Follow-up projects There will be no follow-up projects that will use this project. The customer however may decide to overwrite this project with an implementation of his or her own.
Number 1.0 Version
Page 18

Group 5 - Project Plan

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Group 5 - Project Plan

Hochgeladen von

Copyright:

Verfügbare Formate

PROJECT PLAN Group Five Design Or de lAcadie British Side Document Revision #: 1.

.0 Date of Issue: January 31, 2012 Project Manager: Ryan MacLeod

Or de lAcadie British Side

Business Project Leader

IM/IT Project Leader

Business Project Manager

IM/IT Project Manager

Quality Assurance Manager

Version 1.0 January 31, 2012

Or de lAcadie British Side

3. Managerial Process Plans......................................................................5

3.2 Work Plan...............................................................................................................7

3.3 Project Tracking Plan...........................................................................................10

3.4 Risk Management Plan........................................................................................11 3.5 Project Closeout Plan...........................................................................................11

4. Technical Process Plans.....................................................................12

Organization Group Five Design Owner RM

Title/Subject Or de lAcadie British Side Approved by SP

Date January 31, 2012

Number 1.0 Version

Or de lAcadie British Side

4.4 Product Acceptance............................................................................................12

5. Supporting Process Plans.................................................................14

6. Additional Plans..................................................................................17 7. Project Evolution.................................................................................18

Organization Group Five Design Owner RM

Title/Subject Or de lAcadie British Side Approved by SP

Date January 31, 2012

Number 1.0 Version

Or de lAcadie British Side

Document Change Control

Organization Group Five Design Owner RM

Title/Subject Or de lAcadie British Side Approved by SP

Date January 31, 2012

Number 1.0 Version

Or de lAcadie British Side

Organisation Group Five Design Owner - RM

Project Plan Or de lAcadie British Side Approved by

Date - January 31, 2012

Number 1.0 Version

Or de lAcadie British Side

Organisation Group Five Design Owner - RM

Project Plan Or de lAcadie British Side Approved by

Date - January 31, 2012

Number 1.0 Version

Or de lAcadie British Side

Organisation Group Five Design Owner - RM

Project Plan Or de lAcadie British Side Approved by

Date - January 31, 2012

Number 1.0 Version

Or de lAcadie British Side

Project Manager Software Engineer Sponsor

Organisation Group Five Design Owner - RM

Project Plan Or de lAcadie British Side Approved by

Date - January 31, 2012

Number 1.0 Version

Or de lAcadie British Side

3. Managerial Process Plans

High High Low Low Low High Medium Medium Low

Organisation Group Five Design Owner - RM

Project Plan Or de lAcadie British Side Approved by

Date - January 31, 2012

Number 1.0 Version

Or de lAcadie British Side

Organisation Group Five Design Owner - RM

Project Plan Or de lAcadie British Side Approved by