1 Prepared for presentation to the DFW ASEE Simplifying Program Management: Behind the Scenes of Three Targeted Improvement Efforts Underway at Intuit's

1

Prepared for presentationto the DFW ASEE

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 Prepared for Presentation to the DFW ASEE

“If everybody’s thinking alike, then somebody’s not thinking.”

- G.S. Patton


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


Part 1

Managing Scope When Breaking New Ground


Context

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


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


Product Definitions: Tree Metaphor

Domain

Customer task

Featureleaf

branch

trunk

Domain

Customer task

FeatureComplete return

Print tax return

Print

Highest level of Abstraction

Lower levels of Detail


Customer Task

Feature (Level 1)

ProSeries

Domain = “Print”

Lacerte


Scope Completion - Tracking Scope Units

0

50

100

150

200

250

April

May

June

July

Augu

st

Sept

embe

r

Oct

ober

Nov

embe

r

Dec

embe

r

Janu

ary

2007

Febr

uary

Mar

ch

April

May

June

July

Augu

st

Sept

embe

r

Oct

ober

Nov

embe

r

Dec

embe

r

0

50

100

150

200

250

M1 - July M2 -November

M3 - March M4 -September

M5 -December

MlestoneCumulative

ActualCumulative

PlannedM1 - July 5 11M2 - November 29 68M3 - March 80 109M4 - September 160 189M5 - December 188 232

Milestone View

Monthly Trending


Aggressively Focus on Learning

Plan

Execute

Track

Adjust

Feedback / Issues

Monitor / Learn

Repository- New Scope is Discovered- Operating Mechanism to feed prioritization/planning


Tracking the Unknown – Chart What We Learn

New scope

Baseline Scope(232 Scope Units) 0

510152025303540

Baseli

ne

Octobe

r

Novem

ber

Decem

ber

Janu

ary 2

007

Febru

ary

March

April

Newly Identified Scope Units


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


Part 2

Simple Tool: Resource Allocation


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


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


Summary Worksheet Header – By Team

Schedule period begins 9/2/2006Period ends (code complete) 12/31/2006# schedulable days 85less buffer 5%Baseline days available 80Work days remaining 69ProSeries Resource Summary Team A Eng Team B Eng FQA - Plano SQA - PlanoAE-Plano: IDS Tools UCD Web - OSGAE-Plano: Data MigrationsTotal capacity in days 1168.00 855.00 960.00 695.00 614.00 745.00 626.00 380.00Total days booked 702.00 242.00 706.50 396.00 216.00 223.90 118.00 0.00Days available (overbooked)based on est'd work only

466.00 613.00 253.50 299.00 398.00 521.10 508.00 380.00

Days available (overbooked)excluding work completed

420.25 539.00 222.25 286.00 384.00 480.10 453.00 345.00

Person days of work completed 86.25 11.00 99.75 61.00 48.00 13.00 14.00 14.00Person days of work remaining 615.75 231.00 606.75 335.00 168.00 210.90 104.00 -14.00Total % completed 12.29% 4.55% 14.12% 15.40% 22.22% 5.81% 11.86% n/a

Team C - QA Team D Team E Team F Team G Team H

• 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, %


Summary Worksheet Detail – By Person

Team Member Functional Group Baseline days available

Overhead Time Scheduled days off

Actual days available

Days Booked

Days Completed

Days Remaining

Days Avail by calendar

Days Avail (Over)

Fred Team B Eng 80.00 0.00 0.00 80.00 21.00 2.00 19.00 50.00 59.00Sue Team B Eng 80.00 0.00 0.00 80.00 21.00 1.00 24.00 45.00 59.00Joe Team B Eng 80.00 0.00 0.00 80.00 95.00 5.00 90.00 (21.00) (15.00)Randy Team B Eng 80.00 0.00 0.00 80.00 45.00 4.00 41.00 28.00 35.00Akim Team B Eng 80.00 0.00 0.00 80.00 80.00 5.00 80.00 (11.00) 0.00Sally Team A Eng 80.00 0.00 15.00 65.00 67.00 3.00 64.00 5.00 (2.00)Bill B Team A Eng 80.00 0.00 0.00 80.00 73.00 6.00 67.00 2.00 7.00Bill S Team A Eng 80.00 0.00 0.00 80.00 41.00 2.00 35.00 34.00 39.00

Name Team

Initial DaysAvailable

Planned Time Off

NetDaysAvailable

Planned ExpandedTotalETC

AvailableRemaining


Project Detail Worksheet

Initative Resource Name # Days Days Done

Days Left

Team A Eng Project 31 XYZ Fred 5 3 2Team B Eng Project 31 XYZ Sue 5 5Team B Eng Project 31 XYZ Joe 10 7 0Team C Project 145 ABC Randy 3 2 1Team D Project 145 ABC Akim 5 5Team A Eng Project 145 ABC Sally 10 7 3Team E Project 145 ABC Joe 12 8 5

Team Project Name

PlannedExpended

ETC


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


Part 3

Product Line Development Learning Curve


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


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


A Pattern Approach

VariableFunctionality

VariableFunctionality

Shared Functionality

A B

C

A B

C

Pattern applies to:• Plans• Architecture• Product Line Definitions• Requirements• Design• Code• Tests


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




Essential Product Line Activities

Core AssetDevelopment

ProductDevelopment

Management

Each of these is essential, as is the blending of all three.


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.


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

earlier life cycle

reuse

more benefit

product lines = strategic reuse


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 covered-wagon-train.com from lewisandclark.org


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)


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


Appendix


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."

Documents

1 Prepared for presentation to the DFW ASEE Simplifying Program Management: Behind the Scenes of Three Targeted Improvement Efforts Underway at Intuit's