Upload
taya-griggs
View
214
Download
0
Tags:
Embed Size (px)
Citation preview
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
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