<-- LOCAL CSS -->

banner_stats



Abstraction factor analysis improves product and software development

Contributor: Terence T. Burton
Posted: 10/24/2012
Terence T. Burton
Rate this Article: 
Be the first!

How a new approach to product and software development can help you keep projects on track

Many professional, knowledge-based processes do not lend themselves to the traditional linear waterfall approach to improvement such as DMAIC. The result can be project overruns and overworked staff. Here's how a new approach called Abstraction Factor Analysis can help you understand what's going wrong and why.

There have been many attempts to improve new product development and software development by porting over and applying Lean manufacturing tools such as value stream mapping, kaizen, 5S, flow and bottleneck management, agile thinking, etc. Many of these attempts waste valuable time, are met with resistance, fail to address true root causes, and are often short lived.

Why? Because these complex creative processes include a lot of unpredictability, engineering judgments vs. hard data, a high degree of informal activities underlying a formal process, and fuzzy cause-and-effects in space and time.

The philosophy of continuous improvement is very applicable, but improving these high complexity processes requires nonlinear thinking, creativity, and adaptive improvement methodologies.

In professional, knowledge-based processes there exists a much higher content of people-to-people innovation and people to technology interactions that do not lend themselves to the traditional linear waterfall approach to improvement (e.g., plain vanilla sequential DMAIC).

This article discusses one of several nonlinear process improvement approaches called Abstraction Factor Analysis that has generated new levels of success with clients in improving new product development and software development.

The Typical Scenario

Walk into the majority of product development and software development organizations. What are a few of the obvious practices that we are likely to find?

  • There is a much higher perceived workload of projects than the resources available to execute and complete projects on time and on budget. Schedules are artificially set aggressively to achieve approval for revenue plans. Schedules and priorities are in a state of constant flux. Yet when one looks at project activities and flow much closer, over 80% of the time consumed is wait time - waiting for something to occur (stalled, idle time);
  • Requirements are either misunderstood, incomplete, or characterized by a moving target of feature creep, added functionality, and "drive by" engineering, causing many rework loops in individual projects. In the case of software, development is occurring before hardware is developed or before many critical requirements are even known;
  • Projects are planned and executed through shared teams of resources, often from different functions, business units, and physical locations. This situation always creates overloaded resources, conflicting priorities, the cannibalization of resources, and weak system capabilities to manage and smooth out constraints. Additionally, there are always integration issues as the individual elements of development come together;
  • There are meetings where people discuss very technical and unactionable judgment lists of why projects are behind, and also many perception-based judgments about how to realign individual activities and get projects back on track. These decisions are made without understanding the full impact on all projects, resources, and schedules.
  • There is the unplanned workload for sustaining engineering and/or software maintenance, test, and debug activities, or customer field issues that create resource distractions from gate approved projects.
  • There are conflicting expectations and performance metrics that drive behaviors to do things at a business unit or project level that are totally misaligned with aggregate company objectives. Executives and program managers learn about too many problems after they occur, or when they are about to occur with no opportunity for proactive recovery;

The typical list is much longer but sufficient for this article. Also, these observations are more prevalent in smaller and mid-sized organizations than in larger organizations with an abundance of resources to dedicate to programs.

One challenge that clearly stands out in product and software development is the continuous prioritization and efficient use of the right resources to keep projects moving. One of many complex challenges - simple in concept, difficult in practice.

Abstraction Factor Analysis

Abstraction Factor Analysis is a fact-based approach to understanding and evaluating the utilization of shared resources on development projects. The abstraction factor itself is a measurement of the number of steps a resource is away from the executive development program manager responsible for the successful completion of a project.

An abstraction factor of 1 represents a team resource that is a direct report; an abstraction factor of 9 represents a team resource that is several functions, business units, and site locations away from the executive development program manager.

How many of your projects are suffering delays?

The higher the abstraction factor, the more likely a resource will receive invisible direction(s) from others in the abstraction factor chain that are in conflict and undermine the executive development program manager.

How to Conduct the Analysis

To initialize the analysis, we display the portfolio of gate-approved projects and list the team members and other resources involved in each project. In effect, we create a matrix for each live project that resembles the matrix below:

Next we compare the matrix to the organization chart and calculate the abstraction factor for each person, for each project. We also include other critical project data (stage/gate status, budget, actual time reported by individual by project, development complexity, etc.) in the abstraction factor matrix.

Now we have a baseline of quantifiable data to evaluate project status and resource utilization. We are able to draw valuable conclusions when we begin correlating abstraction factors and actual vs. planned resource utilization back to project status and potential lost revenue.

Using simple Pareto analysis, scatter plots, regression analysis, and other simple graphical and tabular analytics, it demonstrates with facts that the projects furthest behind schedule that are causing high lost revenue have high complexity and high abstraction factors, resources that are actually working less than planned because they are being directed to work on other things, and the wrong resources with the wrong skills assigned to projects.

Abstraction Factor Analysis also provides the ability to drill down to specific projects and individuals and measure actual vs. planned resources consumed, or if we have the best resources assigned to the highest risk programs. Using this approach, it is not unusual to find that actual development time might be as much as 30%+ below planned development time at any given point.

The opposite may be true where a project is resource overloaded at the expense of all other projects in the portfolio. Both situations create significant project delays, design process quality issues, budget overruns, and late time-to-market. Abstraction Factor Analysis also provides a residual input into future resource planning and talent development.

By the way, these typical findings are not a slam at executives, program managers, and resources that are usually working 120% to bring projects to market. Programs are never late because people are not working hard or that they are intentionally inefficient. It is a limitation of the development process, and our inability to identify the root causes of problems with our normal senses and traditional approaches to improvement.

Managing the Abstraction Factors

Now we have also created a process where we can manage shared resources more effectively on an ongoing basis. We recommend a two tiered approach to development leadership:

  • A New Product/New Software Development Steering Committee that conducts a higher level review of projects vis-a-vis revenue plans on a monthly basis, and makes strategic commitments to project resources;
  • A Weekly Program Managers Core Team that conducts collaborative reviews of projects, discusses particular shared resource issues, and resets the process for the next few weeks out.

This is a gross oversimplification of their total specific roles and responsibilities, but the approach works well. Abstraction Factor Analysis equips program managers with the ability to chase down gaps and root causes of planned vs. actual resource contributions by project on a week-to-week basis and reset resource commitments.

Over time, a number of patterns arise about the inefficiencies of shared resource practices such as the common inflection points that drive the portfolio off track in the interest of a single project, or the recurring weak abstraction streams in projects.

Again, executives and managers in the abstraction streams operate with the best of intentions, but they are blind to the impact of their staffing changes on the total development portfolio. The largest advantage of this approach is that it replaces the informality of managing a complex process with actionable facts and analytics in a formal collaborative leadership environment.

Abstraction Factor Analysis has applications in several other high complexity-high unknown transactional processes such as the global supply chain or streamlining emergency room operations in a hospital. The goal is to drive down the abstraction factors, personal leadership interventions, and inflection points through total portfolio management, organizational change, and true empowerment of program managers and teams.

Improving Product and Software Development

Abstraction Factor Analysis quantifies the complex problems of shared resources and provides a more scientific entree into the right corrective actions. Without disclosing any specific client information, there are a number of improvement opportunities that have been implemented based on the hard evidence of Abstraction Factor Analysis.

Below is a partial list of actual improvements implemented in product development and software development. Notice their relevance to the overarching philosophies of Lean and Six Sigma:

  • Continuous customer collaboration (requirements stability)
  • Co-location of key technical resources into clustered work groups (dedicated cells)
  • Continuous monitoring of actual vs. scheduled individual/team time (line of balance LOB)
  • Elimination of inflection points (managing bottlenecks)
  • Paired development practices (shadowing and mistake-proofing)
  • Interactive development (empowered teams)
  • Smaller bits of development with more frequent reviews (pull and one piece flow)
  • Sustainable development process (continuous flow)
  • Visual communication and dashboards (visual management)
  • Structured program management practices (plan discipline)
  • Frequent design reviews (daily team meetings, TWI)
  • Green-Yellow-Red management practices (proactive problem solving)
  • Development shut-downs and recalibrations (quality at source)
  • Clear metrics and planed vs. actual progress (timely closed loop feedback)
  • Business case reviews, lost revenue due to late projects (ownership)
  • Develop vs. test quality into the process (prevention vs. detection via inspection/test)
  • "Fast Track" development, validation, and test (cycle time reduction, risk analysis)

The largest advantage of Abstraction Factor Analysis is that it replaces the informality of managing a complex process with actionable facts and analytics in a formal collaborative leadership environment. The goal is to drive down the abstraction factors, personal leadership interventions, and inflection points through total portfolio management, organizational and process improvement, and true empowerment of program managers and teams.

Summary

The nature of product and software development is not steady state and there are literally dozens of opportunities for improvement in product and software development. This article has addressed only the shared resource issue, albeit a huge opportunity. These are highly complex and innovative processes that will always have unplanned variation creeping in.

This is the nature of human multiple input, multiple output (MIMO), multiple input, unknown output (MIUO), and social complexity processes. Design and software engineers have a max capacity (like a machine). When people are constantly overloaded, they find workarounds or multitask to a point where everything they are attempting to do becomes less efficient.

The answer is not in restraining these people to a rigid standard development process. And "do your best" or "sorry, you're going to have to work harder" is not leadership. Organizations must create the ability to sense-interpret-decide-act-and monitor (SIMDE) within their development environments as unforeseen events begin to appear.

Abstraction Factor Analysis enables executives and program managers to make better fact-based decisions regarding the assignment and utilization of shared resources, visualizing workloads of various planned scenarios, and optimizing revenue opportunities through a more intelligent and analytics-based approach to shared resource management.


Thank you, for your interest in Abstraction factor analysis improves product and software development.
Terence T. Burton
Contributor: Terence T. Burton