Above is a screen shot of the PSU Tech Tutors site … not only is it great design and a great program (training for students by students), the whole thing is built on our new WordPress stack. The new service that we are calling sites.psu.edu allows people at Penn State to not only construct typical wordpress style blog sites, but full on web presences. We’ve licensed dozens of professional themes, have put them through the accessibility ringer, and are making site building easier than ever.
About one year ago I started negotiating with Yammer to bring the enterprise edition to Penn State. In the past year we have had a Yammer implementation team working to make that a reality. I met with the project manager, Heather Huntsinger, this morning in our monthly update meeting and we had a very interesting discussion. One of the things she asked was now that we are winding down on the implementation phase, how do we move this into the “product” phase … essentially closing out one project and starting another one that looks at Yammer as a product/service going forward. A great question and one that made me step back and look at the service in general … are people adopting the platform? Who is using it? How are they using it? Are things trending in the right direction? Having access to both the Yammer analytics and our own Data Warehouse allowed us to get a sense of where all this is heading.
The first thing I will mention is that Yammer has significantly changed my workflow and communication approaches. Within TLT, we make very heavy use of Yammer for ongoing discussion. In the past year we have moved nearly all of our organizational conversations to a series of private and open Yammer groups. TLT is made up of several units, each with its own proviate Yammer group so those local units can have conversations. There is a larger TLT private group for larger conversation and we have a TLT Leadership Team private group for ongoing strategy and operational conversations. I even have private groups that are just for my direct reports. In the end I have eliminated hundreds of daily emails for myself and am able to stay on top of so much more in a much more streamlined way.
But this is more about who is using Yammer at Penn State — I was shocked at what the team was able to discover. The data is about a week or two old, so the numbers are a bit lower than the total user count as of today, 4,695. People use their Penn State user ID to log in, so we can look at various attributes by mashing that data against what we know of people via data warehouse … based on what we pulled, there are 4420 user IDs in the Yammer user list. Taking out 62 unknown users, we retrieved information of 4358 users from Penn State Data Warehouse. Among these users, 481 of them (11%) are faculty members, 1948 of them (45%) are staff members and 1929 of them (44%) are student members. What blew my mind was the student number … I expected staff to be another 2,000 and have students be about 500, but that is not the case.
It gets more interesting as you look across the Penn State system — remember we have 24 campuses across the state of Pennsylvania. There are 2970 users from what many people used to refer to as our main campus, University Park. Among them, 325 users (11%) are faculty members, 1687 of them (57%) are staff members and 958 of them (32%) are students. There are 1386 users from other campuses. Among them, 156 users (11%) are faculty members, 259 of them (19%) are staff members and 971 of them (70%) are students. For example, there are 271 student users from World Campus.
What is striking to me is how differently the user base is at University Park and the Campuses. At campuses, about 70% of the users are students versus 32% at University Park. And the difference in staff use is staggering to me. The next set of questions need to address what are driving these differences and what is going on differently here at UP versus across the Commonwealth.
Part of what makes what I do so interesting is the interconnectedness of the moving parts of the organization. My group, Teaching and Learning with Technology (TLT), has many moving parts and a handful of groups within it that all do different, yet similar things. Our Classroom and Lab Computing (CLC) team focuses time on our physical spaces and the infrastructure that supports them. Education Technology Services (ETS) is a different type of organization in that they not only evaluate, test, and recommend technology solutions for faculty, staff, and students but they also look to unpack the affordances of those technologies. ITS Training Services spends most of their time designing and delivering training to faculty, staff, and students but also manage big projects that deliver all sorts of other services. WebLion is a team that focuses intensely on the overall processes inherent in the design, development, and deployment of large organizational websites. What amazes me is that each of these groups are all part of a larger value chain of sorts that serves our University very well.
They also all produce lots and lots of data. Some of that data comes from the services that we offer, while a whole bunch of it comes from the questions we ask of our audiences. A couple of examples of service level data might be stuff that our Adobe Connect service collects for us, or the data we get each time a student prints in one of our labs, or each time an application is launched. With this kind of data we don’t know what happens in an Adobe Connect meeting, or know what the application does once launched, or the contents of the pages printed (we’d need to do a different kind of analysis to get at that) but we do get clues that help us ask better questions that presumably help us make better decisions. From where I sit the days of, “I betcha …” planning are long gone.
To this end we’ve embarked on trying to make sense of the data we have in new ways — visual ways. A small team in TLT has been working at using the Roambi platform to do just that, visualize otherwise flat data tables to help us make better sense of what is being gathered. The unfortunate thing about this blog post is that you can’t get a sense of what it is like to not only see your data, but to be able to touch it and manipulate it in real time. The screenshot below is a simple representation of the percentage of overall pages printed during the 2011 academic year (Spring, Summer, and Fall) from the College of the Liberal Arts faculty, staff, and students using our managed lab environments.
Now taken by itself this is an interesting piece of information that lets you see that we print quite a bit still in total and that the College of the Liberal Arts prints about 15% of the total number of pages here. But if you take that data and mash it up with our ability to look at it from the departmental level you can begin to make sense of how to address it as a problem to be solved. Printing is expensive and while we do all sorts of really great things to be eco-friendly, it isn’t the best thing for the environment. When you look at the drill down at the departmental level you can pinpoint specific programs that print much more than others. When you do that you can work at a level where some sort of intervention can be applied.
This is where the organizational integration starts to really become powerful. Having the printing data and the departmental data mashed together I can sit down with the unit level directors and begin to construct a strategy to change the overall behavior in a positive way. I can now work with instructional designers in other parts of TLT to construct a workshop for faculty on digital assessment strategies, create learning opportunities for students to understand how technology can be used in the writing process to eliminate passing drafts around, and look at new software that enables new workflows between those audiences. Then we can easily measure the pre and post states to see if our intervention might be working.
Another example that happened not too long ago … we had a meeting to discuss changes with one of our smaller public labs on campus. Essentially we were asked what the impact of moving this small lab might have on students. This happens all the time — construction needs to happen for all sorts of reasons and typically they are good reasons. Well the meeting started and I was able to quickly show just how intensely popular this out of the way location really is. Needless to say the person we were meeting with was blown away and offered new space to better meet the needs of students. It is hard to pack this much information into a readable spreadsheet. The visualization below shows all sorts data represented in an easy to read format … I snapped a single day that represents 3,917 unique userids that logged into the machines in this small out of the way location. By having this kind of data available and readable we can instantly see trends in use and share that in a meaningful way.
We are just at the beginning stages of this approach and haven’t figured all of the details out. But as we go forward we know that using our data in this way could be truly part of a transformative way to get at the future states of our services, our spaces, and the ways we plan for them.
A couple of years ago I outlined an idea for the staff at Education Technology Services that would allow for mini sabbaticals. The idea was met with lots of nodding and lots of questions — it was fairly simple … you share an idea and how much time you need to work on it and I figure out a way to turn you lose with it. The only caveats were that it couldn’t be more than a week and you had to come back with a product to share. Lots of people threatened to actually take me up on the offer, but in the end exactly zero people did.
I always wondered why. I still don’t know. Maybe it is time to dust off the idea?  I was reminded about it after reading, NPR tries something new: A day to let managers step away and developers play.  I really wonder what would happen if we twisted it so it wasn’t about some sort of structured approach and instead something more like what NPR is doing?
NPR is experimenting with something called “Serendipity Day,†wherein everyone on the technology side abandons their day jobs to work on…whatever they want. Bugs that need squashing, scratches that need itching — the ideas that never get to the top of a to-do list. The managers step back, available only if the workers need anything. (I need a designer, I need a room, I need a bagel.) The only rule: In the end, you have to share your work.
“It turns out that that one day of pure, undiluted autonomy has led to a whole array of fixes for existing software, a whole array of ideas for new products, that otherwise had never emerged,†Pink says in the talk. He argues that motivation derives from autonomy, mastery, and purpose: the desire to control one’s own destiny, to get better at something, and to serve a greater good.
Clearly we’d have to do some planning, just as NPR has done, but I wonder what kind of participation I would see in my own organization. Seriously, it is a great idea and I wonder if I’d have any takers?
This post also appears at my PSU Blog. Sorry for any multiple linking.