Simplifying Program Management: Behind the Scenes of Three Targeted Improvement Efforts Underway at Intuit's Professional Tax Division - PowerPoint PPT Presentation

Slide1 l.jpg
Download
1 / 32

  • 288 Views
  • Updated On :
  • Presentation posted in: Industry

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. “If everybody’s thinking alike, then somebody’s not thinking.”

Related searches for Simplifying Program Management: Behind the Scenes of Three Targeted Improvement Efforts Underway at Intuit's Professional Tax Division

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.

Download Presentation

Simplifying Program Management: Behind the Scenes of Three Targeted Improvement Efforts Underway at Intuit's Professional Tax Division

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Slide1 l.jpg

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


Slide2 l.jpg

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

- G.S. Patton


Agenda l.jpg

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


Slide4 l.jpg

Part 1

Managing Scope When Breaking New Ground


Context l.jpg

Context

  • Multi-year, multiple business unit program

  • New technologies

  • New processes

  • Mix of mature and newer products

  • Undocumented current state


Gaining traction l.jpg

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 l.jpg

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


Slide8 l.jpg

Lacerte

Domain = “Print”

Customer Task

Feature (Level 1)

ProSeries


Scope completion tracking scope units l.jpg

Milestone View

Scope Completion - Tracking Scope Units

Monthly Trending


Aggressively focus on learning l.jpg

Monitor /

Learn

Feedback /

Issues

Repository

  • New Scope is Discovered

  • Operating Mechanism to feed prioritization/planning

Aggressively Focus on Learning

Adjust

Plan

Track

Execute


Tracking the unknown chart what we learn l.jpg

Tracking the Unknown – Chart What We Learn

Newly Identified Scope Units

New scope

Baseline Scope

(232 Scope Units)


Lessons learned l.jpg

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


Slide13 l.jpg

Part 2

Simple Tool: Resource Allocation


Context14 l.jpg

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 l.jpg

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 l.jpg

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


Summary worksheet detail by person l.jpg

Summary Worksheet Detail – By Person

Total

ETC

Available

Remaining

Planned

Expanded

Name

Team

Initial

Days

Available

Planned

Time Off

Net

Days

Available


Project detail worksheet l.jpg

Project Detail Worksheet

Planned

Expended

ETC

Team

Project

Name


Lessons learned19 l.jpg

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


Slide20 l.jpg

Part 3

Product Line Development Learning Curve


Context21 l.jpg

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 l.jpg

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 l.jpg

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


A framework for software product line practice sm l.jpg

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 l.jpg

    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 l.jpg

    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 l.jpg

    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


    Mindset level setting slide we used background mindset l.jpg

    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


    Lessons learned29 l.jpg

    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)


    Slide30 l.jpg

    “Truth is what stands the test of experience.”

    - Albert Einstein


    Slide31 l.jpg

    Appendix


    Excerpt from software product lines practices and patterns l.jpg

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


  • Login