Hi Mark,

I don't have any specific research to point you to, but suggest you might benefit from a "Scrum light" approach with a burndown tracker if you don't use one already.

The problem is that "pieces" is a blunt metric that can penalise writers handling complex content and encourages superficial delivery to increase throughput. To get around this, you need to introduce complexity estimates to your workload management processes.

This is how I would see it working:

1. As each new piece of work comes in, the team (not you) estimates how long it will take to complete. A typical Fibonacci estimator looks like this:
• 1 point = an hour or two
  
• 2 points = roughly 1/2 day
  
• 3 point = roughly a day
  
• 5 points = roughly 2 days
  
• 8 points = roughly 3 days
  
• 13 points = roughly a working week
• Anything larger = chunk it down into milestones and estimate these separately
  
  
2. All work effort gets registered and tracked in a backlog. For example, 100 pieces of work might equal 950 "points" of effort.
   
   
3. Every week / fortnight / month (whatever cadence works best for you), prioritise work and complete highest priority items. It is important to assess completion against your quality metrics and not set targets like "I expect you to finish 40 points of work each month". Work should be done because it's done, do not encourage gaming of the system.
   
   
4. After each period, track the team's output based on the completed number of points. Over time you will get a good sense of inflow and outflow rates, and what the team can sustainably complete each month. The estimates will become self-correcting to some extent, so never use the actual number as a target of productivity or again, this will quickly become gamed.
   

If you don't have time to implement this system now, you can "backcast" using the same process with your most recent months of output to produce the same estimate. This is not ideal because you will have the benefit of hindsight. However, it's better than nothing and provides something to go to management with.

If I'm not being clear, feel free to ask any questions here or offline and I'll be happy to help.

Cheers,
Stephen.

Kelsey,

 

Thanks for your perspective.  I 100% agree with you on not setting the quotas too high, especially absent any benchmarking that would substantiate it.  As for your questions, much of the knowledge authoring we do has multiple tabs/topics and runs multiple pages.  In addition, it is heavily ladened with links to source materials such as tables, images, etc.  A lot of complexity which would support a lower ratio.

 

I appreciate you reaching out.

 

Thanks,

 

Mark

 

From: main@SIKM.groups.io <main@SIKM.groups.io> On Behalf Of Kelsey George
Sent: Wednesday, November 2, 2022 9:54 AM
To: main@sikm.groups.io
Subject: [EXTERNAL] Re: [SIKM] Information for Knowledge Management Capacity Planning #content-management

 

Hi Mark,

 

I’m currently working in a technical writer/knowledge management role and I’ve hit about 700 items for the year (including ~150 or so that we’re updates to existing documents). That being said, the subject matter experts were the primary authors and I act more in an editorial capacity. The expected length of the documents required (are these manuals or 1-page help guides, etc) would help determine whether these expectations are feasible for a year. At first glance, I would advise that it is better to set lower quotas for each technical writer and have them blow expectations out of the water than to set someone up for potential failure right out of the gate. 

 

I wish I had the data you’re looking for beyond anecdotal evidence, but it really depends on the skill of your team, how technical or complex the writing is, the participation of subject matter experts, and what materials need to be produced. Someone else may have better insight.

Hope that helps a little bit!

Kelsey George

https://www.linkedin.com/in/kelseydgeorge

On Nov 2, 2022, at 7:26 AM, Stan Garfield <stangarfield@...> wrote:

Mark, thanks for the additional details.

Can anyone respond to Mark?

This e-mail and any attachments may contain confidential information of Northwestern Mutual. If you are not the intended recipient of this message, be aware that any disclosure, copying, distribution or use of this e-mail and any attachments is prohibited. If you have received this e-mail in error, please notify Northwestern Mutual immediately by returning it to the sender and delete all copies from your system. Please be advised that communications with {SECURE MESSAGE} in the subject line have been sent using a secure messaging system. Communications that do not have this tag may not be secure and could be observed by a third party. Our commitment to privacy: At Northwestern Mutual, your privacy is important to us. For more information about our privacy practices, please review our privacy notices.