We are frequently asked to compare Agile and FTTM (fast-time-to-market). FTTM is the process of delivering the right-product at the right-time. It seems that people want to compare these two approaches to managing projects, as competitors to one another. The problem is not the principles behind Agile, which you will see are very similar to FTTM, but rather the way in which Agile software vendors implement software to track Agile-based projects, more on this later.

Three critical principles that need to be understood in order to fully implement FTTM in an organization, explained in this article.

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.

A core principle of fast-time-to-market thinking is to know when to make a decision. Time is lost during "decision-churn" while teams attempt to gather "enough" information to make a decision. Their reasoning is that they want to be "right" and therefore, in the process, take a long time to gather the data in order to be right.

Contrary to general belief, high control "systems" don't generate fast projects. In fact the opposite was the case in very fast organizations. One would think that that less control (i.e. low management overhead) would generate faster projects, like start-ups who have virtually no control systems. Again, this was not the case.

Having worked with and studied fast teams over the past 30+ years, they all share a common set of practices for executing their projects.

You need to pull-in the schedule just to be able to meet the schedule. This is called "time banking." You accelerate to gain time now, since you know unexpected things will happen in the future where you will need to use that banked time (i.e. loose that saved time). What is certain is uncertainty!

Based on hundreds of project experiences we have learned that specific factors set those fast teams apart from other teams that are less successful vis-a-vis meeting their schedule commitment.

Keep in mind, for example, Hewlett Packard purportedly makes 80% of its profit from products released within the last 2 years. So, why is schedule not "king" - even though it's given lip service?

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.

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.

When should you terminate a new product development project that has been underway for a good deal of time? The longer it goes, they harder it is to kill.

“The plan is useless, but planning is essential."

Following are factors that drive successful deployment of Refresh Planning. These have been developed over the years through thousands of consulting engagements.

We've developed an even faster start-up process for getting a team quickly into the refresh planning process. We've learned though the years that it is critical to get to refresh planning quickly and use it to refine and engage the team in the planning and pull-in effort.