Moving the organization_apr2012

Editor's Notes

• #3: Bio30+ years in tech commStarted writing software documentation, in the form of manualsEarly involvement with tagging languages, which evolved into structured authoring“This is a paragraph or list” rather than “increase the indent; change the font”I’m lucky: Early on I embraced the concepts of structured authoring My experience helps me come at this subject from multiple viewpoints:Writer – I know how the transition looks from the writers’ perspectiveArchitect – I know the issues and challenges of building structured documentationManager – I understand the financial issues as well as those of leading a team into something newProud to be an STC FellowThat, along with the 30+ years, doesn’t mean that I know EVERYTHINGIt means that I do know a lot of things, and that my peers have recognized me for itIf questions or comments, use CHAT
• #4: What we’ll coverShort description of collaborative or structured authoring – so that all of you are up to speedStructured authoring isn’t just a move to different tools It represents a change in how you think about content. That’s why it’s often called a paradigm shiftStages of moving the organization into the new paradigmYou have to get understanding and buy-in from ALL stakeholdersPutting it all togetherA few final thoughts about how the pieces fitAnd about keeping everything in perspective
• #5: 1:05Let’s look at 3 principles of structured authoringCOLLABORATION: Here’s where the paradigm shift startsWriters are used to thinking of themselves as the authors of a book, or a help systemNow, you might not even be the author of a particular chapter or section, necessarilyModular writing: you work on pieces, not whole documentsPieces can be assembled in different ways into different documentsFor example, the same piece might be used as part of a website, a help system, and a PDFMultiple writers work togetherOn the same topics ….or chunks of content (think chapters or appendixes, if using the book metaphor)
• #6: Another paradigm shiftIn traditional authoring you create elements –Like paragraphsListsSectionsThe elements are independent of each otherIf you want to connect them, you just copy/paste contentThe elements are formatted however you wantIs something the name of a system command? The writer chooses, say, Arial boldIn structured authoring environments like DITA, formatting is applied at publishing timeThe writer doesn’t chooseIs something the name of a system command? The writer simply identifies it as such, and doesn’t worry about formattingThis is what we mean by “semantic”: the study of meaningWe focus on what something IS (like a system command), not on how it looksSome writers embrace this: Great! I don’t have to worry about formatting, consistency, etc.Other writers resent having to give up this level of controlPart of your challenge is helping your writers adjust to this
• #7: Here’s a big advantage of structured authoringElements can be reusedNow it’s not a copy/paste operationSmall elements, like steps in a procedure, can be used in multiple placesBig elements, like sections and whole topics, can also be reusedWrite one topic, and reuse it in many places: the online help, the web page, the PDFThe payoff is:Efficiency (writers write once, and it’s reused many times)ConsistencyUpdating becomes easier: make the update once, and it’s propagated to all the outputsReuse is sometimes called single-sourcing
• #8: What’s the business case for collaborative or structured authoring?In talking about reuse I already mentioned some of thisEfficiency – write once, publish manySingle sourcing – publish several outputs from one set of inputsLower translation costs – You have fewer source documents, so there’s less to translate You also have better consistency, which always saves translation costsPublishing can be automated: Prompt turnaround More online output = lower print costs
• #9: Customer satisfaction is good businessReach customers in a variety of formats: web, print, etc.Publishing is more nimble: respond more quickly with updatesFuture: Structured authoring can accommodate community-based contentWhere customers contribute data to, say, wikisCustomer-generated content can easily be integrated into your structureExample: What Mozilla is doing (Janet Swisher presentation at 2011 Summit)
• #10: What does it mean to the writers?You need to know this, because you’ll need the writers’ buy-in for any changes that you makeThe writers will probably need to learn new toolsTools aren’t your primary concern, as the managerBut to the writers this will be a crucial issueBe able to answer the question “why are we changing, when the old tools work perfectly well?”The answer is usually rooted in the business caseSo….start with the business caseWriters should be business savvyThey should see their work as part of the overall business, as a direct contributor to the bottom lineIf writers are in silos – a monk in a cell, or a “writing” team in a fortress, isolated from the rest of the organization– they need to get out of that mindsetHelp writers see the benefits of collaborationIt’s a necessity, in fact, in environments like agile where product development is short-term and fastHelp them see themselves as authors of topics, not whole booksRather than individual contributors, they’re part of a teamThey don’t individually “own” books any moreIn microcosm, this is the same as overcoming the “silo” mentality, or the monk-in-a-cell mentality
• #11: What am I talking about?Two examples of structured authoring methodologiesDITA – standard originally for technical documentationNow also for training, and can be customized for other uses as wellS1000D – standard for equipment maintenance and operations
• #12: 1:15Seven steps to moving the organizationWe’ll cover each of themNote: These are not strictly in order. There’s overlap, and there’s bound to be some circling back
• #13: You wouldn’t go on a major expedition without scoping out the landscape first As you evaluate the landscape you’ll uncover a lot of pertinent infoWarning: “Here be dragons.” Sometimes you’ll run into political issues (dragons)When you do, it’s up to you whether to challenge the status quo or work around itFuture needs/objectives: Where does the business hope to go?What would the ideal future look like – in terms of process as well as in terms of the information productsIn other words, have a vision statement that forms a basis for making the moveNeeds of the (customer) audienceThe audience is always the focus for tech commYour plans have to align with the audience (current & potential)Financial landscape:How long do you have to absorb the startup cost? (IOW, how long before it has to start paying for itself?)How much is the executive suite to invest, and how much are they bought in?Skills you have in-houseYou might need to hire a consultant for any or all of:Reengineering business processesInformation architectureTools / services
• #14: Evaluation - ContinuedWhat content currently exists? What formats is it in? How easily can it be converted to structured?Is there any content you don’t need any more? (Do this analysis if possible)What gaps exist – missing content that you need to have?Current workflowHow do things work today?We’ll talk in a moment about refining processesThe starting point is knowing what the processes are todayAnalyze your processes, make mapsThis is business process mappingInformation flow in the organization: Where does it flow from? To?Where are the intersects?Are there choke points? Redundancies? Anyone with too much or too little authority? Current pains: I mean “pains” in the marketing sense: What do the people in your organization identify as problems?This will help you prioritize what parts of the process need to be changedYou should also couch your “buy-in” messages in terms of these painsExample: The review process is outmoded. Both writers and SMEs hate it. No efficiency, not enough accountability.
• #15: 1:20Architecture needs to take a holistic approach – part of an organization-wide content strategyCollaborative/structured makes it easier to align with such an organization-wide strategyContent as an assembly of building blocks (topics, in the parlance of structured authoring)It’s easier to get concurrence with a strategy when folks can see the pieces move from inception through deliveryAs you take your message to the writers AND to other teams in the organizationShow how ALL content can be assembled into customer deliverables(Not just tech pubs content)Development, marketing, training, and support, all are contributorsAll can see that the strategy is doable
• #16: As you design the new information set, considerHow individual topics are structuredRelationships among topicsReuseExpected publishing formatsContent management – version control, access, etc.
• #17: 1:25The next big step in moving the organization is refining business processesBy “processes” I mean the workflows that are in place for each major stage of the content development process:PlanningAuthoringEditingReviewingApprovingTranslatingPublishingI use the verb “refine” because I want to be, well, refinedBut changing the processes might actually be a matter of blowing them up and starting overEvaluate what’s worked well in the past – if it ain’t broke don’t fix itYou don’t have to throw everything outOnly the things that won’t work in a collaborative/structured authoring modelChances are these things are already in need of improvement – even with the old model
• #18: Use Process Mapping to illustrate the delta, or gap, between existing and proposed processesOnce gaps are identified, prioritize which ones to attack – you won’t get it all doneChange processes to allow for collaborative writing: - Engender a collaborative environment - Info developed by many writers and/or SMEs; later assembled (remember the Legos)Explain the changes to all stakeholders who are affected by the processesYou need their buy-in……So that they’ll cooperate when the work is actually going on“No surprises”As much as possible, align the new processes with the current workflowFor example, make sure that your review process complements the development methodology – be it agile, etc.
• #19: All process changes have to be planned in context – not in a vacuumFor this you’ll need an implementation roadmapHow do we get from the current state to the desired state?How do the new processes fit with other processes – such as development/translation/publishingFor every process change, get buy-in from all affected stakeholdersYou won’t be able to ram it down their throatsIf you don’t announce the new process in advance, someone will be surprised at some pointThat almost never goes well
• #20: Reviews and approvals are always critical processes in content developmentThey should be the right level: not too rigorous, not too lightBe sure that all legal and regulatory requirements are metUse the software to help with reviews - no need to rely on old-fashioned methodsOptions: - PDF markup - Word markup - Ideal: Tool with a review workflow (like easyDITA)Make sure all reviewers and approvers are on board with the process, before you start using it
• #21: Up to now I’ve barely mentioned toolsThat’s because moving the organization to structured authoring is NOT primarily a discussion about toolsThat said, tools play an important roleDon’t select tools just because they worked somewhere else (in another company, or at your last job)One size does not fit allFactors in the choice of tools:Current environment – esp. if the company recently invested in, say, a CMS or an authoring platformDo the tools work well together? You might consider an end-to-end solution (CMS, authoring, reviewing, publishing, etc.) – but that isn’t requiredDo the tools work well with the workflow you developed in “Refine Processes”?Remember to engage the IT department (HT to Alan Pringle – blog article on 9 April):They have a good sense of what will and will not work (integrating new tools with the infrastructure)They can help set things up for optimal benefitYou need them on board in case something goes awry later
• #22: 1:30If you forget everything else I say today, remember this:The writing team MUST be trained in the new processesThey need to understand both the whys and the howsOther participants must be trained as well, but the writing team is the most critical pieceHorror story: New tools inflicted on a writing team that didn’t understand the need for themI was one of the writersWe thought we were good at using our current tools – no, we KNEW we were good Management announced we were switching to a new set of toolsNo explanation of why – just that we were going to do itWe writers felt alienated, thought all of our bosses were pointy-haired (like Dilbert)It sure would’ve helped if we’d been told about the business case……and about the added benefit to customers (more formats; easier to update)The key is making the writers understand the business caseI’ve seen PMs gloss over this aspect: they assumed that writers don’t need to know (or aren’t interested in) the business caseWrong!The business case provides the context, the big pictureWithout it, writers will ask “why are we changing, when the old tools work perfectly well?”And you won’t have an answer that’ll satisfy them
• #23: The buy-in part:Tailor the training to each stakeholderBefore starting discussions with any team, plan what you’re going to say to everyoneEveryone should hear a tailored “what’s in it for me” messageFor example….Writers: How this makes me more responsive to customers; things I can do that I couldn’t do beforeEditors: Collaboration; involvement earlier in the processSMEs: Integration with development bug-tracking processes; easier reviews through improved toolsIf you don’t take the time to figure out what to tell each group….…. and who you need to get on your side early….….You’ll send the wrong message to the wrong people and increase your chance of failing in the rolloutIt’s like a marketing campaign for the rolloutDon't rush the trainingMake sure there's time for that glimmer of understanding in the students’ facesFocus first on the WHY, then come back later for the HOWThe artwork is from Simon Sinek’s book, Start With Why (2009)Based on a simple idea:Tell people WHY you're doing something, they'll recognize their self-interest and participateTell people WHAT you're doing, they won'tYou might not have the resources to devote a lot of hours to thisTry to get a core group well-trained so that they can support the others Training is ongoing - you don't just do it once and expect the team to understand everything
• #24: Training for the writer is 2 stages (at least)First, buy-in training – fundamentals of structured authoring… ……including business case and ESPECIALLY “what’s in it for me” training for the writers (how it’ll make your jobs easier)Note: This kind of training content is available on the webLater, practical, hands-on training with the toolsYou’ll likely need to follow up later, after rollout, with supplemental training in the toolsUnless the tools are very similar to what the writers were using beforeCommon mistake: Teaching the tools too soonBy the time the rollout actually happens, they will have forgotten what you taught themOther constituencies need focused, targeted training, for example:XSLTs and schemas for the tech teamHands-on for edits, reviews, and approvals for the SMEsDon’t forget to include the WHY information (“what’s in it for me”) for these groups tooTheir buy-in is easier to get than the writers’, but it’s still important
• #25: 1:40Don’t try to roll the whole thing out at once, across the boardPick a smaller project, with some flexibility in the schedulePilot projects are idealThis gives people the chance to get more comfortableIt gives you a chance to test the new processesTake bite-sized chunks Don’t overwhelm the peopleAnd always….Assess as you go
• #26: Be sensitive to the mood:How are people accepting the changes? Any additional training needed?Some people adapt to change better than others – ideally, mix the people togetherIf you see that the pain level is running high, slow down the pace and deal up-front with the emotions that people are feelingNow I’m going to take a lot of pressure off you….You won’t get everything right the first time!Manage expectationsDecide (and agree) up front: what’s an acceptable error rate?
• #27: Have a Plan B in your desk drawerIf everything blows up, be able to back out and do it the old wayWhat processes can be left in place for now?Keep the big picture in mind:Failure, even in total, doesn’t mean you can’t recalibrate and try againEdison: I am not discouraged, because every wrong attempt discarded is another step forward.
• #28: 1:45Here are the seven stages as they flow to one anotherNote that it’s a circle: You’ll adjust and start the whole thing over againRemember:This isn’t a perfect cycleOften you’ll loop backSometimes 2 or more stages will go on at the same time
• #29: It doesn’t all happen overnightRealize that you’re in it for the long haulThis takes AT LEAST a full product-development cycle, usually longerSet a realistic timelineManage expectations – of executives, managers, and workersMonitor and assess constantly: What’s not working? What needs adjusting? Where is additional training needed?When something doesn’t work, don’t give upA failure is always a lesson learned (as Edison reminded us)Recalibrate and make another run at itDIY or hire a consultantPart of your evaluation process is figuring out what skills you don’t have internallyYou might need to hire someoneTo reengineer your business processesTo do the information architectureTo advise you on tools (or provide tools as SaaS)
• #30: 1:50Tell everyone to use the chat to ask questions (people should stay muted)Repeat each question before you answer it