1. Making Collaboration Happen By Managing Perceptions and Controlling Emotions Pawan Nayar 8 December 2001

2. This presentation discusses... Importance of collaboration in technical communication Existing perceptions that hamper collaboration Important milestones in a typical document development life cycle (DLC) for initiating/sustaining collaboration Tips/best practices for effective collaboration/document review

3. … in a manner that helps you to Identify unnecessary perceptions and emotions Take actions that develop better professional relationship, and as a consequence, facilitate better collaboration

4. Technology & pace of development makes writing difficult Technical communicators are NOT always technical people Document should be zero-defect Clarity, consistency, and correctness Organizations need to groom their talent Technical communicators write for typically 8 software developers Need for outsourcing, telecommuting and cross- geography product development Technical communication is difficult Importance of Collaboration in Technical Communication

5. Collaboration: Opportunities and Challenges

8. Documentation Development Life Cycle

9. Objectives Define long-lasting vision and set the scope for the current release. Define processes, standards Set minimum pass-fail requirements Issues/Perceptions to Avoid General focus is more on product (read code) features. Typical document development process may not interest all. Envisioning/Planning Phases

10. Objectives Create quality deliverables. Ensure proper reviews and QA Improve processes Issues/Perceptions to Avoid Too many activities or crunched deadlines may lower priority of reviews/ collaboration Low focus on doc review because of immediate/other priorities Developing/Stabilizing Phases

11. Be convinced about your project. Sell it. Identify the core set of reviewers –Know your product’s most frequent complainer –Bug/enhancement requestors Identify external requirements –Any internal/external conference –Marketing commitments, key customer requests Inform reviewers in time Make writing process democratic. Seek inputs. (Cont’d) Getting the Review Commitment

12. Maintain Relations –Write occasionally even without work –Remember other person’s important days/moments. Congratulate on time. Show gratitude in right way. Self-perception management –Be sincere yourself - follow up till you get a reply –The other party is there to help. Do not read a NO for a review as anything more than the word NO. You can still follow up - seek an alternate time –Ensure you commit to other’s schedule. If not, inform any change in plans. Personalize Interaction Getting the Review Commitment

13. Inform the progress. –Send people book’s TOC for review –One mail/ month helps sustains interest –Clarify how the other person will be impacted if she does not review. Do you need to raise alarm! Use roles strengths to ask relevant questions: –R&D - How product works, internal technology, and algorithms used –Testing - Real life usage of product –Support engineers - Usability, installation, FAQs –Marketing - What’s new All mails for review must be detailed and complete Creating the First Cut

14. Need New document needs multiple review rounds People generally do one review round Not all reviewers are free together You get questions that subsequent reviewers answer Doc improves in iterative cycles Proposed Style Stagger review Target most passionate person first Incorporate suggestions, send to a group Club questions Rotate questions to the source for answers When doc is fairly stable, target big groups for reviews Scheduling of Reviews

15. Facts All suggestions may not require fix Not all areas are reviewed in equal detail You don’t get all review in one go Some suggestions may impact fixes to work not in your domain Reviewer expects thanks, responsiveness Proposed Response Style Fix each suggestion on merit and communicate it Make it easy for review Clarify. Seek clarifications Explain your perspective Inform all impacted people Thank where required Don’t be monotonous Be careful about what you write and how Fixing Review Comments - Lessons

16. Review of docs is a continual process Onus of subsequent reviews lies with the TC –Target different people for different review rounds –Rotate between questions/ portions of book/ don’t give full doc to person unless he/she agrees to. –Fix what you commit. Remember any suggestion you don’t fix and is caught in second round, ends the deal. Track changes –Track who said what, when, and how –Track changes in source files –Keep original requestor informed of any fixes caused by subsequent review Follow Up and Subsequent Reviews

17. Analyze performance on relationship –Did you just complete work or made friends –How was the success rate on getting reviews Perform root cause analysis of mistakes/oversights Categorize suggestions into areas where you have enhancements for next project. Raise bug/enhancement requests. Analyze your communication - mails/ verbal commitments Retrospection

18. Your suffering is over. Please feel free to share your emotions or previously built perceptions. By note It is not important to believe everything. It is important to believe what you believe. Check whether the belief is not a hangover of an impromptu emotion or a residual perception. Check again whether you believe in the cause of the belief that caused the belief in the first place. Thanks

19. Importance of collaboration in technical communication Perceptions hamper collaboration Collaboration requires timing, commitment and enthusiasm Tips/best practices for effective collaboration Summary - You learned...

20. Overheard Many members of our group do not work and those who work are individualists. They are seldom interested in what the other person is doing or what can be done to improve their work. As a result, I do not care for what they do. May God keep this industry, and all of who deserve continue to get their salary, and others get what they deserve. Possibility 1 You are right in your judgment but then lack of teamwork is not going to help you either. Need some change in culture. Possibility 2 The other person does not suggest/help/review because you may have never asked she is not sure whether it would be appreciated she is short of time Reality You may not like being told what to do. You may not have helped the other person. You may lack trust, risk-taking, or appreciation of the other person’s work.

21. There’s something in it for you You learn something that you IMMEDIATELY need It is an official need It will help you train/educate others It is highly visible. It rewards or helps build relations. Example - Support staff may like to review docs on buggy areas of code or new features highly valuable. You have the time You know/ trust the requestor You know the requestor You know you will get credit You are capable/ the right person to review Case - You may not review a doc if it exposes your limited knowledge Why should you review a doc?

22. –Attach all files (pdf, database) and copy them to a shared region. Include source files –Explain the essence of the doc again. –Mention all known problems and solutions. Include backward compatibility issues –Explain how to start instructions –Remind them again - you are waiting for the review –Be polite. Thank them for their effort –If possible, send individual mails –Follow up on mails till you get a review or reasons why the review may not be completed While sending a doc for review

23. First Cut You had promised but … Would you be able to review this document. This is the first cut... This is the final cut... Perhaps better... I was wondering whether you have completed the document review … Your valuable inputs will help me improve the quality of this document I have completed writing the … The document is fairly complete in structure and content. However, there’s still scope of improvement and your feedback... Be careful about how you write...

24. –Could you have cut the communication short (needless rounds) –Did unnecessary perceptions kill your time - did you follow up on them to remove them –Were there statements that you should not have made –Did you over/under commit –Were you encouraged to share/hide feedback with peers/CFT/supervisor –Did you think you should have given up - why? May not share - ask yourself and perhaps you will get more answers –Did you thank the person who made the maximum contribution and did you tell the ‘capable’ persons with lesser inputs how they could have done better Analyze Your Communication