SanDisk CorporationSanDisk Corporation

July 1, 2008

“Why Doesn’t the Software Do What I Need IT to Do?” or Aligning IT Objectives With the Business

Cecilia ClaudioSVP & CIOSanDisk Corp.

3

But before we talk about software…

• Cecilia, the person

• Journey on becoming CIO

• Decisions made, e.g., left good job due to CIO position not being available

• Look for opportunities and go for it

• Luck, timing and who you know

• Relevant position to influence, drive and make a difference

• “Seizing the moment!”

4

About SanDisk

A Silicon Valley high technology success story—founded in 1988

Invented CompactFlash & co-developed all major card formats

Designs & manufactures its own flash memory chips & cards

Completed fourth NAND flash fab in Japan; currently world’s largest

Opened assembly plant in Shanghai in September 2007

$3.9 Billion in revenue for 2007 with 3,100+ employees worldwide

5

Growing Global Reach: 222,000+ Storefronts Worldwide

37,000 +Food & Drug

60,000 +Mobile Stores

Bell WorldBest BuyBlacksCostco

London DrugsRadio Shack

SearsShoppers Drug

MartWest Fair

Canada Tire

T MobileCarphone

WarehouseWoolworths

DixonsOrange

Wal-MartCamaraEuronix

FotoSistemaFotocoFNAC

Foto ServiceGermanos

Internet shops Knut LeclercMakroMarktPhotoStation

PulsatRIC

RingfotoSchlecker

Best BuyBrooks/Eckerd

Circuit CityCompUSAWal-Mart

CostcoK-Mart

MusiclandOffice Depot

StaplesSears

Rite AidRadio ShackMeijer/Food

SafewayKroger

HEBAAFES

MDIGameStop

SprintVerizon

BestColes

FortressBroadway

LotteCostcoSunfarGoMe

SuNingDahZong

OfficeworksBig W

Harris Tech.Good GuysH Norman

Woolworths

AeonBICBestEdion

K’sKitamuraKojima

LawsonsMatsukiyoYamada

Yodobashi

Americas81,000+

Europe79,000+

Asia/Pac Rim

31,000+ Japan17,000+

6

Mobile/CE/PC Driving NAND Future

Email

PDA Phone

PC

, C

E M

ark

ets

Mo

bil

e M

ark

et

Camera Phone

Imaging

Video Phone

Video

MobileTV

TV / STB

Application

Music Phone

Music

Game Phone

Game

GPS Phone

Map

Why do Software Projects Often Fail?

8

Why do Software Projects Often Fail?

Caveat

• The type of software development I will be speaking about is for business oriented applications. Although most of what will be discussed is applicable to scientific or engineering oriented software, I realize there is a difference.

• I’ve highlighted some of these differences (from my perspective) on a subsequent slide

• Since I’ve primarily been involved with business applications I’ve based my presentation on business oriented software development.

• My belief is that most of the major challenges however (whether business oriented or engineering oriented) are common

9

Software Development Typically Follows a Development Lifecycle

Generic Lifecycle

Requirements Design Testing Implementation

Many Variations of the Lifecycle Are Used

Waterfall

Incremental Model

Spiral Model

Etc.

10

Some Differences Exist Between Engineering Oriented and Business Oriented Software, For Instance:

Attribute Business Oriented Engineering Oriented

Input Source End User Provided or Derived Often a H/W Device or S/W Module

Output Typically End User Often a H/W Device or Module Process Models Business Process Algorithm Optimized for Business Results Efficiency Developed by Internal IT or Systems Integrator Vendors Language Used High Level Low Level Response Time Requirements

Seconds Milliseconds

Requirements Provided by Business (Requirements Document)

Marketing (Requirements Document)

Or Engineering (ECOs) End Users Employees Customers

11

Having Said This …….

As Business Applications Become More Integrated There is an Evolution Towards Becoming More “Engineering like”

And Regardless of the Type of Software, the Main Challenge (making it do what it is supposed to do) Remains the Same

So Let’s Take a Look at Why the Software Often Fails to Meet Expectations

12

What is Failure Anyway?

My definition (mgmt perspective) of software development failure is

• When the end user (or customer) is not satisfied with the results

• Granted, this is a stringent definition

• Particularly when users don’t always know what they want and/or

• When they belatedly realize want they want they try and use “scope creep” as a means of retrofitting their requirements…

• “oh no, we’ve always said that the software should do a, b, c, …” etc.

• The Bottom Line Though …

• Is that users have great influence on their management and if user management is not happy with results there is no way to convince them otherwise. In their minds the software development project has “failed” and this belief will be near impossible to overcome, no matter the reality.

13

When Failures Arise, Often Developers Respond By

• “Works as designed”

• Guaranteed to evoke a strong reaction

• Or, “it’s not a bug, it’s a feature”

• May lead to physical manifestations of frustration

• Rarely by

• “Hmmm, that’s interesting let me review the requirements and advise”

• Or, “perhaps the requirement was flawed, I’ll have to take a look at it”

• Or, “I see your point, however what you are telling me is different than what the requirements stated, perhaps there is a need to revise the requirements”

• In any case, these situations arise at the end of the development lifecycle, which is obviously the most inopportune (and expensive) time to address these issues

14

Why do Software Projects Often Fail?

CC’s Top 10 Reasons for Software Development Failures:

1. Overselling the new solution

• Emphasizing that the “new” system will solve all the problems of the old, and therefore let’s “move forward”

2. Overly optimistic schedules

• Most IT Staff are Optimists when evaluating how long things will take, or the number of barriers that “jump up” during project execution

3. Shortchanging design or the “are we coding yet?” phenomena

• The perception that coding is “where the action happens”, and that design is boring or takes too long

15

Top 10 Reasons for S/W Failure (con’t)

4. Key Assumptions are Not Validated• “We assumed the device would work like….. but it really …..”

5. Lack of Stakeholder Buy in• Often accompanied by lack of user input

• “nobody asked us”

6. When the schedule is under pressure, the plan is abandoned• “we’re way off schedule and there is no time to fix it” or “I Know

what needs to be done, I don’t need a schedule to tell me”

7. Putting dates ahead of quality (or shortchanging the time for QA)• “Look, we told them it wil be ready on MM/DD/YY and IT WILL be

ready then..”

• Old adage, “when the boss wants it really bad that is how he gets it”

16

Top 10 Reasons for S/W Failure (con’t)

8. Having the wrong (or too many) people in charge

• Inadequate or weak skill sets

• Changing players frequently

9. The Us vs Them Syndrome

• Developers assume role of undervalued heroes and end users are characterized as the ever-demanding-never-reasonable enemy

10.Poor (or politicized) project controls

• “we all know that we’re behind schedule but if we show it that way our boss is gonna kill us, color it green and let’s find a way to make up the time..”

17

Wait, You Don’t Believe That These Mistakes Are Still Happening?

While it is True That Most of These Mistakes Were Known For Quite a While

• Standish Group Published a Classic Report on the Topic in 1995 (Chaos Report)

Yet Software Failures Continue to Happen, Consider

• “British Airways CIO Apologises for T5 Launch Debacle” Feb 13, 2008

• “We do make mistakes. T5 is probably at the front of all your minds, and I would just like to say that I am very sorry,” he said, speaking at the Forrester IT Forum in London.

• BA has previously blamed the incident on a combination of software failures and poor training.

18

Preventing Failures – Macro View

At the Macro Level, the Job of Preventing Software Failures Boils Down to a Simple Formula

Success occurs when,

Expectations = Reality

The Key to Success is Having Good People and a Good Governance Structure That Represents a True Partnership Between IT and the Business

19

So How Can These Failures Be Prevented?

My View is That All of These Problem Are Addressed by “Proper” Governance

• What is Proper Governance?

• One that is effective at continually managing end user (or customer) expectations

• One that has the right representation from the end user community as well as the developer community

• Right - means that the representatives of each constituency are at a decision making level and have the appropriate authority

• One that continually focuses on the end goal, emphasizes “one team” behavior and looks forward to results minimizing or eliminating the “blame” time sink

In a Nutshell, Proper Governance Represents a True Partnership Between IT and the Business

20

Governance Structures That Work – My Experience

Business Technology Integration (BTI)

• A Model Used at Farmers Insurance

IT Governance – Operating Council

• SAP Deployment at SanDisk

21

Summary

Software projects often fail even though the reasons for this are well established

Failure occurs when:

• Expectations ≠ Results

The key to preventing software failures is having a proper governance structure that:

• Continually manages user (or customer) expectations

• Has the “right” representation from each constituent

• Is forward looking, focused on the end game, emphasizes results, overcome obstacles, and only looks back when results have been delivered (during post mortem)

22

Q & A