Project achievements included:

- signing our network provider contract
- facilitating one of the most complex global meetings I've ever done
- Mac builds being generated in Casper
- big steps towards finalisation our service hours
- lifting the mist on our event management web requirements

Additionally:

- kept a steady ship (mostly) during a time of business hyperactivity
- interviewed for The Gemalto Review
- experimented with HulloMail cloud-based voicemail
- and Memeo Send
- prepared first draft for my workshop at Google Atmosphere (and checked the train times!)


Next week in one word: capacity

Giving some thought to the changing information security policies that are needed to cope with the increasingly collaborative-based tools that are emerging in the cloud era, and it got me wondering... if the telephone were to be invented today, would it pass muster with one of the more officious information security departments?

Imagine the conversation:

Potential Telephone User: "I'd like to get one of these new telephones, please."
InfoSec Team: "Hmm. We'll need to have a think about that."
PTU: "I really need it. All of my clients are using them, and I need to be able to talk to them. I have to have a phone number!"
IST: "You want to disclose your identity to others outside of the organisation? I don't think so!"
PTU: "You what?"
IST: "And have you thought about the implications of having no password on the phone. Anybody could be picking it up and communicating with your callers."
PTU: "They'll probably just take a message on a post it for me."
IST: "Post Its? Information left out in the open with personal information on it? Are you crazy?!?!"
PTU: "Sod it. I'll buy a mobile."

I'm pulling together some content for a workshop that I'm going to be running at the second European Google Atmosphere event that's taking place in a couple of weeks time at an impressive Chateau just outside Chantilly in France. When I spoke at the London CIO event in the early summer, we had just about completed our first phase of migration, and we were planning how to approach the gradual deployment of Google Docs and Sites across the business.

At the end of the summer we now have about 120 people using Docs to various extents in the business (about a third of our permanent workforce), and we are starting to see people getting to grips with it and finding ways to make their own working practices more effective as a result. It's the first green shoots, and whilst nothing earth shattering, there is much more to come I am sure.

The presentation is focused on developing a business case for a move to a Cloud-based service, and has got me thinking about what a business case should look like (and what our own was like). It also comes after seeing reports like this one on CIO.com, and having conversations with CIOs contemplating a move to Google driven by the potential cost savings.

I'm of very strong opinion here: if you drive a project to move to a service like Google Apps (or Microsoft BPOS, or whatever else) on grounds of cost saving alone, whilst you probably will save some money, the project will fail.

Why? Well, because if you start from a premise that you just want to save money, what's in it for the business, or the people using the tools? A sense that their core tools for communication aren't so valuable and, maybe by proxy, they aren't worth very much.

The CIO.com article talks about four reasons why existing Google Apps clients are looking to move away. Three of the four reasons are directly as a result of a cost-saving driven approach (the final one, because of Google's slightly gung-ho approach to release management is the one that I can relate to...).

Drive a project with good, positive business objectives (ours were to improve relationships with our clients, improve engagement across the business, and to get value for both the company and our clients), and cost savings may well fall out. Drive on a simplistic measure alone, and you might not get what you bargained for...