Method Adoption Workshop

July 2004

IBM and CCS Confidential © Copyright IBM Corporation 2004

 Agenda

 Expectations for this workshop

 Tactical Organization Overview
 (WIP) Project Plan/Task List
 Introduction to IBM’S, IGS METHOD
- Work Product Concept
- Intellectual Capital
- Work Product Examples
 Earned Value Tracking
 Project Management Meeting Schedule

2 Store of Tomorrow | 4/28/2004 | IBM and CCS Confidential © Copyright IBM Corporation 2004
 Expectations

 Expectations for this workshop - ANSWERS

 How are we going to work together?
 How do we synchronize work efforts?
 How do we share information?
 How do we know when we finish?
 How are problems resolved?
 Who works on what?
 What do we do next?

3 Store of Tomorrow | 4/28/2004 | IBM and CCS Confidential © Copyright IBM Corporation 2004
 Tactical Organization Overview
CCS Steering Committee
Dan Benning, Fiona Dias, John Froman,
Chip Molloy, Mike Jones

Project Executives
Nick Otto (CCS)
Richard Baca (IBM)

Project Mgt
Masha (CCS)
Bus. Governance
Bob Manning (IBM)
Mike Beam (CCS)
Steve Schillinger (CCS)
Jennifer Churchil (CCS)
Arch. Governance
Harry Waldo (CCS)
Jack Ehrhardt (CCS)
Todd Mardsen (IBM)
Sunny Mishra (IBM)

Vendor Liason Vendor Liason

360Commerce Yantra
Matt Marx/Brad Clark TBD

Tech Operations Business Apps Architecture Communications Mgt.

POC Todd Dvorak (CCS) TBD (CCS)
Mike Beam (CCS) Jack Ehrhardt (CCS)
Rick Early (CCS) TBD (IBM) TBD (IBM)
Todd Marsden (IBM) Sunny Mishra (IBM)

4 Store of Tomorrow | 4/28/2004 | IBM and CCS Confidential © Copyright IBM Corporation 2004
 Tactical Organization Overview-continued

Tech Operations Business Apps Architecture Communications Mgt.

POC Todd Dvorak (CCS) TBD (CCS)
Mike Beam (CCS) Jack Ehrhardt (CCS)
Rick Early (CCS) TBD (IBM) TBD (IBM)
Todd Marsden (IBM) Sunny Mishra (IBM)

CCS CCS CCS CCS

B.Lester Todd Stormes (split) Kent Rockwell (split) TBD
K.Leung Rick Lugg Todd Stormes (split)
S.Meshreki Sharon Brown IBM
IBM
L.Owen Chris Allport TBD
Manish Vij
P.Sparks Nicole Hughes
Min Lou
K.Rockwell (split)
IBM Cheng-Hue Lee
Jane Schumann Diptiman Dasgupta
Paula Post Prakash Mall
Cary Nimnicht MuthuKumar Rajaram

360Commerce 360Commerce
Jennifer Allen-Butler Sreenath Reddy
Bryna Wortham
TBD Yantra
Phil Tympanick
Yantra
Andy Johnson StreamServe?
TBD
StreamServe?
TBD

5 Store of Tomorrow | 4/28/2004 | IBM and CCS Confidential © Copyright IBM Corporation 2004
 (WIP) Project Plan/Task List

6 Store of Tomorrow | 4/28/2004 | IBM and CCS Confidential © Copyright IBM Corporation 2004
 Introduction to IBM’s, IGS METHOD
Method Blue has a Manage Relationship, Project Management, Risk,
Engagement Quality and Communication
Two Domain
Structure to Work Prepare Focus Select Redesign
Prepare Focus Select Redesign
Products:

Phase View Deploy

Design
Design Configure
Configure Deploy
and
Domain View Business
Assess, Define best practice, Select package,
Redesign processes, Define ROI

Design, Configure, Integrate, Document, Test

Application solution and Migrate data

Assess readiness, Redesign organization and roles,

Organization Manage changes, Train

Assess, Specify requirements, Redesign, Install and

IT-Infrastructure Train IS resources

Application management, maintenance, upgrades,

Operations extensions, troubleshoot and resolve, helpdesk

7 Store of Tomorrow | 4/28/2004 | IBM and CCS Confidential © Copyright IBM Corporation 2004
 Work Products: Focused, attainable goals
Prepare Focus Select Re-design

Design Configure Deploy

1.5
Assess
1.3 Business
Identify Processes
Strategy &
Business
Environment
1.1 1.6 1.8
Assess
Initiate Case Organization Confirm
for Change & Control Case for
Systems Change
1.4
Assess
Customer
Wants & 1.7
Needs Assess
Information
Systems
1.2
Allocate
Costs to
Processes

WP WP
TASK 01 a TASK 02 TASK 04
c

WP
TASK 06
f
WP
TASK 09 TASK 11
k

8 Store of Tomorrow | 4/28/2004 | IBM and CCS Confidential © Copyright IBM Corporation 2004
 The Work Product Concept

Engagement domain

WP 01-01

30
20
WorkProduct A WPD is divided into 2 main sections:
10
Business domain
0
What to do
Description
83 85 87 89
84 86 88

How to build the WorkProduct

Purpose
WPD are the place holders of BMS Intellectual
Notation
Capital
Organization domain
Example
Approach Business
Reference
Validation Model Focus
Workshop
Application domain Guidance guidance
and
References material

Estimation

IT domain

9 Store of Tomorrow | 4/28/2004 | IBM and CCS Confidential © Copyright IBM Corporation 2004
 Intellectual Capital Databases Organize and Disseminate
the Information
Prepare Focus Select Re-design

Design Configure Deploy

Engagement domain

30
20
10
0
Business domain
83 85 87 89
84 86 88

01-03 Work Product

01-02 Work Product
01-01 Work Product

Organisation domain

Application domain

IT domain

10 Store of Tomorrow | 4/28/2004 | IBM and CCS Confidential © Copyright IBM Corporation 2004
 Intellectual Capital Databases

11 Store of Tomorrow | 4/28/2004 | IBM and CCS Confidential © Copyright IBM Corporation 2004
 Work Product Example
 Includes
- Instructions IBM Global Services

Master Test Plan

- Input expectations
Work Product Description (WPD)
- Output info flow Unique ID: APP 133
© Copyright International Business Machines Corporation 1999, 2000
- Examples Version 3.0, January 2000

- Templates 1 Description
The Master Test Plan is a document of understanding on testing between the various
stakeholders of the project. It documents the “what” (scope and objectives), the “why” (purpose),
the “when” (key milestones), and the “who” (organizational roles and responsibilities) for all levels
of dynamic testing. Full lifecycle testing is an iterative process. The development of the master
test plan is started early in the development lifecycle, and is refined, as more information
becomes available. It ties together all the detailed test plans and points to them. Each testing
level represents a known level of physical integration and quality of the system solution under
development.

The master test plan evolves from the test strategy and is driven by the quality goals contained in
the quality plan. It uses the concepts or organization level standards, and applies them to the
project to identify specific test focus areas, types and levels of testing as they apply to the project.
As the master test plan is developed it is possible that the levels of testing, as prescribed by the
standards, may not be sufficient to meet the test objectives or the quality goals set forth by the
quality plan. In this situation, the base set of test levels may be modified or additional levels of
testing defined to accommodate the project needs. For example, Performance Testing, which is
a type of testing as per IBM’s standard testing methodology, could also occur over a number of
different levels of integration (i.e., at unit, integration, systems integration, operability, etc). It is
possible that there could be a separate detailed (and/or master) test plan for Performance Testing
and that Performance Testing could occur, as a stand-alone test, at different levels of integration.
It is also true for Usability testing that spans the full lifecycle and runs throughout the
development phases. Thus the master test plan needs to be scalable and tailorable, and must be
flexible enough to be used for the small project or the very large projects.

For smaller size projects the master test plan may combine the detailed plans for different levels
of testing into one plan.

The table of contents of a master test plan includes the following sections, but does not include
detailed testing tasks or tracking of them or test schedules:

 Test objectives: describe the tangible goals of testing for this engagement based on solution
objectives.
 Risk assessment: detailed risk assessment driven by the business functions and technical
requirements of the solution under development.

12 Store of Tomorrow | 4/28/2004 | IBM and CCS Confidential © Copyright IBM Corporation 2004
 Work Product Example
Example: APP 133 1.0 Introduction

1.1 Overview
This document constitutes the Master Test Plan for VMS Release 2.0. It describes the overall
testing strategy. Its purpose is to answer such questions as 'what will be tested?, how will it be
tested?, who will do it and when?'. It documents system objectives, test objectives, test team
roles and responsibilities, resource requirements, the test strategy and methods and standards to
be used for testing. This is a communication vehicle for the entire project team including,
developers, testers and users to get a high level overview of how the application will be tested.

It provides a comprehensive plan for all aspects of testing including, Unit, Integration, System
and Acceptance tests. This master test plan will be used by both the bank and IBM as a joint test
plan. Where differences exist in terms of reference or in levels of testing as used by the two
organizations, adequate care has been taken to ensure that the contents reflect the bank’s
standards.

At this time it is contemplated that the bank and IBM will work towards a common set of testing
standards and possibly a joint System Test Plan for future releases of VMS.

1.2 Current system environment

The Bank Vault Management System is designed to support the work of the Cash Clearing
Centres across the country. The system keeps track of cash inventories, orders and returns
providing the management of each centre with the information needed to minimize the amount
of cash holdings. The system tracks shipments of cash to and from the Bank branches, assisting
in the quick identification and resolution of shipping problems such as misdirected cash parcels.

The current system resides on two platforms; IMS host and PC Lan. The PC Lan platform is
further broken down to two types; Vault Lan and Branch Lan.

The branch LAN environment consists of 4702 Controller, FBPS/Powerlan and FBSS/OS2
attached workstations.

The Vault LANs are FBSS/Powerlan configurations.

A graphic representation of the system is provided on the next page.

13 Store of Tomorrow | 4/28/2004 | IBM and CCS Confidential © Copyright IBM Corporation 2004
 Earned Value Tracking
Focused work assignments and work package completion tracking
prevents timeline slippage
• Each phase has defined deliverables and work packages
–IGS METHOD templates logically guide work effort

• Each team’s labor contribution is mapped prior to starting work

–Weekly completion requirements established
–Dependencies between teams determined
–Mandatory completion goals established

• Fixed criteria measures all task completion

• Ground rules

No partial value is earned for any category.

An item is either complete or not complete.

All items are claimed in sequence.

Once closed, no item will be re-opened.

14 Store of Tomorrow | 4/28/2004 | IBM and CCS Confidential © Copyright IBM Corporation 2004
 Earned Value Tracking and Assessment:
“The Pulse of the Project”
• Each Business Release contains defined deliverables (Scope)
• Each deliverable consists of work products aligned to the SOW
• Each work product is assigned a % value of the total deliverable
• Work product completion is measured as a % of team labor
• Each Earned Value Item (work product) follows sequentially
Categories and associated value

5%--Definition (work package(s) documentation selection, client education and

method acceptance)-(use existing template, or create new template document)

10%--Conceptual approach and activity assignment (outline activities,

assignments, due dates, final client approver assigned and notified)

25%--Preliminary analysis (draft/working document body assembled, including

charts, work-flows, diagrams, integration points listed etc.)

25%--Functional Review (team lead unit acceptance, integration context diagram

completed, test and training requirements identified; major changes end here)

20%--Detailed Final Document prepared (project manager review, cross-team

review by all team leaders; minor changes end here)

10%--User/Client walk-through(s) (final client approver notified)

5%--Final Client deliverable signoff/acceptance of deliverable items

15 Store of Tomorrow | 4/28/2004 | IBM and CCS Confidential © Copyright IBM Corporation 2004
 Lessons learned from prior projects
 Need leadership and drive to complete
- Beyond a sequence of events, Beyond a ‘project plan’
 Need continuous, visible completion feedback
- Keep the pace and urgency up front
 Need reliable reporting forcing daily accountability
- Fair and respected measurement, everyone understands
- Identify bottleneck tasks between teams, daily
- Provide alternatives to continue instead of excuses to delay
 Need clear cut, attainable goals
- Move on to next task, ‘time box’ work effort
 Need a repeatable process and discipline to execute to plan
 Our project will use IBM’s, IGS METHOD
- Predictable, repeatable delivery
- Reduced Risk, disciplined delivery
- Rapid installation, SPEED
16 Store of Tomorrow | 4/28/2004 | IBM and CCS Confidential © Copyright IBM Corporation 2004
 Method Adoption Workshop

 Example: Only
 Project, all Business Releases= 100%
- BR0=25%, BR1=20%, BR2=30%, BR3=25%
 Solutions team=45%, Integration=30, RICE=25%

 Work products are assigned %’s by team leads

- Earned value %, by work product earned, delivery criteria
 definition 5%
 conceptual approach 10%
 preliminary analysis 25%
 functional review 25%
 detailed final document 20%
 customer walk-through 10%
 final user acceptance 5%

 Earned value by team, BR, total project reported

17 Store of Tomorrow | 4/28/2004 | IBM and CCS Confidential © Copyright IBM Corporation 2004
 Earned Value tracking output example

ESTIMATED HOURS vs. ACTUAL HOURS

60000

50000

40000
estimated total cum
30000 actual IBM+i2 cum
actual cum i2
20000

10000

0
10/14/2000

11/14/2000

12/14/2000

10/14/2001

11/14/2001
7/14/2000

8/14/2000

9/14/2000

1/14/2001

2/14/2001

3/14/2001

4/14/2001

5/14/2001

6/14/2001

7/14/2001

8/14/2001

9/14/2001

18 Store of Tomorrow | 4/28/2004 | IBM and CCS Confidential © Copyright IBM Corporation 2004
 Earned Value detailed tracking example

19 Store of Tomorrow | 4/28/2004 | IBM and CCS Confidential © Copyright IBM Corporation 2004
 Earned Value detailed tracking example

20 Store of Tomorrow | 4/28/2004 | IBM and CCS Confidential © Copyright IBM Corporation 2004
 Project Management Meeting Schedule
 Work week pace
- Close of business Thursdays
 Weekly team inputs submitted to PMO
 Only work product steps completed is reported, no partial completions accepted
- Prior to Tuesday’s Project Status Meeting
 Team Lead weekly status review, time and location by team leads
 Concurrence of work product status: completions, sign off’s, started, late
- Tuesdays
 Project Status
 Review new risks and issues
- Weekly 3:30-4:30 pm ET, DR2 5c/d
- Project managers and Team Leads, standard format provided by PMO
- Wednesdays
 Risks, Issues Status
 Understand, log entries and assign actions items
- Weekly, 2:00-3:00 pm ET, DR2 5c/d
- Project managers and Team Leads
- Thursdays
 CIO progress update briefing
 Progress report, key issues and risks reviewed
- Project executives and CCS project manager

21 Store of Tomorrow | 4/28/2004 | IBM and CCS Confidential © Copyright IBM Corporation 2004