notebook

Are Program Managers of any value?

I’d argue “no” for the most part, but there are exceptions. Let me defend this unconventional “opinion.”

Rate of adoption... to becoming autonomous

Recently, we were asked by a client to define the factors that determine the duration needed to create sustainable change.

The key is to jolt the system, transfer, and exit rapidly. We know that any sustainable change must come from within the organization and can't be forced from the outsitde. We also know from experience that we have to place enough external pressure, for a sustain period of time, in order to change behavior patterns. We've learned that it is essential to leave behind the capability for continuous improvement.

The factors that contribute to becoming autonomous include:

1. Desire to improve (organizational seriousness and awareness/recognition of the current problem/need)
2. Full executive participation/engagement
3. Engagement of key technical stakeholders (team members)
4. Problem/project complexity
5. Skills of internal process owner(s)

More on this topic at my Sustainable Change post. 

Freedom to Act

 

Freedom to act, or in many cases “the lack of freedom” is a root cause of delay, apathy, and a general feeling of helplessness. Regardless of the position in the corporation, we see the “lack of empowerment” from the very top to the bottom of the reporting chain. This post is about a system we adapted called “Freedom Scale.” This originated from our best practice research into factors that drove speed — fast organizations empowered people with “freedom” to act quickly. Pushing power down the hierarchy increases speed to market.

Sustainable Change

Bob Biddinger used to speak about the, "Footprints in the sands of time." Or as Bob would to say, "There aren't any when it comes to real sustained change in organizations. The next tide will just wash them out." Why I wondered?

We developed this model to illustrate the things that need to be affected in order to create change, where there are still "footprints in the sand" months and years after an improvement intervention is implemented.

Two types of thought processes

Two Types of Thought Processes Script

We’ve observed two distinct types of thinking, the process mindset associated with producing many things requiring an understanding of volume, yield, and quality--and then a second thought process associated with projects; which have a start and finish and where something is created... when done the team moves on. However, with the former, the team stays and continuously improves it. 

Creating an Innovation Environment

On a recent client engagement we were faced with the problem of how to increase market share, while radically reducing the cost of innovation... in a mature and potentially a declining market segment.

The executive team interviewed people in a number major corporations to understand how they innovate. We suggested that innovation, at an individual or team level, is somewhat different than creating an environment within which innovation occurs. We advised that they understand how these companies created that environment. The question is, how do you manage the "system" that generates a pattern of continuous innovation?

This Fortune article about Google (Chaos by Design) describes how a group of people there created an environment that encouraged innovation. This was published in 2006, clearly we see the results of this strategy in 2009!

And here are some interesting quotes about innovation--Innovation Quotes (PDF).

Fast Autonomous Teams...drives speed

Fast Autonomous Teams

In this presentation I’ll discuss organizational structures we’ve observed in various development environments. Some generate slow development projects and others contribute to faster development cycle time.

Steven Wheelwright, at Harvard, described four types of product development team structures; 1) functional hierarchy, 2) lightweight, 3) heavyweight, and 4) autonomous. We’ve added speed and accountability to his model.

We’ve worked with all four configurations and many variations in between. We’ve learned to adapt the structure to the readiness the organization and their willingness to transfer power laterally to teams--away from the vertical or functional hierarchy.

Lets take a look at each.

Who "owns" the strategy?

 Define ownership after first defining what needs to get done...

"Organize around the work, rather than force the work to conform to the organizational structure..." said GE's Jack Welch. We've applied this concept to strategy mapping.

The strategy map (right) illustrates a 3-year Vision, its supporting Initiatives, and driving Strategies. Our focus was on defining the Strategies that would drive achievement of the Vision, rather than from an organizational perspective. Our view was from the Vision - out (i.e. where the business needed to go in three years), not from the Business Unit - in.

After defining the work flow, we then assigned ownership of each cross-functional initiative. This caused the senior management team to work together and cooperate on the common goal, rather than focus inwardly within the Business Unit "silos." Note that names and details have been modified so we can present the example.

What is the HOST?

We first found the term "host" being used by fast teams involved in our first best practice research project.

Host, as they defined it, is everything in an organization that is outside and around a team. The host can provision a team or it can interrupt it. Fast organizations design the host to "provide for" when resources, information, or "things" are needed by the team to be effective. For example, HP has always been good at this.

Slow organizations have interrupting hosts that place controls on teams, limit budgets, resources, information, and "things" -- efficiency is consumed by a team "working around" the system (or host interrupts). These interrupts are systemic and situational to projects. For example, the high walls of the marketing and engineering silos tend to be a systemic problem in most companies. It can also be situational and affect just a single project, these are easier to fix.

We use Force Field Analysis to identify the restraining forces and remove them to improve efficiency. Most people focus on the wrong stuff to improve efficiency, i.e. those "driving forces" versus the restraining forces. This concept is a foundation practice. 

The HOST can also be the management hierarchy. They are the first line provisioners to the team and can be the first line unknowing "interrupters." The host can also be stakeholders (internal customers) and other dependent functions like product lines whose hardware on which your software runs (for example). Host can also be all of the support organizations that support the development effort; legal, contracts, purchasing, HR, other design groups, and so on.

The team is clearly the people that go to work every day and work on "project" things. The most effective development teams are dedicated (i.e. 100% allocated to a single project for an extended period of time). As resources get multiplexed beyond 2.5 their effectiveness drops off dramatically. Most teams don't have the luxury anymore to have this level of dedication and focus. The more you multiplex the less you get!

Links | 3.4 Create a fast organization structure: fast provisioning with minimum interrupts | Provisioning hosts accelerate development projects | IBM's "Provisioning Steering Committee"

Define the process, then form the organization around it

Jack Welch at GE said something like this... "Organize around the work, rather than force the work to conform to the organizational structure..."

He was referring to the way most problems are solved in corporations; re-org, restructure, move some boxes on the org-chart, hire some people, fire some people... then wait. When this does not work, repeat the process. Call it empowerment and "delegating to the operating level" and "opportunities to develop your skills" and so on and so forth... 

Product development is a cross-functional lateral process, yet organizations continue to do it with vertical hierarchical structures. They force the laterally flowing process of development to navigate the hierarchy and cross over the white space between the functions

The result is slow cycle time and inefficient use of resources not to mention stress and tension as the interface points between organizations create friction. People behave the way they are measured, and when they are measured based on their functional performance (i.e. their silos) they tend to drive functional deliverables at the expense of product development results.