Ten Tenets of Fast Projects (10)
Tenet #9: Communicate the purpose and status
It is my opinion that, for any kind of robust project management, there is little chance of over-communicating to your team and your sponsors. Far more likely, you and your team are under-communicating, and it’s hurting your sponsorship and reducing the sense of urgency and therefore the speed of your projects. However, not all communication methods are equivalent. Communication must be a light burden on the team, and has the right material targeted for those consuming the information. It must be tailored for the audience intended and more often than not it should be simple and concise, requiring little time for others to pull the essential elements out of the communication vehicle. Some of your communications should be visible at all times as admonished by lean practices, but not all.
Reasons for communicating
There are three major reasons for frequent communications:
- To generate buy-in
- To generate synchronization
- To generate feedback
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:
- Reduce: Distractions that should be anticipated and diminished, and ideally barred from utilizing your NPD resources.
- Plan: Distractions that can be handled proactively by appropriate planning or changes in roles and responsibilities.
- 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.
Tenet #8: Monitor buffers and queues
Monitoring buffers and queues of active products under development in your system is extremely important for speed. I will first show how taking advantage of project buffers can assure an aggressive project and on-time delivery, and then show how to monitor and react to growing queues at the front of process centers in your product development factory.
Building an accurate project plan must take into account the complex psychologies of your team members; in particular, their necessity to overstate the time needed to complete a task can reduce schedule predictability and slow the project. This tendency is due in part to the way leaders have responded in the past to late tasks, and how team members have suffered if they underestimated the task length. Punitive actions for tardiness communicate to the teams (perhaps without leaders realizing it) that “schedule accuracy is more important than project speed”. To create a faster organization, leaders need to find a way to give the opposite message: “speed is more important that schedule accuracy”, and then reward the team accordingly.
Tenet #7: Decentralize the decision-making
In this blog I would like to discuss the importance of decentralization in decision-making. I mean to illustrate the difference in effectiveness between managing decision-making from a central (usually high level) authority compared to empowering those people lower in the organizational structure (and typically closer to the daily status of specific issues) with the knowledge and authority to make these decisions for themselves. These differences will fall into the following categories:
- Project speed
- Decision correctness
- Leadership development
- Job satisfaction
I will mainly discuss how distributed decision-making impacts the first two points.
Tenet #4: Reduce the portfolio
In most cases, the best way to improve the speed of product development is to reduce the number of projects in the active portfolio or project pipeline. Your choices of the number and type projects in the pipeline at any one time have significant consequences when it comes to the speed of your development systems. The balance chosen between “trying doing too much” and “doing too little” is an essential decision-point for the firm.
Throughput has been studied theoretically and experimentally in a diverse set of fields, from communication to traffic flow. Product development can be thought of as a chain of processes through which specific solution ideas, prototypes and documents, encompassing “products under development (PUDs)”, flow until they are deemed ready for production. Each PUD takes some capacity for its development, including engineering time, modeling and prototyping tool time, testing time and equipment, etc. It is self-evident that trying to develop too many products at the same time will slow everything down, but how can we find the optimum for a given capacity of development resources?
Tenet #5: Sharpen your prioritization
I have worked with new product development leaders in the past who have said “We don’t prioritize projects in our active portfolio. All projects in the active funnel must be completed according to our agreements. That’s why they are approved to be in the active funnel; and it’s how we drive our teams to get the best performance.” This reasoning may appear to be sound, and perhaps in some industries and for some types of projects this mandate will work well; but in many industries and for many types of projects, the uncertainties in a project are just too high. Unless you have already driven your organization to a high level of conservatism in schedules (read “long schedules”) and have pushed risk-taking out of your process (read “little innovation in your products”), this type of directive will probably fail since few projects can account for the significant surprises that will impact scope, schedule or cost. In short, if you want fast projects and wish to maintain an innovative environment, this idea of no prioritization is a bad one.
Prioritization of projects is almost always necessary for the well-run product development organization wishing to emphasize fast throughput time and at the same time encourage high levels of innovation. This prioritization is essential to allow for well-reasoned decision making, agreed upon at the highest levels when leaders are faced with surprises.
Tenet #6: Standardize the routine
Although innovation necessarily involves risk and variability, much of what is done in Product Development is predictable and routine, so where does standardization make sense in an NPD process?
There are two types of standardization that may be discussed with respect to the NPD system:
- Processes and Tools
Processes and Tools
Let’s start with the fact that NPD is not the same as manufacturing operations. Ideally in manufacturing, there is no need to change anything. From the beginning, products launched into manufacturing are perfect, low cost, high yield and exhibit high reliability. The suppliers will never stop supplying critical parts and there will never be a need for a redesign of the product. Of course, this ideal is seldom achieved, and it is less likely to be achieved the more cutting-edge your products.
Tenet #3: Focus on the risk
In this blog I will talk about risk, and how a focus on risk will drive a project faster and through reducing risk, be able to allow for greater innovation. By necessity, I will also talk about some of the methods of reducing risk. Aspects of this discussion apply also to the previous tenet, “Tenet #2: Think in sprints”.
There are two types of risk of which all participants on a project must be aware: Market risk and implementation risk.
- Market Risk: A market (or market segment) is the collection of customers to whom you are targeting the new offering. Market risk in summary is the risk associated with market acceptance of the new product. Your view of the risk may be seen in your uncertainty of the projected unit sales forecast or the price you will be able to charge.
Implementation Risk: This is the risk that your implementation of the project necessary for the product offering will not go according to plan. It includes technology risk, logistic risk and other areas potentially impacting the successful completion of the project.
All New Product Development (NPD) projects contain some level of both of these risks. And both must be actively managed for faster projects. Figure 3-1 shows six major ways to manage risk.
Tenet #2: Think in sprints
In my last blog, “Tenet #1: Align the organization”, I discussed the need to align the organization in two ways:
- Align with information to motivate for the needed change, and
- Align with structural changes, reporting, roles, responsibilities and metrics to make your pipeline faster.
Alignment of the organization in both information/motivation and structure is critical to moving faster. Don’t make the mistake of false economics that has hurt so many companies, that a lower cost product development engine with higher utilization of all resources is best for the company. In the end, this choice will slow you down, and slower projects will cost you far more in lifetime gross profit than a so-called efficient and highly utilized organization will save you in project cost.
Blog #1 of 10 – Introduction and Tenet #1
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 . 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.