®
IBM Software Group
Systems and Software Trends
Critical Success Factors in Process
Walker Royce
IBM Software Group
IBM Software Group | Rational software
What we see …
Geographic distribution of business - The new norm
 Work aligned to markets and customers
 Evolution of right-sourcing
 Leveraging distributed development
Accommodating compliance - The new necessity
 Management reporting, audit support
• Sarbanes Oxley, HIPAA, 21CFR11, Basel II, EASHW
 IT, systems, project and product level accountability
• ITIL, COBIT, COSO, ISO 900x, Six Sigma
 Development compliance level
• Change management of assets, traceability
• CMM/CMMII, RUP, DODAF
Open computing - A new route to collaboration and
innovation
Modular systems - Greater flexibility
 Maximize investments: Reuse components
 Increase flexibility: Interoperable systems
 Accelerate initiatives: Scalable and agile
Open
architecture
Open
computing
Open
standards
Open
source
IBM Software Group | Rational software
Evolving software and systems delivery
TRADITIONAL
PROJECT
DRIVEN
Co-located teams
Technology led
Vendor lock-in
Application silos
BUSINESS TRENDS
Right-sourcing
Standards
CURRENT
BUSINESSREALITY
DRIVEN
Geographically distributed
Compliance
Open computing
Modular systems (SOA)
Business Driven Development
Enabling organizations to govern the business
process of software and systems development
IBM Software Group | Rational software
System Cost/Time Estimation
IBM Software Group | Rational software
Business Driven Development
Increased revenues
 Better quality
 Differentiated products, systems
or services
 Earlier time to market
Better = Revenue
Growth
*
Business
Cost
Reduced costs through SOA, GDD, Automation
 Better software economics
 Smaller development teams
 Faster development cycles
 Rightsized processes and skills
 Effective architectures and reuse
Improved Reputation
 Better Governance
 Attractiveness to customers
 UL stamp
 Attractiveness to workforce
 “Best company award”
 SOx, CMMI, ISO 9000,
HIPPA, CFR11
 Openness, Standards
 Track record of performance
IBM Software Group | Rational software
Software Governance
1960s-1980s
1990s-2000s
2005+
100% Custom
30% Reused Assets
70% Custom
70% Reused Assets
30% Custom
Ad-hoc
Repeatable
Managed and
Measured
Team
Collocated
OJT
Collocated
Software Skills
Distributed
Systems/Software
Professionals
Tools
Proprietary
Not Integrated
Mix of Proprietary
and Commercial
Not Integrated
Commercial
Integrated
Processes-Tools
Predictable
Unpredictable
Predictable
over budget,
over schedule
Infrequently
on budget,
on schedule
Frequently
on budget,
on schedule
25%-33%
50% +
Complexity
Process
Project
Performance
Success Rate
10%
IBM Software Group | Rational software
Development Governance
Definition
 Application of governance to
 Development organization
 Development programs

Context
 May be part of IT Governance
 May be part or whole of product
development
 May be service
Governed Processes
 Program
 High Variance
•
Analysis
•
Design
•
Development planning
 Medium Variance
•
Implementation
•
Iteration planning
•
Version control
•
Build/Integration/test
 Low Variance
•
Maintenance/Test
•
UCM
•
Product Data Management
 Organization
 Portfolio Management
•
Qualitative
 Estimation
 Service delivery
 Asset management
IBM Software Group | Rational software
Four Patterns of Success
 Scope management  Asset based development
Solutions need to evolve from user specifications AND user specifications need
to evolve from candidate solutions.
• As opposed to getting all the requirements right up front.
 Process management  Rightsize the process
Process and instrumentation rigor evolves from light to heavy.
• As opposed to the entire project’s lifecycle process should be light or heavy
depending on the character of the project.
 Progress management  Honest assessments
Healthy projects display a sequence of progressions and digressions.
• As opposed to healthy projects progress to 100% earned value with a
monotonically increasing and predictable plan.
 Quality management  Incremental demonstrable results
Testing needs to be a 1st class, full lifecycle activity.
• As opposed to a subordinate, later lifecycle activity.