notebook

Look forward (not back)

A core principle of fast teams is that they spend more time looking forward and less time looking back.

They know that pull-in opportunities are in the future and that looking back for fault or blame is a waste of time. When they do look back it is to learn from mistakes or poor estimates, so they can improve the remaining tasks in their schedule.

The second core idea is that they push ownership out to the work package level. These are clusters of work that integrate together and lead to a major customer focused milestone or project integration point. The core team manages the project and the program director manages the core team. Part of taking ownership for these work package owners is to look forward in their area and challenge their own assumptions; 

1. Am I being to aggressive or not aggressive enough?
2. Have I missed anything?
3. Can I eliminate anything?
4. Can I do things differently or do things in parallel?
5. Where is risk highest? ...and
6. Have I put enough contingency time in?

Accelerate transfer

For many years we have worked with clients on “process research and development projects.” 

These are characterized by projects to create (in most cases) bleeding edge manufacturing capability for a complex fabrication process. These have included process development projects on semiconductor IC node development (28nm, 22nm, 20nm, 14nm), different types of solar fabrication (essentially a derivative of semiconductor applications), biomedical and life science processes, MEMS, and even a quantum computer chip fabrication process where the max yield was expected to be a whopping 1% with a total volume of 10. In this case, the prototypes were the final product! 

Some of these projects have been in large multi-national corporations and many have involved small venture backed start-up teams trying to do what the big guys wouldn’t or couldn’t. It usually involved the simultaneous creation of new manufacturing tools, application of new materials research, bleeding edge manufacturing process, and development of factory and tool automation/information systems.

They all shared a common attribute; the transfer demarkation line separating development and operations was rarely clear and poorly defined, the hand-off roles were unclear, and upstream research folks were usually unwilling to let go of their babies and give the process to operations; instead, always wanting to conduct that final improvement experiment to get a that final 1% increase in Yield, Performance, Cost Reduction, or Reliability. 

The problem was that the “1%” was in the diminishing returns part of the curve and the improvement rarely out weighed the benefit, but ended up costing a lot of time. Most never had the visibility to see the bigger picture and the context for the endless improvement cycles and how these eat up critical ramp time.  

Here is a problem statement we saw in one Greentech start-up:

• How to characterize the process to make it repeatable, in the fastest possible time frame?...so it can scale-up to prove the economics of our investment

The problem is always to find a way to rapidly transition from the “lab” to the “fab,” it is especially hard when the technology involves expensive capital equipment where you are forced to bet a lot of money with very little information, because if you wait to have more information… you could miss a critical market/technology window. Large companies like Intel have a similar problem; just at an exponentially larger scale. It is relatively “easy” to make a few things in a lab, but much harder to make millions of them in a production fab at costs where you make money.

Measuring maturity

Many of our clients measure how well teams have adopted the FTTM Planning Method. We’ve seen many different assessment systems. 

We’ve developed a common and reusable metric by which teams can assess and track their growth or “maturity" in using the methodology on multiple projects. Clients that use this system are typically running FTTM on tens if not hundreds of concurrent projects. 

But lets not forget, the goal is to accelerate projects and finish them on or before schedule, per customer requirements. Matturity Level (ML) is less important than actual project performance. However, we have found teams that have achieved Maturity Level 3 (ML3) are most likely also those teams finishing fast.

These (above) are the process maturity learning cycles teams migrate through over time. They are serial and a team can’t jump a step. Starting with ML0; which indicates no use of FTTM methods. A team can achieve ML1 in 2-3 weeks, if they are focused and committed, while ML2 and ML3 are much harder to achieve and take significantly longer to realize. Over time, the idea is to get a team independently (i.e. without outside help)  accelerating the schedule and continually improving their skills and methods.

“Innovation can’t be managed”

Many projects we work on involve bleeding edge innovation. The most common push-back to planning these projects is that, “Innovation can’t be managed.” The proponents of this notion believe that, “Ideas happen when they happen, and that it is impossible to program these out over time with any reasonable degree of confidence.” Therefor, it is a “waste of time” to plan.

The problem with this logic is that these projects have investors or shareholders that expect some degree of predictability about when they will see a return on their investment. Not planning is not an option in the real world. Further, we reject the view that innovation can’t be planned. We know this to be false because we have worked on many projects around the world where we did in fact program innovation and accelerated market entry of cutting edge technology. It can be done.

We have even achieved breakthrough cycle time on advanced semiconductor node development (i.e. <=20nm) where the manufacturing process was being developed while basic materials research was still being done. Simultaneously, tools (semiconductor manufacturing equipment) were being developed and a customer’s product was being designed using the new manufacturing process. A new manufacturing process, new tools, new product design, new design software (PDKs), and a new manufacturing facility was being started-up all at the same time. Even in this environment, we were able to plan (predict) and then manage the project to an accelerated pace.

Smith and Reinertsen discussed this idea in their book “Developing products in half the time.” They point out that 90% of “innovation” in projects is known and most of the time, less that 10% of the project involves real “new” innovation. The trick is to isolate this 10%, get it focused and properly resourced with the right skills, and to make sure it has a wide window of time; while you manage the remaining 90% using conventional methods. We also have observed teams becoming transfixed on the 10%, and wait for the solution; and when it comes, they end up behind schedule because they failed to get the easy part (i.e. the other 90%) done on time.

Learning Cycles

Innovation can be planning using the Learning Cycle concept. I critical component to innovation is learning from failure; the faster the failure, the faster the learning. You have heard people say, “Fail fast,” and this is the idea in rapid innovation projects. So how does one plan what they don’t know?

We can break a learning cycle down into some generic steps; plan, do, check, act (above). How do we know how long each of these steps will take if we don’t know the results of the experiments we have yet to perform?

Why change?

When implementing improvement systems that impact business processes and require methodology and tools; you must first define the problem you are trying to solve. Often we see organizations start with possible solutions without first define the business problem they are trying to solve. They get enamored with technology (perpetuated by software vendors) and lose sight of the desired end-state, since the end-state was never defined. In the worst cases, the end-state is defined by software vendors as the attributes of their software solution.

The ‘end-state” can also be called the “Why Statement.” Why do you need to make the change? What is not working the way you want it to now? What is the gap between the as-is and should-be? What if you didn’t make any changes, what would be the impact? The “why?” statement is also the overall goal for making the improvements in systems and processes.

Next you must define the Improvement Objectives. These are the 3-5 specific outcomes you want/can measure with the improvement intervention. We typically prioritize these objectives using a pairwise comparison of each objective to determine which objectives are the most important. This is a metric by which the improvement program can be measured to determine if it is achieving the goal. In other words;

• What is not working and what would it look like when it was working right?

FTTM is more than being on time

We work with two types of technology companies in Silicon Valley; 1) established companies with a portfolio of new products being released from an ongoing development pipeline, and 2) with new venture start-ups where the single project is in fact the company. Both need FTTM (fast-time-to-market) thinking in order to hit the optimal market window, yet both have very different drivers.

This is the FTTM Model we use with clients that have a portfolio of products in development (above). The driver is to accelerate “Time-To-Break-Even.” The fastest teams we’ve worked with measure success by quantifying the complete life-cycle of development from team formation to break-even. 

Slower, more siloed companies, hand off development such that the core engineering team rarely see when, or if a product actually achieved its expected return on investment or even broke-even in the market. Having this connection to financial performance is a key element of accelerating innovation cycle time.

Manage pipeline as lateral system

Causing projects to finish on time, or even making them faster is the “back-end” of the new product execution system.

Deciding what projects to do, and then aligning them with business strategy and available resources is the “front-end.”

The effectiveness of the front-end of an integrated “lateral system” drives the chances of success at the back-end in terms of Fast-Time-To-Market (FTTM) performance. In other words, you can’t solve the FTTM cycle-time problem unless you also deal with the system that feeds it with new projects.

It is critical to deal with this horizontal work flow as one integrated system. Often ownership is parsed out to various functions, with no overall owner managing the portfolio of products from end to end. The classic functional silos of Marketing, R&D, and Operations point fingers when projects fail to be delivered on time.

When these systems work well, organizations have decision mechanisms to assess the impact of new projects on the capacity of the execution organization’s ability to deliver. They manage it the way one would manage a factory operations problem; by carefully balancing demand and capacity.

When capacity is not aligned, projects take longer to execute and in turn miss optimal market windows where their ASP and Margins are the highest. Growth is impacted. The chain reaction is to reduce resources across the board to lower burn rates, which exacerbates the capacity problems even further. We’ve also seen a resource and budget constraint placed at the back-end, while not simultaneously reducing the flow at the front end. Rather, the most effective new product development engines we’ve seen run it like one integrated system.

Say "no"

I recently read an interesting collection of Steve Jobs quotes assembled by Bruce Temkin. One in particular caught my attention;

• "And it comes from saying no to 1,000 things to make sure we don’t get on the wrong track or try to do too much. We’re always thinking about new markets we could enter, but it’s only by saying no that you can concentrate on the things that are really important."

Converge

 

Knowing when to converge is the trick. Converge too soon and you may end up with the wrong product, wait too long to converge and you run the risk of delivering too late.

In order to deliver the right product at the right time, best practice is to permit divergence for about 1/3 of the overall development time frame. By divergence I mean this is the time where you define the problem you are trying to solve and explore all the possible solutions, with no limitations — the goal is to define the killer product during this time frame. 

Some try to avoid convergence in order to keep all their options open, and fear convergence on the wrong thing… these projects also tend to miss their target windows since finite resources are never focused on delivering the highest value functionality. In an attempt to do all they achieve none.

Why accelerate?

 

It seems odd to ask this question (Why accelerate?), since it’s obvious in the technology business that you die if you don’t release new products faster than your competition. Fast teams know this reality and communicate the “need for speed” to the engineering teams. In slow environments, this critical information is insulated from the technical teams and only reserved for marketing, finance, and leadership forums.