Avoiding the pitfalls

Think about the variety of engineering disciplines involved in new product development (NPD). Then think about the large number of business functions that should also be involved (sales, product management, manufacturing and marketing). Is it any wonder that, when looking at the NPD process in an organisation, you will inevitably find problems associated with communication? One of the 'inputs' to the NPD process is information, which is then used to define and make a product (which you hope will delight your customers and generate profit). That information can take many forms – knowledge of a customer requirement, definition of an interface protocol, assembly instructions for a complex mechanical component – the list is endless. However, in all cases, the information needs to be captured, refined and used as the starting point for generating more information of value. Communication of information is vital to a successful NPD process. A solid process and positive culture that supports communication are also key factors; however the focus here is on the communication tool. What are the requirements for a good system of communication for NPD? • Information must be easily accessible • Multiple contributors must be accommodated • Adding information must be simple • Discussions and decisions must be traceable • Specific searches should be easy and quick • Both formal information capture and informal discussion should be supported What are the pitfalls and problems from which many systems suffer? • Too complex – information is difficult to enter and retrieve • Too formal – users are afraid to commit themselves and prefer offline informal methods • Too fragmented – information is captured and communicated by different methods and not everyone is always on the 'same page' • Requires accessing regularly to review what has changed • Information is shared too widely and too much time is spent on endless online discussions. It is not uncommon to find organisations that operate with locally stored documents that are emailed to different groups of people with multiple threads of revisions and comments. In conjunction with this, micro discussions take place between a few individuals, with key contributors to the project often 'out of the loop'. All too often, this situation exists alongside an expensive document control or project management system. Does this sound familiar? With these thoughts and the identified requirements and pitfalls in mind, is it time to review the tools that you use to communicate within your NPD process? There is a multitude of potential solutions to the problem of communication within NPD. What do they all boil down to and what do they offer? Network drives Probably all organisations have networked storage. Most will have created directories for users or projects and will have defined some loose procedures to control the quality and accuracy of information held about specific projects or activities. This system is simple, quick to implement, easy to understand and easy to build on to create more structure as required. However the system can often fail to deliver against the requirements. Primarily, people will fail to follow the rules (losing traceability) and finding the relevant information can be onerous. Because short initial discussions may not merit a document on the system, they start as offline emails, which develop into locally stored documents. Unless some discipline is maintained, the system becomes out of date and underused. In addition, it is difficult to set up a system whereby users are notified of changes to the information. Controlled document repositories Source code repositories are almost ubiquitous in a software development environment. More mature organisations have ERP systems that will often provide document control functionality. It is not uncommon to see either of these systems pressed into service to hold information about NPD. More discipline on the creation and development of documents is enforced; it is difficult to ignore the rules and traceability is maintained. However, with such a formal system, the failing seen in the network drive solution of short initial discussions is an even bigger risk. This risk is often exacerbated by complex checking in and checking out procedures presenting a barrier to using the system to instigate a quick discussion Collaborative project management tools Many software houses have recognised the problems associated with knowledge sharing in a project environment and there are hundreds of solutions on the market. While many organisations have had considerable success using these tools, they are not without their deficiencies. They are often complex and force users to accept a particular structure (clearly defined projects and team members for example). This can often result in an overcomplicated solution, particularly when enabling technologies applicable across multiple development projects are being explored. Often, these tools are focussed on project (or progress) management, rather than the 'big picture' of sharing information at all levels. The enforced structure and its focus on project management can often result in resistance to its acceptance by development teams and the inevitable off line communication methods take over. Wikis Once a niche area, there has been a marked growth in the use of enterprise wikis. In simple terms, a wiki is a website that allows the user to create and edit pages through a browser interface. In its raw form, there is no inherent structure to the website and, as part of its growth, a particular wiki will itself define a structure tailored to the needs of the organisation. Alongside the raw engines, a number of wiki based tools have focussed on collaborative project management and have a basic structure as a starting point. In an enterprise wiki implementation, any user can start or edit a page on any subject – from the results of customer research through to a product launch plan via a discussion on some enabling technology or software feature list. All pages associated with a particular subject can be linked from an index page (and the organic growth of this index page can define the overall structure). One interesting point is that wikis have often originated from grass roots activities within an engineering team. Wikis are based on informal discussion pages and, as such, are more accepted and trusted – and less likely to be subverted by offline email methods. On the downside, many of the tools are crude and still under development – for example, WYSIWYG editors are relatively new and integration of non textual forms of information (graphs, pictures) can be problematic. Quite often, the biggest drawback to the use of an enterprise wiki is, ironically, the enthusiasm with which people contribute adopt it! If growth is too rapid, the organic development of the structure is adversely affected, requiring the occasional intervention of a 'wiki gardener'. There is no 'one size fits all' solution to the problem of providing an effective communication tool that supports NPD. What is important is that the requirements and pitfalls identified above are taken into consideration. And, of course, don't forget that you need a solid NPD process and positive innovation culture. Author profile: Graham Cooke is director of NPD Express