Project Charter - CSE SERVICESranger.uta.edu/.../Fall2012/Charter_Power_Vision_1.0.pdf · Project...

Project Charter Electric-Eye

Nichelous Herndon

Adis Kovacevic

Zack Davis

Juan Sifuentes

Rommel Alonzo

Project Charter | 2

Document Last Updated on 11/15/2012

TABLE OF CONTENTS

1. General Organization 7

1.1 Project Manager 7

1.2 Project Oversight 7

1.3 Roles and Responsibilities 8

1.4 Project Constraints 9

1.5 Project Assumptions 10

1.6 Preliminary Schedule and Costs 10

2. Scope Statement 12

3. Cost Management Plan 13

3.1 Overview 13

3.2 Labor Costs 13

3.3 Material Costs 13

4. Earned Value Management 14

4.1 Overview 14

4.2 Earned Value Measurement 14

4.3 Earned Value Reporting 14

5. Scope Management Plan 15

5.1 Overview 15

6. Work Breakdown Structure 16

6.1 Overview 16

7. Quality Management Plan 18

7.1 Overview 18

Project Charter | 3


7.2 Documentation 18

7.3 Hardware 18

7.4 Software 18

7.5 Design Documentation 19

7.6 Test Plan 19

8. Communications Plan 20

8.1 Overview 20

8.2 Internal Communication 20

8.3 External Communication 21

9. Change Management Plan 22

9.1 Purpose of Integrated Change Management Plan 22


9.3 Review and Approval Process 23

9.4 Change Identification, Documentation, Implementation and Reporting 23

10. Risk Management Plan 25

10.1 Purpose of Risk Management Plan 25


10.3 Risk Identification 26

10.4 Risk Triggers 26

10.5 Risk Analysis 27

10.6 Risk Severity 28

10.7 Risk Response Planning 29

10.8 Risk Documentation and Reporting 29

10.9 Risk Control 29

Project Charter | 4


11. Procurement Management Plan 30

11.1 Purpose of the Procurement Management Plan 30


11.3 Required Project Procurements and Timing 30

11.4 Description of Items/ Services to be acquired 31

12. Project Closeout Report 32

12.1 Purpose of Closeout Report 32

12.2 Administrative Closure 32

12.3 Lessons Learned 33

12.4 Plans for Post Implementation Review (PIR) 33

12.5 Final Customer Acceptance 33

12.6 Financial Records 33

12.7 Final Project Performance Report 33

Project Charter | 5


List of Figures Figure 2-1: Product Concept .................................................................................................................12

Figure 9-1: Change Request Form ....................................................................................................... 24

Project Charter | 6


List of Tables Table 1-1 : Roles and Responsibilities .................................................................................................... 9

Table 1-2: Preliminary Schedule ...........................................................................................................10

Table 1-3: Preliminary Costs ................................................................................................................. 11

Table 6-1: General Project Overview ................................................................................................... 16

Table 6-2: Project Charter Detailed Overview Example ........................................................................ 17

Table 10-1: Risk Analysis ....................................................................................................................... 27

Table 10-2: Risk Severity ..................................................................................................................... 28

Project Charter | 7


1. General Organization

1.1 Project Manager

The role of project manager shall be performed by Nichelous Herndon. Nichelous will take on the

responsibilities of keeping the team on task at meetings, coordinating the free times of the group

members along with the work deadlines in order to schedule appropriate meeting times. He will also

set the agenda at meetings, decide on important issues with the valuable input of the team, assign

team duties, and sign all the team’s engineering notebooks.

To accomplish these responsibilities, Nichelous will rely on his skill set which includes years of work

related management experience, as well as software project management and software engineering

classes taken at the University of Texas at Arlington.

1.2 Project Oversight

1.2.1 Internal Controls

The Project Manager will manage internal control by approving team roles which will monitor

important areas of the project, and setting weekly team meetings which will allow time for each

member to provide the team with their individual work status as well as receive feedback. The

deliverables will be internally maintained by the team via cloud storage services which include Google

Docs and Dropbox.

1.2.2 External Controls

External oversight will be handled by our Senior Design class, Professor O’Dell, and our sponsor Chris

McMurrough. O’Dell will require frequent and timely individual status reports as well as team progress

reports. Chris McMurrough will provide input and feedback on the project and the project’s quality

throughout the process.

1.2.3 Controls Interaction

The Gate Reviews will bring the external control of Professor O’Dell and the internal control of the

team together to interact and review the quality of each major deliverable.

Project Charter | 8


1.3 Roles and Responsibilities

Name Role Description

Mike O’Dell Department Head

Supervise project progress

Supervise project quality

Grade deliverables

Chris McMurrough Power Vision Sponsor Sponsor input Quality control

Nichelous Herndon

Project Manager

Keep team on task Coordinate team

meetings Set team meeting

agenda

Development Manager Assign team roles in

development

Software Developer Create software

Quality Assurance Test quality of project

Zack Davis


Researcher

Research important areas essential to the project.


Document Editor

Formats and edits documents before submission.

Project Charter | 9


Adis Kovacevic

Hardware / Software Developer

Develops hardware and software


Rommel Alonzo

Planner

Create an outline of the important dates throughout the project.

Hardware / Software Developer

Develops hardware and software


Juan Sifuentes


Researcher

Research important areas essential to the project.


Table 1-1 : Roles and Responsibilities

1.4 Project Constraints

The Electric-Eye project is limited by our budget, time and personnel constraints.

We are given a budget of $800. Any expenses past the initial budget will be funded by the members of Power Vision.

We are limited to one academic year for development. Schedule constraints of the team members limit when we can work on this project.

Project Charter | 10


1.5 Project Assumptions

These are the assumptions for the project:

The team will receive a budget of $800.

The team will be given a workspace.

Power Vision will not provide maintenance for the Electric-Eye after May 2013

1.6 Preliminary Schedule and Costs

Key Project Task Dates to Accomplish

First Draft of SRS 10/11/2012

First Draft of Project Plan 10/18/2012

SRS Gate Review 11/02/2012

SRS Baseline 11/09/2012

Project Charter Baseline 12/4/2012

MS Project File Baseline 12/4/2012

Architectural Design Specification 01/21/2013

Detailed Design Specification 02/22/2013

Test Plan 04/01/2013

Final Project Delivery 05/03/2013

Project Wrap-up 05/09/2013

Table 1-2: Preliminary Schedule



Item Name Cost ($)

Motherboard 180

Camera 160

Solid State Drive 150

Case 220

Miscellaneous 20

Total: 730

Table 1-3: Preliminary Costs



2. Scope Statement The module will utilize a RGB-D camera that will read in data from an indoor environment. The

module will then store the frames read in from the camera onto an on-board storage device. After all

the frame data has been stored, the module will use it to create a digital world map. When finished,

the module can be mounted on a robot and start performing localization to help navigate it through

the area by using the newly created world map.

Figure 2-1: Product Concept



3. Cost Management Plan

3.1 Overview

When it comes to developing a product as a team, cost management is essential. In the case of Power

Vision, the budget is limited and the amounts of hours the team can dedicate to the project differ

depending on team member’s personal and school schedules. The cost management plan is critical to

ensuring that the project runs smoothly as far as man-hours and budget is concerned.

3.2 Labor Costs

The rough estimate for labor costs for the project is 2000 man-hours. In order to assure that our

project is completed on time, and given this rough estimate, we have calculated that about 10-15

hours per person each week will be needed to complete our project. To help the team keep track of

what tasks we should be working on and how much time should be dedicated to them, we will use

Microsoft Project. We will be referring to the project file to help us determine where we should budget

our time.

3.3 Material Costs

The budget given to our team for this project is 800 dollars. After doing initial research on parts that

will be needed to build our module we have found that material costs will range between 610 - 800

dollars. There are many different parts that would work perfectly for our project, which gives us more

flexibility as far as the budget is concerned. For instance, if we choose to get a faster processing

motherboard then we can cut back on the hard drive size, which will not harm the performance of the

module in any way. To help us monitor our budget, we will have a folder that has all of our records and

receipts from our purchases.



4. Earned Value Management

4.1 Overview

Earned value management is one of the many tools that we will be using to track our individual

performance as well as group performance. With our earned value management plan, we will be able

to make sure that we are not spending too much time in sections that we have scheduled. Power

Vision will track and record all earned value using the Microsoft Project plan.

4.2 Earned Value Measurement

For measuring earned value we will be using the following equations:

BCWS: Budgeted Cost of Work Scheduled (Planned Value)

BCWP: Budgeted Cost of Work Performed (Earned Value)

ACWP: Actual Cost of Work Performed (Actual Cost)

CPI = Cost Performance Index = Earned Value / Actual Cost

SPI = Schedule Performance Index = Earned Value / Planned Value

If our CPI or SPI > 1.0 then we have excellent performance.

If our CPI or SPI < 1.0 then we are having poor performance and schedule adjustments will be need to

be implemented as soon as possible.

Using this information we will be able to easily track the performance of our team members and the

team as a whole. It will also tell us whether we are on track with our schedule or if we need to make

adjustments.

4.3 Earned Value Reporting

Team members of Power Vision will record all time spent working on a certain task in their

engineering notebooks. Power Vision will also have a document in our Dropbox folder that each team

member will update regularly; the project planner will then use that document to update the

Microsoft Project file accordingly. Each week, we will begin our meetings by analyzing our current SPI

and CPI, and we will adjust our budget of person-hours if needed.



5. Scope Management Plan

5.1 Overview

Our time period is restricted to a 2 semester period, so we will focus on the main requirements that

are needed to make this project successful first. If our time and budget allows it, we will later add

features that will make our module more efficient, accurate, and/or compact. We also realize that

based on our limited experience with 3D data and Robot Operating System (ROS), we reserve some

flexibility of adding necessary features that are required to complete our project successfully. If a

feature has been nominated to be added, then all members in Power Vision must agree before

implementation can occur.



6. Work Breakdown Structure

6.1 Overview

Power Vision has divided the project into two main phases named Senior Design 1 (SD1) and Senior

Design 2 (SD2). In the SD1 phase we will be working on the system requirements specification, project

charter and some architectural design. During the SD2 phase, we will be finishing our architectural

design, detailed design specification, test plan, and implementation.

WBS Task Name Start Finish

1 Senior Design 1 9/26/2012 12/6/2012

1.1 System Requirements Specification 9/26/2012 11/09/2012

1.2 Project Charter 9/26/2012 12/4/2012

1.3 MS Project File 9/26/2012 12/4/2012

2 Senior Design 2 1/14/2012 5/09/2012

2.1 Architecture Requirements Specification 1/14/2013 1/21/2013

2.2 Detailed Design Specification 2/01/2013 2/22/2013

2.3 Test Plan 2/22/2013 4/01/2013

2.4 Final Project Delivery 4/01/2013 5/04/2013

2.5 Project Wrap-up 5/03/2013 5/09/2013

Table 6-1: General Project Overview



WBS Task Name Start Finish

1.2 Project Charter 9/26/2012 12/4/2012

1.2.1 Sections 9/26/2012 12/4/2012

1.2.1.1 General Organization 9/26/2012 12/4/2012

1.2.1.2 Scope Statement 9/26/2012 12/4/2012

1.2.1.3 Cost Management Plan 9/26/2012 12/4/2012

1.2.1.4 Earned Value Management 9/26/2012 12/4/2012

1.2.1.5 Scope Management Plan 9/26/2012 12/4/2012

1.2.1.6 Work Breakdown Plan 9/26/2012 12/4/2012

1.2.1.7 Quality Management Plan 9/26/2012 12/4/2012

1.2.1.8 Communication Plan 9/26/2012 12/4/2012

1.2.1.9 Change Management Plan 9/26/2012 12/4/2012

1.2.1.10 Risk Management Plan 9/26/2012 12/4/2012

1.2.1.11 Procurement Management Plan 9/26/2012 12/4/2012

1.2.1.12 Project Closeout Report 9/26/2012 12/4/2012

Table 6-2: Project Charter Detailed Overview Example



7. Quality Management Plan

7.1 Overview

The quality management plan shall be used to ensure that the Electric-Eye system meets all of our

customer requirements and that a high quality product is produced. This plan outlines different quality

management techniques that will be used. The quality management plan shall be implemented by the

Power Vision team.

7.2 Documentation

All documents are split into sections and assigned to different members of the Power Vision team.

Each team member is responsible for completing his individual section. Before final submission, there

is a team read through of the entire document. This allows every team member to approve each

section of the document. This also assures correct and concise terminology and formatting

throughout the document.

7.3 Hardware

Hardware shall be purchased based on need, quality, power and cost. This is to ensure a highly

responsive and durable product. All components of the module will be tested individually before being

assembled into the module’s case. After integration and after the software is loaded onto the module,

the module’s performance as a whole will again be tested. Test cases will be written up and

implemented to test the correct output of the module based on different input scenarios.

7.4 Software

The software for the Electric-Eye will be designed, documented and tested to the highest ability of the

team. The code will be written in a modular manner to allow easier testing, and will be written with

readability in mind. The documentation will be proofread to stay consistent with the actual code on a

module by module basis.



7.5 Design Documentation

Two design documents will be submitted with the Electric-Eye:

The Architectural Design Specification document

The Detailed Design Specification document

These documents will allow the team to maintain a record and ensure all requirements in the System

Requirements Specification document are met. They will allow for a modular design and help meet

the maintenance requirement of the product.

7.6 Test Plan

A test plan will be developed to allow the testing of each component of the Electric-Eye. It will make

sure that all components are tested and that each scenario is tested and approved by the team. Each

software module will be tested individually before integrating the module into the code. This will

ensure each module is accepted and works properly. Each hardware component will be inspected

separately to ensure it is in working order before being assembled in the case. The product will pass

testing once the team approves all parts and code are correct and in working order.



8. Communications Plan

8.1 Overview

When working on long-term projects, communication is important for making sure any decisions

made are made with the team in mind. Our communication plan will provide our team with proper

protocols and standards that will allow us to work efficiently in almost any setting and situation we

may encounter. As well as internal communication, we will also set a standard to discuss project

updates and requirements with our sponsor, Chris McMurrough.

8.2 Internal Communication

8.2.1 Team Meetings

In order to provide our sponsor with a well-made product, we have decided to place the meetings as a

high priority in our communication plan. The purpose of our team meetings is to provide members

with any updates necessary and vital to the project’s progress. The plan calls for at least two meeting

every week. The duration of each team meeting may vary between 10 minutes to 2 hours, depending

on the information being discussed. Information will be discuss and documented and shared amongst

the team.

8.2.2 Email

Team Power Vision will use email services as means of discussing information relevant to the project

that isn’t time sensitive or a high priority. Every team member will be allowed to use his own preferred

email service as long as a valid email address is provided to the team.

8.2.3 Phone/Text Messaging

Text messages will only be used in case of emergencies or to check-up on a team members’ status

during team meetings and activities.

8.2.4 Dropbox

The Dropbox service application will be used as means of providing the entire team with access to all

documentation created or supplied. This service was chosen because it provides the simplest method

of distributing project relevant information to the team.



8.2.5 Google Docs

The team has chosen Google Docs as a means of actually creating any documentation. Google Docs

provides services that allow multiple team members to edit a document at the same time. This has

proven to be a useful feature during times where very detailed documents have to be reviewed. Each

team member may view the document at his station while other team members discuss whether the

written information properly reflects the teams’ actions.

8.3 External Communication

This section will provide team Power Vision with standards needed to provide proper communication

with our sponsor, Chris McMurrough.

8.3.1 Email

As stated before, team members and sponsors will use their own preferred email service to

communicate. Any emails exchanged between any one team member and sponsor (including current

and future sponsors) will be forwarded to the entire team.

8.3.2 In-Person Meetings

In preparation to a sponsor with scheduling conflicts, we require any meetings with sponsors to be

planned at least two weeks ahead of the actual team meeting date. Also, any meetings that have been

requested with our sponsor will also be required to have a list of questions or concerns that are to only

be discussed at the time of the meeting.



9. Change Management Plan

9.1 Purpose of Integrated Change Management Plan

A change management plan is essential when working on a project of this size. Change can be

beneficial for the project but it can also pose new risks that make the project infeasible. Some changes

are planned and some are spur of the moment, so it is important to have a change management plan

in place so that the team does not make any quick decisions regarding changes. Having a detailed

change management plan in place will help Power Vision address changes as they come up and turn

those changes into benefits for the project.


Department Head - Mike O’Dell

Our department head will give us advice regarding changes in our project, and give his opinion if a

change is beneficial or not based on his experience.

Project Sponsor - Chris McMurrough

Chris will be providing us with advice and consultation regarding the project. He will give us input on

how a change will affect our project and if the change will be worth our time to implement.

Project Leader - Nichelous Herndon

The project leader will consider a change and determine if it is worth bringing the change up with our

sponsor or department head.

Project Team – Power Vision

The team will decide whether a change is beneficial or not based on a detailed discussion about the

change. We will address the change democratically to determine if the change is necessary or not.



9.3 Review and Approval Process

When a project change is brought up by a team member, sponsor, or otherwise, there will be a change

control form filled out by the team member that thought of the change or by the team member that

heard the change from the sponsor or other person. After a form is filled out there will be a team

meeting that same day or night (whenever we have time) where we will discuss the change in full

detail and determine if it is a smart decision to make. If needed, our sponsor and department head will

be brought into the discussion so that we can have their inputs. Ultimately, the team will decide if the

change is necessary or not for the project.

9.4 Change Identification, Documentation, Implementation and Reporting

Power Vision will have a simple change request form that will be available in our senior design cubicle.

This form will be filled out by the person that is proposing the change and will begin the process of

analyzing the change and determining if it is a smart change to make. If a change is approved by the

team, the appropriate documents will be corrected to reflect the change immediately by the project

planner.



Figure 9-1: Change Request Form



10. Risk Management Plan

10.1 Purpose of Risk Management Plan

The purpose of the risk management plan is to establish a standard for managing the team’s risks

during the development of the Electric-Eye module. The plan will help team Power Vision identify and

measure each risk, along with the effect of the risks on the project. Once identified, the plan can help

control these risks and their effects on the project.


Department Head - Mike O’Dell

Our department head will help us determine and analyze risks to the project as a whole based on his

experience.


Our project sponsor will provide great feedback on possible project risks due to his technical skills and

experience. This will help in finding and analyzing any possible risks in the technical aspects of our

project.

Project Leader - Nichelous Herndon

The project leader will have the responsibility of determining whether a possible risk is worth

considering. The leader can also advise and determine the scope and plan of action of a risk if the

team cannot agree to a single solution.


The team must conduct meetings to determine what the impact and solution for a given risk is. The

team must agree unanimously on the specifications and plan of action. Also, each person is

responsible for identifying and submitting a report to alert the team of the new possible risk.



10.3 Risk Identification

Power Vision will be responsible for identifying all risks associated with the project. Each individual

member will be responsible for identifying any new risks associated with the parts of the project

assigned to that member. If that member encounters a new risk, he will bring it up in the nearest team

meeting and the team as a whole will address the severity, cause, and resolution of the new risk. The

risk will then be added to the internal risk document to keep track of all known risks.

10.4 Risk Triggers

Power Vision has identified the high level risks associated with the project. The team will use risk

triggers to identify new or unseen risks. These risks will probably include more specific elements of the

code or hardware. If a risk occurs, the identifying team member will inform the team, and the team

will have a meeting to deal with the new risk and its potential effects. Some of the possible risk

triggers are:

Failing to meet an internal deadline due to unseen complexity, lack of motivation or effort.

Hardware trouble, such as a failure, lack of hardware, cost, etc.

Absence due to illness or other unforeseen event.



10.5 Risk Analysis

The following table is the risk analysis that Power Vision has identified.

Risk Group

Risk Probability(%) Cost(days) Risk Exposure(days)

Technical Lack of knowledge of PCL 5 14 0.70

Technical Lack of knowledge of ROS 5 7 0.35

Technical Lack of Processing Power 10 7 0.70

Third Party

Cost of Hardware 2 10 0.20

Third Party

Shipping issues, hardware is lost in the mail or wrong items are sent.

5 14 0.70

Technical Hardware failure, hardware is shipped DOA, or fails shortly

afterwards.

5 14 0.70

Technical Runtime Errors, the module doesn’t function properly during run-time

50 5 2.50

Team Scheduling Conflicts 10 2 0.20

Team Doc. Management Service fails, Google docs or DropBox crash for

extended amounts of time

1 7 0.07

Team Customer Requirements aren’t met by Chris

2 14 0.28

Total 6.40

Table 10-1: Risk Analysis



10.6 Risk Severity

The table below reflects how team Power Vision will deal with the risks that have been stated above.

Along with each risk, we have provided a strategy, description of action and a possible trigger

associated with it. Our strategies should be understood as follows:

Avoid: The Power Vision team will avoid this risk at all cost

Mitigate: Team Power Vision will monitor the situation and only resolve if the

probability begins to reach unacceptable levels

Plan: Team Power Vision will analyze, implement, and monitor a risk management plan.

Risk Priority Strategy Description of action Trigger

Lack of knowledge High Avoid Team will actively learn required technologies through books and tutorials

Team neglects to research software and technologies

Lack of Processing Power

Medium Mitigate Seek better hardware or improve software algorithm

Software testing exposes hardware limitations

Cost of Hardware Low Plan Research cost effective alternatives Actual cost estimates exceed budget

Shipping issues Low Mitigate Make sure product procurement begin as early as possible.

Third party neglects to inform team of shipping delays

Hardware failure High Avoid Research in procurement phase must be thorough

Team neglects to review and resolve hardware limitations

Runtime Errors High Avoid Software testing must be thorough Software bugs aren’t resolved

Scheduling Conflicts Medium Mitigate Weekly meetings are mandatory Team’s lack of time management

Doc. Management Service fails

Low Avoid Back up all project documents onto a team members physical thumb drive

Third party service is shut down

Customer Requirements aren’t met

Medium Avoid Keep sponsor updated with any major project decision made

Sponsor meeting indicates that requirements are not being met

Table 10-2: Risk Severity



10.7 Risk Response Planning

If the risks stated above aren’t properly handled, the probability of a certain impact occurring may

grow. Any high-impact and probability risk assessment will be subject to a team review and monitored

in our weekly team meetings until the probability levels are in acceptable levels or until the entire risk

is resolved.

10.8 Risk Documentation and Reporting

Risks will be maintained in an internal document, viewable to all team members. During the weekly

meetings, if a new risk comes up and is accepted, the team will label the risk’s probability, cause, and

effect. The team will update the document to keep track of all the risks encountered so far.

10.9 Risk Control

Team meetings are the main source of risk control. If a team member identifies a new risk, he will

bring it up at the team meeting. The team will decided on the impact of the risk and how the risk will

be handled. These meetings occur at least once a week, twice a week on most weeks.



11. Procurement Management Plan

11.1 Purpose of the Procurement Management Plan

The Procurement Management plan is meant to provide our team with an idea of what products and

technologies we can invest in in-order to keep the project on track for scheduled delivery. Most of our

investment will focus on the hardware requirements of the Electric-Eye; any and all software will be

used under the BSD licensing agreement. We are also limiting our hardware procurement purchases

to $800, any expenses over the given budget will result in Power Vision splitting the cost evenly

among the team members.



Project Sponsor shall provide advice on project procurement purchases.

Project Manager - Mike O’Dell

Project Manager is required to finalize any procurement purchases as well as advise the team on any

improvements on the project.

Project Leader – Nichelous Herndon

Project Lead is require to provide an initial request for project procurement


The project team is required to identify which products will be beneficial to the overall design of the

project as well as prove that the procurement satisfies its requirements.

11.3 Required Project Procurements and Timing

The Project Procurement phase will begin any time after the System Requirements Specification Gate

Review is given and before the initial plans for Architectural Requirements Specification begin.

Purchases will begin a month before the implementation phase is set to begin to let our team become

familiar with the products procured.



11.4 Description of Items/ Services to be acquired

The overall idea of the Electric-Eye is to provide our users with the most efficient and reliable methods

of mapping the room and providing localization services to a ROS-compatible robot all packaged into

a small portable case. These are the major component procurements needed in the implementation of

the Electric-Eye:

Motherboard

RGB-D Camera

SSD

Miscellaneous Items

o Ethernet Cables

Pelican Case



12. Project Closeout Report

12.1 Purpose of Closeout Report

The closeout report will be used to confirm that all proper documentation has been completed, and

serve as the post-mortem of the project

12.2 Administrative Closure

12.2.1 Were the objectives of the project met?

When the product has been completed it will be evaluated based on our System Requirements

Specification (SRS). Additional requirements and features that were implemented but not specified in

the SRS document will be properly archived.

12.2.2 Archiving Project Artifacts

All data and documentation will be digitally stored. Most files that are used for documentation will be

stored in Google Docs since it keeps track of revisions, can be edited by multiple users in real time, and

is accessible to everyone in the team. Everything else, such as large code source files, will stored in in

Dropbox. Everything will be backed up with an external drive in case our source control is unavailable.

Documents to be archived:

Financial records

Cost and schedule performance reports and records

Quality data

Correspondence

Meeting Notes

Status Reports

Issue and Action Log

Risk Log

Contract Files

Change Requests

Technical documents



12.3 Lessons Learned

At project completion, Power Vision shall have an overview meeting of the lessons learned. Everyone

is also individually responsible for keeping track of their lessons learned in their interim status reports

and engineering notebook.

12.4 Plans for Post Implementation Review (PIR)

At project completion, Power Vision will give a final report that will cover all schedule performance,

risk management, and earned values over the course of the project.

12.5 Final Customer Acceptance

At project completion, Power Vision will schedule a meeting with our sponsor to evaluate the Electric-

Eye, and confirm that all specified requirements have been met.

12.6 Financial Records

We will digitally archive all purchases made that were for the purpose of this project. This will include

any physical receipts and online order confirmations. This method will help us keep our budget on

track and help us determine whether we have enough to implement extra useful feature to our

module.

12.7 Final Project Performance Report

At project completion, Power Vision will conduct a final project performance report that will evaluate

our quality of performance over the course of our project completion. This will cover our performance

over:

Schedule

Cost

Quality achievements

Risk containment

Date post:	11-Jun-2018
Category:	Documents
Upload:	duongdiep
View:	218 times
Download:	0 times