Archive for results

Podcast and Screencast Results / Justification

Posted in Web2.0 Productivity with tags , , , , , , , on September 29, 2011 by Lance Strzok

So I looked over some stats with respect to the podcast and screencast work that I have been doing.

Why podcast and screencast?

Podcast – The driving factor on the podcast was primarily in understanding that there was a lot of command information coming in from across various channels. Newsletter, email, email, and announcements, internal portal, did I mention email? And to stay informed meant checking in a lot of places. The bulk of them were unclassified in nature, and could be aggregated in one location (the podcast). So why then a podcast? Part two of that question was a matter of time. Even if I knew where to look, how much time did I have to read the content of all that information? Once at work, time is usually somewhat limited, so in my quest for free time, I realized that my 1.4 hour commute was some time that I might consider sharing. As it is, I listen to a couple of stations, but for the most part, the weather, news, and market are quick, so I ended up listening to podcasts on technology and science. The point is that I gladly listened to more information because driving time was usually something I could and would easily share. Thinking this could be true for others, (average commute in DC per NPR news article is about 45 minutes each way every day), I wanted to see if people would get past the small technology barrier of getting the information from the network, onto a device that they could listen to in the car on the way to work or heading home. In this way, if we could aggregate the information for employees, and make it easy to access and listen to on time they have, they may choose to do so.

Screencast – The primary driver on the screencast was reusability. If there was a question or procedure that could be shared or demonstrated once, then people to use it to learn new skills, or be reminded of how to do it if they forget. I started to think of it as self help that people could get too before heading to the actual help desk. One of the reasons behind this was to reduce the number of classroom demonstrations I was doing, but also so I could spend my time making new content about plenty of other worthwhile topics and demonstrations. In addition to this, people could get it on demand, during their lunch break when they want to sit back in their chair and watch a “howto” video on “searching SharePoint” or one of several topics. I like to do this at home, watch a Youtube video on how to derive equations of motion while eating fried chicken. You get the point.

As for the results – just the numbers.

Over the time period of March to October;

I created roughly 21 podcasts with approximately 3445 downloads, and

I created roughly 45 screencasts, with a total of 3972 views.

On the surface, it is not apparent that I am getting the results I was looking for, and so I began to speculate about what some of the factors might be. This being driven by a recent question with regard to continuing to create them or not.

I have done a weekly podcast since about May of this year, and to date, across all the locations that I made it available, I think roughly 3200 downloads have been recorded. I have a few folks from time to time thank me for an article or two, but for the most part, those are the only numbers I can get.

I have been asking for more ideas/desired stories, in the emails that I send out with the weekly contents and to date, I have had only one person respond with a suggestion.

So what do I think were some of the challenges?

Marketing – When I asked people if they knew about it, if they were not on the weekly email list, then they did not. So I am not sure that they were being forwarded to anyone else beyond the people on the immediate list of recipients. I did not do any other marketing of my own, but in retrospect, I could have made fliers, and discussed the merits of how to effectively use it.

Accessibility – I think that having to have it on a network that required a user log in and password was a hurdle because many people just don’t want to create an account for what they view will be one benefit. Too many passwords already, and I can relate. A recommendation on this would be to grow our NIPRNET presence to allow for one log in that grants you access to email, and a few key services – one of which could be the aggregated weekly podcast.

Re-posted – I was asked to post it on a different network, and as soon as I did that, more people viewed it on the new network, but it totally defeated the premise for putting it on the original network in the first place.

Consistent – I think I lost some followership when I did not post for a week or another because I was on leave or unable to do so. This may have also been a factor.

Content – As much as I ask for ideas, I received only one in the 6 months I was making the podcasts. So the content was all original in terms of what I shared, discussed, or posted. Most of the content was stuff that employees would get in email and across disparate mechanisms, but aggregating it in the podcast seemed like a good idea.

Timing – I am not sure that our workforce today is as active in the media environment as we could be, or in my humble opinion, should be. There is also not a drive to move in that direction present, so there is only personal initiative or interest to explore alternative sharing mechanisms. Put another way, it is my belief that not many in our workforce use their smartphones to download and sync podcasts that they can listen to while they are at home. If we made this easier – it would help to demonstrate the value. I believe that over time, as more people get used to using the technology for information on demand, that this will change – but we’re just not there yet.

Now, all that being said, the question posed to me was – what kind of followership did I build up, and should this production effort be sustained?

I am afraid that I cannot answer that at this time. There is too little information to make a decision. I think the next question should be – do we market this from a leadership position, and present it as one way to aggregate information, with the option of those other mechanisms staying in place and simply using a unique identifier with those other items that would allow someone that chooses to listen to the podcast, to sort into a folder, those items that would normally end up in their input streams so that they don’t end up having to read or listen to them more than once.

As for content, the challenges that remain are getting people in those various channels of production to modify what they do only slightly to share what they are already doing, and minimize redundancy in information.

My recommendations:

With workforce input, develop a clear plan on what kind of content you want to aggregate, (added benefit of advertising this cooperatively developed product).

Host the content on the NIPRNET behind the same login as email to remove the need for separate login, and find ways to make syncing the content as easy as possible for both phone and desk/lap-top computers.

After aggregating it, tag the initial source location and products in a way that will allow people that choose to listen to the podcast to not have the information come again through the original channel – or if it does – can be auto-foldered into a location out of the workflow, (this is an effort to reduce duplication.

Revisit the content discussion on a quarterly basis, and make sure that there is a mechanism that is collocated with the download that allows for feedback and input (like – link to the podcast from a blog).

Try to get to more of an interview style podcast, not just a news podcast of someone reading the headlines. Different voices, debated views, etc… That will develop more interest and followership. In addition, if you have a section that reviews pertinent comments from the commenting mechanism – that will allow users to see how their input can effect the process and their voice can be heard.

I enjoyed the opportunity to run this experiment. I thank Jack Gumtow (CIO) for the opportunity to do this, and learn from it in doing so. I hope my sharing some of this information helps others, and I am open for questions or comments.

I would happily help anyone interested in starting or maintaining an effort similar to this one.

Cheers,

Lance Strzok

Advertisements