I attended your session on Portfolio management at Symposium last month. It was a very informative use of time. You mentioned using drivers and categories for demand management and I was wondering if you could provide me some more detail?

Kulasekhar Jayaraman – via email

Thanks for the feedback. The session was a lot of fun and I really enjoyed the discussions.

The Work Types and Drivers approach is a compromise that we came up with to address the disconnect between the nature of a work request or project and the motivator for the request. We were having continual debates about “discretionary” vs “non-discretionary”, BAU vs KTLO, etc. By implementing this dual category model, we ended up with a way of tagging projects in such a way that we could map a project to any set of definitions or criteria that we needed to. It provided the right level of detail to be able to provide the engineers, executives and finance with the appropriate split and sorts that they needed.

Here’s the summary:

Work Types

Keep The Lights On/Operational Support/Core

· Work required to keep the environment viable in its current state.
· Break/fix activities (“worked yesterday, doesn’t work today”)
· Repetitive activities such as backups, cleanups, etc.
· Proactive maintenance to prevent performance degradation

Technical Continuity

· Work required to address changing technical requirements.
· Application of non-critical support packs
· Upgrade or refresh of systems or platforms
· Responding to integration issues.
· Replacement of End-of-life products

Business Continuity

· Work required to address changing business requirements.
· Explicitly excludes any addition of functionality.
· Master Data Changes
· Content management
· Offer Launches and Updates
· Configuration-only Changes
· Organizational Changes

Minor Enhancement (Discretionary)

· Addition of, or changes to, functionality.
· Requires < 3 person/months of effort.

Major Enhancement

· Addition of, or changes to, functionality.
· Requires > 3 person/months of effort. Anything over 3 person/months should be scoped as a project and not as a change or work request

Drivers

The Drivers are intended to provide an additional level of categorization for reporting purposes. There is no hard restriction regarding which drivers may be used with which work types. However, every effort should be made to ensure that the categorization is appropriate. (eg: it’s unlikely that there would be many “Break/Fix” Enhancements or KTLO “Projects”.)

Legal/Statutory/Regulatory
· Work that is directly addressing legal, statutory or regulatory compliance issues.
Project
· Work that should be tracked as part of a defined project budget.
· If work is not part of a formally recognized project, the work should not use the “project” driver.
Stabilization (Most commonly used with KTLO/Technical Continuity)
· Work required to maintain or improve the stability of the environment.
· Expansion or extension of the environment to maintain the “status quo” as the business grows. (ie: to address an immediate or imminent need)
· Application of service packs
· Routine maintenance
· Vendor provided “dot” releases of application or OS software
· Replacement of “End of Life” products
Optimization
· Work required to improve the efficiency or performance of the environment
· Database reorganization
· Performance tuning
· System consolidation/decommissioning
Continuous Improvement
· Work required to grow or develop the environment or infrastructure
· Expansion or extension of the environment to address future needs (additional capacity/functionality 6+ months out)
· Platform upgrades
· Major Version upgrades of OS of Application software
· Incremental improvements to an existing architecture
· Process reengineering
Innovation
· Work which creates or facilitates a major change to the business or technical landscape
· Typically High Risk/High Reward
· New business models/major organizational change and/or introduction of a major new technology
· Replacement of a legacy architecture
· Introduction of a new platform, technology or operating system (not just a version upgrade)
Break/Fix
· Work required to address lost functionality (i.e.: “worked yesterday, doesn’t work today)
Drivers may evolve/escalate with time. For example, a hardware upgrade might be “nice to have” this year (“Optimization” or “Continuous Improvement”) but may become a requirement (“Stabilization”) next year as new versions of software or new business requirements are entered into the environment. In this type of situation, the work should be categorized based the current driver and not the future requirement.

While the list is somewhat geared towards IT, it can easily be adapted to an enterprise-wide list. We never came across anything that couldn’t be categorized using the list, but it did sometimes take a little bit of thought to find the right placement and combination.
Good Luck!