Jim Gibson, Intuit, Inc. September 21, 2006

1. Simplifying Program Management: Behind the Scenes of Three Targeted Improvement Efforts Underway at Intuit's Professional Tax Division Jim Gibson, Intuit, Inc. September 21, 2006

2. “If everybody’s thinking alike, then somebody’s not thinking.” - G.S. Patton

3. Agenda • Introductions • Deep dive into three specific areas • Scope management when breaking new ground • Simple tool for better resource allocation decisions • Product line development challenges • Q&A

4. Part 1 Managing Scope When Breaking New Ground

5. Context • Multi-year, multiple business unit program • New technologies • New processes • Mix of mature and newer products • Undocumented current state

6. Gaining Traction • Imperatives • Even in well understood domains, scope must be explicitly defined • Capture a useful “as is” starting point (Product Definitions) • Agree to “Scope Units” that you can use to • Ground/level the teams • Plan/estimate and track work • Mindset challenges • Inaccuracies and inefficiencies will exist • Not all scope units are alike • Valuable enough to start • Leveling is not perfect, just useful • Scope Units • Features (customer facing) • Enabling functions (non-customer facing) • Non-functional requirements

7. Product Definitions: Tree Metaphor Feature Lower levels of Detail leaf branch Customer task Domain trunk Highest level of Abstraction Feature Complete return Print tax return Customer task Print Domain

8. Lacerte Domain = “Print” Customer Task Feature (Level 1) ProSeries

9. Milestone View Scope Completion - Tracking Scope Units Monthly Trending

10. Monitor / Learn Feedback / Issues Repository • New Scope is Discovered • Operating Mechanism to feed prioritization/planning Aggressively Focus on Learning Adjust Plan Track Execute

11. Tracking the Unknown – Chart What We Learn Newly Identified Scope Units New scope Baseline Scope (232 Scope Units)

12. Lessons Learned • Need the basics: clear, simple levers (no surprises here) • Critical Success Factors • Planning assumptions • Scope, cost, quality, schedule • Objective view into progress builds stakeholder confidence • Quantify and track visually • Pre-plan checkpoints - Prioritize new scope and update plan • Feedback loop • Scope Units aren’t created equally • Understand and accept the inequities and inaccuracies • Mindset challenges • Buy-in to value • Frustration with the inherent inaccuracies

13. Part 2 Simple Tool: Resource Allocation

14. Context • Problem statement • Need tops-down visibility into available resource capacity to improve effectiveness of work prioritization and trade-offs among conflicting priorities • Issues • Multiple teams, multiple projects • Inconsistent methodologies • Multiple tools and data sources • Inconsistent understanding and execution of fundamentals • Estimating skills • Tracking actuals • Internalizing Estimates To Complete

15. Key Ideas • Pool of available capacity for work, managed in 3 month windows • ETC for each person, each project • Simple, quick “what-ifs” • Does not show % allocation over time

16. Team C - QA Team D Team E Team F Team G Team H Summary Worksheet Header – By Team • Allocation Period (3 months) • # available days in the period • # days remaining (based upon current date) • Team total capacity • Team total days booked • Effort expended, remaining, %

17. Summary Worksheet Detail – By Person Total ETC Available Remaining Planned Expanded Name Team Initial Days Available Planned Time Off Net Days Available

18. Project Detail Worksheet Planned Expended ETC Team Project Name

19. Lessons Learned • Managing capacity in blocks of allocated time is useful • Simplifies the problem space • Natural alignment with cone of uncertainty • Simple spreadsheet = powerful views = better decision making • Resource availability across teams • Who’s working on what and how much is left • Easy to explore what-ifs changes • Tracking actual time is inconsistent • When people see how ETC is used at org level, buy-in increases • Credibility / patience with leap of faith (“just do it”) is short lived • Achieving consistent project-level “ETC mindset” is not trivial • Focus deliberately on new behavior • Focused on collecting ETC separately for short time, now rolling into project approval request database (one stop shopping) • Feedback loop for input and improvement suggestions is vital

20. Part 3 Product Line Development Learning Curve

21. Context • Implementing Product Line Development • Focused within a specific program (point of leverage for org roll out) • Foundation for future flexibility / responsiveness to market • Challenges / requisites • Product Line knowledge / understanding • Architectural must=haves (domains, life time objectives) • Mindset • Mapping and migrating current state • Skills, processes, tools • Executive buy-in and engagement

22. What is a Software Product Line? • Set of software intensive systems sharing a common, managed set of features that satisfy the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way. • http://www.sei.cmu.edu/productlines/framework.html

23. A Pattern Approach Variable Functionality Variable Functionality A B A B C Shared Functionality C • Pattern applies to: • Plans • Architecture • Product Line Definitions • Requirements • Design • Code • Tests

24. A Framework for Software Product Line Practice SM • The three essential activities and the descriptions of the product line practice areas form a conceptual framework for software product line practice. • Core Asset Development • Product Development • Management • This Framework is evolving based on the experience and information provided by the community. • Version 4.0 – in Software Product Lines: Practices and Patterns • Version 4.2 – http://www.sei.cmu.edu/productlines/framework.html • Version 5.0 – to be released in late 2006

25. Essential Product Line Activities Core AssetDevelopment ProductDevelopment Management Each of these is essential, as is the blending of all three.

26. How is Production More Economical? • Each product is formed by • Taking applicable components from the base of common assets • Tailoring them as necessary through preplanned variation mechanisms such as parameterization or inheritance • Adding any new components that may be necessary • Assembling the collection according to the rules of a common, product-line-wide architecture. • Building a new product (system) becomes more a matter of assembly or generation than one of creation; the predominant activity is integration rather than programming. • For each software product line there is a predefined guide or plan that specifies the exact product-building approach.

27. earlier life cycle reuse more benefit How Do Product Lines Help? • Product lines amortize the investment in these and other core assets: • requirements and requirements analysis • domain model • software architecture and design • performance engineering • documentation • test plans, test cases, and test data • people: their knowledge and skills • processes, methods, and tools • budgets, schedules, and work plans • components product lines = strategic reuse

28. Mindset Level-Setting Slide We Used:“Background & Mindset” • We are breaking new ground every day • Trail Guides • Framework • Ambiguity • Prototype • Learn - teach - learn • Frequent checks and adjustments • Collaborative • Nimble • Challenges and rewards from lewisandclark.org from covered-wagon-train.com

29. Lessons Learned • “Common vs. variable” is a new paradigm • Old habits crop up – must constantly focus on short and long term • Permeates all work • Requirements and allocation • Design • Coding • Testing • Workload management • Must think differently • Leading mindset changes • Getting out in front via Trail Guides • Mixed success (and buy-in to Trail Guide approach) • Product Definition TG experience was good (timing and buy-in) • Project Management TG experience was bad (timing and buy-in)

30. “Truth is what stands the test of experience.” - Albert Einstein

31. Appendix

32. Excerpt from Software Product Lines: Practices and Patterns • Software Product Lines: Practices and Patterns • By Paul Clements, Linda M. Northrop. • Addison-Wesley • #16. Enchiladas verdes: Corn tortillas baked with a zesty filling, covered with a green tomatillo sauce. Your choice of chicken, beef, pork, or cheese. • #17. Enchiladas rojas: Corn tortillas baked with a zesty filling, covered with a red ancho chile sauce. Your choice of chicken, beef, or pork. • See what I mean? This restaurant clearly produces an "enchilada" product line. (Well, all right, "clearly" applies only to those of us who have been thinking about this for too long.) While admittedly a cheesy example (sorry), it actually provides a pretty good analogy with software product lines and the central concepts they embody. • The enchilada product line consists of seven separate products, differentiated by filling and sauce. This defines their variabilities. The corn tortillas are core assets because they're used in every product. The red and green sauces are also core assets because they're used in four and three products, respectively. And the meat fillings are also core assets, used in two products each. But the cheese is a product-specific asset, used only in the enchiladas verdes. • Some of the core assets have attached processes that indicate how they are to be instantiated for use in products. Here, the beef, pork, and chicken have attached processes that dictate how they're chopped, seasoned, and cooked. The processes call for different spices to be added depending on the sauce. • All of the products share an "architecture"—tortillas wrapped around a filling, covered with sauce. And they also share a "production plan": prepare filling, wrap filling in tortilla, cover with sauce, bake at 350 degrees for 15 minutes, garnish, serve. • This little product line provides economies of scope; the common ingredients let the restaurant stock a small number of food items delivered from a small number of suppliers. They provide personnel flexibility: the same person who makes the pork enchiladas rojas is, I would bet my house, the same person who makes the cheese enchiladas verdes. And because the choices are limited, many of the ingredients can be pre-prepared, allowing for rapid time-to-market, which in this case means time-to-table. • Finally, because the commonalities and variabilities are exquisitely clear, it's easy to see how this product line's scope could be expanded, by offering new fillings and new sauces and perhaps new combinations. You could even see how this efficient production capability could be used to launch an entirely new product line to capture a new market segment: replace the corn tortillas with flour tortillas, lose the sauce, add lettuce and tomato and other condiments, and open a new restaurant chain that sells "wraps."