Our previous post argues the case for breaking out NPD team members from their functional silos and forming them into sets of dedicated, co-located NPD teams, analogous to manufacturing cells. The benefit is to drastically cut idea-to-launch lead-times.
But by how much? Lead-times vary by product category and project type, but to be provocatively realistic there are many projects that could be delivered to market 50%-75% quicker.
To most, the theory probably makes sense; after all it’s been happening across other business processes for years. The real challenge is how to apply it to New Product Development.
In an NPD team environment, people would no longer have the office space, the packed schedules, the IT or the reporting structure to shelter them from the pressures of reality. Instead, they’ll get raw exposure to genuine project commitments, risks and unknowns, all sitting for the first time uncomfortably within their personal space.
How do teams react to this? Do they quickly find their feet or collapse under the stress?
Our past experience hasn’t been to sit back and find out, but instead to equip them with some practical tools suited to an agile product development environment and watch them seize the freedom and responsibility with both hands. Let’s discuss what these are.
Team sizing: Once you have agreed the NPD cell’s focus, co-locate dedicated teams to cover the essential skills required. Unless you have a strong case to do otherwise, start with one person per skill. Don’t be too concerned about getting the right team sizes at first because it’ll get flushed out when running. The key is to caution on the smaller size. It’s easier to increase the team size if a particular skill is under capacity than vice-versa.
A simpler stage gate process: The stage gate principle of check/synchronization points still holds true, but teams can be put-off by unjustifiable, one-size-fits-all processes. A Value Engineering project does not need to be subject to the same gate criteria as a New Product line. Equally, users don’t benefit from ungainly workflow systems that demand them to follow pre-defined, cascading activity lists; there are just too many variables. Traditionally styled project management tools such as Microsoft Project and many third-party applications fall into this category.
Your team members are professionals. They know better than any software how to do their jobs. So, instead, simply provide a set of deliverables per gate that team members can meet in the sequence and manner that they believe best. This gives the project team more scope to complete their tasks in parallel, gives them the greater space to innovate, and provides you with the perfect input for the gate-review team.
More freedom and responsibility: In manufacturing, cells follow a maturity curve gaining self-sufficiency over time. Initially the team manage their own schedules and take on basic maintenance tasks for their own mini-factories. As cells mature they may even advance to conducting their own recruitment.
This same principle should be applied to NPD cells. A good starting place is the management of allocated budgets between gates. Why do so many companies give projects a great testing during their gate reviews only to re-subject them to exactly the same questioning in a separate capital expenditure sign-off process? “Because they use different forms”, isn’t a particularly compelling reason!
Visible metrics: This is nothing new to general business processes, but the scarcity and inconsistency of key metrics used by NPD teams is surprising. In manufacturing, anyone can walk up to a cell and see a physical board posting metrics for both outward and inward consumption.
A great NPD cell should have a simple, visible dashboard covering project purpose, progress, financials, team and timelines.
Visible, pull based scheduling: Use the completion of one project to signal free capacity to do the next. This keeps the desk tidy and the productivity high. Precedence is given to finishing projects, not starting them. ‘Finishing’ pays, where as ‘starting’ costs.
Contrast this with the push system that many businesses use knowingly or otherwise. This is to keep adding more and more projects into the pipeline with the hope of gauging the company’s development capacity by monitoring overtime and general levels of stress. This encourages multiple projects to be done at the same time, each competing for the same people. Priorities are harder to control, and the jumping from project to project causes efficiency to drop. The effect, as many will have experienced is a log jam. Under these times of stress and delay, it takes a confident person to do the right thing and take some projects off the table.
Hopefully the above points will strike accord, but there’s certainly extra complexity you’ll have to deal with. Perhaps project teams are spread across sites, continents, even companies. Maybe you don’t have sufficient people of all skills to dedicate to a project team. Undoubtedly your projects have long lead-time items outside your control meaning it’s impractical to do one project at a time. And on a wider scale, how can we as a company shape our portfolio of projects if it can’t trust the resource figures they’re given?
We will re-visit some of these topics in one-by-one to get to explore the details.