twitter2  fb2  in2

Ten Tenets of Fast Projects

Rate this item
(0 votes)
by Larry Pendergrass, Principal 

Blog #1 of 10 – Introduction and Tenet #1

Introduction

The business world is moving faster than ever, and every company is challenged to keep up with, or even surpass the competition in delivering great products [1]. Market windows come and go more quickly. Technology inflection points arrive with ever increasing frequency, and provide opportunities to lose or gain significant market share. The total lifecycle of essentially every type of product is shrinking, with the end of life usually out of the hands of the provider, and driven by customer choices. No matter how fast you are now, no matter how many improvements in speed you have made, if you are to survive as a business you must continue to increase the speed of new product introductions. You must improve in identifying a need, innovating to produce the best solution to that need with a clear competitive contribution, and then delivering that solution to the market place.

 

There are at least 4 reasons your firm must continue to improve New Product Development (NPD) speed:

  1. Beat the competition: Your competition is getting faster so you must also, or be left in the dust. Whether you are in a fast-growing industry (where early wins establish the leader) or in a slower growth industry (where revenue growth is less due to market growth and more from taking share away from competition) you must continue to improve product development speed or lose.
  2. Stale new products:: Your customers are changing, evolving and altering plans faster, and thus long development cycles may produce stale and less useful products by public release. The old method of discovering customer needs –creating product definitions followed by specification setting and then embarking on a long development cycle – will deliver a product that is too little and too late in today’s environment.
  3. Market windows are moving closer-in and shrinking, and you must either hit these windows or become irrelevant. In today’s business world, the required time-to-market, the time from discovery of the customer need to delivery of a product, is surprisingly short. Depending on your industry, this time may have reduced by 30% to 50% and even more during this decade [2].
  4. Cost of delay: The end of life for a product is out of your hands. The cost of delay in releasing a new product is real, is severe, and can be calculated in lifetime gross profit (covered later in “Tenet #5: Sharpen Your Prioritization”). If you delay projects, if your projects are slow, even if you hit the market window you will significantly reduce the overall gains to offset the development investment because the end of life is driven by the market. What’s more, you may have a reduced market share if you are later than your competition.

 

Although the exact recipe to developing products faster will vary from business model to business model, industry to industry and even over time, there are several key tenets (or principles) that can be described. These tenets will be true, useful and actionable for almost any business situation. My ten tenets for creating faster projects are:

  1. Align the organization
  2. Think in sprints
  3. Focus on the risk
  4. Reduce the portfolio
  5. Sharpen the prioritizatio
  6. Standardize the routine
  7. Decentralize the decision-making
  8. Monitor buffers and queues
  9. Communicate the purpose and status
  10. Remove the distractions

Tenet #1: Align the organization

Aligning the organization is a two part tenet. In order to successfully drive an organization to faster throughput times [3] , leadership must:

  • Align the organization through communication to create a shared motivation for this change
  • Align the organization through organizational design to allow for greater efficiencies and effectiveness

Aligning the organization through communication

Regardless of a firm’s present product development speed, talk of going faster will always raise questions and fears. Leaders say “we need to release products at a faster rate” and the organization hears “you need to work harder and put in longer hours”. If as a leader you want to move faster, one of the first battles you will have is motivating the organization to make the necessary changes.

Much has been written about change management [4], an important topic and well worth the study if you are faced with driving significant change. In this limited space I will focus on two essential elements: “Learn together why we need to change.” and “Create our guiding coalition.”

In order to successfully motivate a whole organization toward the changes necessary to move faster you must identify those leaders in your organization (and they are not always those people with authority) who will sway others once they are convinced. These people, including your leadership team, will become your guiding coalition. But first, they need to be convinced of the need for change themselves. And the best way to persuade this group of the need for change is to learn together.

Examine the question as objectively as possible. Benchmark your projects against a non-competing company in an industry close enough to yours so that the benchmarking is relevant. Ask what would happen if you did nothing. Ask what would happen if you improved speed by 30%. Get as quantitative as possible. Be as honest as possible. Look to the past for sample events, and look to the future for probable events.

I worked with a company recently that was interested in making a significant change in speed. Their targets were 30% improvement in the front end and 40% improvement in the back end of the product development process. They had been through several successful rounds of improvements already. In fact, you might say the organization was “change weary”. But once the guiding coalition was identified and began to examine the facts in detail, the team had to admit that more must be done. And these “change weary” leaders rolled up their proverbial sleeves and got to work. The guiding coalition was able to motivate the rest of the organization to shake off the weariness and envision greater corporate success at the finish line. At last check-in, the throughput time of projects in the pipeline was showing an improvement over historical numbers of about 30%.

Aligning the organization through organizational design:

First, by way of definition: Organizational Design is the effort to align reporting structures, roles, responsibilities, process, rewards and metrics with a given organizational strategy.

Organization design is both an art and a science. It is a science in that many have studied organizational structures and its impact, or at least correlation to success as measured in various quantitative and qualitative ways. And it is an art in that any organization involves people, so the results are very dependent on the culture, the historical issues, the personalities involved and many other variables that are difficult to measure or fully understand. There is no absolute “right” way to organize: any organizational design is a trade-off, improving some business interactions and processes while degrading others. The implication is that the organizational design you pick should solve the biggest problems of the day, while still allowing you to minimize or at least manage the new issues that will present themselves.

If you wish to design a product development organization for low running cost (cost per unit time ), you should drive toward maximum utilization of each person and any other costly resource. Many organizations are built this way. You may have everyone home-based in a functional group (such as “analog hardware engineering”) working on multiple projects, and loaned out to project managers on five or six projects. In this way you will drive high utilization of your resources, a seemingly efficient way to run an organization. Additionally, pooling similar disciplines together in such functional teams will provide backup, training and knowledge growth. (See Figure 1-1 for a chart of this organization.)

8may15-img 1-fig-1-2

Figure 1-1: Organization built for lower R/D budget (cost per unit time) [5]. Organized in pools of engineers of common discipline, borrowed by program managers. Engineers may work on 5 or 6 projects. This kind of organization is called a Functional Organization.

On the other hand, if you wish to design an organization for high speed, the functional organization described above is the antithesis of what you want. To achieve high speed, individual utilization levels should be closer to 75 percent [6] and each person should be dedicated to a very few, ideally one project. The project manager should have direct authority for all essential project personnel [7]. (See for example, Figure 1-2.) The downsides of this type of organization are that the running costs (cost per unit time) will be higher because of redundancy of expertise. Additionally, specialists in the group may not feel that they are getting the full benefit of their functional peers. (One solution to this problem, as implemented in one of my previous roles, is the creation of Engineering Forums, discipline specific gatherings where engineers are encouraged to interact, share knowledge and work on common problems with peers across projects.)

8may15-img 1-fig 1-1

Figure 1-2: Organization built for speed. Project manager has as direct reports all key personnel for the project. Group is mixed-discipline. Engineers work on very few projects, ideally only 1.

Inbound (or Strategic) marketing resources should be in lock-step with this project manager using aligned metrics and rewards, and the combined marketing and R/D team should be sent out to the field in order to more directly understand the real needs of the customers by observing them doing their jobs. This activity will lead to greater innovation and improve speed.

Aligning your organization in this way ensures a focus of the entire team along a single goal: getting a specific new product into manufacturing to meet or exceed performance expectations, rapidly and predictably. While it may cost more money as measured by burn rate (cost per unit of time) to run NPD in this way, the faster throughput times for your projects will pay off increased lifetime gross profits. Additionally, you may find as I did that since the projects were executed faster, even with higher expense burn rates the total project expense cost was not greater.

For most industries, and it’s almost universally true in high tech industries, it is “penny wise and pound foolish” to organize your product development engines for low burn rate cost with maximum utilization of people. The price you pay in lost gross profit of slower projects completely swamps out the money saved with higher utilization.

For higher speeds from your NPD process, you must align the organization in two ways: (1) with communication to motivate for the change and (2) with structural changes, reporting, roles, responsibilities, incentives, metrics and the like. Both of these types of alignment are essential to driving toward greater throughput from your system.

In my next blog, “Tenet #2: Think in sprints”, I will show why thinking in sprints will allow you to drive faster projects and produce products that hit more accurately the needs of your customers.


[1] Note that while most of what we will discuss in these blogs apply to developing both products and services, for brevity’s sake I will simply use the term “product development” and assume “service development” is implied.

[2] See for example the HBR article “Six Myths of Product Development”, by Stefan Thomke and Donald Reinertsen https://hbr.org/2012/05/six-myths-of-product-development Also see http://www.strategy2market.com/Preston-Smith/Articles2/New-Product-Development-Fast-Cycle-Time.html

[3] Although cycle time is often used interchangeably with throughput time, cycle time is actually the period between product releases, the average time between two products coming out of the end of the product development pipeline. Throughput time is the time it takes to get through the product development system. I will use throughput time throughout this blog, only calling on cycle time when I wish to refer to the period of subsequent product releases.

[4] See for example my Ten Tenets of Change Management” available on the TechZecs, LLC web site at: http://techzecs.com/images/larry_ten_tenets/Ten%20Tenets%20of%20Change%20Management%20Apr13.pdf

[5] Note that this may give low cost per unit time, but not necessarily lower cost expense per project, and it is likely to reduce the overall lifetime value of the project as we will see.

[6] This will be discussed in some detail in “Tenet #4: Reduce the portfolio”

[7] An extreme version of this is the so-called “heavyweight team”. See for example “Organizing and Leading "Heavyweight" Development Teams” http://www.auburn.edu/~boultwr/8heavytm.pdf

Leave a comment

Make sure you enter the (*) required information where indicated. HTML code is not allowed.

Corporate Headquarters:

TechZecs, LLC
1730 Kearny Street,
Suite F-3
San Francisco,  California
94133 USA

Principal and Founder

Dr. Scott S. Elliott
Telephone: +1.415.830.5520
Email: scott.elliott@techzecs.com
           info@techzecs.com

Grab our contact information

qr-linkUsing your smart phones, open your QR Code reader and quickly scan this image to save our contact information automatically .