 |
|
|
The product development newsletter no 8 |
| Topic: The benefits of not working in vertical silos - and what
vertical silos do best |
| |
| The predominant structure of most businesses is vertical. The areas,
departments, functions, and business units are the primary organizational
building blocks as well as the accounting units and career conduits. This is
a problem because processes flow horizontally across the organisation.
Especially in developing a product because the process touches more than one
area, department, function, or business unit. |
| But it's difficult to mix project and functional departments; you need
co-operative people and good organisation processes. It's even more
difficult to manage multiple projects. In a matrix organisation, who has the
final say? Project manager or department head? |
| If a department performs a product development task in isolation, the
quality of the task is likely to be inferior or incomplete. It invariably
lacks vital data from other areas. Not only that, but if you pass product
development tasks sequentially from one department to the next, you waste
time. |
| Even more important, transferring tasks from one department to another
loses knowledge. And perhaps the greatest problem is that it fudges
ownership of who owns responsibility for which part of the product; it
enables poor decisions to be passed without accountability. |
| If you work in vertical silo fashion, passing tasks from department to
department, first the task is delayed until the new department can do it:
wasted time. Then the staff brief themselves to understand what they need to
do: wasted effort. Then they do it and usually need a decision from another
department or more: further delay as it queues for new attention. (Or worse,
they do it without full knowledge.) The new department briefs itself on the
problem (more wasted effort) and takes a decision in isolation. You discover
later that they didn’t take a vital something into account that was known by
someone else in another department all the time. So later, it is
‘discovered’ that a change is needed (far larger cost of wasted time and
effort). And the later you make a change, exponentially the more it costs. A
concept stage £100 change could cost £100,000 at the tooling stage. And
frustratingly, you probably won’t discover why it wasn’t done better so you
can avoid it next time because all the responsibility is lightly smeared
across several departments. |
|
|
|
A number of factors affect what you should do, such as the need for:
- fast rate of technology change (needs departmental expertise);
- shortest possible project duration (needs effective project teams);
- best interdependency of components (needs project organisational
expertise). |
| Project-based organisations are better at global problem solving; to
innovate by cross-fertilising ideas between functions; and to collaborate
across functions. |
| Put yourself in the position of a new product as it progresses from
concept to launch. What is the process that it needs? Visualise and chart
what will happen at each step. Aim at minimising the process time, and
eliminating all the unnecessary tasks so that product lead-time equals the
process time. |
| The fastest way to develop products is to use cross-function teams. You
bring the necessary people together to do the task; define all the people
needed and their remit - the vital input of each one. Generate a route map.
Identify all the steps that add no value. Don’t circulate the tasks at arm's
length around departments. The team manages the task from start to finish.
So give them the tools, the support and the authority. |
| So what are departmental skills best used for? |
|
|
|
Function or departmental-based organisations are good at developing
functional skills, new technologies and keeping up to date; better component
performance results. They are most effective at developing standardised and
optimised individual components, building blocks and systems. But
departments are not good at organising projects, multiple or single. |
| To get innovative new designs, you first have to develop your new
technologies and do it continuously as background product development
programme. This, despite technology advances being the least sustainable
form of progress; people and information flow communicate new developments
to competitors surprisingly quickly. But even so you have to develop new
ideas and technologies continuously to get an edge. |
| But putting the development of unproven ideas or components into your
main time-line is a recipe for time and budget over-runs, or even worse,
catastrophic warranty costs and loss of reputation. If you attempt to debug
untried ideas in your main development programme for the next product, your
programme will inevitably be late and over-budget. You cannot control how
long it may take to de-bug untried ideas. |
| To overcome this problem, you run a separate background product
development programme for new, untried ideas; it could be only 2% of your
product development expenditure. You don’t mix this with your main
development time-line - you keep it separate. |
| And this continuous background development is better done by specialist
functional (or system) departments rather than by product teams. You also
need good planning to ensure that the new, shared building blocks arrive on
time for your cluster of new projects. And you manage suppliers'
inter-meshing programmes as a part of your in-house programme. These are all
factors that you plan into you programmes. If you are a small company, have
one or two people devote part of their time to it aside from their project
duties. If you are a larger product-team based organisation, your product
development (engineering, technical etc.) department is the best place to
run it. They will have the best repository of specialist knowledge. |
| So vertical silos and project teams both have their strengths you can
use to good effect. |
| But how many of you run really good project teams with representation
from all areas? See previous newsletters! |
| So how does your company fare? |
