Using Wikis to collaborate on Product Design

Came across an interesting post from Oleg Shilovitsky on the "Daily PLM Think Tank Blog" about the weaknesses of wiki as a medium of collaboration for PLM platforms in general. As it happens, I have somewhat of an opinion on that issue - we've been using our own PLM for managing product development lifecycle, documentation and even requirements for many years. We've also been using an enterprise wiki for many years.

While the author of the PLM Think Tank Blog brings up a few good points - and I agree with all the facts that he has presented. However, I also believe that some of the weaknesses could very well be strengths - it just depends on how you use a wiki.We often use the wiki for the following purposes:
a) A number of small teams need to chime in on a feature that one of the teams is working on
b) A developer wants to publish a design based on numerous discussions and prototyping
c) Program management wants to publish schedules, weekly meeting updates, action items, etc
d) A product manager starts a page on a future feature that he'll continue to add to as customer requirements trickle in

Now, the common aspect of each of these use cases is - well defined ownership. Now wouldn't that defeat the whole purpose of the wiki, you'd ask. The answer is no - the owner's job is not to maintain the page, but to initiate and publish it. The fact that a wiki is much easier to update than an excel sheet checked into a document management system, it is that much more effective in gathering those little inputs that form just a single line item on a long spreadsheet of product requirements.

Another aspect touched upon by the blog above is the fact that information on the wiki could be outdated or disorganized pretty soon. That's why it is essential to understand the reasonable expected lifecycle of a wiki page based upon its content and number of expected participants. A number of our wiki pages explode in content (such as feedback requests on a proposed idea). However, we use those for short-term data gathering only. The moment we have all that information, we move it to a more presentable summary medium such as powerpoint, or in a more scalable enterprise application.

Integration is another aspect that we've done fairly well to the extent needed in wikis. You can use Agile PLM's URL Attachment feature to link any wiki page to any PLM object. You could even put that URL in a descriptive field on that object's attributes, and Agile will automatically render that URL as clickable in your browser. We've also implemented a small macro on our wiki editor which automatically converts any Agile part numbers in the wiki to clickable URLs pointing directly to that part in Agile. With LDAP authentication enabled, that part in PLM is literally a click away from the wiki post.

Eventually, the utility of any social media is limited only by the drive of the people using it, and what is the wrong choice for someone could be the right one for others. All I've presented here is the level of success that we've had by the Wiki, and I thank Oleg Shilovitsky for the food for thought. I'd love to hear from our readers about their own successes or failures using social media with PLM.


The classic Wiki-model, as exemplified by Wikipedia itself, is one that thrives on public ownership and public participation: Anyone can edit it, contribute to it, or view it. In essence, it's meant to be a communal encyclopedia, a repository of knowledge. That model would be disastrous if deployed in product development. The model you're describing above (with well-defined ownership) functions as a communal dashboard for a team with common goals. I can see how this could add value in product development. In the way it accepts and displays information, it's much better than a discussion forums and far superior to typical email applications. Neither discussion forums nor email apps facilitate the type of product data integration you're describing. I'd say people need to pick the right Wiki-model for their purpose. Otherwise, it could do more harm than good.

Posted by Kenneth on May 05, 2009 at 03:37 AM PDT #

This article echoed our internal discussion. We are using Wiki for collaborative aspect (intial discussions, elaboration of bullet points/concepts to more formal details) and at that point use standard edm/pdm/plm (Agile etc) tool for formal approval, revision, dependencies etc. We have created a simple macro to show product issues (maintained in Agile) as a quick status update on wiki page.

Posted by Viral Patel on May 07, 2009 at 05:10 AM PDT #

That's remarkable Viral. We used to do something quite similar by exposing real-time defect list on specific topics in wiki, back when we used to use Clearcase for tracking defects. We've not done that yet with our new bug tracking system, but it's sure nice to see an application of Agile data being exposed in an internal team wiki. As we continue to expand our offering of web services in Agile PLM, we hope to see more of such collaboration use cases being enabled.

Posted by Anurag Batra on May 07, 2009 at 06:06 AM PDT #

Update: just found out that another group within our company uses the Atlassian Confluence wiki. This wiki has features such as hierarchy of pages, security, notifications and even integration with desktop and enterprise application. Certainly addresses some of the concerns of enterprise wiki customers today.

Posted by Anurag Batra on May 08, 2009 at 10:30 AM PDT #

Post a Comment:
  • HTML Syntax: NOT allowed

Hear from the community that's pioneering PLM's critical role in transforming supply chains into sustainable value chains that power profitable innovation and competitive advantage.

Subscribe to Oracle Agile PLM Blog by Email


« June 2016