ETA Systems Process – Process Documentation
Revision: 1.012/14/2017 Page: 9 of 10
5.0 Launch
5.1 Host
Setup of hosting servers for the client project, by the creative team.
5.2 Launch
Release of the developed project onto the client hosting server, by the creative team.
5.3 Train
Training and knowledge transfer, of any skills and documentation supporting the client project, are provided by the creative team.
5.4 Service Level Agreement – SLA
Agreement of Services to be provided after project completion by ETA for Client. Hosting of website or other services, including uptimes, issue reporting and their expected Levels.
5.5 Sign-off
Final sign-off, signifying the formal acceptance, is obtained from the client by the ETA project team.
5.6 Closing
Lessons learned and all other valuable information are collected and archived, by the project team.
ETA Systems Process – Process Documentation
Revision: 1.012/14/2017 Page: 10 of 10
References
Adobe-InDesign - http://www.adobe.com/products/indesign.html InVision - https://www.invisionapp.com
Workamajig - https://www.workamajig.com
Trello (Agile - board) - https://trello.com/login
Corrello (Metrics - reporting, burndown, performance) - https://getcorrello.com
[email protected] $famous$
Project Name: ETASP (Systems Process)
1.0-Checklist X 12/12/2017 X
Discovery I
12/13/2017
a
ETA Systems Process Project Charter
Last Updated: Dec 13, 2017 Author: Gary Neshanian/AJ
Owner: Cassandra Popli
ETASP-PC: Project Charter
Date Printed: December 19, 2017
2
Revision History
Date of this revision: Month dd, year Date of Next revision: As needed
Revision Number
Revision date Summary of Changes Changes
marked
Initial Dec 11, 2017 Initial draft Y or N
n.n Month dd, year Identify changes. Y or N
Approvals
This document requires the following approvals.
Name/Signature Title
Cassandra Popli Vice President, PMO – ETA Agency Customer Stakeholder, Client – Customer
(name) (title)
Distribution
This document has been distributed to
Name Title
Cassandra Popli Vice President, PMO – ETA Agency
Gary Neshanian/AJ Gary Neshanian/AJ, Project Manager – ETA Agency Customers Stakeholder, Client – Customer
Somebody Long Beach Transit
(name) (title)
ETASP-PC: Project Charter
Date Printed: December 19, 2017
3
Table of Contents
1. PROJECT SUMMARY ... 4
1.1 BUSINESS AREA ... 4
1.2 REQUEST DESCRIPTION... 4
1.3 REQUIRED DATE ... 4
1.4 BUSINESS OBJECTIVE(S) ... 4
1.5 PROJECT SCOPE ... 4
1.6 PROJECT OUT OF SCOPE ... 4
1.7 PROJECT MILESTONES ... 4
1.8 BENEFITS ... 4
1.9 ASSUMPTIONS ... 5
1.10 RISKS ... 5
1.11 DEPENDENCIES ... 5
1.12 STAKEHOLDERS ... 5
2. REQUIREMENTS ... 6
3. COMMUNICATION PLAN ... 7
3.1 ETA ROLES ... 7
3.2 CLIENT ROLES ... 7
3.3 PROJECT REPORTING ... 7
4. STATEMENT OF WORK ... ERROR! BOOKMARK NOT DEFINED. 4.1 LOCATION OF WORK ... ERROR! BOOKMARK NOT DEFINED. 4.2 DELIVERABLES ... ERROR! BOOKMARK NOT DEFINED. 4.3 PERIOD OF WORK ... ERROR! BOOKMARK NOT DEFINED. 4.4 GANTT CHART ... ERROR! BOOKMARK NOT DEFINED. 4.5 ACCEPTANCE ... ERROR! BOOKMARK NOT DEFINED. 5. ACCEPTANCE CRITERIA ... 9
6. REQUIREMENTS APPROVAL ... 10
7. CHANGE MANAGEMENT ... 11
ETASP-PC: Project Charter
Date Printed: December 19, 2017
4
1. Project Summary
1.1 Business Area
CLIENT Company - CLIENT Department.
1.2 Request Description
The CLIENT Project - Description (the “Project”) is being undertaken by ETA on behalf of CLIENT Company.
This initiative is being undertaken for the CLIENT’s department, complying with policies and industry best practices.
1.3 Required Date
Target date from RFP.
1.4 Business Objective(s)
PROJECT will deliver a solution to CLIENT’s problem.
PROJECT will provide a...
Currently the CLIENT ...
1.5 Project Scope
PROJECT, taken from RFP. Things you are committing to based on communications/kick-off so far.
1 Feature 2 Function 3 RFP
1.6 Project Out of Scope
Things you may have talked about, or options/features, that will not be done in this PROJECT.
1 Feature 2 Function 3 RFP
1.7 Project Milestones
PROJECT, taken from RFP…
1 Start 2 Develop 3 Complete
1.8 Benefits
PROJECT will benefits taken from RFP. Your sales pitch for this PROJECT.
ETASP-PC: Project Charter
Date Printed: December 19, 2017
5 PROJECT more details...
1.9 Assumptions
Phased Rollout Approach
• Phase 1 – Discovery.
• Phase 2 – Architecture.
• Phase 3 – Design.
• Phase 4 – Development.
• Phase 5 – Launch.
PROJECT will follow the ETASP Systems Process methodology. You are making the assumption that you are using your own development methodology, but you want to make that clear to the CLIENT, and anything else you are assuming.
Phase 4 – Development will be scheduled in an Agile (Scrum) iterative release format.
1.10 Risks
Budget
• ETA has made every attempt to - appropriate legal disclaimers
• Cost Restrictions or Fixed Bid limitations examples Business
• None – Cost Restrictions or Fixed Bid limitations example Schedule
• None – Waiting for CLIENT materials that have not yet been delivered example Resource
• None – Understaffed CLIENT example Technology
• None – Critical Paths example
Also any Critical Paths seen in the PROJECT. These can be things that are out of ETA’s control.
Something like waiting for a vehicle tracking system to come from the CLIENT that has not yet been built or purchased, but will go into a future release of a website.
1.11 Dependencies
Budgets or other dependencies.
1.12 Stakeholders
Taken from RFP and Kick-off.
ETASP-PC: Project Charter
Date Printed: December 19, 2017
6
2. Requirements
Requirements are taken from RFP, and follow up communications after Kick-off. Requirements are documented by Business Systems Analysts or even Subject Matter Experts on very complex projects. A Business Requirements Document (BRD) is a standard on more complex projects.
1 Requirement 1
• details 2 Requirement 2
• Details
ETASP-PC: Project Charter
Date Printed: December 19, 2017
7
3. Communication Plan
Explains what will happen, when, and how people will be told.
3.1 ETA Roles
Program Manager
Project Management
Business Requirements
Overall coordination and Project delivery Project Manager
Manage Project Plan
Technical Design reviews
Periodic Project update, Deliver to milestones Implementation Partner
Deliver final solution
Share Best Industry practices
Subject Matter Expert / Governance, Risk & Compliance
Technical Design review
Milestone and Stage gate reviews
Review/Update/Develop policy
3.2 Client Roles
Business Owner
Provides process guidelines
Reviews application for process acceptance Business Project Manager
Business Project Management
User Acceptance Testing Subject Matter Expert
Provides process guidelines
Reviews app for process acceptance
3.3 Project Reporting
Define communications and reports, their frequency, and the distribution list for each.
Also define review and acceptance process.
ETASP-PC: Project Charter
Date Printed: December 19, 2017
8
3.4 RACI
Responsibility Accountability Consulted Informed (RACI) chart, assigns one four levels to individuals for their roles on the project. The RACI model clearly lays out roles and responsibilities for any activity or group of activities. A very technical tool used in the most complicated projects, but a term you might hear.
Example below.
Job functions or titles are noted across the top, such as “IT,” “Human Resources,” “Project Manager,” etc.
Tasks or responsibilities are noted down the left hand side, such as “Conduct weekly communication meeting with sales team,” or “Analyze prior-month performance and send out summary the first week of each month.”
The cells inside the RACI model or chart are filled in based on the following criteria –
◾R = Responsible = The person who performs the work. There must be one “R” on every row, no more and no less. “R” is the only letter that must appear in each row.
◾A = Accountable = The person ultimately accountable for the work or decision being made. Use this letter where appropriate, but not to excess – only when a key decision or task is at hand. There can be from zero to one “A’s” in each row, but no more than one.
◾C = Consulted = Anyone who must be consulted with prior to a decision being made and/or the task being completed. There can be as many “C’s” as are appropriate in each row.
◾I = Informed = Anyone who must be informed when a decision is made or work is completed. There can be as many “I’s” as are appropriate in each row.
ETASP-PC: Project Charter
Date Printed: December 19, 2017
9
4. Acceptance Criteria
An acceptance management process will be implemented by which Deliverables produced by the Project teams are formally reviewed by the CLIENT stakeholders ensuring the following:
All required documents have been completed, including any user training manuals.
All documents have been reviewed.
All documents have been approved.
All software has been adequately tested and accepted.
Deliverables will be distributed to the Project team members to review and provide feedback. Review meetings will be scheduled to discuss the comments and changes to be made prior to the publication of the final version. Once agreed-upon changes have been incorporated, acceptance and sign-off will be requested.
Acceptance of the Deliverables shall be determined in CLIENT’s reasonable discretion within a time frame as reasonably determined by CLIENT.
ETASP-PC: Project Charter
Date Printed: December 19, 2017
10
5. Requirements Approval
This document accurately reflects the requirements described herein and the proposed solution to be applied. The undersigned hereby agrees with the content of this report and authorizes the system changes to be made, tested and implemented.
______________________
Name Date:
________________
Name Date:
ETASP-PC: Project Charter
Date Printed: December 19, 2017
11
6. Change Management
Once this document is signed, the Change Management process must be followed. All changes following sign-off will require a change management form and approval from appropriate parties.
All changes introduced will cause the project plan to be re-estimated and end dates re-established.
.
12/13/2017
ETA Systems Process Statement of Work
Last Updated: Dec 13, 2017 Author: Gary Neshanian/AJ
Owner: Cassandra Popli
ETASP-PC: Project Charter
Date Printed: December 19, 2017
2
Revision History
Date of this revision: Month dd, year Date of Next revision: As needed
Revision Number
Revision date Summary of Changes Changes
marked
Initial Dec 11, 2017 Initial draft Y or N
n.n Month dd, year Identify changes. Y or N
Approvals
This document requires the following approvals.
Name/Signature Title
Cassandra Popli Vice President, PMO – ETA Agency Customer Stakeholder, Client – Customer
(name) (title)
Distribution
This document has been distributed to
Name Title
Cassandra Popli Vice President, PMO – ETA Agency
Gary Neshanian/AJ Gary Neshanian/AJ, Project Manager – ETA Agency Customers Stakeholder, Client – Customer
Somebody Long Beach Transit
(name) (title)
ETASP-PC: Project Charter
Date Printed: December 19, 2017
3
Table of Contents
1. PROJECT SUMMARY ... 4 1.1 BUSINESS AREA ... ERROR! BOOKMARK NOT DEFINED.
1.2 REQUEST DESCRIPTION... ERROR! BOOKMARK NOT DEFINED.
1.3 REQUIRED DATE ... ERROR! BOOKMARK NOT DEFINED.
1.4 BUSINESS OBJECTIVE(S) ... ERROR! BOOKMARK NOT DEFINED.
1.5 PROJECT SCOPE ... 4 1.6 PROJECT OUT OF SCOPE ... ERROR! BOOKMARK NOT DEFINED.
1.7 PROJECT MILESTONES ... ERROR! BOOKMARK NOT DEFINED.
1.8 BENEFITS ... ERROR! BOOKMARK NOT DEFINED.
1.9 ASSUMPTIONS ... ERROR! BOOKMARK NOT DEFINED.
1.10 RISKS ... ERROR! BOOKMARK NOT DEFINED.
1.11 DEPENDENCIES ... ERROR! BOOKMARK NOT DEFINED.
1.12 STAKEHOLDERS ... ERROR! BOOKMARK NOT DEFINED.
2. REQUIREMENTS ... ERROR! BOOKMARK NOT DEFINED.
3. COMMUNICATION PLAN ... ERROR! BOOKMARK NOT DEFINED.
3.1 ETA ROLES ... ERROR! BOOKMARK NOT DEFINED.
3.2 CLIENT ROLES ... ERROR! BOOKMARK NOT DEFINED.
3.3 PROJECT REPORTING ... ERROR! BOOKMARK NOT DEFINED.
4. STATEMENT OF WORK ... 5 4.1 LOCATION OF WORK ... ERROR! BOOKMARK NOT DEFINED.
4.2 DELIVERABLES ... ERROR! BOOKMARK NOT DEFINED.
4.3 PERIOD OF WORK ... ERROR! BOOKMARK NOT DEFINED.
4.4 GANTT CHART ... ERROR! BOOKMARK NOT DEFINED.
4.5 ACCEPTANCE ... ERROR! BOOKMARK NOT DEFINED.
5. ACCEPTANCE CRITERIA ... ERROR! BOOKMARK NOT DEFINED.
6. REQUIREMENTS APPROVAL ... 6
7. CHANGE MANAGEMENT ... ERROR! BOOKMARK NOT DEFINED.
ETASP-PC: Project Charter
Date Printed: December 19, 2017
4
1. Purpose
A statement of work (SOW) is a document routinely employed in the field of project management. It defines project-specific activities, deliverables and timelines for a vendor providing services to the client.
The SOW typically also includes detailed requirements and pricing, with standard regulatory and governance terms and conditions. It is often an important accompaniment to a request for proposal (RFP).
1.1 Project Scope
PROJECT, taken from Request for Proposal-RFP and Project Charter-PC...
1 Feature 2 Function 3 RFP
ETASP-PC: Project Charter
Date Printed: December 19, 2017
5
2. Location of Work
ETA locations and personnel
CLIENT locations and personnel
3. Period of Work
Milestones and other previously agreed/committed dates
Phases
Discovery: Start Date, RFP, Award, Kick-off.
Architecture: Creative Brief, Site Map and Flows
Design: Design Options and Selection.
Development: Phases/Sprints
Detail Phase/Sprint releases the customer should expect
Launch: Hosting, Training, Sign-Off, Target Completion Date
Sprint/Releases
4. Resources
ETA will furnish,
CLIENT will furnish
5. Deliverables Schedule
CLIENT Releases/Sprints, Website, Training/Support Documentation…
6. Gantt Chart
ETA Timeline including: Discovery, Architecture, Design, Development, Launch.
7. Acceptance
How CLIENT of PROJECT will determine if the product or service is acceptable, usually with objective criteria. May reference any external Acceptance Testing documentation.
8. Payment Schedule
Type of Contract/Payment Schedule: The project acceptance will depend on if the budget available will be enough to cover the work required. Therefore a breakdown of payments by whether they are up-front or phased will usually be negotiated in an early stage.
ETASP-PC: Project Charter
Date Printed: December 19, 2017
6
9. Requirements Approval
This document accurately reflects the requirements described herein and the proposed solution to be applied. The undersigned hereby agrees with the content of this report and authorizes the system changes to be made, tested and implemented.
______________________
Name Date:
________________
Name Date:
12/13/2017
ETA Systems Process Service Level Agreement
Last Updated: Dec 13, 2017 Author: Gary Neshanian/AJ
Owner: Cassandra Popli
ETASP-PC: Project Charter
Date Printed: December 19, 2017
2
Revision History
Date of this revision: Month dd, year Date of Next revision: As needed
Revision Number
Revision date Summary of Changes Changes
marked
Initial Dec 11, 2017 Initial draft Y or N
n.n Month dd, year Identify changes. Y or N
Approvals
This document requires the following approvals.
Name/Signature Title
Cassandra Popli Vice President, PMO – ETA Agency Customer Stakeholder, Client – Customer
(name) (title)
Distribution
This document has been distributed to
Name Title
Cassandra Popli Vice President, PMO – ETA Agency
Gary Neshanian/AJ Gary Neshanian/AJ, Project Manager – ETA Agency Customers Stakeholder, Client – Customer
Somebody Long Beach Transit
(name) (title)
ETASP-PC: Project Charter
Date Printed: December 19, 2017
3
Table of Contents
1. PROJECT SUMMARY ... 4 1.1 BUSINESS AREA ... ERROR! BOOKMARK NOT DEFINED.
1.2 REQUEST DESCRIPTION... ERROR! BOOKMARK NOT DEFINED.
1.3 REQUIRED DATE ... ERROR! BOOKMARK NOT DEFINED.
1.4 BUSINESS OBJECTIVE(S) ... ERROR! BOOKMARK NOT DEFINED.
1.5 PROJECT SCOPE ... ERROR! BOOKMARK NOT DEFINED.
1.6 PROJECT OUT OF SCOPE ... ERROR! BOOKMARK NOT DEFINED.
1.7 PROJECT MILESTONES ... ERROR! BOOKMARK NOT DEFINED.
1.8 BENEFITS ... ERROR! BOOKMARK NOT DEFINED.
1.9 ASSUMPTIONS ... ERROR! BOOKMARK NOT DEFINED.
1.10 RISKS ... ERROR! BOOKMARK NOT DEFINED.
1.11 DEPENDENCIES ... ERROR! BOOKMARK NOT DEFINED.
1.12 STAKEHOLDERS ... ERROR! BOOKMARK NOT DEFINED.
2. REQUIREMENTS ... ERROR! BOOKMARK NOT DEFINED.
3. COMMUNICATION PLAN ... ERROR! BOOKMARK NOT DEFINED.
3.1 ETA ROLES ... ERROR! BOOKMARK NOT DEFINED.
3.2 CLIENT ROLES ... ERROR! BOOKMARK NOT DEFINED.
3.3 PROJECT REPORTING ... ERROR! BOOKMARK NOT DEFINED.
4. STATEMENT OF WORK ... 4 4.1 LOCATION OF WORK ... ERROR! BOOKMARK NOT DEFINED.
4.2 DELIVERABLES ... ERROR! BOOKMARK NOT DEFINED.
4.3 PERIOD OF WORK ... ERROR! BOOKMARK NOT DEFINED.
4.4 GANTT CHART ... ERROR! BOOKMARK NOT DEFINED.
4.5 ACCEPTANCE ... ERROR! BOOKMARK NOT DEFINED.
5. ACCEPTANCE CRITERIA ... ERROR! BOOKMARK NOT DEFINED.
6. REQUIREMENTS APPROVAL ... 5
7. CHANGE MANAGEMENT ... ERROR! BOOKMARK NOT DEFINED.
ETASP-PC: Project Charter
Date Printed: December 19, 2017
4
1. Overview
A service-level agreement (SLA) is defined as an official commitment that prevails between a service provider and a client. Particular aspects of the service – quality, availability, responsibilities – are agreed between the service provider and the service user. The most common component of SLA is that the services should be provided to the customer as agreed upon in the contract. It is often an important accompaniment to a request for proposal (RFP).
2. Type of Service
Web hosting
CLIENT support
3. Performance Level
Definition of acceptable
Uptimes: 5 day x 9hour, 7 day x 24 hour
Service/Maintenance periods
4. Monitoring
Realtime
Monthly Analytics
5. Issue
How to report issues, outages.
6. Response
Response time to issues.
7. Repercussions
Consequences to SLA failures.
ETASP-PC: Project Charter
Date Printed: December 19, 2017
5
8. Requirements Approval
This document accurately reflects the requirements described herein and the proposed solution to be applied. The undersigned hereby agrees with the content of this report and authorizes the system changes to be made, tested and implemented.
______________________
Name Date:
________________
Name Date: