TICS

Malvern Instruments

Paul Walker - Managing Director

Background

Malvern Instruments Limited specialises in a range of instruments that analyse particle size. We characterise solid particles in liquids, slurries and suspensions; and we analyse liquid particles in aerosols and emulsions. The key technologies are ultrasound, spectroscopy and laser diffraction.

Up to 1994 the company’s products were primarily technology-driven. We were world leaders in particle size analysis. Ideas for products were born and developed within R&D. There was little input from the market place or from manufacturing. There was an arrogance that R&D knew what was required better than the customer. This could not continue. Changes in the Company’s management gave us the opportunity we needed to re-structure the company to grow its market share and reputation in the market.

The new senior management team’s task was to attune it better to what current customers and future markets would need. This required us to:

Until 1994, the company’s products were technology-driven. Ideas for products were born and developed within R&D. There was an arrogance that R&D knew what was required better than the customer.

Changing the company structure

Early changes in 1994 included a change to the role of R&D. To help break down the walls between R&D and other departments, we changed their title to New Product Introduction (NPI). This demonstrated that they were only one part of the product development process. A marketing department was established to identify market and customer requirements and to interact with NPI. Changes were also made to the way product design R&D interacted with the downstream functions such as manufacturing and customer support.

The NPI organisation had a flat structure: so flat that everyone reported to a Director. But the structure was polarised. Although there was some interaction between Marketing and NPI, both were remote from the downstream Operations area. This included the manufacturing engineers, the manufacturing design office and manufacturing personnel.

The manufacturing drawing office was a separate department from the development drawing office but they were obviously an integral part of product development and were merged with NPI. Most of the first year was spent trouble-shooting problems with recently launched products. This gave us a good opportunity to observe how people interacted, and to re-assess their skills and personalities.

We needed to attune our product development to what current customers and future markets would need. We changed the structure of the organisation to do so.

Between 1995 & 1997, the NPI resource trebled from 15 to 45 people as we invested more in product development on the back of growing sales and the acquisition of new technology and partly due to incorporating the drawing offices. This gave us the opportunity to introduce the cultural changes we needed. We looked for new skills and attitudes in new recruits. We wanted potential future product champions who would be able to understand what the customer wanted and when acting as project managers in multi-disciplined teams would be able to drive those issues into the organisation.

New personnel were potentially more effective because they had not been part of the recent company history. They naturally wanted to work in a multi-disciplined way and to encourage others to be part of a team. They were happy to work with Operations, Materials Supply, Customer Support and Technical Publications, and to develop links with external suppliers. A project manager’s task is to involve everyone in meeting project time-scales, knowing by when their work needs to be complete. It is an important management skill to ensure that everyone feels their contribution is valued.

As part of restructuring all our business processes in 1994, we started to put ISO 9001 in place in parallel. We used it to restructure our business processes. It then gave us a framework to make further changes. We put right the lack of effective quality standards and systems in NPI. We were certificated in 1995.

Introducing structured project management

Traditionally, there was no formal monitoring or reporting of progress. So structured project management was introduced.

Traditionally, there was no formal monitoring or reporting of progress. So structured project management was introduced.

Each month, project leaders had to come before the other project and departmental managers. They reported what they had planned and achieved in the previous month, and what was planned for the next.

We then created an orthogonal management structure consisting of:

We thereby identified potential project managers for the future. Several were not up to the task. We then introduced another management layer into NPI. By delegating more control, we could identify and develop peoples’ capability to manage. Project management became a team effort between the development and project managers. This changed the line management process and effectively abolished the separate job of project manager.

We decided that project management should be a role not a job. An electronics engineer or physicist with project management skills could now contribute technically. As project manager, they had enough overview and product expertise to champion the project.

Previously a technical expert managed teams who then didn’t have time to make their own valuable technical contribution. They were often poor project managers too. We decided that project management should be a role not a job. An electronics engineer or physicist with project management skills could now contribute technically. As project manager, they had enough overview and product expertise to champion the project.

The development manager was responsible for providing support and administering a number of projects. He allocated resources and resolved any resulting conflicts. He budgeted and the tracked costs.

Everyone acknowledged the restructuring to be a major improvement. Projects had previously been developed within NPI. Now it was evident that product development was a company-wide activity.

Project planning and forecasting

We then introduced Microsoft Project for project reporting and started to accumulate data on project spend. Previously this information had been lost in the cost of sales.

We developed a time-tracking system linked to Microsoft Project. It analyses the project plans and produces electronic time sheets for each team member.

But Microsoft Project takes too long to find out where people are, add their time input and update the plan. So we added ‘In Time’ software, a time-tracking system linked to Microsoft Project. It analyses the project plans and produces electronic time sheets for each team member. It simplifies updating the project plan and we can now see what personnel spend their time on.

Every Monday morning, team members examine their time analysis. They enter the hours spent on a task, and the number of hours they need to complete it. The information is then reinserted into Microsoft Project, which updates the plan automatically. For the first time, the project manager now had information on how to adjust his project and still meet the time-scale.

But to make effective use of this information, the project must first be well designed: this was a vital lesson. Too many changes reduce the tool’s value. The better the project plan, the better the management information. Project managers had to improve the design of their project plans.

This new forecasting process proved its value in developing a major product launched in September 1998, the Mastersizer 2000. In October 1997 we were planning a July 1998 launch. But the NPI team identified a scheduling and resource problem. We decided that the launch should be moved to the September. This gave everyone sufficient time to regroup, resolve the issues, add two additional items and launch on the revised date.

All departments now knew the status of the project and adjusted their own time-scales. Previously they would have followed the original one. Exhibitions would have been booked and service training organised, only to be informed, too late, that the project would be late.

Training and locating the NPI teams

Tools and techniques

To enable them to work effectively as a concurrent team, NPI personnel were trained in a range of tools and techniques, including DFA, FMEA and QFD.

To enable them to work effectively as a concurrent team, NPI personnel were trained in a range of tools and techniques, including DFA, FMEA and QFD. DFA and FMEA were quickly put in place and are now an accepted part of the development process. Team members immediately saw their practical use.

Introducing QFD was far more difficult. We knew how useful the technique could be but we didn’t go far enough. We needed more extensive front-end marketing input to provide detailed customer information. And insufficient time was allocated to apply the technique through other levels of the project.

Co-location

During 1995 we realised that we needed to co-locate the development teams. A pilot quickly taught us the good and bad things about co-location. During 1995 we realised that we needed to co-locate the development teams. So as a pilot exercise we co-located a team for fast-tracking the Ultrasizer project. The aim was to take it from basic technology transfer to production in 18 months. This pilot quickly taught us the good and bad things about co-location.

For example, we included draughtsmen who traditionally had worked in the enclave of the design office. Separated from other draughtsmen however, they lost the interaction and the tools which they use as a group. They felt isolated. The same applied to the software engineers.

At about this time we were planning the new factory. We could plan a layout to deal with these issues. To facilitate team working we located the design office between the industrial engineers and the design engineers and marketing personnel. All are now located quite close to their peers. With short communication lines and line-of-sight communication, personnel now work more effectively.

Revising the product range

Commonising the building blocks

Four years ago, our products lacked commonality of design, both across and within the product ranges. There was a very large inventory. There were different microprocessors, different controllers, different optics and no common chassis. It was important that NPI addressed this issue.

A number of strategic projects were being planned that highlighted the need for common hardware and software. Without this approach we could not achieve evolutionary product development. We could not introduce small changes to up-grade products quickly.

We embarked on commonising design, both across and within the product ranges. Without that, we could not up-grade products quickly by small changes.

The principal engineers had an overview of all the products and projects, both hardware and software. They were therefore given the task of commonising components, controls and if possible the software base.

Re-developing the core products

During 1995 we began to re-develop the core products to incorporate new technology.

The Mastersizer 1000, introduced in 1987, was the market leader and well respected. It comprised an optical system with a number of accessories. But all the accessories had different means of connection. They all used different microprocessors and the software had grown like Topsy. Originally it had used a DOS programme, then various Windows programmes. One product used a transputer. It was a real mix of technologies. Our problem was that not enough people had the knowledge to manage them all.

During 1995 we began to re-develop the core products to incorporate new technology.

The new product, the Mastersizer 2000, was a laser diffraction-based particle size analyser. It used all the new front-end marketing procedures to verify customer requirements. All were put through a long feasibility process to confirm the requirement specification. We incorporated a common processor design across all parts of the instrument. It would be used in other products too. A new strategy was formulated for a common user-software interface, using object orientation techniques to develop the software.

Developing software using object orientation

We trained in software design by object orientation techniques that also covered preparing the product definition.

As our source of software tools and techniques, we used Select Software Tools Limited of Gloucester to train the software team and the hardware project leaders. They trained in object orientation techniques that also covered preparing the product definition. We then applied the new techniques to design the user-interface in collaboration with marketing.

The hardware and software platforms were developed in parallel. Using the object orientation techniques we made sure the software and firmware linked effectively with the hardware. The software was split into two parts:

Developing the hardware

At the same time we established a hardware project team. They proceeded to evaluate the technology risks with feasibility studies. The original requirement specification for the Mastersizer 2000 was ambitious. We had to compromise what we considered the ideal specification as a result of the feasibility work. It was too risky to incorporate all the new technologies we wanted. But the risks had been quantified: we were able to avoid dangerous routes.

Lessons of the programme

Software development lessons

This was the first software project of such complexity that we had ever completed on time.

This was the first software project of such complexity that we had ever completed on time. This was because we spent far more time designing the software at the front-end, as opposed to just coding it and trying to make it work. We spent ten months on the software structure before writing a single item of coding.

Object orientation allowed us to encapsulate software design for the first time in a way that gave us well-defined tasks. You can’t move onto the next phase until you resolve the task being worked on. The programme is divided into modules, sections and classes. You know exactly what you’re developing. It is so well defined up-front that, when necessary, it is easy to design changes and see their impact. By contrast, designing the old fashioned way, you fixed problems by redesigning the software. This in turn would spawn half a dozen more problems because the linkages were not understood.

It took us far less time to fix the problems that we identified in the latter stages. It was an order of magnitude improvement; and the software quality was so much better.

But you can still get into difficulties. Mistakes are still possible, or you can start without planning the whole route. Insufficient planning inevitably misses those additional requirements that become apparent later, which then blows the original design concept.

The software for the new Mastersizer 2000 was late, but only by days and weeks, not weeks and months. It took us far less time to fix the problems that we identified in the last stages, again measured in days and weeks. That was an order of magnitude improvement; the software quality was so much better.

Hardware lessons

Hardware management is considered to be easier. The work naturally falls into sets of PCBs, assemblies and so on. And you can see the product in 3D. This can give you the illusion that designing hardware is more manageable than software - people think it’s easy. It isn’t.

You may have the illusion that designing hardware is more manageable than software - people think it’s easy. It isn’t.

We fell over because the front-end work was not properly defined; that is where we learnt from the software design methodology. It was more likely to fail because software techniques were not previously applied to the hardware. Much of what is now common practice in hardware, in terms of the life-cycle approach comes from software design practices.

Software developers established early on the need for a structured process that involved producing requirement specifications, systems analysis, and design and then coding.

Using this structured approach on hardware - analysing what is required, systems analysis, design, then manufacture - is a good model for designing hardware. It is particularly important to analyse requirements and systems at the conception of the product. And it costs relatively little to do thoroughly. It was here that we used simulation tools to improve the concept of the hardware design before we started on the expensive stages of product development.

The importance of customer needs

We have learnt that the link with the customer has to be even stronger with our new approach. Getting the QFD process right will allow us to achieve even better future products.

We have learnt that the link with the customer has to be even stronger with our new approach to software and hardware. Getting the QFD process right will allow us to achieve even better future products.

Software and hardware engineers interpret marketing requirements in their own way. It is difficult to get a software engineer to understand that the customer wants the software to present the data in a certain way. It is not easy to bridge the culture gap. And marketing interprets customer requirements in their own way. So we are forging even closer links between customers and the project teams, particularly the software and hardware designers and the marketing personnel.

Revising the NPI process

The value of modular products

A 24-month development cycle is too long. Previous products incorporated processors and hardware that were so different that they could not be incrementally developed. So we had to do a major re-development of the product every time. But having a product baseline with common, modular building blocks allows fast new product turnover. We can now introduce incremental developments on a four to five month cycle.

Streamlining the new product introduction process

We decided to streamline the NPI process further. We asked ourselves “Is the current structure needed?”

We then decided to streamline the NPI process further. We had a marketing front end, development middle and an operations back end. But the central processes were from marketing to operations, with NPI multi-disciplined teams operating alongside.

We asked ourselves “Is this structure needed?”

We had been considering changing the structure for some time. But two factors finally precipitated it. Our parent company had significant Far East exposure which, together with the strength of the pound sterling, was likely to slow our growth significantly over the next few years. We therefore had to reduce the size of our workforce, but by 10%. So we decided to revise the company’s structure and activities rather than just make piecemeal cuts.

The new structure

We changed to being totally project-based. Functional departments changed their role

We changed to a totally project-based organisation. We made it clear that everyone should forget about the previous role of functional departments. Their new role was to provide back-up functions such as line management, ensuring pay and rations, and organising training.

A feasibility project would be managed by Marketing. A development project would be managed by Operations. Staff doing front-end work on market data capture and technology development would automatically become part of the team that took the project through development. The formal interface between Marketing and Operations would be increasingly fuzzy!

The front-end processes determine what the customer wants, to prepare a good requirement definition:

We are now achieving 12-month development cycles, but generally a more rapid and responsive time-to-market.

Customer- and market-driven product development

A problem with customer-driven and competitor-driven product development is that both can invite a short-term view of the world.

One of the problems with customer-driven and competitor-driven product development is that both can invite a short-term view of the world. We needed to understand our customers’ long-term business needs. This demands an understanding of the customers, markets, processes and industries that work with and use our instruments. It was important to put as much resource as possible into understanding where our markets were going.

In 1996, the Board recognised that far fewer customers would be buying instruments for use in the laboratory in ten years time. Most analysis would be done by in-process measurement. The material’s specification would be known by the time it was made. Laboratory testing would not be needed on anywhere near the same scale.

We therefore needed products that would make the measurements in-process.

We had a choice. Should we develop the technology in-house? This would be a difficult route because it would take a long time and this was not our traditional market. It involved big risks. So we decided to buy a small company in the USA that was already doing this work. It would give us an early entry into that market. This work is now a growing part of our business. In five years time it may be bigger than our traditional one.

We would never have taken that step if we had just reacted to what our competitors were doing, or to customers wanting bespoke products. Many of our customers are laboratory managers dealing with today’s problems. They are not the strategic drivers of the Glaxos and ICIs. We say they are our customers. But in truth they are just laboratory managers wearing a Glaxo or ICI badge!

Moving up the supply chain; outsourcing

Future challenges demand that we move up the supply chain and out-source many more of our non-core activities.

Future challenges demand that we move up the supply chain and out-source many more of our non-core activities. We are involved with products using three fundamentally different technologies: ultrasound, photon-correlation spectroscopy and laser diffraction. They demand separate approaches in their application and development. We now have the opportunity to make sure that all three use common approaches, such as user interfaces, components and methodologies.

Each of the three product ranges has a slightly different market. So we have three different product managers.

Laid over that, we have the transition in the market place from laboratory equipment to on-line equipment. This potentially applies to all three technologies. So we need to be successful in six levels, three technologies with two markets each. They have to be done in parallel; if we don’t, the competition will. But we can’t do this if we’re trying to do the nuts and bolts of all six streams. We couldn’t afford the size of product development resource to cope with the total complexity.

We shall therefore move up the chain and out-source those elements of the design and manufacturing process which are not core and focus more carefully on those areas where our expertise and specialist resources add real and unique value as well as providing us with competitive advantage.

We need to manage the process by which we bring products to market. But we need to own and develop only that which supports and develops our position in the market. The valuable part is the capability of managing, marshalling and integrating the entire input. We shall continue to assemble and test: that is a core part. The feedback from these activities is an essential input to our continuous improvement programme.

But we don’t need to design, develop or manufacture the non-core parts. Many companies can design and assemble components or sub-assemblies for conventional equipment. It isn’t a unique skill: we can sub-contract it. We are therefore creating strategic alliances with suppliers and external design groups to out-source the non-core parts of our projects. In parallel we are growing and developing the elements that are unique to our company and its products.

Conclusion

Continually developing better products governs the prosperity of the whole organisation.

We must continually address what we need to be good at in order to satisfy the needs of an ever-more demanding and competitive marketplace. But the goal is a continuously moving target. The company’s success and survival depends on continually monitoring and responding to the demands of that moving target. The development of better products and getting them to market more quickly is a crucial element of the strategy for success. It ultimately governs the prosperity of the whole organisation. That is what product development is all about.

All the elements of what this company did are part of a methodology you can learn - adaptable to any product development project from the totally new to just a small change. Develop products that customers clamour to buy. Cut the cost of developing them. Cut the cost of manufacturing them. Drastically reduce the time it takes to develop them. Learn how...

©2014 - Dr C B Mynott (Managing Director) TICS Limited