ETA Systems Process ETASP Process Documentation. Revision 1.0

(1)

12/14/2017

ETA Systems Process – ETASP

Process Documentation

Revision 1.0

(2)

ETA Systems Process – Process Documentation

Revision: 1.0

12/14/2017 Page: 2 of 10

ETA Systems Process – Process Documentation

Revision: 1.0

12/14/2017 Page: 3 of 10

ETA Systems Process – ETASP Purpose

The systems process is utilized by the project managers and the PMO at ETA Advertising agency.

The purpose is to define requirements and guidelines used on client projects.

The Eve shared space is where all project documentation is stored: \\EVE\Data

The Templates folders contains all the document templates: \\EVE\Data\ETA-SP\templates The Projects are maintained in their client folders: \\EVE\Data\ETA - Clients\Clients - CURRENT

When a new ETASP project is started a client folder is created, and all appropriate templates are copied from the templates folder to the new client folder. Document “1.0-Checklist” contains the list of documents the PMO has assigned for the PM to create and maintain for the project.

Definitions

Project Management (PM) – The discovery, architecture, design, development, and launch of project activities to meet client project objectives (ETASP).

ETA Systems Process (ETASP) – consists of the information gathered, documentation created and managed, by both the creative team and project manager, working for the project management office.

Project Team – consists of the project manager and the program manager, composing the project management office, working on ETA client projects.

Creative Team – consists of the creative designers and developers, working on ETA client projects.

Project – A project is a set of organized activities defined in phases and sprints, created by the creative team, and managed by the project team, in the ETA Systems Process.

Creative Team members

Designers include Niko. Developers include Josh.

Project Team members

Project Managers are AJ, and other PMs.

Project Management Office

The Project Management Office (PMO) is composed of the Vice President - Cassandra.

(4)

ETA Systems Process – Process Documentation

Revision: 1.0

12/14/2017 Page: 4 of 10

Process

The ETA process is composed of 5 phases, with many documents, and their activities.

• Discovery – Request for Proposal, Bid Response, Kick-Off, Requirements, Project Charter

• Architecture – Creative Brief, Site Map and Flows

• Design – Design Options and client Selection

• Development – Planning, Scheduling, Development (Agile/Scrum-Sprints)

• Launch – Hosting, Launch, Training, Closure

Discovery - I Architecture - II Design - III Development - IV Launch - V

Proposal-RFP 1.1 client request for bids Scope, Requirements

Creative Brief 2.1 Requirements, Scope, Milestones-Gantt

Design Options 3.1 wireframe options

SOW 4.1

Create Statement of Work

Host 5.1 setup servers

Response-Bid 1.2 vendor responses

Site Map 2.2 diagram site map Adobe-InDesgn/InVision

Select Option 3.2 client selection

Plan 4.2

creative schedule

Launch 5.2 release servers

Selection Vendor 1.3 decision/award

Site Flows 2.3 UX flows

Schedule 4.3 Agile(Scrum) create Backlog

Train 5.3 training and documentation Kick-Off 1.4

meeting client & vendor review Scope, create Communication Plan

Sprints (1-n) 4.4 Sprints/Scrums from Backlog, with k-os and l-ls.

SLA 5.4 Service Level some from RFP

Requirements-BRD 1.5 gather Requirements, refine Scope

Sign-off 5.5 formal accept

Project Charter-PC 1.6 collect all discovery docs Customer approved.

Close 5.6 lessons learned Proj Man Plan-PMP 1.7

created from the PC, plus ETA only info.

Project Initiation is done by the PMO assigning a PM, with the “1.0-Checklist” file being filled out.

The PM will copy all assigned documents from the template-folder to the client-folder.

1.0-Checklist

(5)

ETA Systems Process – Process Documentation

Revision: 1.0

12/14/2017 Page: 5 of 10

1.0 Discovery

1.1 Request for Proposal – RFP

A Request for Proposal is received by the PMO from a potential ETA client. The RFP should include an initial scope, and high-level requirements.

1.2 Response – Bid

A bid is submitted in response, from the PMO to the client. The response is drafted by the PMO, and may include input from the creative team and an assigned project manager.

1.3 Selection – Award

A selection of a chosen bid from the list of vendors is made, based upon client criteria, and the award is made to the vendor (ETA).

1.4 Meeting – Kick-off

A meeting with the client and ETA is held, to kick-off the awarding of the project. A communication plan is drafted during the meeting including all stakeholders, client contacts, ETA creative and project team members. The scope is further refined and agreed upon. High-level requirements are reviewed and further clarified.

1.5 Requirements – BRD

Detailed requirements are collected in follow up communications between the client and the ETA project team.

1.6 Project Charter – PC

A Project Charter is created by the project manager working with the PMO. The PC contains the finalized-scope, the communication plan, and the detailed requirements, all previously created after the kick-off. The PC is a client approved document, replacing the RFP-Response with this updated project outline. The PC is the baseline for the PMP.

(external)

1.7 Project Management Plan – PMP

A Project Management Plan is created based upon the Project Charter, which has been

approved by the client. The PMP includes more information and detail about the project,

and is not shared with the client. The PMP is updated throughout the project. (internal-

only)

(6)

ETA Systems Process – Process Documentation

Revision: 1.0

12/14/2017 Page: 6 of 10

2.0 Architecture

2.1 Creative Brief

A creative brief is sent to the client, from the assigned project manager. The brief contains the communication plan, and the refined scope from the kick-off meeting. It also contains the high-level requirements that were gathered after the meeting.

2.2 Site Map

A proposed site map is sent to the client, from the creative team. The maps are usually done in Adobe-InDesign currently, but may be done with InVision in the future.

2.3 Site Flows

A proposed site flow is sent to the client, from the creative team. The flows are usually

presented in a UX design.

(7)

ETA Systems Process – Process Documentation

Revision: 1.0

12/14/2017 Page: 7 of 10

3.0 Design

3.1 Design Options

A set of design options is sent to the client, from the creative team. The options include wireframes and other design choices.

3.2 Selection of Option

A final selection of the chosen option is received from the client, for the creative team.

(8)

ETA Systems Process – Process Documentation

Revision: 1.0

12/14/2017 Page: 8 of 10

4.0 Development

4.1 Statement of Work - SOW

A Statement of Work is created by the project manager working with the PMO. The SOW will contain all the background from the Project Charter, and a preliminary Timeline, including a Gantt-Chart, for formal client acceptance.

4.2 Planning

Planning is started by the development team, based upon the chosen option received from the client.

4.3 Schedule - Backlog

Scheduling is started by the project team, based upon the plans supplied by the development team. The project manager works with the PMO on allocating the needed resources. Schedules are currently created in Agile (Scrum) - Iterative approach.

The Software tool being implemented is Trello https://trello.com/b/bAEUIgQo

4.4 Sprints (1-n)

Development is tracked and managed in short iterative sprints, and many deliveries are made to the client for review, throughout the project. Lower risks of missed expectations and less potential for wasted time occur with early and regular feedback from the client.

A Sprint is started/kicked-off with building the tasks/stories/features that will go into the

sprint, and may involve client approval. A Sprint is finished with a review of the completed

tasks/stories/features of the Sprint. The client should be involved in a formal

review/acceptance of the Sprint. A ETA mini-lessons learned should be conducted at the

end of each Sprint, documenting good and bad experiences from the development team,

to be used to improve future Sprints. The Backlog list, and the Burndown chart, and any

other metrics, should be updated at the conclusion. Productivity should also be tracked

for each Sprint, and an increase in efficiency should progress with each new Sprint.

(9)

ETA Systems Process – Process Documentation

Revision: 1.0

12/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.

(10)

ETA Systems Process – Process Documentation

Revision: 1.0

12/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$

(11)

Project Name: ETASP (Systems Process) Client: ETA Agency

PM: Gary Neshanian

Task

Documentation

PMO Assigned

PM Completed

PMO Approved

1.0-Checklist X 12/12/2017 X

Discovery I

1.1-RFP 1.2-Bid 1.3-Selection 1.4-KO 1.5-BRD 1.6-PC

Architecture II

2.1-Creative Brief 2.2-Site Map 2.3-Site Flows

Design III

3.1-Design Options 3.2-Client Selections

Development IV

4.1-SOW

4.2-Plan Creative 4.3-Schedule (Backlog) 4.4-Sprints (1-n)

Launch V

5.1-Hosting (docs) 5.1-Launch (docs) 5.2-Training (docs) 5.3-Sign Off (doc)

5.4-Lessons Learned (doc)

(12)

12/13/2017

a

ETA Systems Process Project Charter

Last Updated: Dec 13, 2017 Author: Gary Neshanian/AJ

Owner: Cassandra Popli

(13)

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)

(14)

3

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

(15)

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.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.

(16)

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.

(17)

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

(18)

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.

(19)

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.

(20)

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.

(21)

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:

(22)

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.

.

(23)

12/13/2017

ETA Systems Process Statement of Work

Last Updated: Dec 13, 2017 Author: Gary Neshanian/AJ

Owner: Cassandra Popli

(24)

2

marked

n.n Month dd, year Identify changes. Y or N

Approvals

(name) (title)

Distribution

Name Title

(name) (title)

(25)

3

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...

(27)

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.

(28)

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:

(29)

12/13/2017

ETA Systems Process Service Level Agreement

Last Updated: Dec 13, 2017 Author: Gary Neshanian/AJ

Owner: Cassandra Popli

(30)

2

marked

n.n Month dd, year Identify changes. Y or N

Approvals

(name) (title)

Distribution

Name Title

(name) (title)

(31)

3

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.

(33)

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:

ETA Systems Process ETASP Process Documentation. Revision 1.0