About Intel. Intel Values. Intel Employee Facts. Cultural Highlights. The Benefits of Size

Transcription

1 in Five Years of Requirements Engineering Improvement Erik Simmons, Intel Corporation Requirement Requirement Schedule Schedule Cost Cost CPU CPU load load at at full full operation operation Outstanding Outstanding WW37 WW37 $9.00 $ % 20% Use Case ID Title Summary Actors Pre-conditi ons Target Target WW39 WW39 $10.00 $ % 25% RK_Web_Download I nstall Client Adapter web download Actor downloads latest web pack to perform fresh install or driver update on one or more systems. End user, IT person Minimum Minimum WW44 WW44 $11.50 $ % 34% Wired product, single NIC Windows versions 2000, XP and 2003 Add as note: Web packs vary according to user needs and download capability About Intel Year founded: 1968 Number of employees: 78,000 (48,000 US) Revenues: $30.1 billion (2003) Products and services: over 450 Fortune 500 ranking: 65 Brand value: $33 Billion, 5 th in the world (2004) Worldwide offices and facilities: 294 Basic course of 1. User selects package from web. One pack needs to cont ain options events as in RK Install Autorun. 2.User downloads file to drive, local or remote. 3. User execut es file which requests confirmation of license agreement 4. I f user does not accept license agreement then execution is terminated. Web download is left on system. 5. I f user accepts lic ense, files are extract ed and installation proceeds according to type of pack see Web Pack Use Cases. 2 Intel Employee Facts Intel Values 16% work at more than one campus 64% work with three or more teams 67% work in virtual teams 69% work with people in different time zones 70% collaborate with team members they don t meet face-to-face Customer Orientation Discipline Quality Risk Taking Great Place to Work Results Orientation 3 4 Cultural Highlights The Benefits of Size Egalitarian: No offices (except in acquired firms), little affordance for seniority, work judged on merit Open and Direct: Constructive confrontation, open door policy, rigorous annual review process Entrepreneurial: Own your own employability, assume responsibility, take informed risks Teaming, yet Competitive: Many dispersed teams, virtual teams, but annual review is at the individual level Dedicated and Aggressive: Continual pressure to improve, sense of urgency, market focus, aggressive goals, dedication to meet commitments Dynamic: Frequent reorganizations, employee movement; shifts to attack new opportunities Large companies have more organizational slack; they can devote greater resources to continuous improvement They have more simultaneous projects, so it can be easier to pilot new methods and practices in low-risk situations With so many sets of eyes and ears, many sources of new practices can be monitored at once and shared through communities of practice Larger companies are often more mature than smaller companies, and have lost the start-up atmosphere that can eschew rigorous practices 5 6 1

2 The Drawbacks of Size The Requirements Engineering Program Organizational complexity! Decision authority, resource allocation, and program management are all tougher A large potential audience for training, consulting, and related project work stretches available resources Changing practices on a team can have unintended side effects on large, multi-team projects Geographic dispersion means that face-to-face time could be impossible or impractical Started in 1999, based on informal previous work: Two full-time positions in the Corporate Quality Network One program in a larger methods group covering product life cycle, software test, configuration management, program management, etc. Organizational improvement model includes: Free assistance to platform & product development teams via direct engagements Business result driven, not audit or standards based Methods and best practices over rigid processes Knowledge transfer emphasis for long-term selfsufficiency 7 8 RE Program Evolution What is ROI? Which of the following represent ROI? 1. Customer Reaction and Satisfaction Path-finding, problem definition Requirements Engineering Program begins Open Enrollment training begins Broad engagements in components, ingredients, IT, e-business Focus on platforms and key ingredients; cross-over to Intact Team training Extensive desktop platform engagement; training surpasses 6,000 Corporate move to platform-centric Extension to all platforms and ingredients 2. Knowledge and Skills Transfer 3. Application and Implementation 4. Business Impact 5. Financial Benefits 6. Intangible Benefits Significant return on investment can be found in both financial and non-financial categories Source: Adapted from The Consultant s Scorecard, Jack Phillips 9 10 Problems in ROI Calculation Problems in ROI Publication Even when the categories for ROI measurement are established, the details are vexing: How long a period to measure or project for returns Difficulty in valuating non-financial attributes Poor data collection tools Purposeful data misreporting Multi-causality Estimation errors Magic Numbers: Lack of a standard for period of return, accounting of investment, or valuation of tangible/intangible returns Security Issues: Classified budgets, headcount numbers, etc. limit published details Result Filtering: There are more positive reports than negative, so typical results are more likely to be best case instead Variable definitions And more It is usually inappropriate to compare ROI estimates between companies or even between projects at the same company

3 A Few Examples of Requirements ROI What s the ROI? (an actual project) Requirements ROI could be found in many places: Decreased time to market & lifecycle costs Improved schedule predictability Reduced product validation & support costs Generational benefits through reuse Improved employee morale and retention, reduction in unpaid overtime Increased market segment share due to better product match with user needs Increased brand equity And more Which can be quantified?... and when can they be quantified? A Software team of 13 people implemented requirements engineering, inspection, and estimation practices. Among their results on the first project: Validation reduced from 18 weeks to 6 weeks, resulting in an early release Customer-reported defects within the first 6 months reduced by an order of magnitude; customer satisfaction at record high level Team pride and enthusiasm for new methods and continuous improvement in general Investment: 1 trainer/mentor for 120 hours over 6 months, 1 week international travel, individual team member study time, individual learning curves Quotes and Lessons What We ve Heard, What We ve Learned I am CERTAIN that were it not for the profound learnings that I received from you in your Requirements Engineering curriculum, these results would not have occurred. I recently learned that the increased sales projections due to XYZ are estimated to be between two and three Billion dollars! 16 our first implementation of requirements engineering principles and ABC framework [enabled us] to increase operations efficiency by reducing 99% of false "network backup" problem alerts while increasing resolution rate of real problems from 20% to near 100%. A $33, development investment has helped us achieve cost benefits of $1,100, over the next 4 years Customer-stated financial ROI: 32:1, but note multi-causality with a commercial tool, 4-year horizon, 1. The ROI for requirements engineering can be Very Large, even on first application 2. It pays (literally) to focus on solving business problems rather than achieving certifications, counting students, or blanketing organizations with processes or tools 3. Let your business unit partners express the value of your engagement; their words are more powerful than yours 4. Some requirements benefits can be hard to show conclusively without waiting a long time for proof, but many benefits can be demonstrated early

4 Bottom Line: Next time I start a program I will ask for help [at the beginning] because it added value and was worth the time. Our [requirements document] and the entire [development] process we followed is better than last time. The result will be a much shorter product development time and a higher quality product. We have already found and fixed several problems that will save us weeks. 1. Requirements engineering improvements are incremental; don t expect full benefits the first time through 2. Engage early with teams to maximize benefits and business results 3. Teams often engage too late in the process the first time they seek help; when this happens, improvements compete with schedule pressure 4. Spending time up front can save much more time later on this is the requirements ROI I held my entire program up for 4+ weeks due to unclear, unwritten requirements. Took some heat for that in the beginning, but the deep dive requirements effort is highlighting a Silicon spin we didn't know about, standards that we don't support, other post-launch requirements nobody considered all of this causing us and mgmt to question the viability of the product. BTW, this is all stuff we wouldn't have realized until it smacked us in the face 6 months from now. Spending a month now prevented us from spending millions before a conscious decision. I think I will always have your voice in my ear as I write future requirements. I'm sure the engineering team appreciates this even more than I do. Thanks again for spending the time with us. I am certain that, without your input, we would not be moving forward - a culture change was required, and this could only have been set in motion by input from someone with your expertise. Emphasis added Other Advice 1. Changing practices up front especially adding time for requirements takes faith and courage; this risk taking must be encouraged and rewarded 2. Improved requirements practices often start with an individual, move to a team, and finally an organization 3. Large-scale improvement programs are more likely to succeed after enough influential individuals are already on board 4. Change agency is a discipline in its own right, and must be mastered in order for individuals to effectively drive improved requirements engineering practices It is not necessary to have upper management support to improve requirements practices in the beginning but, you must not have active opposition Know your corporate culture, how it changes, and how to influence change within it; otherwise, your best efforts may amount to nothing Start with a platform or product lifecycle; without it you can t ground practices in a framework Don t mistake formality for rigor (and it s appropriate rigor that you want) You must overcome the battle of anxieties (survival vs. change) by reducing learning anxiety

5 The Bottom Line Failure to improve requirements engineering practices is something akin to corporate malpractice Requirements engineering has one of the bestdeveloped business cases in existence; learn it and use it to influence others Even a small investment of time and resources can pay off in a big way: 2 people X 5 years = many millions in ROI, hundreds of project engagements, 8,000+ trained, and dozens of internal champions The ROI on requirements engineering is large enough that its absolute value is irrelevant 25 5