twitter2  fb2  in2

Ten Tenets of Fast Projects - Tenet #10: Remove the distractions

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

Tenet #10: Remove the distractions

It should come as no surprise that, without active management, the resources needed for NPD will have a strong pull away from projects and toward seemingly urgent and very important tasks. Some of these tasks will be as critically important as advertised, while others will have the illusion of importance due to their urgency. Keeping your resources focused on generating new products is not always easy, and this undertaking is made much harder for the smaller firms where everyone must wear many hats. Potential distractions abound, and I would like to break down these distractions into three buckets of possible recourse:

  1. Reduce: Distractions that should be anticipated and diminished, and ideally barred from utilizing your NPD resources.
  2. Plan: Distractions that can be handled proactively by appropriate planning or changes in roles and responsibilities.
  3. React: Distractions that unfortunately must be handled reactively by using your NPD resources.

Clearly those tasks that fall under Plan or React are not seen as adding zero value. These tasks should be done, but some of them will not add value to a given project and so should be managed for as little impact on the project as possible.

From my experience, the following are the major issues that draw heavily on some, if not all resources used in a NPD processes. I have also made an attempt to put each of these into one of the three buckets listed above.

 

Figure-10-1

Table 10-1: Examples of distractions, and the action categories in which they fall

 

This is of course not an exhaustive list. I am sure your list would be much longer. But this will suffice for illustration.

Reduce or Eliminate: Let us first address those issues we should work to reduce or eliminate, and how a NPD leader might make this reduction. On our list are checkpoint presentations, too many meetings in general, too many requests for reports, and too many non-essential emails. Recall that the job of an NPD leader is to manage sponsorship, to manage partnership and to manage the projects. Having already read my “Tenet #9: Communicate the purpose and status”, it probably won’t surprise you that I don’t recommend eliminating all of these forms of communication. But the quantity of communication that adds little value typically too high and reduces the effectiveness for an organization. Reduction of this “noise” can create dramatic gains in freed-up project time. Additionally, the burden for the bulk of this communication needs to be pulled off of the backs of the people that can truly move the project forward. Here are a few possible solutions:

  • Checkpoint presentations: Consider having smaller checkpoint meetings with attendance by only the key decision makers. If this has become a big event in your company, shake up the culture with a major change in the expected delivery structure. Release a clear and brief guide of expectations for presentation content, driven by the needs of the decision-makers. Try to eliminate any and all involvement of key team members[1]. Keep this from being a review of all things about the project and present only key accomplishments, key issues and risks, and key questions. The checkpoint meetings then become a quick check-in and a decision-making meeting rather than a full “song and dance”.

  • General meetings: All meetings should fall into one or several of the following purposes:

    • Make decisions
    • Deliver urgent critical information
    • Provide group training
    • Drive teamwork

    If your meeting purpose doesn’t fall into at least one of these categories, you should ask if another form of communication (less invasive and more time efficient) should and could be used. ”Driving teamwork” tends to be a primary reason given for many of the typical Monday morning staff meetings, and sometimes improving teamwork is a very real need, especially if the team is new or significant changes are underway. However, all too often teamwork is used as an excuse for a meeting that has become habit, and may no longer be necessary with the same frequency.

  • Report requests: Some reports do provide key information. However, many become habitual and have long been overlooked, yield little new information, and often find their way into a virtual file drawer without being read. Asking for a special report may also be a very ineffective way to gather information. The requestor may be after a very select piece of data while the author may take much more time to assure that the report is all-inclusive and (since it’s in writing) with no mistakes. Verbal communication can often be much more effective. Try MBWA (Management by Wandering Around)[2] in order to get your information quickly, fresh, and with little impact to the team. MBWA has the additional benefit that you will get to know your teams, and they you. Where a written report-out is necessary, you may be able to provide tools and templates that will reduce the amount of time it takes for your team members to fill in the essential information. (See for example the MPU discussed in “Tenet #9: Communicate the purpose and status”, Figure 9-7.)

  • Non-essential emails: We all know the story. We are flooded with emails, even after eliminating all of the junk mail. As an executive. I would get 200 about non-spam emails per day. Maintenance of this pile of information is a serious burden, not just for leaders but for everyone in the organization. One answer is to set up rules for your organization about group email responses, on reduction of email recipients, about how to address the subject line so it is clear if action must be taken, and any number of other methods. I knew one company that declared Friday an “email-free” day… no sending and no reading emails on that day. But a manager I knew some years ago had the most creative way to eliminate his email burden.

    Bill had been managing for many years and had accumulated vacation time for a long and well-deserved period away from the site. Three weeks later Bill came back, well rested and ready to go. Early in the morning I saw him wandering around the engineering cubicles practicing MBWA, gaining information as was his usual practice. After exchanging a few words about his vacation, I said “you must have a ton of emails to dig through!” I reasoned that with three weeks at 200 emails a day, that’s over 4000 emails! Bill looked me straight in the eyes and said with jubilance “Nope!” When I asked him why, he declared proudly “I deleted them all!” I was aghast! I spluttered and finally got out the words “How could you do that?” He gave me a piece of wisdom that has stuck with me for these many years (although I have to admit I have never taken it quite as far as Bill did). He said “I am finding out what’s important right now through MBWA. I have been gone long enough that if anything was really important it has either been taken care of, or it will come up again in my MBWA. And in that case I will just ask for someone to resend me the email with essential information.” In this way he saved himself from having to look through 4000 emails!

Proactively Plan: With a little attention, many disruptions can be improved or at least accounted for in project plans. Eliminating or trying to reduce these disruptions may not be appropriate, but with planning they can keep from slowing down your projects. Included in this category are visits to team members’ work areas, supporting issues on products previously released to manufacturing, discovering product requirements by visiting customers, responding to the demands of key new product customers, requests for product demonstrations from sponsors and the demands from all functional areas on resources applied part time to a give project (their day job).

  • Work area interruptions: Having co-workers or visitors step into your work area or office and interrupt your work can sometimes be positive and produce clear value to the project. However, these visits still represent interruptions that may break periods of deep concentration, which may be essential to create the innovative solutions demanded by the modern product development organization. Nothing is more frustrating than to be on the verge of a breakthrough and lose the insight because someone steps into your work space and starts talking. Putting in steps to reduce office visits may backfire, however, by taking away one of the key reasons people enjoy work – socializing; and thereby reduce morale.

    If work area visits are seen in your organization as causing a significant impact on effectiveness, you may choose to create guidelines for these office visits. I know of one company that placed a small light at the entrance of a cubical that could be switched from green to red by the engineer engaged in deep and productive thought, not wishing to be disturbed. Noise-cancelling headphone can also help with the intensely focused work, and give visual a signal of not wanting to be disturbed. (Note that these methods may be good for your individual contributors, but I would never suggest that your management staff adapt any method that limits office visits!) Whatever you choose to implement, make sure that it will improve effectiveness without greatly impacting your team morale.

  • Released product issues: In some companies, engineering responsibility is held in R/D after a new product is released for shipment. These companies may experience slower product development throughput times as a result of the inevitable interruptions that occur due to issues in manufacturing. These issues must be addressed of course, but speaking as someone who has managed on both sides of the fence, there is often a better way to serve the needs of manufacturing plus create a fast new product pipeline. In my experience, manufacturing is better served and NPD is faster if you set up a team to take full engineering responsibility for products after shipment release[3]. In the past I have called these teams “Manufacturing Design Engineering” or MDE to emphasize that the engineers in this group will be designers. It is not a paper-pushing job. The role requires intelligent engineers that can redesign as necessary for improved assurance of supply, better yield, higher reliability, and lower cost. The responsibility is a little like remodeling a house compared to building new construction. Both remodeling and new construction have constraints with which to deal. Both can be extremely challenging and both require smart and capable people. The work is highly varied with short deadlines, and it appeals to some people more than a traditional R/D job. One additional major distinction with MDE team projects compared to the R/D engineering job is that the work will not result in a new product and a new part number. All work should maintain the form, fit and function of the released product.

    Here are a few more characteristics of the MDE teams:

    • Priorities for the team (from highest to lowest):

      1. Assurance of supply (immediate “fire-fighting” on the product line, and redesigning as needed to handle critical discontinued parts)
      2. New Product Introductions (guiding into manufacturing: creating test processes, validating quality, learning theory of operation for new products)
      3. Reliability Improvement (redesigns to improve failure rates)
      4. Cost Reduction (through yield improvements, better parts or designs)
    • Team size: Your exact needs may vary based on your percentage of revenue allocated for R/D, but I have typically used about 10-15% of my R/D spend for MDE teams. If you spend 15% of revenue on R/D, you might spend 1.5-2% of revenue on MDE.

    • Reporting structure: The MDE team can report into R/D or manufacturing, depending on how well the functions work together, and which management will be capable of balancing the real-time needs of production support with the needs of redesigns for quality, cost, assurance of supply, etc. (Whether this is taken on the P/L statement as cost of goods sold or R/D investment is up to your CFO.)

  • Customer visits for product requirements: I am a big believer in encouraging key NPD employees to travel with marketing and sales personnel to learn about customers’ unmet needs. I have seen this generate greater innovation, as well as create passion and ownership for the customer issues. Allowing inventors to watch customers do their work produces new ideas much better than listening to a representative of the company (from marketing or sales for example) describe what they saw at a customer site, or worse yet, dictating new product requirements. Sending out NPD engineers and managers to learn directly about customer requirements will not only produce better products, but also create a drive in the teams to move faster. Nonetheless this activity will take project time and needs to be managed well.

    As an example of essential planning, there is a great tendency to wait until one product is shipping in manufacturing before sending these representatives to visit customers for the next product. However, waiting to do this “serially” (that is one product finishes and investigation into requirements for the next one starts) can delay the start of the next product by as much as 3 months. This early stage work gates the start of the new project, and should ideally be done overlapping with the end of the previous project. In this way the new project can be started as soon as possible. This action alone may reduce project duration by 1 quarter.

  • Key partner/customer demands: Having key customers willing to help you in key design decisions can be a significant advantage in creating the right product, but key customers can also create significant time sinks. Your key customers will probably be working with a less-than-ideal prototypes, and may require significant hand-holding from your development teams. These same key customers will expect that their feedback will be taken into account to modify the product and improve it. It may or may not be clear that the requested features will be helpful for this key customer, and they may not be applicable for the general market. These requests may create conflict and will need to be managed carefully. As I have found in the past, sometimes having a key customer representative resident onsite with the project team will be helpful. This immersion will help both sides get the full information they need quickly and make balanced decisions. I have also found that one or two key customers are helpful to creating the right product, but diminishing returns start showing up with three key customers. Managing three key customers may not yield much new information, and it will certainly add to the chaos and slow down your project.

  • Demo requests: Sponsors need to be informed and they want to feel involved. One way they will occasionally show this desire is by requesting a demonstration of a product still in development. These “dog and pony shows” are often highly disruptive. They are seen by some in the team as a chance to meet the big bosses and to be remembered, and as a result may generate anxiety and exuberance in equal measure. Your teams may consume valuable project time and resources to create audio-visual aids to help in the presentation and before long it seems that you are giving a “poster session”, complete with rehearsed talks and a hardware/software breadboard splayed out on a workbench.

    One thing is for sure: this sudden demo request will deflect the attention of the team. The best way to moderate this interruption is to plan on demonstrations at regular intervals. Those organizations practicing agile software development probably already know this approach well. With agile software, at the end of each sprint it is expected that the result will be a product that can be demonstrated to sponsors and sometimes to key customers. However, when a project takes on hardware and software, the integration of the two to create a functioning demonstration version can be more of a challenge[4]. Still, it is a good practice to plan for demonstration versions being available at regular intervals timed with the end of sprints. Keep the hype down and ideally leave this demo version accessible until such time as it is replaced after the next sprint.

  • Day jobs: Another major deflector of time is the part time nature of the work many of your resources will spend on your projects. Representatives from other functional areas such as manufacturing may be assigned to help with your project. But work on your project may only account for 5-10% of their time. The rest of the time they are expected to perform other duties, duties that may take priority over the work on your project. Assigning a so-called “heavyweight team” (where all resources are assigned 100% to the project) to the project is a solution that few organization can absorb. The most practical solution is to incorporate into your project plans the expectation that you will have little mindshare of these resources and anticipate some delays as a result. Watch them carefully and react if and when they become a part of the critical path.

Handle Reactively: I have placed only one item in this category, urgent customer issues[5]. Most issues can be estimated, resourced, planned and accounted for. But when a major customer issue hits, one that has the potential to sink the company (such as a jump in annual failure rates from 5% to 75%) there is little to do but to throw all available resources at the problem and take the impact on the new product introduction pipeline[6]. However, I believe few problems fall into this category and much of what we call customer service issues can be better handled by an organizational re-design (such as MDE) to create roles and responsibilities that better isolate the NPD teams.

In this blog for Tenet #10 I have argued that for faster projects you must keep the distractions away from your team. These distractions fall into three different types: those you should work to reduce or eliminate, those you should proactively plan for and those you must handle reactively. I have given some examples of ways leaders can handle issues in each of these three categories, including a description of the value and make-up of a Manufacturing Design Engineering team.

 

Conclusions
These Ten Tenets of Fast Projects have been developed from my years of experience in leading NPD organizations, and from discussions with and readings from various thought leaders on the subject. While this is not an all-inclusive list, I believe these tenets are essential in nearly all circumstances if you wish to drive for faster throughput times in your NPD pipeline. Applying these principles will help you become faster, and no matter how fast you are today, the demands of your industry and of your markets will force you to continue to improve your product development speed.


[1]In some organizations, participation in checkpoint meetings and the exposure it brings is seen as a perk. If this is true in your organization, you will need to find other ways to recognize and reward team members for their contribution. Examples include personal visits by leadership to gain awareness and show gratitude to team members for their efforts.

[2]Hewlett-Packard was famous for teaching MBWA to all of its managers. It became a hallmark of the HP Way.

[3]There are also other significant side benefits seen. For instance, you are likely to see higher quality designs and better documentation, to name just two added benefits.

[4]See “Tenet #2: Think in sprints”

[5]There are a great many other interruptions I could list that may critically threaten your project. For example: layoffs, budget cuts, re-organizations, loss of key resources quit… even real catastrophes like fires, earthquakes and the like. These would clearly fall under this same category of “Handle Reactively”.

[6]At this point, it is probably time to call an Out of Bounds (OOB) meeting, review and reset the boundaries, and re-plan the project.

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 .