Friday, December 7, 2012

Measures Matter

The metrics we chose to measure matter because they make a difference in whether or not we win.  They make a difference in whether or not we achieve our vision, our strategy and our objectives.

The reasons to measure are pretty straightforward because as Tom Peters says, "What gets measured gets done." But selecting what to measure is bit more complicated and just as critical.  For example, if you're going on a trip from New York to Paris, you may want to get there fastest, or cheapest, or in the most gracious style. If fastest, then you measure speed and total duration of the journey.  If cheapest, then you measure dollars.  If in the most gracious style, then you may have to first understand how you would know.

Similarly, in business, what you measure yields vastly different methods for the same goal.  The Oakland A's shared every baseball team's goal to win but didn't have the budget to recruit players with great batting averages, the typical metric. They found another way to win by measuring something different. They began recruiting players based on on-base percentage and slugging average because they found that these measures were better indicators of offensive success. And sure enough, they won more. Measuring something different from the other teams led to a competitive advantage.

In another example, rather than focus solely on revenue per seat metrics, Southwest Airlines began measuring aircraft turnaround time at the gate to drive a reduction in unit costs. It seems obvious but this change resulted in a competitive advantage for them.

On a professional level, what are you measuring today to determine performance for your self, your department, your charter, your business? How could you find another way to win by measuring something different? Do the current measures drive the results and success that you want?

On a personal level, what are you measuring?  The number of things accomplished, the number of people influenced, business strategies affected? What else could you measure that would result in a better life?

Wednesday, December 5, 2012

Core vs Context: Three Common Myths and Three Useful Tools

The phrase "core vs context" is part of the common vernacular in the business arena.  However, sometimes, the things we're sure of could use a closer examination.  It's in this spirit of seeking to understand that I re-examined Geoffrey Moore's core vs context model in his book Dealing with Darwin. First, a bit of background.

There are Two Major Distinctions
The 4 quadrants are based on 2 major distinctions:
  1. Mission Critical vs Non-Mission Critical measures whether a process shortfall creates a serious and immediate risk to revenue.  If it does, it's Mission Critical. 
  2. The Core vs Context categorization addresses whether the process creates a differentiation that wins customers.  If it does, it's Core.  If it doesn't, it's Context. Both Core and Context are Mission Critical but Context processes do not provide a strategic differentiation from competitors.

There are Four Quadrants
  1. Invent: Revenues aren't big enough to be mission critical but inventing is core to the company's future new products.
  2. Deploy: When the innovation is ready to be deployed it moves to this mission critical core quadrant.
  3. Context: The focus here is on managing mission critical processes as context at scale.
  4. Offload: Offloading non-mission critical processes frees up resources to move back to Quadrant 3 and therefore resources in 3 to move back to 2 and so on.
Three Common Myths
  1. "Core" means the majority of our revenue comes from the core.  Actually, "Core" means that the process is mission critical and the company expects the highest returns because the initiative gives them distinct competitive advantage. 
  2. If my company is looking at Core vs Context, I'll lose my job.  Ideally, you'll be able to move up the quadrant scale.  If you're currently working in 4, look for opportunities in 3.  You'll know a lot about downstream impacts that will likely be useful.  Similarly, if in Context, look at opportunities in Core. You're understanding of how to manage mission-critical processes at scale will help when deploying a differentiation at scale.  You could also move the other way.
  3. Offloading and Out-tasking are the same thing.  Out-tasking means taking some number of the tasks performed in a role or department today and moving them to an outsource which frees up internal capacity for other things.  Offloading is much larger in scope.  A good example would be the recent divestiture of the Juarez manufacturing operation where the responsibility for manufacturing the product was outsourced.
Three Useful Tools
Geoffrey Moore addresses some of this but not all. When you're working on something whether product, project or process, it's useful to know which quadrant you're working in because that suggests that certain tools will be more useful than others:
  1. When managing either in the Invent or Deploy quadrants, Agile development methods help with the uncertainty that goes along with going from the first time a new product, process or project is introduced to scale. Introducing products into new markets such as Brazil or Russia are useful examples.
  2. When managing in the Context quadrant, Moore covers the 5 levers of driving cost out of the process.  Centralizing processes under one roof and standardizing them is followed by modularizing and optimizing the process. Consolidating all project and program management functions in one place and standardizing the program management lifecycle across all functions would be a potential example.
  3. When managing in the Offload quadrant, the focus is more on de-risking the process by setting clear expectations with outside sources through service level agreements or contractual agreements.  The recent divestiture of the Cisco Scientific Atlanta Juarez manufacturing operation is an example.
If you'd like to know more, Cisco figures prominently in Moore's book, Dealing with Darwin.

Monday, December 3, 2012

Oobeya: The Project Control Room in a Virtual World

Oobeya literally means "Big Room" and is used to mean "Project Control Room". The basic concept of Oobeya of bringing visualization to knowledge work to shorten project cycle time and increase quality is not a new concept. But putting that capability in one room for all functions and using that room as the SSOT (Single Source of Truth) is rare.

The room's walls include Boards set up in cascading order for: Corporate or Project Objective--> Target or Expected Output--> Metrics--> Action Board or Concurrent Schedule Board--> Decomposition Area--> Issues (includes Potential Issues).   All of these are clustered in clockwise order around the prototype or end state.

Some of the most compelling concepts in Oobeya are:
  1. At the center of all of the big room is a visual representation of the goal, the end state, the output that the team is responsible for.
  2. The concurrent schedule board fosters concurrency similar to that of APEX, a project management collaboration tool used to develop cross-functional schedules for acquisitions at Cisco.
  3. The Decomposition Board show hot items (things that were coded red on the Action or Schedule Board) that need attention.
  4. The Issue Board shows the types of critical problems that can only be resolved by higher level management.  The person referred to must respond within 48 hours.
While this method is easy to use at home or in business settings where all team members are on-site, is this concept relevant in an age of projects that are distributed globally?  The same needs that an Oobeya satisfies exist, but they may need to be met in different ways.  With certain modifications for working from home, working remotely and global workers, it may be possible to leverage this project control concept to a virtual environment.

For example, APEX is a concurrent scheduling tool that allows all functions to create a project schedule in the same place and view it together.  It may also be possible to create an Oobeya at each site.  Signage Tools could be used to remotely refresh the board in rooms across the globe.  If collaboration portals were organized according to the Board Flow above, it may also be possible to use them to re-create this flow.

A virtual work environment certainly adds a layer of complexity or implementation difficulty to the concept but it doesn't take away the need for a project control room and for shorter project cycle times.