Project Charter Final

Senior Design Documentation Library Project Charter

Department of Computer Science and EngineeringThe University of Texas at Arlington

Team Virtual MD

iGait Application

Team Members: Kevin Kocian

Abdul Hadi KhanMohammad Kothawala

Jesus LinaresRoss Walker

Last Update: d MMMM yyyy 42231.9277777778 h:mm:ss am/pm

Project Charter

Table of Contents

1 General Organization........................................................................................................1

1.1 Project Manager...................................................................................................................11.2 Project Oversight.................................................................................................................11.3 Roles and Responsibilities...................................................................................................21.4 Project Constraints...............................................................................................................21.5 Project Assumptions............................................................................................................31.6 Preliminary Schedule and Cost Estimates...........................................................................3

2 Scope Statement.................................................................................................................4

2.1 Introduction..........................................................................................................................42.2 Product Definition................................................................................................................42.3 Intended Audience...............................................................................................................4

3 Cost Management Plan......................................................................................................5

3.1 Project Budget......................................................................................................................5

4 Earned Value Management..............................................................................................6

4.1 Use Microsoft Project for scheduling tasks.........................................................................64.2 Report will be made within Microsoft Project.....................................................................6

5 Scope Management Plan...................................................................................................7

6 Work Breakdown Structure.............................................................................................9

7 Quality Management Plan..............................................................................................15

7.1 Introduction........................................................................................................................157.2 Documentation...................................................................................................................157.3 Software.............................................................................................................................157.4 Testing................................................................................................................................15

8 Communications Plan......................................................................................................17

8.1 Introduction........................................................................................................................178.2 Internal communication.....................................................................................................178.3 External communication....................................................................................................18

9 Change Management Plan..............................................................................................19

9.1 Purpose of Integrated Change Management Plan..............................................................199.2 Roles and Responsibilities.................................................................................................209.3 Review and Approval Process...........................................................................................209.4 Change Identification, Documentation, Implementation and Reporting...........................21

Table of Contents

10 Procurement Management Plan.....................................................................................22

10.1 Purpose of the Procurement Management Plan.................................................................2210.2 Roles and Responsibilities.................................................................................................2210.3 Required Project Procurements and Timing......................................................................2210.4 Description of Items/ Services to be acquired...................................................................23

Table of Contents

Senior Design Documentation Library

1 General Organization

1.1 Project Manager

Kevin Kocian

1.1.1 Roles and Responsibilities:

Schedule Manager Team Leader Meeting Scribe

1.1.2 Skills and Justification:

Previous leadership positions Organized Attention to documenting meetings

1.2 Project Oversight

Internal Oversight: Design decisions will have three levels. At the lowest level the leads of the various application functionalities are free to implement the functionality as they see fit. If their implementation requires adding additional or changing functionality then the addition or change will be discussed at the next level, a team meeting. The lead of the affected functionality and the team leader must approve the change.

External Oversight: If the change is approved then it will be added to the list of proposed changes and will be brought to the attention of the project sponsor at the next meeting with the sponsor. Any changes that affect the cost of the project must also be brought to the attention of the organization / company for approval.

d MMMM yyyy 42231.9277777778 h:mm:ss am/pm 1Procurement Management Plan

Team MeetingSponsor &

Organization Approval

Design Lead


1.3 Roles and Responsibilities

Interface Development Team:

Name Role ResponsibilitiesKevin Kocian Team Leader Handles the team schedule, and assigns individual

assignments to team members.Frontend Developer Handles the team schedule, and assigns individual

assignments to team members.Software Developer General software development responsibilities:

design, coding, and testing.Mohammad Kothawala

Frontend Developer Handles the team schedule, and assigns individual assignments to team members.

Backend Developer Primary developer for the backend server functionalities.

Server Manager Responsible for ensuring the server is maintained.Software Developer General software development responsibilities:

design, coding, and testing.Jesus Linares Network Developer Creates the functionalities necessary for interaction

between the server and client services.Performance Optimizer Overlooks algorithms to ensure they are optimized.

Abdul Hadi Khan

Document Master Compiles documents into their final iteration and manages changes to documentation.

Network Developer Creates the functionalities necessary for interaction between the server and client services.

Security Developer Develops functionalities that responsible for ensuring data transfer between client and server is secure.

Ross Walker GitHub Manager Maintains the GitHub version control system, and aids other developers with properly committing their work.

Software Developer General software development responsibilities: design, coding, and testing.

iGait Development Team: iGait is the software that the interface will be designed to interact with. This team is responsible for the development and testing of the iGait software.

1.4 Project Constraints

1. Interface must communicate with iGait software / server



2. Limiting Data / Hour used3. Business Model effects design4. Architecture Design5. Components

5.1. Wrapper5.2. Camera5.3. Test Data

6. Meeting with physicians / Subject matter experts.

1.5 Project Assumptions

Backend Server Hosting: We are assuming we will make use of a dedicated host server. The server will be dedicated to handling the backend of the interface. This also includes the assumption that the client base will be large enough to justify dedicated server hosting.

1.6 Preliminary Schedule and Cost Estimates

Preliminary Project Schedule

Project Milestone Due Date Cost (Hours)

Project Charter 07/17/2015 30

SRS Gate Review 07/24/2015 60

Architectural Gate Review 08/13/2015 100

Final Design 09/14/2015 10

DDS Gate Review 09/20/2015 5

STP Gate Review 10/1/2015 30

Early Prototype I 10/26/2015 30

Early Prototype II 11/15/2015 20

Final Presentation and Demonstration 12/15/2015 50

Server costs - estimate $50. 00 (Shall have better estimate towards development)





2 Scope Statement

2.1 Introduction

The purpose of this project is to provide a graphical interface of the iGait program that has been created by Dr. Mariottini and his research team in the ASTRA Robotics Lab. This interface will be in the form of an android application and a web application that doctors or therapists can use to monitor the progress or regress of their patients. The application will work in collaboration with Kinects that will be installed at the patient’s residence to monitor their gait.

2.2 Product Definition

The application that we propose to develop will have features that are going to be of great benefit not only to doctors but also to the well being of the patient. According to what version of the application the doctor purchases, there will be a difference of features. However, the enterprise/professional edition describes the entire scope of services that the application will render. Firstly, it will have a database of the entire clientele that a particular doctor will have. This will only be accessible once the doctor successfully logs into the system. Once the doctor enters the system there will be a list of all patients with their picture/demographics. There will also be a status of the patient, showing either red or green. If the status is green, the doctor will know that the particular patient is doing fine. A red status bubble will indicate to the doctor that there is something wrong and they should investigate. Patient list will appended according to the frequency of red events. Once the doctor selects the patient, they will be able to view a timeline of weeks, days and hours. The doctor will be able to view the gait of person as a skeletal video of that occurrence. Furthermore, the doctor will have a chat service embedded in the application that can be used for communication with the patient or staff. The doctor can also request for an actual video of the incident; however, he/she will have to send a request that needs to be accepted by the patient.

2.3 Intended Audience

Our target audience in mainly doctors and therapists involve themselves with the patient’s recovery. Furthermore, this will attract hospitals and clinics running pain management facilities to monitor their patient’s condition after surgery.



3 Cost Management Plan

3.1 Project Budget

Senior Design is a two semester long course, the first half being documentation of analysis, requirements, feasibility study etc. with second half reserved for the actual implementation, review, testing etc. Roughly it is a 2000 person-hours job for both parts.

For the first half we have planned to allocate approximately 800 - 900 person-hours and the rest for the second phase where the actual implementation is scheduled to begin.

We don’t plan on using much of our budget, but at most will cover the following● 2 Kinect($130 x 2 = $260) ● 1 Amazon Server ($100)● 2 tablets (approximately $400)● license software (approximately $70)



4 Earned Value Management

4.1 Use Microsoft Project for scheduling tasks

a. Will use a range between 0.00-2.00i. The range will be determine with agreement of the team

1. Below 1.00 stands for easy task2. 1.00 stand for normal workload.3. Above 1.00 stands for more difficult and/or time consuming task

ii. If agreement can’t be made, 1. Will proceed to do anonymous majority vote.2. Once vote is made, decision is final.

4.2 Report will be made within Microsoft Project.

a. If necessary, i. Will use Excel to tally total Earned Value.

b. Team lead shall distribute Earned Value evenly



5 Scope Management Plan

Controlling the scope involves constructing a bureaucratic yet effective system. A strict adherence to the initial feature set can be accomplished using a feature checklist and feature role sheet. Comparisons between the initial feature set and actual feature set will be completed by committee at scheduled dates and dynamically at major GitHub commits. The scheduled committee comparison will hold deliberations of approving or disapproving excess features and of completing uncompleted features. Approved features to the feature set will follow a careful update of the feature checklist, cost management, earned value, work breakdown structure, and requirements.

Feature Checklist:

Feature Completion in %

Month view:Display the average levels of health per month.

---%

Week view:Display the average levels of health per week.

---%

Day view:Display the average levels of health per day.

---%

Hour view:Display the average levels of health per hour.

---%

Glance view:Display a simple Green/Red icon for the patient’s current health.

---%

Patient view:View patient information such as name, phone number, address, and e-mail.

---%

Chat function:Communicate with a certain patient using text messaging.

---%

Add/Remove patient function:Allow the ability to add and remove patients.

---%



Video request function:Request archived patient video stream. User must the accept request.

---%

Feature Role Sheet:

Developer Role

Abdul Hadi Khan Document MasterNetwork DeveloperSecurity Developer

Kevin Kocian Team LeadFrontend DeveloperSoftware Developer

Mohammed Kothawala Frontend DeveloperBackend DeveloperServer ManagerSoftware Developer

Jesus Linares Network DeveloperPerformance Optimizer

Ross Walker GitHub ManagerSoftware Developer

Scheduled Comparison Structure

Every second week of every month all developers will hold a committee to compare the original feature set and the actual feature set. The process is as follows:

1. GitHub masters review all committed changes to the committee.2. GitHub masters bring forth excess features and features not completed.3. Committee deliberates and votes on the approval or disapproval of the excess features.4. Committee deliberates and votes on how to complete uncompleted features.5. Feature checklist is updated.6. Cost management, earned value, work breakdown structure, and requirements are

updated if needed.

Dynamic Comparison Structure

With every major commit to GitHub, the GitHub masters will compare the original feature set and the actual feature set. The process is as follows:

1. GitHub masters review major commits.2. GitHub masters approve or disapprove commit based on comparison of feature set.

If a commit is disapproved, the GitHub masters will bring it forth during the scheduled comparison for further deliberation.



6 Work Breakdown Structure

WBS Name Start_Date Finish_Date

1 Senior Design June 9, 2015 November 10, 2015

1.1 Phase 1 June 9, 2015 August 17, 2015

1.1.1 Charter June 9, 2015 July 7, 2015

1.1.1.1 Initial Charter Draft June 29, 2015 June 29, 2015

1.1.1.2 Complete General Organization section of Charter Draft June 30, 2015 July 6, 2015

1.1.1.3 Complete Scope Statement section of Charter Draft June 30, 2015 July 6, 2015

1.1.1.4 Complete Cost Management Plan section of Charter Draft June 30, 2015 July 6, 2015

1.1.1.5 Complete Earned Value Management section of Charter Draft

June 30, 2015 July 6, 2015

1.1.1.6 Complete Scope Management Plan section of Charter Draft June 30, 2015 July 6, 2015

1.1.1.7 Complete Work Breakdown Structure section of Charter Draft

June 30, 2015 July 6, 2015

1.1.1.8 Complete Quality Management Plan section of Charter Draft

June 30, 2015 July 6, 2015

1.1.1.9 Complete Communications Plan section of Charter Draft June 30, 2015 July 6, 2015

1.1.1.10 Complete Change Mangement Plan section of Charter Draft June 30, 2015 July 6, 2015

1.1.1.11 Complete Procurement Management Plan section of Charter Draft

June 9, 2015 June 9, 2015



1.1.1.12 Compile Chapter Draft Sections Together June 9, 2015 June 9, 2015

1.1.1.13 Review final draft of Charter July 7, 2015 July 7, 2015

1.1.2 Requirements Definition July 8, 2015 July 17, 2015

1.1.2.1 Requirements Spread Sheet July 8, 2015 July 8, 2015

1.1.2.2 SRS July 9, 2015 July 17, 2015

1.1.2.2.1 Initial SRS Draft July 9, 2015 July 9, 2015

1.1.2.2.2 Complete Product Concept July 9, 2015 July 15, 2015

1.1.2.2.3 Complete Product Description and Functional Overview Section of SRS Draft

July 9, 2015 July 15, 2015

1.1.2.2.4 Complete Customer Requirements Section of SRS Draft July 9, 2015 July 15, 2015

1.1.2.2.5 Complete Packaging Requirements Section of SRS Draft July 9, 2015 July 15, 2015

1.1.2.2.6 Complete Performance Requirements Section of SRS Draft July 9, 2015 July 15, 2015

1.1.2.2.7 Complete Safety Requirements Section of SRS Draft July 9, 2015 July 15, 2015

1.1.2.2.8 Complete Maintence and Support Requirements Section of SRS Draft

July 9, 2015 July 15, 2015

1.1.2.2.9 Complete Other Requirments Section of SRS Draft July 9, 2015 July 15, 2015

1.1.2.2.10

Complete Acceptance Criteria Section of SRS Draft July 9, 2015 July 15, 2015

1.1.2.2.11

Complete Use Cases Section of SRS Draft July 16, 2015 July 17, 2015

1.1.2.2.12

Complete Feasibility Assessment Section of SRS Draft July 9, 2015 July 9, 2015

1.1.2.2.13

Complete Future Items Section of SRS Draft July 9, 2015 July 9, 2015

1.1.2.2.1 Compile SRS Draft Sections Together July 9, 2015 July 9, 2015



4

1.1.2.2.15

Review Final Draft of SRS July 10, 2015 July 10, 2015

1.1.3 System Architecture July 20, 2015 July 28, 2015

1.1.3.1 Initial ADS Draft July 20, 2015 July 24, 2015

1.1.3.2 Complete General Section of ADS Draft July 20, 2015 July 24, 2015

1.1.3.3 Complete Introduction Section of ADS Draft July 20, 2015 July 24, 2015

1.1.3.4 Complete Meta Architecture Section of ADS Draft July 20, 2015 July 24, 2015

1.1.3.5 Complete Layer Definition Section, Section of ADS Draft July 20, 2015 July 24, 2015

1.1.3.6 Complete Inter-Subsystem Data Flow Section, Section of ADS Draft

July 20, 2015 July 24, 2015

1.1.3.7 Complete Subsystem Descriptions Section, Section of ADS Draft

July 20, 2015 July 24, 2015

1.1.3.8 Complete Operating System Dependencies Section, Section of ADS Draft

July 20, 2015 July 24, 2015

1.1.3.9 Complete Testing Considerations Section, Section of ADS Draft

July 20, 2015 July 24, 2015

1.1.3.10 Compile ADS Draft Sections Together July 27, 2015 July 27, 2015

1.1.3.11 Review Final Draft of ADS July 28, 2015 July 28, 2015

1.1.4 Weekly Tasks June 9, 2015 August 17, 2015

1.1.4.1 Teem Meeting Agenda June 9, 2015 August 12, 2015

1.1.4.1.1 Team Meeting Agenda 1 June 24, 2015 June 24, 2015

1.1.4.1.2 Team Meeting Agenda 2 July 1, 2015 July 1, 2015







1.1.4.1.7 Team Meeting Agenda 7 August 5, 2015 August 5, 2015

1.1.4.1.8 Team Meeting Agenda 8 August 12, 2015 August 12, 2015

1.1.4.1.9 Team Meeting Agenda 9 June 9, 2015 June 9, 2015

1.1.4.1.10

Team Meeting Agenda 10 June 9, 2015 June 9, 2015

1.1.4.2 Team Meeting June 24, 2015 August 17, 2015

1.1.4.2.1 Team Meeting 1 June 24, 2015 June 24, 2015

1.1.4.2.2 Team Meeting 2 July 1, 2015 July 1, 2015





1.1.4.2.7 Team Meeting 7 August 5, 2015 August 5, 2015



1.1.4.2.10

Team Meeting 10 August 17, 2015 August 17, 2015

1.1.4.3 Weekly Meeting Minutes June 9, 2015 August 12, 2015

1.1.4.3.1 Weekly Meeting Minutes 1 June 24, 2015 June 24, 2015



1.1.4.3.2 Weekly Meeting Minutes 2 July 1, 2015 July 1, 2015





1.1.4.3.7 Weekly Meeting Minutes 7 August 5, 2015 August 5, 2015

1.1.4.3.8 Weekly Meeting Minutes 8 August 12, 2015 August 12, 2015

1.1.4.3.9 Weekly Meeting Minutes 9 June 9, 2015 June 9, 2015

1.1.4.3.10

Weekly Meeting Minutes 10 June 9, 2015 June 9, 2015

1.1.4.4 Status Reports/ Friday Deliverables June 24, 2015 August 5, 2015

1.1.4.4.1 Team Status Report 1 June 24, 2015 June 24, 2015

1.1.4.4.2 Team Status Report 2 July 1, 2015 July 1, 2015



1.1.4.4.5 Team Status Report 5 August 5, 2015 August 5, 2015

1.1.4.5 Status Report Presentation June 26, 2015 August 7, 2015

1.1.4.5.1 Status Report Presentation 1 June 26, 2015 June 26, 2015

1.1.4.5.2 Status Report Presentation 2 July 3, 2015 July 3, 2015



1.1.4.5.5 Status Report Presentation 5 August 7, 2015 August 7, 2015



1.1.4.6 Meeting with Dr. Mariottini June 24, 2015 July 6, 2015 9:00 AM

1.1.4.6.1 Meeting with Dr. Mariottini 1 June 24, 2015 June 24, 2015 9:00 AM

1.1.4.6.2 Meeting with Dr. Mariottini 2 June 29, 2015 June 29, 2015 9:00 AM

1.1.4.6.3 Meeting with Dr. Mariottini 3 July 6, 2015 July 6, 2015 9:00 AM

1.1.4.7 Holiday Break Meetings June 9, 2015 June 9, 2015

1.1.4.7.1 <New Task>

1.2 Project Planning June 9, 2015 June 26, 2015

1.2.1 Individual Schedules June 9, 2015 June 9, 2015 9:00 AM

1.2.2 Project Schedule June 22, 2015 June 26, 2015

1.2.3 MS Project June 22, 2015 June 26, 2015

1.3 Phase 2 August 18, 2015 November 10, 2015

1.3.1 Design August 18, 2015 September 14, 2015

1.3.2 Implementation September 15, 2015

October 12, 2015

1.3.3 Testing October 13, 2015 November 9, 2015

1.3.4 Demonstration November 9, 2015

November 10, 2015



7 Quality Management Plan

7.1 Introduction

The purpose of a quality management plan is to develop an effective method for maintaining standards for all aspects of this project. Among other set of documents a well-crafted system requirement specification document in key to keep the project streamlined. It will comprise of the requirements we receive from our customers (Dr. Mariottini, Kinesiology Department and JPS Hospital) and what we, as developers, deem to be appropriate.

7.2 Documentation

All the documentation and minutes from meetings are well organized into separate folders per topic or deliverable in a shared Google Drive repository. Each folder has two subfolders, namely “Compiled” and “Working”. Each team member is designated sections from the actual document which they can edit on Google Docs in real time. This way each member can conform to a common format set by the document master for the purpose of making the compilation as smooth as possible. An internal deadline for each document is set before a collective team meeting is held to critique on the produced draft. Should there be a need to make any changes the document master will update the document and post it inside the Compiled folder.

7.3 Software

Our team in going to adhere to well established principles of software design and development. In order to keep are application focused we will be creating a chart of features and requirements, requirements being on the x-axis while features on the y-axis. Where ever most intersections take place with corresponding requirements, that feature will be implemented into the application. We will also be employing various software testing techniques so as to eliminate any margin of error.

7.4 Testing

To elaborate on testing techniques, as individual parts completed with an integrated we will be performing Integration testing. This will ensure that the two modules are compatible and congruent. This will be performed after each new module is added to the base product. Once we have an initial system ready we shall perform white box testing on the system to ensure everything performs smoothly. During this time designers of all individuals modules will look for any anomalies under their sections. If so, that anomaly will be tackled as a group and that particular module will undergo another Integration test,



followed by white box test. After the initial systems is ready, additional features will be added to the system and a final Unit test will be performed before presenting the application to the sponsor.



8 Communications Plan

8.1 Introduction

We all established earlier that communication will be an integral part of this project. An effective plan of communication is essential to keep all aspects of the project in order, otherwise everything would be in disarray. Our plan has been made a standard to be followed by all team members. We have also tried to establish an emergency mode of contact incase the university has be closed.

8.2 Internal communication

8.2.1 Team meetings

Weekly Team meetings, which include implementation and completion of tasks due for the week. Apart from that, preparing and planning for meetings with the sponsor and professor as well as assigning individual tasks. Impromptu meetings (especially in order to prevent unnecessary delays. Allowing some flexibility when needed (and which is not detrimental to the project). All in all this fosters an environment that is conducive to communicating.

8.2.2 Scrum meetings

Employing project status, and scrum meetings for 15 minutes after each senior design class. In these meetings we discuss what we have been doing for the tasks that have been assigned to us. A team member can enlighten others with some extra research they have been doing regarding something that might be useful but had not been talked about during our weekly meetings. Furthermore, in the last few minutes we discuss if we have any questions, concerns or announcements that we have.

8.2.3 Whatsapp and Skype

We employ agreed-upon methods of communication, such as email, where we have shared our student emails as well as a secondary email address. Skype accounts have been setup for virtual meetings in case of emergencies where the university has to be closed down. Group chat has been established on Whatsapp for instant messaging and updates. This is an application that is quite useful for instant updates to all group members. It allows voice messages and picture messages should an opinion is needed which is also time sensitive. The messages are kept relevant, concise and simple so as to avoid confusion among team members.



8.2.4 Google Drive and GitHub

We use Google Drive to upload documentary material related to the project for team members so that they can view and modify/update as per the situation. Furthermore, a GitHub account has been created that will contain all the code that has been written and similar to Google Drive any team member can view/update the code without having multiple different files leading to confusion.

8.3 External communication

8.3.1 Meetings with project mentor (Dr. McMurrough)

We have decided to have short meetings with Dr. McMurrough, our project mentor, in case we are unclear as to how to tackle a situation. Furthermore, since we have a sponsor, Dr. Mariottini, who also provides us with requirements pertaining to the project, it is beneficial to converse with our mentor so we can steer ourselves towards the correct course of action.

8.3.2 Meetings with project sponsor (Dr. Mariottini)

We hold weekly meetings with the sponsor on Monday, to discuss the current situation of the project. Update him with the progress made and discuss the future plans for the project. Also get a much better understanding of what he wants us to do regarding the application and whether or not a proposed feature is necessary to be embedded.

8.3.3 Weekly status reports

Hold weekly presentations for the class, so that everyone is aware as to what we are currently working on, steps that have been taken to accomplish the tasks at hand, as well as to inform them of the future plans and scope.



9 Change Management Plan

9.1 Purpose of Integrated Change Management Plan

The purpose of the Integrated Change Management plan is determined what shall happen in an event where a major change must occur. This plan is not to outline when a dynamic change shall happen, but more of what minimally shall happen in a major change. Furthermore, we plan to define all processes, tools, review bodies, and authority necessary to monitor and control project performance, identified change and the potential impact of change on project objectives.

9.1.1 Processes

Identification of Change Change Management Approval of Change

9.1.2 Tools

MS Project GitHub IDE Server Database

9.1.3 Authority to monitor and control project performance

Project Mentor – Dr. McMurrough Project Sponsor – Dr. Mariottini Project Manager – Kevin Kocian

9.1.4 Expected change

Architecture Design Physicians wants and needs

9.1.5 Potential impacts

Wasted work and time Converting code




Project Sponsor – Shall meet with Project Manager and Project Team. Shall review Project Teams progress.

Project Manager - Shall halt all progress in working. Shall plan emergency meeting with Project Sponsor, Course Professor, and Project Team. Shall be main person responsible for communicate with Project Team.

Project Team – Shall meet with Project Manager and Project Sponsor. Project Team shall continue working in anyway where the change will not be an issue of confliction.

Project Mentor - Shall be readily available to help in any decision making progress.

9.3 Review and Approval Process

9.3.1 Identification of Change

Be brought up to members immediately If needed

i. Emergency meeting shall take place

Team manager notifies sponsor and stakeholders

9.3.2 Change Management

Change in Project Scope: i. Shall be determine by Project Sponsor and Project Manager

Change in Cost: i. Shall be determined by Project Sponsor and Project Manager.

Change in Budget: i. Shall be determined by Project Sponsor and Project Manager.

Review boards: i. Project Team.

Change Approval Authorities: Project Sponsor, Project Manager, Project Mentor.

9.3.3 Approval of Change

Project Team meets with Project Sponsori. Project Team and Project Sponsor create a list of options for change ideas

Project Team makes majority vote on options Team Sponsor and/or Team Manager can request to override the vote

i. Once request is made, the Project Team shall discussion the overridden vote

ii. If any member in the Project Team doesn’t not agree with the decision1. Project Team will meet with Project Mentor2. Project Mentor will determine what change shall be made

a. Project Mentor decision is final and must be followb. Change immediately takes effect.



9.4 Change Identification, Documentation, Implementation and Reporting

MS Project – shall be adjusted by Team Lead Earn Value – Shall be adjusted by Team Lead Communication- Shall be done by Team.



10 Procurement Management Plan

10.1 Purpose of the Procurement Management Plan

The Procurement Management Plan will ensure that all necessary tools, services, and components are available at appropriate times based on the project schedule. The plan will also provide a procedure to follow to ensure the team, and sponsor are in agreement that procurement of the product or service is necessary and worthwhile.


Title Role/Identification

Project Sponsor Approves procurement list before it is submitted.

Project Manager Communicates to Project Sponsor and to Project Team

Project Team Communicates to Project Manager

Project Stakeholders Dr. Mariottini

Project Mentor Dr. McMurrough

10.3 Required Project Procurements and Timing

Product / Service

Description

Server Hosting

Necessary for the implementation of the backend services for the interface.

Analysis:● Server Hosting: Approximately $50 / month for dedicated server hosting.

May also use a service that charges based on use, for this the charge is estimated at $0.008 / gigabyte. Developing the infrastructure for a dedicated server will also drastically decrease the amount of man hours that could have been spent to further the quality of the interface itself.



Planned procurements only include materials that will be necessary for the implementation of the interface system, as such procurements must be completed before Phase 2 begins. Procurement of services may wait until the completion of Phase 1.

10.4 Description of Items/ Services to be acquired

The scope of the project includes developing an interface to the iGait software that will user friendly for a physician to view relevant data on their patients whose gait is being recorded. Under this scope we are to develop an android application.

Major Deliverables

iGait Interface - Android


Documents

Project Charter Final