SCE PDSG: VASGOutsource Project Management Process

Su-Cheng Wu Sony Computer Entertainment America

Outsource and Sr. Technical Project Managersu-cheng_wu@playstation.sony.com

Outsource Project Management Process• Summary:

Bench Mark Samples and internal Time Study Define Deliverable Phases and Due Dates Documents Establish prefer method of working, factor in pipeline's ramp-up

time, including QA reporting, tracking and fixing tools Delivery Method/ Version Controls Define what and how deliverables are reviewed or approved. Sequences, establishing dependency of all Milestones,

understanding how they relate or impact one another. Flip side of quality management: Cost Control, minimally:

Risk and Assumption Management plus Scope Change Control Plan: Check all dependencies constantly. Track your risks. Consider using an agile like Product Backlog xls with Estimated Planned, Forecasted and Actual-Consumed Man Weeks.

Outsource Project Management Process• Time Mgmt:

OS Lead Time: Establish and Define Names and Content of all Outsource Milestones’ Content, Duration and Dates, including Buyer’s Internal Bench Mark Assets’ Effort Study (Man Day)

Establish understanding between Buyer and Vendor, a "Minimum Duration" required for each Milestone, based on agreed quality (From Concept to QA) Using a PERT method is recommended.

Sequences, establishing dependency of all Milestones, understanding how they relate, from Concept to QA.

Schedule (Top down/ Bottom up/PERT Effort Estimate), adding in Delivery, Client Review, Revision time, QA fixes if needed

Tracking and Reporting Tools Feedback Loops and Revision time need to be built in the

schedule

Outsource Project Management Process Estimate Deliverable Phases’ Durations (PERT)

See Appendix A: OS Project Management Requirements Estimate Deliverable Phases’ Durations (PERT)

Outsource Project Management Process• Stakeholder Expectation Management:• Quality Mgmt:

Need Buyer's complete Statement of Work: Scope, Art and Technical Requirement Documents.

Need Buyer's 2D/3D Quality Samples (files) and PERT Effort Study (Man-Days associated with each Milestone/ Quality samples.)

Create OS Test, select Vendors. Secure Outsource HR Bandwidth (at the established Man Day Rate) Establish an understanding of Buyer’s Quality Expectation and Acceptance

Criteria per milestone delivery , define deliverable requirements Viewers? Is the vendor delivering pure Maya files? Pipeline confirmation, prefer method of working, delivery instructions, team-

work structure, role definitions and leadership requirements QA reporting? Define delivery version control and tracking method and proper

tools for QA (At least a Check-list, based on Time-Phased Deliverable and Technical Requirements, etc)

Outsource Project Management Process• Stakeholder Expectation Management:• Communication Mgmt:

Update and communicate schedules considering review and production bandwidth

Provide updated technical documents as pipeline becomes more clear Provide visual and Task Driven Feedbacks:

• Minimize run-on feedback comments, focus on giving "Revision Tasks" with “Verb Driven” sentences.

• Per “Revision Task”, Buyer to offer Recommended Hours/Man Days. This gives vendor a budgeted time/quality target, also reminds the buyer’s Art Director to carefully consider the revisions’ impacts, balancing quality with cost and time

• Good practice to establish categorizing feedbacks into: Must Have, Should Have, Could Have and Won’t Have. (See MoSCoW Analysis)

• For translation purpose, bullet points are the best

OS Project Management Requirements: The Importance of Timely and Efficient Feedbacks

• MoSCoW Analysis and Time-Boxing Burn Chart:

Ideal Process

Source: Kanabar, V. & Warburton, R.D.H. (2009). Adapted from PMBOK 2009. PA. Newtown Sq.

Collect Requirements

Define Scope/ Scope Change CTRL

Create WBS

Scope Mgmt

Time Mgmt

Define Activities

Sequence Activities

Estimate Activity Resources

Estimate Activity Durations (PERT)

Develop Schedule

Cost Mgmt

Track Spending/ Payments

Estimate Costs

Plan Quality

Quality Mgmt

COMS DatabaseHuman Resource

Business Intelligence

HR Mgmt

Plan CommunicationsEffective Collaboration

Communications Mgmt

Legal and ProcurementsBusiness Intelligence

Procurement Mgmt

Develop Outsource Project

Mgmt Plan

Integration Mgmt

Beyond this Talk:VASG Planning Check List:

PMI Planning Process Group.

Modified from Source: Kanabar, V. & Warburton, R.D.H. (2009). Adapted from PMBOK 2009. PA. Newtown Sq.

OS Project Management Requirements: MoSCoW Analysis

• MoSCoW is often used with timeboxing, where a deadline is fixed so that the focus can be on the most important requirements, and as such is seen as a core aspect of rapid application development (RAD) software development processes, such as Dynamic Systems Development Method (DSDM) and agile software development techniques.

• All requirements are important, but they are prioritised to deliver the greatest and most immediate business benefits early. Developers will initially try to deliver all the M, S and C requirements but the S and C requirements will be the first to go if the delivery timescale looks threatened.

• The plain English meaning of the MoSCoW words has value in getting customers to understand what they are doing during prioritisation in a way that other ways of attaching priority, like high, medium and low, do not.

• Must have requirements labeled as MUST have to be included in the current delivery timebox in order for it to be a success. If even one MUST requirement is not included, the project delivery should be considered a failure (note: requirements can be downgraded from MUST, by agreement with all relevant stakeholders; for example, when new requirements are deemed more important). MUST can also be considered a backronym for the Minimum Usable SubseT.

• Should have SHOULD requirements are also critical to the success of the project, but are not necessary for delivery in the current delivery timebox. SHOULD requirements are as important as MUST, although SHOULD requirements are often not as time-critical or have workarounds, allowing another way of satisfying the requirement, so can be held back until a future delivery timebox.

• Could have requirements labelled as COULD are less critical and often seen as nice to have. A few easily satisfied COULD requirements in a delivery can increase customer satisfaction for little development cost.

• Won't have (but Would like) WON'T requirements are either the least-critical, lowest-payback items, or not appropriate at that time. As a result, WON'T requirements are not planned into the schedule for the delivery timebox. WON'T requirements are either dropped or reconsidered for inclusion in later timeboxes. This, however doesn't make them any less important. Sometimes this is described simply as "Would like to have" in the future, this however leaves some ambiguity in the minds of the users as to its priority compared to the other marks.

http://en.wikipedia.org/wiki/MoSCoW_Method

Appendix A: Outsource Project Management Process Estimate Deliverable Phases’ Durations (PERT)

• Program Evaluation and Review Technique :• PERT is a method to analyze the involved tasks in completing a given project, especially the time needed to complete each

task, and identifying the minimum time needed to complete the total project.• A PERT activity: is the actual performance of a task. It consumes time, it requires resources (such as labour, materials, space,

machinery), and it can be understood as representing the time, effort, and resources required to move from one event to another. A PERT activity cannot be completed until the event preceding it has occurred.

• Optimistic time (O): the minimum possible time required to accomplish a task, assuming everything proceeds better than is normally expected

• Pessimistic time (P): the maximum possible time required to accomplish a task, assuming everything goes wrong (but excluding major catastrophes).

• Most likely time (M): the best estimate of the time required to accomplish a task, assuming everything proceeds as normal.• Expected time (TE): the best estimate of the time required to accomplish a task, assuming everything proceeds as normal

(the implication being that the expected time is the average time the task would require if the task were repeated on a number of occasions over an extended period of time).

• TE = (O + 4M + P) ÷ 6

• SCW Note: At SCEA PDSG/VASG, we use: TE = (1*O + 2*M + 3*P) ÷ 6 • PERT was developed primarily to simplify the planning and scheduling of large and complex projects. It was able to

incorporate uncertainty by making it possible to schedule a project while not knowing precisely the details and durations of all the activities. It is more of an event-oriented technique rather than start- and completion-oriented, and is used more in projects where time, rather than cost, is the major factor. It is applied to very large-scale, one-time, complex, non-routine infrastructure and Research and Development projects.

• This project model was the first of its kind, a revival for scientific management, founded by Frederick Taylor (Taylorism) and later refined by Henry Ford (Fordism). DuPont corporation's critical path method was invented at roughly the same time as PERT.

• http://en.wikipedia.org/wiki/Program_Evaluation_and_Review_Technique