Reviews a company's move from RoboHelp to Flare and the buy-in that needed to happen across departments for the project to be successful.

1. Superheros and a leprechaun, with Flare: A case study in breaking down silos

2. Key Pointes Moving documentation from RoboHelp to Flare Key: Buy-in and cooperation from the team The process for how we made the transition

3. Your questions Please let me know if you have any questions. My contact info will be at the end. The slide info will be at the end.

4. Who I Am Usability Consultant Self-employed Company is Key Pointe Usability Consulting. Started as tech writer and moved into usability

5. Who Is Meridian Software Company based in California with an office here in Vancouver Makes Construction Project Management Software

6. How I came upon the job is a long story, but I’ll make it short.

7. Joe, Irish, Doc manager Theresa, consultant Marcy, writer Contract writer Brian, CTO Viktor, Design Jay Support 3 Johns

8. Product 1: Proliance 4 RH projects with 2000 help topics for Proliance with 400 duplicated topics 10 bulletins, 10 white papers, installation manual, upgrade manual in Word Readmes in FrontPage Technical Library for Developers in Notepad 1000 kb items in Pivotal 1999 (no XML)

9. Product 2: Prolog 2500 help topics in Prolog with about 600 duplicated topics 8 online help systems RoboHelp 50 technical bulletins in Word Readmes, Installation guides, Upgrade guides in FrontPage 3000 knowledge base items in Pivotal database from 1999 (no XML capabilities)

10. Help Situation RH had problems with big projects No Version Control No technical writers on staff Things had reached critical mass

11. Things They Wanted To fix things up, bring them up to date To hire a writer Coordinate with Support Services (in California)

12. Coordinating with Support Too many resources meant customers couldn’t find information. Information was out of date. Support needed to drive more people to the finding information on the website, away from emails and phone calls.

16. Helping Support Documentation was important to Support, so why not integrate with them more? New SupportLink WebHelp proposed Support Manager buys in!

17. Tool evaluation requirements Technical documentation oriented Import from RH and Word Something like RH, but have much better content reuse options

18. Choosing Flare Offered the most options in terms of functionality Worked most easily with RH Lower cost Lower perceived learning curve

19. Business case Reviewed why we should move from to Flare. Written for the V.P of R&D

21. Project plan Iteration 1 and 2 reviewed: Purpose Objectives Scope Resources Timeline Effort Estimate

24. Project estimate Gave an estimate for when the project could be accomplished with two writers vs three writers.

25. Writer Writer Writer

26. Presentation to R&D People were curious Something fresh was happening for a stagnant department

31. Implementing Decided to change both products at the same time, but slightly delayed the second product so I could train the technical writer to do: Information model Content audit Detailed reuse model

32. Information model The information model gave a high level overview of the deliverables we would create. This was more for people outside the department who wanted to know what we were doing, and easy way to see content reuse.

34. Content audit The content audit was much more in depth and looked at all the documentation and where it was duplicated.

35. Detailed reuse model The detailed reuse model showed on a topic-by-topic basis where the content would be reused and in which deliverables.

37. Keeping in Touch We were also in contact with: Support Services Marketing R&D

38. SupportLink mockups Done in Visio We asked for CSS support and graphic design support Acted as a proof of concept

40. Design Help with Flare skin The graphic designer made it look pretty And was concerned about usability and “Web 2.0” Yay!

42. Importing KB Items Worked with Support to figure out the knowledge base process. Items up to date Not duplicated

43. Technical Library CTO needs a Technical Library “ I want the ‘MSDN look and feel’.” I’ve seen the MSDN and it’s not that attractive, so I asked him what he meant

44. It was clear: Documentation suffered from a lack of understanding in R&D.

45. Support relied on the documentation to be accurate and concise, but it wasn’t.

46. Rarely do we measure technical support efficiency in terms of useful documentation because we’re not familiar with the connection.

47. This transition was large for everyone: move from multiple sources, lots of browsing, to searching in one place for the necessary information.

48. In early releases, some Support staff panicked when information was missing. To succeed, to show our flexibility and willingness, we had to be accommodating and understanding.

49. By reaching out from documentation, we were able to start a team effort and build understanding. 90% of people bought in

50. Without the enthusiasm and excitement, the project would not have gone as well. (Link to WebSite unavailable)

51. Info Theresa Putkey [email_address] www.keypointe.ca