This is a follow-up to my talk at the UCISA 2011 management conference about the Google Apps experience at Loughborough University. For a quick overview of our project to implement Google Apps, please see the “Loughborough Goes Google” Case Study.

In this post I’ll look at using a tool called the Value Stream Map (see Rother and Shook's excellent book, "Learning to See") to help you analyze where and how much your existing business processes add value. I've chosen a scenario that illustrates the benefits of the move to Google quite nicely:

In this example an academic is setting their students coursework to be undertaken in small groups. As a lecturer it would be quite reasonable to want your students to have a shared file space to collaborate on their project, and a mailing list to use to communicate with each other. In fairness I should note that we are in reality rarely asked to create both a shared space and a mailing list for student groups - this combination is more common for staff.

If Value Stream Mapping is new to you, the diagram above illustrates the process (in this case, creating the group shared collaboration facility), breaks it down into its constituent parts (showing which groups or teams are responsible for each stage) and gives an indication of how time is likely to be spent. The square wave notation indicates where value is being added (top of the wave) versus "wasted" time that doesn't add value (bottom of the wave). The Japanese term "muda" is often used when referring to the latter - this whole approach originated in Toyota.

If you have good eyesight you will see that the time spent “adding value” in my example is quite small, but large amounts of time are lost due to waiting for someone to do something. From the organization's point of view this is perfectly reasonable - we don't operate an out of hours Service Desk like NorMAN at present, for example. I’ll also note that this is depicted as a serial process because the work of one team largely depends on the outputs of the previous team. More prosaically, our current Service Desk system  requires a case to be assigned to one person and one “queue” (queues are loosely equivalent to teams) at a time.

The upshot of all this is that it can be easy for a trivial request to take a significant length of time to resolve. In the diagram above our worst case scenario for resolution is 8 days, with only some ~35 minutes being spent doing anything which truly helps us to complete the task.

If you are doing Value Stream Mapping formally, the next step would be to create a map that showed your intended "future state". Obviously the ideal would be to eliminate as much of the "waste" as possible. In terms of IT systems, this is typically about removing the need for manual intervention and providing a self-service front end - ideally for the service user, so that the Service Desk is only involved if there is a problem.

Now let’s look at the equivalent process in Google Apps…  A Google Group is a mailing list with a built-in archive and search facility. It also functions without any further work as a sharing target for things like Google Docs documents and folders and Google Calendar. So, how do we create a Group?  It’s pretty simple:

Reflect on this for a moment – a task that might previously have taken as much as ten days can now be undertaken in a matter of minutes, and without the IT Service Desk having to be involved. This is pretty good news for all involved, particularly in the current climate of doing more with less.

Couldn't we have built something like this ourselves? Yes, we could - but it this is just one small part of the larger Google Apps proposition, and there is simply no way that we could build something internally that would offer more than a fraction of the capabilities of the full service. Innovation at the pace Google have been able to deliver it (~200 feature updates to the Google Apps service last year) is clearly not going to happen.

I hope the quick introduction to Value Stream Map has been interesting, and that you find it useful in analyzing your own processes.