Runner Project
Charter
1.
Problem Statement and Background
cineSHARE, ACORN and EAGL have each achieved tremendous success since its respective launches
and today are critical components of major digital media workflows supporting various SPE
business operations. However, cineSHARE, ACORN and EAGL are 9, 8 and 7 years old, respectively,
and in the fast-changing digital media technology landscape, these applications are inadequate in
functionality to meet customer demand. Additionally, as is common among aging systems, each
application has amassed a lot of technical debt impacting system reliability as well as the ability to
be responsive to new enhancement requests. New infrastructure technologies, such as Cloud
Computing, along with new development approaches, such as Agile Development, are ushering in a
new era of scalable, cost efficient, and reliable systems with modern web development
technologies.
As an example of slow responsiveness, the last major release of EAGL took 3.5 months from the
beginning of the QA phase until production launch. The bulk of the time was attributable to
manual regression testing and the corresponding bug fixes. The manual deployment process also
contributed to the slow release.
On the reliability front, last year the DMG development teams spent more time fixing bugs and
addressing production issues versus time spent on new development of features. This effort is
common across the three sometime functionally overlapping code bases of its three asset
management systems.
Additionally, with three separate applications and repositories, DMG must often replicate assets
across systems to support multiple workflows with increases infrastructure costs and, given system
reliability and scaling challenges, maintenance overhead.
As further background, the DMG team has been experimenting with agile methodologies for the
past few years. At first, Scrum was rolled out to the EAGL team and after more than a year of
following Scrum processes, it became evident that EAGL was not architected and implemented in a
way that aligned well with the vertical slices of functionality sought after in Scrum. What was
needed was Continuous Integration and ultimately Continuous Delivery – the ability to check-in
new code as it is finished and see immediately if that code breaks anything and that it can be
deployed instantly.
2.
Objectives
The goal of the Runner project is to build a new digital media platform and several web applications
(user experiences) to replace cineSHARE+, ACORN and EAGL while keeping in mind the following:
 Agile best practices to improve responsiveness
 Modern web technology stack to accelerate development and hire and retain top
Phoenix Project Charter
development talent
 Cloud computing to scale on demand
3.
Version 1.0, July 28, 2017
Scope
The Runner project will build a new digital media platform and several web applications (user
experiences) to replace cineSHARE, ACORN, and EAGL. Also included in scope are:
 New platform and web applications will be hosted on AWS
 Migration of DMG-integrated systems like SPT B2B and Worldwide Theatrical Publicity Sites
 IDM integration for central authentication
 GPMS integration for product master data
 Migration of Screening Room Online
 Storage management and file transfer services provided by MCS
4.
Options/Alternatives
The DMG team looked into the possibility of meeting the Runner project objectives using two
different approaches. The first approach involved refactoring and/or reengineering one module or
function at a time while making it continue to work as a whole until the entire application has been
redone. The second approach was to build a brand new application from scratch and migrate users
and data to the new application.
After trying the refactor approach for some time, it was estimated through extrapolation that this
approach would take roughly 3 to 4 years to complete given consistent team velocity.
Additionally, this would not directly address the multiple systems and repository issue that had
been consistently delayed by DMG due to its inability to tackle that need in conjunction with new
business needs.
The second approach, which was ultimately chosen, was to build a new platform and web
application. This approach was determined to be favorable as it would be shorter in effort and
duration while also allowing DMG to redefine the current workflows and user practices to capture
new efficiencies. Additionally, it would allow the new system to be built leveraging the new Sony
MCS offering as a backend and create the new system to be most efficient in a scalable, dynamic
cloud environment. We requested bids from external vendors who were familiar with the new
technology stack and determined that even with pessimistic assumptions added to their estimates,
we could perform the build and migration is less time at a lower cost than the refactor approach.
5.
Assumptions
The key assumptions for the Phoenix project are:
 Adopt agile best practices
o Continuous delivery pipeline supporting continuous integration and deployment to
receive immediate feedback on newly checked-in code
o Incremental and continuous benefit delivery to the business – weekly deployments
in the course of focused user group targeted releases
o Test driven development to achieve automated unit and integration test cases
Version 1.0
Page 2 of 5
Phoenix Project Charter
Version 1.0, July 28, 2017
o Pair programming to more quickly ramp up new and junior resources with the goal
of having any developer be able to tackle any piece of code
o Access to an open workspace environment to facilitate more collaboration and team
productivity; all Phoenix team members will be on-site
 DMG-integrated systems may need to make code changes in order to migrate to Runner
 DMG will be able to fund the necessary business improvements and maintenance for its
existing systems over the duration of the Runner project.
6.
Constraints
The team velocity will primarily be constrained by funding and resources.
Network bandwidth and storage performance as well as MCS performance will dictate the duration
of asset migration to Runner.
7.
High-level Risks
The high-level risks for the Runner project are:
 MCS shuts down
o Alternative 1: Build storage and asset management services internally
o Alternative 2: Leverage Vidispine being used by MediaCentre project
 Retention of existing developers who maintain cineSHARE, ACORN and EAGL
 Retention of Runner developers over the course of the program
 AWS unknowns and potential instabilities
 New technology stack unknowns – DMG has not built scale applications on these
technologies to date
 Coordination of migration activities across multiple DMG-integrated systems
 Network connectivity bandwidth to AWS
 Customer availability for input and feedback may impact project schedules
8.
Project Budget
Capital: $3,292,210
9.
Stakeholders
These are the individuals who have a positive or negative vested interest in the project. Stakeholders can be project
team members and most likely would be a part of the project Steering Committee. For clear definition of Stakeholder
roles, please see the attached Appendix page.
Business Unit Stakeholders
Mark DeRosa
Tracey Garvin
….. in progress
Version 1.0
Title/Role
Executive Director, SPT Digital Marketing
SVP, SPHE
Page 3 of 5
Phoenix Project Charter
IT Stakeholders
Stephen Andujar
Ryan Kido
10.
Version 1.0, July 28, 2017
Title/Role
CIO
VP, DMG
Resource Plan
In this section please detail out the resource plan for this project. Is the project managed by the BRM organization and
the development work is to be done by ADM? Is design and development work being done by a 3rd party Vendor?
Role
Project Manager
Technical Product Owner
Functional Product Owner
User Experience Designer
Graphic Designer
Full-stack Developer
Full-stack Developer
Full-stack Developer
Full-stack Developer
Dev Ops
Full-stack Developers (2)
11.
Named Resource
Charles Cole
Tatsu Oiye
Catherine Wong
Miles Kemp
Rachael Pope
Chad Brown
William Andrews
Ron Dollete
Travis Herrick
Keith Stevens
Third Party Resources
Responsible Organization
DMG
DMG
DMG
DMG
DMG
DMG
DMG
DMG
DMG
DMG
Pivotal Labs
Project Benefits
If your project’s proposed budget is under $100,000, you do not need to complete the section below. Please list your
project benefits by bullet point. If your project’s proposed budget is above $100,000, please complete the section
below. This will assist with the Benefits Realization of your project.
Benefit
Avoidance in the duplication of
assets due to multiple
repositories/systems (Yearly,
increases by 25% YoY)
FY14 IT Infrastructure Refresh
(Servers, Storage, Tape Library), One
time
Reduction in Contract Developers (2)
- cineSHARE+ (TCS Fixed Bid), Yearly
Reduction in Contract Developers (2)
- EAGL, Yearly
Reduction in System Administration
FTE (1)
Version 1.0
Accountable Person
Metric
Tracking Time
Frame
Tracking
Start Date
Report Source
DMG
Ryan Kido
$300,000 year 1
Sept 30, 2015
DMG/IT
Ryan Kido
$1,500,000
Sept 30, 2015
Ryan Kido
$208,000/year
Sept 30, 2015
DMG
DMG
Ryan Kido
$374,400/year
Sept 30, 2015
DMG
Ryan Kido
$100,000/year
April 1, 2014
Page 4 of 5
Phoenix Project Charter
12.
Version 1.0, July 28, 2017
Required Signatures
Required Signatures
Line of Business CFO
Signature
Name
Date
Customer- Business
Signature
Name
Date
Executive Sponsor- Business
Signature
Name
Date
Product Manager - Business
Signature
Name
Date
VP- Information Security
Signature
(Electronic
Signature)
Name
Jason Spaltro
Date
CIO
Signature
Name
Stephen Andujar
Date
Sponsoring DCIO/VP
Signature
Name
Ryan Kido
Date
Project Manager
Signature
Name
Charles Cole
Date
VP – Enterprise Infrastructure Services
Signature
(ELECTRONIC
Name
Ferdinand
Fattorini
Date
SIGNATURE)
Disclaimer
The purpose of this Project Charter is to define a business problem/opportunity. The information
contained in this document is preliminary and by no means certain. Cost estimates and schedule
dates are contingent upon findings discovered within the Inception and Elaboration Phases of the
project. The total project cost is currently only an estimate and should be viewed as only an
estimate. The anticipated benefits are subject to change as well but once defined may be tracked
for benefits realization post go live.
Version 1.0
Page 5 of 5