More Effective NPD Factories

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.

Advertisements

Why you should build an NPD factory

Name the last time your NPD projects were deemed so important that they were all being worked on at the same time. Maybe key people were dispersed across multiple projects to help expedite them through the door.

And despite all best efforts, still none of the products were launched on time. Knowing this, ‘they’ throw in some more pet projects to get a ‘head start’, so that they too aren’t delivered late. Cunning.

Is there a good model for organising Product Development teams? I certainly haven’t witnessed one.

Hold on a second. Maybe that interminably unimpressed guy from manufacturing has a point. We need to sort ourselves out. It can’t be rocket science.

How to get tasks completed efficiently and on time has been the study of Manufacturing Engineers since the 1800s when Fredrick Taylor got excited about the size of his shovel. Since then, there’s been a torrent of studies, theories, university courses, professorships, mathematical proofs, guru’s, bookshop aisles, and even best sellers dedicated to the science of manufacturing.

Perhaps it’s worth having a chat with old grumpy from the factory.

He takes us on a tour to show off his ‘manufacturing cells’. These are mini factories. Factories-within-a-factory. Each cell has the people, skills, tools and responsibility to do the whole job of converting raw material into finished product, ready to ship. They are small, tightly knit communities where everyone helps each other to simply get the job done. The parts flow; you can see them. When there’s a problem, they all stop, collectively get stuck in to fix it, and away they go again. Crikey, that is a team.

Maybe there’s a reason he looked so dejected when he joined our ‘NPD team’. A loosey goosey bunch of nominated bodies who all report to somebody else, who rarely meet, and who are quite frankly more worried about their day job than supporting this latest brainwave from the R&D geeks, which if like last time, will get canned in a few months anyway when someone points out it’s non-strategic and a complete waste of time.

We move onto the next cell. They’re making something different. There’s a different number of people, different tools, different skills, but it shares the same buzz of progress. The ‘magic’ of a cell over an old-fashioned department/silo structure is blatantly obvious when seeing it in the flesh.

Is this what we do when we create an NPD skunk-works team, or is it something else? Let’s think on that one.

So what’s the reasoning behind the different manufacturing cells?

To design a set of cells, it is important to establish what they call the ‘focus’; what’s important and how can a cell excel at it. It varies by business. They could be product-focused cells where specialist technologies or skills are required. They could be customer-focused cells where it’s important to build a responsive service capability to meet particular customer demands.

Translating this to our world of Development, we could have specialist NPD teams dedicated to different families of project. They could be focused on certain technologies, customers or perhaps project types. For instance, maybe a repackaging Product Development cell with dedicated, co-located resources could really drive consistency across the product range, drive out costs and free up creative resources for the innovation projects.

This is beyond skunk-works. Skunk-works are generally a one-time reaction to save a really, really key project from the vat of functional siloed melee in which the rest have to swim. The Manufacturing Engineers would build an NPD structure that automatically gives every project the simplicity of it’s own well resourced, highly tuned, well practiced skunk-works team, every time. And projects would fly through.

All good in principle, but the devils in the detail. I think we’ll need a closer look at those cells….