Scheduling with Clients (It’s Easier than Scheduling with Senior Management)

Until recently, no one in our department had had occasion to schedule anything with a client, as far as I know. I was under the impression, in fact, that we weren’t encouraged to speak to clients at all—as in, we might not technically be allowed to speak to them.

At my company, we’re all familiar with Outlook invites; our company uses them heavily. If you are a person who happens to book meetings frequently, which I am, you can become an Outlook pro at our company. First you have to schedule the room. Then there is a separate invite for scheduling the people. Some rooms require that an administrative assistant send you an invite which you are NOT to use to invite the rest of the meeting attendees, because then the admin gets the responses. If you get the dreaded Declined response from an invitee, you get to figure out with them how to propose a new time for the meeting from that point, which is what they probably should have done in the first place.

If you are like me and you haven’t had much need to deal with inviting clients to anything, but the above sounds familiar, I can reassure you a bit that inviting clients is actually a more intuitive, normal process than the Outlook rigmarole.

The Reason I Had to Talk to Clients Was…

When we were finally finished with redesigning our help systems and creating topic templates, we presented them to our department director. Reorganizing our information was a cinch—that was our domain. But we were also asking for other fancy things like feedback features and a new look-and-feel that requires a new file format . These were not going to as easy for us to get. So our director asked us to show it to clients. We could see which features clients thought were going to be useful. After all, if clients want something, that’s more important than us wanting something. Pretty smart, actually.

So, demo planning began. We needed a new script tailored to clients and to an online format. We needed a survey to capture their responses for easy internal distribution. We needed to get clients to the demo. And we needed to include a growing list of internal folk.

Our director wanted to be there, in case the discussion got negative. The help design team wanted to be there, and our department manager. Another department wanted to send a couple of people to observe because they were considering using focus groups for some things. Our knowledge base administrator got invited, and the writers from another department. We were encouraged to include someone senior from the programming group. On top of that, the rest of our department was growing restless for information on the project, so we needed to include them, somehow.

How We Went About Getting Clients to Volunteer

First we had to get our hands on the actual clients. I drafted an email explaining that we needed some volunteers to preview the new help system, and our Marketing Director sent it to our user listserv. We got over 20 volunteers in under 24 hours. The clients really did want to talk to us. Just one of the little things that has made me less cynical during the course of this project.

How We Wooed the Volunteers

Here was the easy part about all this scheduling: I just called everyone. There was a super friendly email prior to that: “so glad you’re interested, I’d like to get back to you when we get to the scheduling phase in a week or so.” The guideline throughout was for the client to feel appreciated and to never feel like I had forgotten to get back to them.

When I called to formally invite each client to the demo, I had a script so that I wouldn’t forget to say anything important. I needed to let them know the date and time of the demo, the technical requirements, and a little more about what we would be covering. I also had some questions for them: I wanted to ask them to invite someone else from their facility, and I wanted to find out how they were currently using help systems. In fact, I had a survey that I filled out as I spoke to them. If they were in a hurry, I gave them the option of going online at their convenience to fill it out.

The point of making the phone call instead of continuing via email was to get a better level of commitment to attending. And we did get full attendance at the demo. In addition, it was too much information to successfully convey via email. I don’t think we would have gotten many survey responses—people wouldn’t have read down that far. And if people didn’t finish reading the email, then they might have ended up feeling like they had sufficient information about the demo, which is not how I wanted them to feel at any point.

Lastly, the phone call provided a much better opportunity for me to start building rapport than an email could have. The client and I can laugh together, I can ask them what they think about what I said to them, we can chat off topic a bit. Then I can send the Webex demo invite via email after the phone call, with the little Outlook invite attached, and if something is confusing or inconvenient, I am now a friendly person of whom they can easily ask a question. But you probably know all this; it’s fairly natural.

By the way, I never offered the option for any of the clients to choose a different time for the demo, and that wasn’t a problem for them. I presented it as, “this is the time we’re having the demo, can you make it?” Before I did that, I asked my favorite SME when the busy times are at hospitals, since our clients mostly work in hospitals. I looked at our director’s schedule and found a time that wasn’t during any of those busy times for the client.

I would have rescheduled if more than two or three clients had been unable to make it. But why open that can of worms before I had to? I was going to have plenty of fun scheduling internally.

Scheduling 80 Million Internal Attendees is Not Natural

When we came to our senses and realized we didn’t want all those people shuffling papers and typing while were giving the presentation on speaker phone. We thought some of them might get on the demo remotely by taking a Webex seat like the clients were doing, but there is a limit on the number of seats available. There was always the possibility of the client forwarding the invite to multiple people and filling up the seats, and we didn’t want technical difficulties.

We ended up with three demos: the online demo for clients, an internal demo for a couple of directors and architects who would need to implement these features for us (in which we shared how much the clients loved the pretty new format and the feedback features), and the demo for our team, in which we recapped what was new since the last time we talked about it.

What about you, do they let you talk to clients? What works for you?

Being a Judge for STC and Removing Flare Conditions

I’m using this morning to finish up my FTCC judging, so I will just make a plug for STC and give a quick Flare tip.

First; the plug: You should submit something to your local STC competition next year. Besides making your company look good if you win something (one reason why they should pay your entry fee), you will also get detailed, custom feedback on your delivarables (the biggest reason why your company should pay for it, I guess).

Judges benefit, too. They get driven to the awards ceremony in a limousine exposed to the work of tech communicators in their area, and incentive to learn how to articulate what works and what doesn’t. Ask your chapter leaders if you can get something else, too, like a nifty judge’s badge for your web site or a recommendation on LinkedIn.

If you already entered an STC competition, please let me know how you process that feedback. Last year our team got pretty systematic about the feedback we got on our entries. We categorized the feedback, then went through it as a team to determine next actions. Most of the time the next action was to add it to the list for future discussion. But every week we discuss something and come up with styles and guidelines out of those discussions. So we have a plan for using the feedback. Do you?

The Flare tip: I guess my blog comes up if you search for “Flare removing conditions.” Since I once had to remove unnecessary conditions from some of my Flare projects, I’ll tell you how I did it.

The biggest thing to remember is to remove the applications of the condition before you delete the condition from the set. You can see where you have applied a condition at the topic level if you have the indicator boxes set to display in the Content Explorer. However, as we know, things do not always happen cleanly in the code when you do it in the GUI. Additionally, there is no quick way to find all applications of a condition within a topic. (Something I recommend you minimize, anyway).

No problem; you can search for the code that indicates a condition is applied using the Find feature. Search for <MadCap:conditionalText MadCap:conditions=”YOURCONDITIONNAME”> and remove the applications, one by one. I don’t think this is something you can fix all at once using Find-and-replace, unless you are finding the condition tags are empty. You can find and replace empty condition tags: <MadCap:conditionalText MadCap:conditions=”"><MadCap:conditionalText>.

The nice thing about this is that it will keep empty condition tags from causing those indicator boxes to do funny things. For example, have you ever seen an indicator box half-colored when you applied a condition? Half of the box can have the color of your condition and half can be blank, which can seem pretty odd. It can happen if you removed or renamed the condition from your condition set but didn’t remove it where it was applied.

As a reminder, if you import topics from a source project into a master project, you should do the find-and-replace in the source project first, then reimport, then do it in the master project.

How Real Do We Need to Get about Our Documentation?

Our team has been working on reorganizing our template for help system content, and last week we showed it to clients in an online demo. We also went on our first-ever client site visit to a hospital that uses our laboratory information systems. The lid is off Pandora’s box.

We’ve been asking to get our hands on clients for years. When we got our new manager a year or so ago, she led an organized effort to this end. We were told to use internal resources, first. So now we receive the relevant emails from the user listserv. And the irrelevant ones.

We were told to comb the knowledge base for things that ought to be added to our manuals. My product alone has almost 200 articles. My plan is to categorize them and prioritize them so I can start incorporating the information. But it’s overwhelming.

I started asking around about getting access to demographic information on clients from the marketing database, and was told to watch my step in that inquiry because that information is fiercely guarded. So I’m saving that task for a day when I feel especially crafty.

The help design project, though, was an opportunity to talk directly with the clients. Ostensibly, we wanted their opinions on the prototype. But it was also an opportunity to chat about what they do all day (it was mainly a group of system administrators, who test the system and make sure everyone is using it correctly). By coincidence, we were scheduled in the same week for the standard hospital tour that our tech support new hires get. It was a chance to ask a boatload of users what they think of our current help systems.

They don’t think much of them, that’s what.

The system administrators use them when they absolutely must. The end users (technologists, phlebotomists, lab managers, nurses..) all ask the system administrators when they hit a snag in the system. Period.

Admittedly, I’m generalizing from one site visit and and one call with 15 sys admins. But this is 100% more information than we had the week before. I think we’ve got some solid areas to test. Such as: how long does it take for an end user to solve an issue in the system if they look it up in help vs. how long does it take if they call the sys admin and ask for help?

There seems to actually be resistance to end users using help. “They don’t have time to be clicking around in the system.” Should we be advocating for help use or should we give it up and write directly to the system administrators; give them more tools to help the end users themselves?

I cringe now when I think about how many heated discussions we had over verbiage that no one is going to read and links that no one is going to click.

A team member had a good question: how are we going to reconcile all this feedback (part of the new help design incorporated even more client feedback features) with the standards we’ve worked so hard to develop? Is there going to be push-and-pull there?

Our manuals are huge. Our systems are complex. We want to have time to incorporate video and be responsive to feedback. How real do we need to get about what we can leave out?

Introducing HD (Help Design)

One day a long time ago, in our staff meeting, our new manager referred offhand to our new mandate: that help systems shall be our primary deliverable. Print manuals shall take a back seat. Or maybe I referred to it when I said we should have topic templates. Or maybe that was when someone suggested that we streamline some of heading phrases that we use throughout our documents. What I clearly remember is that our manager asked for a few volunteers to meet as a committee and come up with suggestions as to how we could optimize our content for online help.

This week, I went digging through our old SharePoint site to figure out exactly how long ago that was. I was afraid to look, and rightly so. In March, it will have been a year and a half. Oh, and we will still be going in March, meeting with team members as they start to implement the new format and designing training exercises. We’re presenting a prototype to clients and programming this week, and we’re finally in implementation phase, but—a year and a half!

So begins the story of my first time leading a group project. Three SharePoint sites and roughly eighty meetings later, the project that has come to be called “HD” has taught me so much. From the outside looking in, the pace may have seemed glacial, some of which is a result of our inexperience and some of which is just the standard pace of change in a large, hierarchical company when many departments are affected, but we have had our hands full the entire time. I don’t think the same project would take us as long today, and I’d like to figure out why—where did we stumble? What did we learn?

I had some general ideas, but I wanted to know what other people on the committee thought. Jason Burke pointed out that our scope increased quite a bit: we were originally tasked to come up with some formatting and maybe minor content changes that would make our content work better online. We ended up pitching topic templates, a structural overhaul, custom documentation, and Flare Feedback server to clients and management. Plus trainings and implementation guidance for the team. “There as a real focus on doing it right,” he also said.

None of these were things any of us had much prior knowledge of. There was a ton of research and trial and error. Everyone went down their own pet research rabbit holes at one time or another, which took time. Our manager admitted that she wondered at times whether she should have placed a deadline on more things in the project; she wonders how that would have changed our outcome. We used consensus rather than having a decision maker, and we were very thorough, she pointed out. Those things take time, and their products are different than a process where the group leader sets hard deadlines and makes the final call on ideas.

I have plans for a series of posts about this project, but for now I’ll just list the skills I improved during the course of it, with the goal of linking back to this list as I write the posts:

• Project management for group projects (how to keep all the notes)
• Influencing without authority (50 ways to not end a meeting)
• Fostering collaboration (how to kill your darlings)
• Collaborating with SharePoint sites (if you really must)
• Developing topic templates sans DITA (because it’s easier than asking for CMS)
• Internal selling/getting buy in (the clients want what?)
• Scheduling with clients (is far easier than scheduling with senior management)
• Demo scripts for multiple presenters (so people don’t hate their lines)
• Developing surveys (how to beat around the bush)
• How committees can keep larger teams happy (!)

I’m looking forward to these posts. It was worth examining what took so long, partly because in the process I was reminded of how well the HD group works together, now. There is more trust, we build on each other’s ideas, and we’re more efficient at producing those ideas. That experience of being on a strong team will serve us after the topic templates are long obsolete.

Why I Blog About Work

One day at work a year or so ago, I was reading Intercom at my desk on my break. Someone (a manager) asked me, “Don’t you ever shut off? You know, just do something else?” Actually, those might not have been the exact words, but it’s close. Reading that magazine was relaxing for me, though. I wasn’t reading about anything we were working on. We don’t use DITA. I wasn’t taking a break from drafting a formal communication policy. It was basically daydreaming. It was a fifteen minute break, not a vacation day.

I’ve been thinking of that remark when I count the weekly hours it should take to do this blog right. I think it’s worth it. In fact, that’s beyond obvious to me.

When I decided I wanted a blog, it was pretty simple to settle on this topic, technical communication. It was the only subject about which I felt sure I would always have something to say. At the time I was starting to appreciate movies and good television shows the same way I had always appreciated books. I considered a blog about being a newbie to television. I thought blogging about television would make me watch good shows and prevent me from mindlessly consuming programs. And I wouldn’t run out of things to say, I thought, since there is no shortage of programming.

I recently friended freelance writer Amy Vernon on twitter, who has a TV blog. It’s not from a newbie perspective, but it’s sort of what I had a in mind—an independent spouting off about shows. Eric Deggans does The Feed in association with the St. Petersburg Times that is enjoyable even though I didn’t end up becoming a connoisseur of quality programming. I’ll watch almost anything, in fact.

So, I wrote a couple of sample posts in Word and then I got bored. Writing about tech comm, I never get bored. I get blocked, I get “too busy” to post, I get worried that I’ve said to much. I don’t run out of things to say.

I blog to stay engaged. I blog to sort out what I think about an issue I’m experiencing or to get my thoughts straight about a project. Every post I finish is one more thing I have to talk about with people in my field. I blog so that I have a reason to ask those people questions. Right now, I ask senior tech commers questions, and they refer me to their blog posts. Eventually I’ll be able to do that.

I blog to have writing samples. I’m working on an article about business analysts, for example, with interviews and research. I blog so I can link from my resume to show that I helped solve work problems. Do I know Flare? Why, yes I do, and here are some posts about advanced project linking to prove it. I haven’t actually rigged up my resume like that, yet, but I will.

I blog because I spend more time tech writing than just about anything else, and if I still have something to say about it when the day is over, it’s part of my proof to myself that I’m in the right field. If I still have something to say, it means that I’m processing my work experience and moving forward, not just cranking out projects without reflecting on I’ve learned.

A blog post can be a postmortem for a project, it can be venting, or a request for conversation, or just a blip out into the world that I was here and I imported something into Flare today, even if it was only to produce a .chm.

I blog about work so that I never have to type about tech writing what I had to type about job coaching; so that I never have to say I wasn’t a very good tech writer.

What I’m after here is mastery. I think blogging is one of the roads to mastering a subject. Since I’m at work all day, and I’m in the right field, why not do all I can to be good at it?