나의 인생 이야기

Final Sign-Off

1. The key elements of effective acceptance are:

A clear understanding of the List of Deliverables to be accepted(Requirements Traceability Matrix)
A clear understanding of Acceptance Criteria
Clear documentation of any variations to the Acceptance Criteria
Obtaining customer sign off

2. The critical success factors of Project Completion are

the customer perceives the value of the project
the customer accepts project deliverables
the customer will provide references
the project's financial performance criteria has been accurately measured

3. Why client may be reluctant to accept ? (Acceptance Implications)

Payment is expected
Any future changes are chargeable
Oracle's involvement may end
Any bug fixes may be on T&M basis
Warranty period begins, the is only 90 days
Fear-Uncertainly & Doubt(FUD)

4. The value of "a compelling event" and why you should NEVER de-couple this event with the 'sign-off'.

A Risk is an uncertain event or condition that will affect project objectives if it occurs.
A Issue is a REALIZED RISK. It is something which has already happened and which requires action for resolution.
1. Risk Management

Identification

Brainstorming & interviews
GRM Bid Review
Bid Risk Analysis Workbook
Assumptions Analysis

Assessment
Planning

Avoid
Reduce
Transfer
Accept and Control

Management

Appoint Owner
Develop Contingencies
Ongoing Review

2. Risk Identification

Categories of Risk

Scope
Resources and Logistics
Market Factors
Client Factors
Technical Factors
Contract and Project Mgmt

Botth External and Oracle Internal Risks

Resourcing the Project

5 areas to look at

technical abiliity
leadership qualities
interpersonal skills
character/personal qualities
personal agendas

User Acceptance Test

Common Problems/Issues that come up during UAT

Client claims that functionality is there, but system is simply "too slow"
Client raises a "bug" but it's a change in disguise
Numerous TPRs raised that are consistently not Oracle's responsibility
UA Testers not providing sufficient detail/accuracy when reporting TPRs
UAT resources were committed but are found to be unavailable
UA Testers not adequately trained in testing/system functionality
Client requests changes and want;s them included in the release!
UA Testers find a Bug in a Sub-Contractors Deliverable, Teh Sub-Contractor claims that Oracle accepted the deliverable earlier during SIT
UA Testers raising NEW TPRs upon regression test, not raised previously
UA Testers overly slow performing test
Acceptance Blackmail

Incident Analysis Breakdown

Finger Trouble - User testing understanding issue (10%)
Duplicate - Same fault reported more than once (5%)
Change Control Request - CCR masquerading as a Fault Report(5%)
System Maintenance Issue - Security, Permissions, Access (20%)
Data Related Problems - Test Cases have incorrect data (25%)
Network Fault (3%)
PC Client Configuration fault (2%)
Interface - Teh fault is on the non Oracle side of an interface in the SI (10%)
BUG this is definitely our problem (20%)

Change Control

1. Definition : A request, actio or event resulting in an agreed CHANGE to

Project delivery timescales, costs or price
Agreed functionality or requirements(SOW)
Contractual Conditions

Payment Terms
Penalties
Customer Involvement

2.Typical Casation

Contractually agreed commitment not being met by Customer
Change in Requirements
Poor effort estimation and planing
Product Problems
force Majeure

3. Things typically change dur to a Change Control

Schedule -> Cash Flow-> Work Effort & Price ->Cost -> Revenue Recognition -> Contact Terms

4. Common Occurrences related to Change Contorl

Customer keeps requesting & rejecting CC whilst refusing to pay for analysis
Customer views payment for CC as " not in the spirit" of the project
Sales wants to give CC free
Customer believes the request/change is within Scope, ie not CC
customer requests a CC that moves a milestone payment out
Customer wants to reduce already agreed scope and believes reduced cost should be passed on to customer as other fuctions or reduction in price
Customer does not believe the estimate is a accurate(already too high)
Change is required on a Sub-contractors deliverable, the customer says it is within scope & will not pay and the Sun-Contractor say it is not within scope, OCS is in the middle.
Acceptance Blackmail(ie No free Change Control then No Acceptance)

5. Rules for Managing Change Control

Stay calm : if discussion becomes too heated on a given topic, move from the topic.
Get all of the issues on the table and deal with them one by one but think holistically
Allo Positions to be clarified : Allow the customer and OCS fuctional Analysts to give the technical case as to whether an item is in or out of scope.
Deal Holisticall : When you have heard both sides, do not agree items one by one but rather wait until all items have been heard by both side.

6. How to make a "Reasoned Case"

Constrct your argument in four level

Contractual High Ground(Check it you have it)
Moral High Ground(Do you have it)
Mutual Culpability(Is the guilt balanced)
Vible Threat(BANOC-Best Alternative to a Negotiated Outcome)

Use the "Range" Argument to enumerate positions
Use DEDUCTIVE and INDUCTIVE Agrumrns where appicable
Allow the Opponent(Customer) to speak and complete their point
Avoid burning bridges(relationship must not be lost)
Deal one on one where possible(avoids group dynamics)
Make it clear that it is not personal, we are both trying to do the right thing by our employers
Never-Exaggerate or strect the truth
Argue PRINCIPLE not DETAIL

Kick Off Meeting(PM)

It presents an ideal opportunity for:

Introducing yourself as the team's leader
Team members to meet one another
Presenting the vision for the project
Gaining acceptance/buy-in to the vision
clarifying jthe projects's objectives
Setting expectations and explaining what the future will be like
Briefing Orcle staff on politics situations, personalities

*Your team will be forming their first impressions of you so prepare well and carefully-consider your style

The Typical Meeting Agenda
Introductions and Background
Strategy and Plans/Milestones
Project Structure
Standards
Do's and Don'ts
General Questions answered
Handout a "Project Introductiory Pack" to team members

Training and Accreditation Program

Oracle® Unified Method (OUM) Training and Accreditation Program

Oracle's Global Methods team has designed a series of self-service, self-paced training courses in support of the Oracle® Unified Method (OUM). Each training course can be taken online through Oracle University or downloaded and taken off-line.

The OUM Accreditation Program helps to ensure that individuals in consulting sales, delivery, and management roles have the level of delivery and estimating knowledge required for them to competently perform their job. The Accreditation Levels include:

Level 1 - Oracle Unified Method Overview and Awareness
Level 2 - Focus Area1 Specific Overview
Level 2 - Use Case Overview
Level 2 - Business Process Overview
Level 2E - Estimating Overview
Level 3 - Gathering Requirements using OUM
Level 3 - Analysis and Design
Level 4D - Discipline2 or Service Offering3 Specific Delivery Readiness
Level 4E - Business Requirements Questionnaire Estimating Readiness
Level 5 - Advanced Delivery Readiness

*OUM Focus Areas: Manage, Implement, Envision
*OUM Disciplines: Application Implementation, Business Intelligence and Enterprise Performance Management, Software Upgrade, Technology Implementation, Business Intelligence and Analytics, Software Upgrade, Technology
*OUM Service Offerings: TBD
Accreditation testing for Levels 1 - 4E is provided with each training course. Accreditation for Level 5 requires verification of performance on a successful client delivery project using a specific discipline or service offering.

X = Required Training

O = Recommended Training

Course
Level 1 - Awareness
Level 1 - Overview and Awareness
Level 2 - Overview
Level 2 - Manage Focus Area Overview
Level 2 - Envision Focus Area Overview
Level 2 - Implement Focus Area Overview
Level 2 - Use Case Overview
Level 2 - Business Process Overview - planned for Q1FY2011
Level 2E - Estimating Overview
Level 3 - Requirements, Analysis, and Design
Level 3 - Gathering Requirements using OUM
Level 3 - Analysis and Design - planned for Q2FY2011
Level 4D - Delivery Readiness - as appropriate for your Discipline or Business Area
Level 4D - Application Implementation Delivery Readiness
Level 4D - Business Intelligence and Enterprise Performance Management Delivery Readiness
Level 4D - Custom Development Delivery Readiness - planned for FY2011
Level 4D - Enterprise 2.0 Delivery Readiness - planned for FY2011
Level 4D - Enterprise Architecture Delivery Readiness
Level 4D - Performance Management and Tuning Delivery Readiness - planned for FY2011
Level 4D - Security Delivery Readiness - planned for FY2011
Level 4D - Service-Oriented Architecture (SOA) Delivery Readiness - planned for Q2FY2011
Level 4D - Software Upgrade Delivery Readiness
Level 4E - Estimating Readiness - as appropriate for your Discipline or Business Area
Level 4E - Business Requirements Questionnaire Estimating Readiness
Level 5 - Advanced Delivery Readiness - as appropriate for your Discipline or Business Area
Level 5 - Advanced Delivery Readiness
Supplemental Training and/or References
Supplemental Training and/or References