Reviewing Project & Product Success

There are two fundamental categories of post-launch reviews. The first we shall call “Team Self-Assessment Project Reviews.”

These reviews are primarily for product developers to explore their lessons learned from working together on a project that has just completed. The second we shall call “Management Business Reviews of New Products.”

These reviews are primarily for management to explore the financial and marketplace results of the new product in both a relative and absolute sense, and to contrast the results to those that were promised when the project was approved.

Ideally, there is minimal overlap in the content of the two review categories. However, and this is especially true where the team that created the product stays together to enhance and service the product during its life cycle, much of what should be covered in structured Management reviews is done in Team reviews.

To breathe a bit more life into this statement, consider that management makes the business decisions. They could invest scarce R&D funds in many places. They choose to invest in certain projects because of the business plan that was presented to them.

If management does not involve themselves in a comparative analysis of promised vs. actual results, they diminish their capability to “see” similar or analogous estimating shortfalls in future business plans and decisions.

The learning loop does not get closed for management. Manufacturing and operations professionals, in just about every company these days, have achieved closed-loop decision-making. The opportunity is still on the table for most executives that direct engineering and product development professionals.

A “project” is a “temporary organization vehicle that is used to develop new products.” Companies don’t sell the project; they sell the product(s) that results from the project. Team reviews should have a heavy project emphasis. Management reviews should have a heavy product emphasis.

Of course there is overlap, but it is not that difficult to draw a pretty clean line of what in a product should be part of a project review and vice versa. The Team’s ability to realize the specifications of the product is part of a project review.

Similarly, Management cannot do a product review without certain project information such as the development cost and any slippages in project schedule that may affect return on investment. Teams should include the technical aspects of product achievement in their project reviews. Management should include the financial aspects of the project in their product reviews. With those guidelines, pretty clean lines can be drawn.

Team Self-Assessment Project Reviews: Typically Team reviews are done within six months of a project completing. It is best to wait until some level of commercialization has occurred, as many avoidable errors are not discovered by the company’s test suite but by the company’s customers.

Until the marketplace at some level vets the product, a project review stands to be incomplete. Team reviews are often done many months after launch, often more than a year or more. This is problematic because as soon as a product is launched a new force starts taking effect as enhancements are requested and tailoring begins.

These post-launch forces were not part of the original project and they introduce change. It soon becomes challenging to distinguish between avoidable changes that should have been caught by the team, versus unavoidable changes that originated after the project was complete.

Folks that run change management organizations are expected to be efficient. As such, changes for a certain part or subassembly get grouped together. The ability to clearly see what was avoidable is lost and the Team loses the opportunity to best close the loop for the project it undertook.

Management Business Reviews of New Products: The right timing of Management reviews depends on the product life cycle curve. Some products are new for a year, and then they are old. Some products are new for three or five years, and then they are old.

Typically business plans presented to management carve out the first one or two years as an estimate, and then the first three or five years as an estimate. Then, there is a column or field for projected lifetime revenues.

Use the business plan as the guide for when to hold Management’s post-launch reviews. The primary goal is identify the errors of the business plan estimates versus the actual results achieved. If business plan used one and then three years, then a post-launch review should be conducted at those two points.

The first review is the most important in most companies; call it a “first year review” for discussion purposes. Many companies have “hockey stick” commercialization results. Sales are often near zero for too many months, and then they start increasing.

Usually the business plan did not show zero projected revenues in the first year. If the organization knows that management will not conduct a serious first-year review, the likelihood of a hockey stick result increases. That hockey stick result then impacts subsequent years as the marketplace sees that there is slow adoption of the new product; therefore something must be wrong or underperforming with the product.

That customer perception affects all subsequent results. If a product is launched fast and decisively, as policed by a first-year review, the three or five-year review usually does not disappoint.

Product Portfolio Reviews: Of course there is a regular periodic need to examine the portfolio as a whole, new and old products together. Portfolio reviews have yet a different purpose; they are more strategic in nature and embody a longer horizon for thinking.

Summary: Analogous to the differences between the shorter-term horizon of a sales organization versus the longer-term horizon of a marketing organization, post-launch reviews have the comparatively shorter horizon.

As well, post-launch reviews focus on a project, and the one or several products that result from the project. Portfolio reviews have a longer horizon and focus on products as a group. Mixing these horizons and clouding the single vs. group distinction, a regular basis, typically results in underperformance.

For post-launch reviews, closed loop cycles of learning are best achieved when the content of post-launch reviews are focused to those items that are within the Team’s control versus those that are in Management’s control.