A year or more ago I wrote a post that lamented how I was struggling to book meetings within a project team where a half dozen suppliers used separate calendar systems. The post disappeared from my blog either because of my own fat finger trouble or glitch in the publishing system. I promised to come back to the point and then promptly forgot to, despite being reminded every day of the very point I was trying to make. So here’s a reworking of it. I don’t know if it makes the same points as I did back then but I hope it makes some of them and maybe even adds some more.
Calendars
The government, by its very nature, wants to keep systems secure. Success at that aim has varied wildly. But one thing it has surely kept locked down is the calendars of its employees. Once you’re on a UK [central] government system you can forget about publishing your calendar to the world. Why would you want to do this? Because even then you’re on the inside of the great firewall, you want to meet people who are on the outside. And a public – or, at the very least, a shared – calendar is the easiest way to get to organise those meetings. As it is, though, I run several calendars and am forever juggling appointments between them all, copying invitations back and forth (which, when meeting locations, dates and times are updated numerous times gets very confusing).
Today, I have three calendars: internal government, external systems provider and personal. I can publish one of those to the web (using multiple routes, but my favourite is Tungle). But two of them, both behind “restricted” firewalls don’t allow me to make that simple synchronisation. That means that people in other government departments can’t see my calendar and, of course, people working with suppliers (even those working in the same team as me) can’t see it either. Cynics might say that if people managed their own calendars then there’d be no way to keep an eye on what they were doing.
If I could wave a magic wand, then my 2010 wish would be for that to be made a simple click – with whatever devious security rules that need to be manipulated (contravened?) happening in the background. I’d like that to be a feature of the new GSI so that anyone in government could see my calendar and that those that I invited, from outside of government, could also see it. In a flash, things would be synchronised together and the complexity of meeting organisation would trend downwards. So a GSI service that was available outside the GSI. Hold on, we could call it an ex-GSI. Although I think that name is taken.
Beyond Calendars
Is it reasonable that in 2010, someone wanting to send a file to another entity should have to copy it to a CD and send it with a registered courier? No. But it goes on, every day. After the Child Benefit data loss, you’d have thought that this would have been top of the list – right after all the IT folks had banned memory sticks. Sending secure information from [cleared] entity to [cleared] entity goes on all the time because the necessary tools that would remove that need are not yet widely deployed. They exist, of course. Sometime in 2003 the team that I led in the Cabinet Office created such a capability for the folks in Criminal Justice (who wanted to allow barristers, solicitors and the courts to exchange information about cases) – that, or one of its near relatives, is still in heavy use. But it isn’t available to everyone (even inside government, let alone those outside government who are running secure systems).
With the second wave of my magic wand, I’d create twin track email systems that would recognise what they could and couldn’t send to any given email address and would block what they couldn’t send (much of government has this in place) but would then – cleverly – consult a central address book looking for alternative, and secure, email addresses for that person and then send the material to the relevant address. A separate note would be sent to the usual mail address letting them know that they had new mail (and perhaps even allowing them to stay on the cc loop for any replies to the original mail).
I’d have this as a hosted service within the GSI too – one that knew who had secure email capabilities and who didn’t and, based on rules about which documents went where, would automatically swap out insecure email addresses for secure ones.
Beyond File Exchange
I’ll need a bigger wand for this one. I work with a lot of suppliers on various projects that, inevitably, overlap and interconnect in various ways. We exchange a lot of information – certainly emails and meeting requests but also files, ad hoc thoughts, ideas, cost proposals, requirements, designs, pictures, photos of whiteboards and so on.
Today there is absolutely no way that we can do that in a secure and managed way. I’m looking for the hosted social network [facebook, sharepoint, ning equivalent] for people involved in a programme who *and this is the important bit* whose only shared network is the Internet. They’re not on the GSI, they’re not on their own corporate network, they’re not on some super secure network in a tempest-protected building. Often, they’re not even in the same building and occasionally not in the same country. But what they are all doing is working on the same project and trying to stay up to date with torrents of information, latest versions, thinking and status checks. They have tasks allocated to them on the same plans, issues from issue lists and risks from risk lists.
This problem has been solved where everyone can freely access the Internet and exchange data – but I can’t find anyone who has solved it in a public/private setting where various (necessary) levels of security prevent the creation of a simple sharepoint (to name one solution) structure.
Some of the data will be freely available (possibly even public – indeed, I’d like to think that a lot of it could be public so that there was far greater transparency over programme status), some of it will be held so that anyone invited by the programme team can access it and some if it will be more closely guarded, available to only a few of the programme team. Controls would probably need to be in place to stop some information from being further circulated – and this is where it gets difficult and where the problem in getting it done so far lies.
This is another service that I’d host centrally but allow access to from inside and outside government. Invite only, management of who was in and who was out devolved to the programme teams. A high turnover team would have to be on its toes to ensure that as people moved in and out of teams, their access was kept appropriate (another thing that, I’d suggest, would make some people throw fits about this kind of service being made available).
There would be risks in this. The expectation would be of rock solid secure collaboration. Yet it would have to be insecure to make it work. Too much security and it would be too hard to use and so no one would use it. Hence, Secure Insecure Collaboration. Or the idea of collaborating securely yet insecurely.
So…
If government programme management – and delivery – is going to evolve … these need to get solved. [Relatively] simple tools like these would allow the delivery umbrella to be extended to a wider range of organisations including small ones who don’t normally see the inside of government.
