What, Who, Why, and Value?

What, Who, Why, and Value?

There are key decisions that are necessary to be made quickly during the concept stage of new product development. When these decision are not made or are unclear, project schedules drift and fail to converge in time. You end up with the wrong product at the wrong time or in other words, “late and not what customers want.” When you quickly get them right, you end up with the right product at the right time. Drift and confusion at the start of projects have the greatest impact on future product success. We have seen it many times go right and also spectacularly wrong when poorly managed.

Read More

The 4 questions

The 4 questions

So you're chairing your 3 hour monthly project review. The project manager is presenting the current dates, the dates from the last review and the target dates. You listening and yet you don't feel that you have the whole picture. People use words like Portfolio Management and companies supply sophisticated tools, giving you a mass of information to "manage" your portfolio.

Read More

Let go

Let go

We observed on a recent program that the program manager was "taking control," but was also "avoiding responsibility" for the current state of the program and its eventual outcomes (it was very late). It seemed like the worst-case scenario in that the manager positioned himself as a gate keeper of information and control, while avoiding responsibility for the root causes of the problems (which were causing the delay).

Read More

Investment fund prioritization: deciding where to invest

Investment fund prioritization: deciding where to invest

We've been working with a large European venture fund to determine their optimal portfolio of investment opportunities. The modeling concept is based on the work we have been doing prioritizing strategy, markets, customers, product requirements, and new product project portfolios. It is based on the idea that these decisions are influenced by objectives or decision criteria.

Read More

Collaborative new product development supply chain

Collaborative new product development supply chain

When we think of supply chain, we think of manufacturing and the problem of various materials suppliers feeding a chain that leads to the manufacturing of goods. The same supply chain concept is applied to product development today with the ever increasing complexity of technology products and global market distribution. We called this a development supply chain. Typically this is characterized by customers and suppliers of product development teams that lead to the integration of sub-components into a system at the end of the chain closest to the final customer.

Read More

Reconcile MKTG and ENG... what we want vs. what we can do

Reconcile MKTG and ENG... what we want vs. what we can do

Recently, we’ve been working with a client to solve the classic problem between marketing and engineering functions; reconciling customer/market needs (i.e. requirements) with the budget and resource constraints of an already stretched engineering organization. How do you reconcile what is wanted by marketing/customers with what can be done by engineering with their available resources within the expected delivery time frame?

Read More

Failure of perception, not of performance

Failure of perception, not of performance

Where do your schedule target dates come from? Are they fact or fiction?

In our experience, schedule target dates (i.e. the point in time which something is needed to be delivered) are difficult to determine. They should be driven by customer demand/needs, but all to often they are artificially generated by either top management or external partners in the case of co-development projects.

Read More

Unmanaged fuzzy-front-end

Unmanaged fuzzy-front-end

What is wanted versus what can be delivered? A failure to reconcile. Rarely are engineering resources involved in the critical step of reconciling what is wanted with what can be delivered. The Marketing (or product) Requirements Document (MRD or PRD) is written and basically "tossed over the wall" to Engineering, who also typically ignores what they are not interested in, or don't want to do, or don't have the resources to do... and at the end of the day the resulting product is a function of what can be done versus what is really needed (by the customer).

Read More