Author: Iris

In my new corner of the IT world, I’ve been thinking a lot about knowledge management in an environment where people are chronically overworked, under-staffed, and nobody is formally in charge of knowledge management for the whole group. It seems inevitable that, if you have good people working in this kind of context, and if you’re able to retain people for any length of time, it’s inevitable that you’ll end up with extremely competent people who really know their stuff, but who have often managed to keep their heads even near the surface of the water by “doing the work rather than documenting the work.” And this means that processes get heavily siloed, relying on specific people to do things that only they know how to do, and who can certainly do the thing faster than they can train someone else to do the thing.

It’s a tough spot because digging out of it takes time and effort, which are the two things that folks in this kind of context can’t really spare.

I’m lucky to work with extremely dedicated and competent colleagues, and they even carved time out of my job description to build and tend a client-facing Knowledge Base! My goals for the KB are to a) help folks in our community do what they need to do, but also very much b) help our front line staff provide quick and consistent answers to the questions that flood in every day. And particularly at a service where the frontline staff are generally student workers, getting staff up to speed quickly and simply is crucial. Even if our frontline staff weren’t students, I’d still want this kind of a KB. My own analogy always goes back to the way that we used research guides in the library so that even I, a humanities librarian to the core, could help the STEM who came to the general research desk for help. I certainly didn’t know what a Gini coefficient was, but luckily the ECON librarian had a guide on what to do when someone needed whatever-it-was so I was able to provide help and support even in a context where I simply couldn’t know enough about everything. The reference librarian’s mantra is “I don’t know everything, but I know where to find out about it.”

Over the course of the last 9 months, we’ve gotten our KB up and running (and my little “KB Team” and I have learned so much!). And though that work will NEVER be done, I’m also starting to see other knowledge management opportunities on the horizon.

The biggest thing I’m pondering right now is building out “Workflows” in our ticketing and project management system. These are things that would step through flowcharts of choices, tasks, approvals, etc within the ticketing system, and if we’re able to build them such that they step us through our more complex processes they would in effect be the Knowledge Base of Processes. (And yes, I know it wouldn’t be sufficient documentation for our procedures, but it’d be actionable and more than we have available to us right now.) So, for example, what if our processes like hardware request/deployment, hardware reclaim, software/licensing review, change control, Software renewals, certificate renewals, system maintenance, and project request/review (just to name a few) all had workflows in the system?

For things we do less frequently, workflows would help reduce the time we spend thinking “I wonder how we did this last time.” For things we do all the time, they would be safeguards against forgetting crucial steps, and they would be training aids for new employees. For managers and auditors, they would allow for better reporting and visibility for work (and especially for the often-invisible routine operational work) going on in the department. In this way they would complement the already-visible work of answering support questions and working on formal Projects-With-A-Capital-P.

The trick, of course, is getting the time to actually build these Workflows into the system (and then maintain them). And they’d have to be built such that the processes aren’t so complex that they become an added burden on already over-extended employees.

But there’s got to be a sweet spot where these workflows could both document our processes in fundamentally actionable ways, and also help us work more efficiently while shining a light on the mostly invisible labor that makes up so much of our jobs.

Comments closed

My small-but-mighty team and I are well into the project of starting up a new knowledge base. The first big question was ONE WORD OR TWO??? Knowledgebase or Knowledge Base. We’ve settled on two words because that’s what TeamDynamix uses, but opinions are definitely divided on the matter. I’m personally quite firmly on both sides of that fence myself…

Last week I “promoted” my two student workers to Approvers – so now they can not only draft articles but also approve and publish them. We’re working on a style guide (I’ll share when we have something people might be able to understand), and we’re developing a topic/category structure so that clients who browse rather than search have a hope of finding what they need (or to catch people who search and land on something almost right so that they can find similar things). All of this preparation and foundation is of course with the goal that before too long we’ll be able to open up authoring/editing/approving to lots and lots more people in the department, and they’ll be able to make easy and wise choices about where to put their content and how to present it effectively.

We’re also adopting a lot of the KCS philosophy, which means that basically everyone can submit articles or flag existing articles for editing, and ideally techs will turn to the KB for nearly every question responses (our motto is: Find it, Flag it, Fix it, Add it). Then content experts will be able to approve/publish articles. Basically, just like with library research guides, I want as few bottle necks as possible in the process of producing reasonably standardized self-service tech support articles.

We’ve come up with a set of initial priorities for content:

• High-traffic, client-facing, self-service content, especially:
  • Whatever will be needed for new students/faculty/staff for Fall Term (connecting to the wifi, getting MS Office on your computer, etc)
  • How to get your computer connected to our cloud back-up system, the VPN, cloud storage drives, and other core systems that basically everyone has to do all the time
  • Mac/Windows OS update information
• Whatever we find ourselves typing frequently into responses to incoming questions to the Helpdesk (since KB articles can be attached to responses to tickets)

I’ve also talked to a few people who are interested in adding content, and we’re all trying to work out how to decide where to put all the different kinds of content people need to get out there for clients. For now, here’s how I’m thinking about the distinctions between what goes in the KB vs what goes on the WordPress-based campus/department website:

• In the KB
  • “Live” content – things that will be constantly updated
  • Content that needs to be restricted by audience in any way (we’re defaulting to fully public KB articles, but there are plenty of audience restrictions available as needed – WordPress audience restrictions are also available to us but are less granular)
  • Content that people will want to easily embed in answers to questions/tickets
  • Content that we want to have easily linkable from the pages where we have clients open tickets
  • Content that we think people will find primarily via search, especially Google search. The KB seems to be able to boost search results based on titles, article summaries, tags, and initial paragraphs of text, so we have a lot of options for catching people who are searching for guides.
• In the campus website
  • More high-level, stable descriptions of services/policies with pointers to the KB for specifics
  • The “why” instead of the “how”
  • Things that need more stability (things presented at conferences, etc) where there’s some expectations that redirects and archiving could be possible compared to the more ephemeral/evolutionary nature of a KB article that will be updated regularly

We’ve also worked out naming conventions for KB articles based on how we think clients will discover content and how techs can find articles to attach to ticket responses. And we’re feeling our way toward conventions/styles that we think will be as sustainable and consistent across all authors while still allowing for as much flexibility as possible so that content experts don’t feel hamstrung by too many rules or too few styling options.

Then there’s a scope question for the KB: how comprehensive do we plan to be with our content in this system? We do NOT want to recreate either Google or vendor-supplied support sites. We want to augment those things by either pointing our clients to vendor-supplied support sites or adding local context to Google result list. And coming from an information-management background, I’m very interested in developing a curated set of publicly visible support articles. But exactly what fits into this “curated” set? How aggressively will we weed the “just in case” or “previously useful” articles? How will we strike a balance between answering as many questions as we can for people who search through our content vs restricting our search result lists (or category browsing lists) to only the most current and relevant topics? We’re still feeling our way to the proper balance for these things, for sure.

I’m also thinking through the cultural pieces of launching this new thing.

• Some parts of campus are pretty used to going elsewhere for information, so when should we move their content into this new place? Which new content will help drive eyes to the new space vs which content will languish in the new space because people will keep looking for it elsewhere?
• What about the techs who have created information in previous information repositories? How can we honor the work that they’ve done while also transitioning to a new location that has affordances that privilege different rhetorical strategies? I certainly don’t want to make anyone feel like their hard work in a different system is somehow bad or wrong just because information seeking and/or information presentation options have changed.

So, 6 weeks into my new job, and a month into this project, we have a pretty solid foundation and are turning our attention to adding as much content as we can. Things seem to be going well! But there are miles to go before we have anything like a mature knowledge base.

Comments closed

So… things have happened since last I wrote. I’m still a librarian (because I still have an MLIS), but I’m no longer employed by a library. I’ve decided to step sideways into technical support and information management at my institution’s IT department. Super exciting and super terrifying all at the same time!

I’m a few weeks into this new job now, and while new jobs are just basically always hard (I’d grown very very used to knowing everything about my job, and now I know a whole lot less about my job), I’ve been relishing all the times where the skills and habits of information literacy translate into this new context. That’s always been my favorite thing about taking on new liaison areas or even new topics and methodologies within established liaison areas, and now it’s my whole life. And spoiler alert, “all the times where the skills and habits of information literacy translate into this new context” are basically all of the times.

I’m still scrambling hard to learn all the things I need to know about campus IT infrastructure and about departmental workings — there are days when I wonder if I’ll ever know enough to be less dependent on patient and helpful colleagues. On the other hand, it seems like my experience with the underlying concepts of information seeking, information retrieval, and the reference interview are pretty useful in a variety of contexts. I also get to build a new knowledge base and help my new colleagues restructure parts of their ticketing system to help make it so techs can more easily see what they need to see when they need to see it.

The upshot is, I’ve decided not to shelve this blog. I’m still me, and I’m still interested in the same concepts. But if you’re mostly here for ideas about teaching primary source discovery to undergraduate researchers, that’ll be in pretty short supply. Granted, that’s been in short supply for a while now as personal and professional priorities edged out blogging most of the time in the last few years. But to the extent that I’m able to form coherent thoughts that I want to share down the road, it’s unlikely to be about traditional reference and instruction. It may be (and probably will be) applicable or analogous in some way, but it’d take some translation.

On the other hand, if you’re interested in guides and/or knowledge bases, that’s what’ll be on my mind for the next while at least. What do you put into them? What don’t you put into them? How do you manage discovery vs known item retrieval? Are we going to shoot for exhaustivity or a more limited collection? How are library research guides similar and different? Right now it feels like the week we subscribed to Libguides for the first time and had to decide how to structure things there: boundless possibilities and a ton of work in front of us.

2 Comments

Like lots of us, my work pretty quickly shifted this year to emphasize remote instruction. And remote instruction means (among other things) instructional videos. And I have never made an instructional video or any other kind of video that wasn’t just pointing my phone at something cute my nephews or pets are doing and then sharing that with friends and family. So… I don’t know what I’m doing. Like, not at all.

Last spring I made a few videos using our institution’s lecture capture system, Panopto. (Insert shudder here about the panopticon…) Pros: I was able to get up and running with no-frills videos quickly, and I really appreciate any help I can get with accessibility features like captions. Cons: editing is extremely limited, and I just couldn’t get it to do some of the things I needed.

So over the summer I watched some YouTube videos about making videos (very meta), and then I faced down almost a week of script-writer’s block, and then I spent a week writing a whole bunch of scripts. And I made myself a slide template so that my videos would have a consistent look to them, which I’m hoping will help me mix and match them for the various courses I’ll be supporting. And now I’m deep in the weeds of video production.

Here’s the process I’ve developed so far:

1. Write a script (trying to get things down to 5 minutes or less means I can’t risk too many tangents, and making videos that people may need to watch more than once means I can’t risk too many stumbles, so scripts are where it’s at for me right now)
2. Create slides in PowerPoint using my template
3. Export the slides as large-ish JPEG images
4. In QuickTime, record a “movie” of me going through the script. (I don’t use my face through the whole finished video, but if there’s any part of this where I want the video and audio synced up, it’s when my mouth is moving, so it’s easiest for me to just record this all and then overlay it with other stuff later where all I need is my voice.)
5. In QuickTime again, record any screen captures I’ll need of me navigating through things or whatever.
6. Sometimes I need screen captures of me drawing or annotating PDFs or whatever, and I do those on my iPad.
7. In iMovie, edit the places where I stumbled or whatever, and then drop in the Slide images and screen captures (usually sped up to x2 or x4 speeds) where appropriate.
8. Sometimes I need to do more voice-over work in iMovie.
9. Export my movie to my computer
10. Import my movie to Panopto
11. Use Panopto to generate auto-captions and then go through and edit the captions as needed.

If the video isn’t super specific to a single course, I’ve added two more steps:

1. Download the caption file from Panopto
2. Upload the movie and the caption file to YouTube

Now I have two places where students can find my videos:

• Panopto: easy to feed into their Moodle courses, etc, and familiar on campus for course-related viewing
• YouTube: easier to stumble across or use for less formal work

And through all of this, one of the big things I’ve learned is that it is absolutely possible to be super corny and super boring all at the same time! Weeeee!

My main other take-away is that need to figure out a teleprompter situation. Right now I’m not very happy with the fact that my eyes are always just slightly down from camera even though I’ve pushed my script up as high as I can on my computer screen. Recommendations for good set-ups are welcome!

8 Comments