How to Doom a Project with One Sentence

I was once invited last-minute to a meeting that was supposed to be a kind of kick-off or brainstorm session for a mysterious new initiative. Judging from the pre-meeting chatter as folks filed into the room, I wasn't the only person lacking context.

The meeting organizer came in and began outlining the project goals. Someone raised their hand and asked, reasonably, "What's the priority level of this project, given other initiatives underway?".

I departed that organization shortly after this meeting (for unrelated reasons!), but I feel confident predicting the ultimate fate of that project: nothing ever came of it and it fizzled in development, if it made it that far (or, as Calvin put it, "(that) train of thought is still boarding at the station").

Whence my confidence? Because in response to "what's the priority level of this project", the answer was, verbatim, "it's somewhere in the top ten of our number two priority list".

In other words, doomed.

To be clear, this is not to disparage the original project idea (I thought it was a good idea, and agreed it was sorely needed), nor doubt the sincerity of the organizer, or the good intentions of the other people in the room (it was a mercurial time for the team and I'm sure the priority lists were indeed in flux); rather, it's to highlight that in spite of those good intentions, the high quality of the idea, the good-will and desire from the team to get it done...it was likely doomed to fail before it started, because it simply wasn't a set priority. Or rather, everyone agreed that it should be done, but either couldn't or wouldn't allocate the resources and time to get it done, at least not at the expense of other ongoing concerns.

This is how knowledge management dies

Lots of KM efforts fall into this trap. I think that this inability to "put it somewhere in the top ten of the number one priority list" can arise for several reasons: one of the biggest culprits I've personally observed is when a team expands really quickly, KM doesn't scale accordingly, and a total monster is created.

It might look like this:

1. Small, tight-knit, fast-moving team works in close coordination on a project that is ambitious, but early enough in its conception that it's feasible for just a few SMEs to be working on it. Because the project is small and the team is tightly coupled, there's a lot of tacit, institutional knowledge shared informally among the group (hello, Slack threads). It's common for someone to be the "go-to" person for particular tasks or questions, and the small group of SMEs tend to handle issues or inquiries personally on the fly.
2. The team and the project both expand, fast, and the original SMEs are either promoted into lead positions or otherwise abstracted away from the hands-on work they were originally doing. Lots of new hires hit the team and begin to get tasks delegated to them that the original SMEs were doing (or, worse, the original SMEs keep firefighting because they're too busy to properly hand off tasks). The people with the most context are now too busy to document what they know.
3. The first wave of new hires either shadow SMEs to learn how to perform tasks, and may document their findings, or just do their best to improvise new processes for new tasks as they come up. The first wave of new hires become the new SMEs for the product, another wave of new hires join the team, and the process repeats. Everyone is so busy trying to either onboard, learn the product, train others, or stand up new product lines or teams, that it leaves little time for knowledge capture. There is little to no set standard/template or standard process for writing, publishing, or updating documentation, which leads to a chilling effect for even people who have the time and inclination to document things.
4. A year later, the knowledge base/SharePoint site/Confluence site/what have you is an unholy stew of outdated articles, orphaned attachments, broken links, and siloed actually-still-useful artifacts that only a few people know how to find. No one bothers with the sidebar or homepage, but rather Slacks each other the one or two links that have relevant information on them, often with disclaimers like "Step 5 says to (x), but ignore that. You actually have to..."
5. The knowledge/documentation debt becomes unsustainable, and it's determined that something needs to be done to, uh, document stuff - but the original issues of "everyone is so busy" not only haven't gone away, they may have gotten worse. In addition, lots of the articles/documentation that's marginally useful was written by people who have since left the team, processes have fractured, Humpty Dumpty is in the arms of an angel, and who can afford all the kings horse's and all the king's men?

At this point, even strong teams can struggle to dig themselves out.

If this sounds familiar, don't despair - you're definitely not alone. I'd even go so far as to say that this is a normal experience for expanding teams, and requires rather remarkable foresight and effort from the outset to forestall. To be honest, I've rarely seen it done well. But my recommendation would be, for those wanting to try: dedicate, empower, and integrate a KM specialist from the very beginning, or as close as possible, to drive knowledge capture and knowledge management culture.

Like security or FinOps, knowledge management is above all a distributed issue, but it only works with a clear owner; everyone has a role to play, but it's imperative to have a centralized person or team in place to help set and socialize quality standards, assist team members with questions, and generally be "the voice" of knowledge management on a team.

In short: if no one does it, no one will do it - and if no priority is set, the priority level is automatically "zero".