Tuesday, February 28, 2012

Reinventing Government IT

In the 80s the theme in Government IT was inhouse development of big Line of Business applications. In the 90s, it shifted to outsourcing both development and maintenance of all aspects of IT. By the 00s we had two themes - the move online and the creation of multi-billion pound programmes (most of which have resulted in abject failure for whatever reason).

In the 10s we are, again, re-inventing Government IT. With re-invention comes risk, sometimes significant risk.  The models in place today are well understood and well practiced yet have also come with significant and continuing risk; there has been no avoiding it.  Few would be able to point at more than a handful of successful deliveries in government IT.  And yet in the past, changes have occurred relatively slowly.  Today we are running several themes at once - vast reinvention on a pan-government scale - which inevitably brings with it more risk.  And with that risk will come, again, the risk of failure - sometimes with individual point solutions adopted, other times with whole threads of activity.  Spotting those failures before they occur and addressing them will be a time sink for the elite SWAT teams that will doubtless be needed. But some will escape the risks and deliver brilliantly of course; if only we knew which ones up front.  Learning the lessons and applying them to everything else going on - as they occur and almost in real time - will be the activity that differentiates this reinvention from those that have gone before.

1. Real Innovstion - gCloud

This week saw the launch of the gCloud framework and its associated CloudStore.  For the first time, government buyers can see the price of services upfront and compare across lots of different providers (ok, so it's not easy to do that yet but it will get easier I'm sure).  Companies that had little or no access to government customers before can now chase business and, if they're priced well, win against the big players.  Government can, in turn, try services out with little tail risk. Want to try collaboration for a project? Sign up to a new service for 2 or 3 months and see how your team adapts before committing your entire organisation to it. Fed up running an old version of Exchange that doesn't support modern mobile phones well? Move to another.

We already know how this plays out in the consumer scene.  We sign up to services, use them for a while, abandon them in favour of something newer and shinier and then repeat the process, often with a dozen different services at one.  Of course, we rarely pay for these services and there is little tie-in beyond whatever data we commit to them (and so services, naturally, try and take as much off us as possible - hence the recent storm about address books being uploaded into the cloud).

We don't, though, know how this will play out in government.  Big, slow, old-fashioned government is used to buying from big, slow, old-fashioned suppliers and living with them for a decade or longer. Will departments break that mould quickly and buy IT for their staff the way that they buy IT at home? Will they have the courage to bring together 5, 10 or 15 services from different suppliers and manage them as a whole, without the shield of a huge prime contractor?  Will they overcome their innate fear of "security" and adopt innovative ideas from new suppliers inexperienced in the government world?

gCloud's main risk is not that the services fail, but that the whole idea behind it fails - that departments hunker down and ignore it, that they don't switch enough of their existing spend to it so that it makes a difference or that they use their existing suppliers to do what gCloud wants to do and so undermine gCloud.  The incredible energy behind gCloud - small team that it is who manage it - goes a long way to holding that risk in check, but departments are the buyers and they need to show their hands.  A move to these kind of services is inevitable, it's only a question of when.  Departments publishing their plans for what they plan to buy (e.g. email, collaboration, storage as a service, etc) and when would allow suppliers to focus their efforts on core products whilst still looking to provide innovative services that departments didn't even know they needed until they were shown them (or, better still, recommended them by the gEnius tool that doubtless will come with gCloud v2 - "services you need that you didn't know you needed"™  or perhaps "service discovery as a service"(tm)

For me, gCloud has to work and will work, although there will be bumps, because it's actually the foundation of the second area of reinvention:

2. Rejection of the old SI model - Service Integration

If the 90s outsourcing model was single, behemoth suppliers providing all of a department's IT (though not meeting all of its needs, often despite best efforts all round), the model in the 10s is quite different.

The model adopted for the 10s, by at least a few departments, with MoD and MoJ leading the way, is to buy services from as many as a dozen providers - and to have a single Service (as opposed to System) Integrator bring all of those together.  The twist is that the SI no longer owns all of the other contracts - instead, they're all owned by the department.  This has the advantages of eliminating the margin on margin common in traditional prime contracts as well as allowing the customer to pick what might have been called "best of breed" (back to the future!) suppliers (either through competition or from a framework) for each strand. On the downside, the procurement process becomes significantly more complicated and operating the end to end service becomes even trickier - liabilities, ownership and incentives will be murkier than government is used to.

To pull this off requires far greater client side expertise to be in place than either currently exists or than has been thought about.  In a world of reducing budgets and prohibitions against consultants and contractors, sourcing enough people within the public sector (or transferring them in) will be a huge challenge.   Those people certainly exist internally, but given going on for £40bn of contracts at original signing value coming up for renewal in the next 5 years, I very much doubt that there are enough to handle the forward workload.  In the 00s, one of the consequences of the multi-billion pound contract era was that government directly drove inflation through its own buying process; that could happen again and so needs to be carefully planned for - by managing the timetable for procurements, by being clear with suppliers about where frameworks will be used and where procurements will take place, by being clear about the baseline that will be in place at the point of transition (departments are not standing still after all, they are busy virtualising their servers, hopefully looking at buying gCloud services and bringing their costs down in line with overall targets) - any procurement underway in the next 2-4 years will be against a very dynamic departmental baseline.

This, then, is a riskier area of reinvention than gCloud.  With gCloud, departments are buying in to a service for a few months and maybe for only a small part of their organisation.  They are specifically able to try things out - one project team or one function - before committing.  And even if they commit, it might be that it doesn't work and they have to pull out (see the point above about reinvention brings risk of failure).

But the Service Integration model is trying several new things at once, and for longer periods.  And, of course, wrapped in these contracts are all of the legacy applications and services (many of which are much the same as they were in the 80s).  Failure with these is certainly bigger than with gCloud but of a smaller likelihood than with the old model - if a single provider from within the group of 6, 9 or 12 struggles, then they can be replaced (not, perhaps, by one of the others - that model hasn't exactly worked out well in the NPfIT/CfH world).  The risk may, in fact, be all on the buying process - are the resources there to package all of these services up intelligently and effectively, to establish a great competition amongst suppliers (when many other competitions are likely to be going on at the same time, forcing suppliers to pick where they field their best teams) and to ensure that all of the liabilities, incentives, controls, processes etc work across multiple providers of services so that the user sees things just "working"?

These models will also end up working but I think there will be significant bumps along the way - both during procurement, transition and operations.  They should also work better than the current model, but not immediately - I suspect it will take 2-3 years to bed the new model in properly.

3. Relentless Commoditisation

Typically government believed it was special and so developed everything in a "for government" way - it had one of everything and everything at least once.  Huge bespoke estates resulted with everything the department needed bought by the department (or the department's supplier).  That resulted in huge build costs and even larger maintenance costs.  In the last few years that has changed and, in the last 18 months, that change has dramatically accelerated.

Wherever possible, frameworks are being set up for networks, document archives, IT equipment, cloud services and all sorts of other things.  Looking at the GPS list of frameworks just now, I counted 24 for IT (including IT consultancy) and a further 16 for software out of over 600 frameworks in total.  I can only see that number going up as government tries to get its "managed spend" figure from its current level which I believe is somewhere over £1bn to far more than that.

Not all frameworks are created equal of course, nor are they used equally.  Within the Service Integration model above, departments, such as MoD, have already made clear that they will use frameworks where it makes sense to.  Others, like MoJ, have implied that they will create frameworks within their new model so that other departments can use their services (e.g. perhaps for hosting).  It's possible, likely even, that frameworks will be the route by which all equipment is bought even within, say, a hosting service - in which case, suppliers with high degrees of vertical integration (like HP & Fujitsu perhaps) may not, having won, say, a hosting contract be able to fill that data centre with their own hardware unless it is proven to be best value in a competition on a framework.

4. The One That Isn't Any Of The Above

Perhaps the biggest reinvention is going on within Government Digital Services.  There, they aren't using frameworks (at least so far), aren't looking for a service integrator or for a dozen suppliers to bring together a service under various contracts and they aren't doing some of the other things that the Government's own ICT strategy says should be done, such as using COTS or making the most of small businesses.  They are, though, rebuilding - from scratch and with in-house, largely permanent, staff - government's most visited website (direct.gov.uk to be renamed, or re-renamed, www.gov.uk).  If the rebuild succeeds then it's likely both visitor counts and visitor durations will go up - if it's easier to find everything you need, you may stick around longer to see what else is there and, if transactions are hosted on the site, then completing transactions will add to the stay time. It could be very, very big.

Building websites and services from scratch is, of course, relatively common. After all, there was no COTS for Facebook or Twitter.  It isn't, though, common in the public sector (not since a couple of bright people in CITU did it in the mid-90s anyway).  It also doesn't fit well with the public sector's current business model, whether IT or operations. I'd say that's a pretty serious reinvention.

This is early days. The "beta" of www.gov.uk is, at best, a proof of concept. It's got some impressive capability already and the rapid iteration and incrementing of features is exciting to watch.  But it's also got a huge do list ahead of it. One that, in less than a year, must allow direct.gov to be turned off.  The lessons to be learned by the .gov.uk team are doubtless very interesting (and they're learning most of them in the full glare of publicity); I hope that they are not learning every lesson from scratch although given the amount of from scratch building, I suspect they are encountering new problems every day that many others have already encountered, inside and outside of government.

Having your team inhouse is a fascinating experiment though - your only wasted cost is that of opportunity, i.e. would it have been better to have the team work on a, instead of b or did you not even notice c and what that could have done for you. It's still real money of course - and based on the team size, it might be a real lot of money.  You can achieve speeds and quality of delivery that I don't think can be achieved by all except the most integrated of supplier and customer teams.  But you can also spin wheels because the cost is essentially sunk. Every working day you burn £x and measuring whether you have achieved the same in value is hard - especially when your scope is shifting and evolving within the agile methodology.  Also, big companies manage turnover on an every day basis - they draft in new people, have a constant stream of more junior employees who can work for lower rates and who can progress up the ladder before moving to oer clients and can bring in additional bodies for particularly tough deadlines - all of that is hard with an inhouse team (especially a small one).

Predicting the future for GDS and the .gov.uk is hard.  I suspect a transition to an alternative model in the future - perhaps to a series of suppliers with GDS holding the integration role or, more radically, the creation of a mutual where GDS gets some investment and becomes a supplier to government itself, so adopting a mix of commercial disciplines with at least partial employee ownership.  That would free them up to compete for other business and would put all of the incentives in the right place, as well as provide a more structured career path for those in the team.   It would almost be a return to the days of CITU.

This is potentially the riskiest reinvention of them all.  I hope that the risks don't come home and that this programme succeeds enormously but I can't help but feel nervous for its prospects.  And Facebook disappeared during development or had a few outages in its first few months, few would have noticed or cared. But when you take on such a big and visible project with an entirely new approach, it could hardly be more challenging.

5. The Underpinning Reinvention

All of these changes are underpinned by an openness and transparency that is incredibly refreshing.  Seeing new starters in GDS blog about what it's like to work there and very senior people across government blog / tweet / respond to comments has opened up the workings of government - my guess is that the regular audience consists of a relatively small number of geeks but the occasional bursts into the mainstream press so no change in message.  We have done betas and pilots and test versions in UK government before, but never quite in this way.

As I said at the beginning, with reinvention comes risk. With risk comes the potential for failure. With failure comes interrogation and criticism.  The good news is, I think, that all of the interrogation and criticism will have been done on the inside and posted on blogs long before that point.

Tuesday, February 21, 2012

26.1 Tips For Marathon Running


With the spring marathons not far away, a lot of people have been asking me if I have any tips on training.  I've always responded with an ad hoc list to date but thought I would write down what I think is really important.

I'm not a natural runner.  At school I came pretty much last in every cross country race I ever ran.  I didn't run as a kid (I played squash mostly).  I ran my first marathon, on a whim, at the age of 29 (it was brutal, I didn't know anything about training and I finished in about 4h 15m - and had to walk downstairs backwards for at least two days afterwards).  And I ran my second at the age of 35.  Since then I've run quite a few in several cities around the world, sometimes running two a year.  I've run enough to know what works for me and what doesn't.

So here are 26.1 tips for getting to the finish line. Hope they're useful.

1. It's (nearly) all in the head

Sometime around mile 20, your body will want to give up.  It will think it has nothing left.  Your head, if you're not ready for it, will let it.  Marathons are made in those last few miles. and so are marathon runners.  When it's dark, cold, wet (or all of them at the same time) is when you most need to commit to your training.  If you don't do the distance, it will do for you.   Most of your training is about teaching your brain to overcome your body's tiredness. You won't run a full marathon distance during your training, you may only run 30km (with a marathon another 12km beyond that - but any runner can run 12km can't they?), so getting your brain and body aligned so that neither quits when it gets tough is the most vital lesson.

2. Running is just running.  

You have everything else to fit in too - family, kids, work, evenings out, friends and whatever else occupies your life. Make time for those. The race is important. But it isn't life. 

3. When it's not in your head, it's in the training

You need a plan but probably not the one you think.  Pick up any running magazine or book and they will give you plans for all abilities.  you might be able to work with one of those plans but my guess is that the rest of your life, your head, an injury or some other problem will screw up your plan, so be ready to improvise. 

I ignore all the plans that require me to run 4, 5 or even 6 times a week - I don't have the time, I don't recover fast enough and there are other things that I need to do.  Instead, I average two runs a week and peak at three. My plan, roughly, is to gradually run further and closer together with the aim of, eventually, running a near-marathon distance in three days.  But first I build up to running a marathon in a 7 day period (perhaps 3 times 10k runs in a week) and then narrow how many days it takes me to run the distance. And somewhere about a month away I run a 30km and two 6km runs across 3 days - perhaps 6-30-6.   Let me tell you, recovering from 30km even at training pace will take some time; if you can even walk 6km the next day you'll be doing well.

Here are the distances that I ran each week in the run up to the 2006 London Marathon (which I finished in 3h 51m).  One week I managed 4 runs in a week, the rest it was a maximum of 3 and often just 2.  You'll see that I tried to run pretty much marathon distance each week, once I was ready for it.  The blank week is when I was away skiing.  The week before the race - the second to last column - is me tapering (reducing how much training I do).  



4. Have a goal.

Be clear why you are doing this.  It might be for charity, in memory of a loved one, to lose weight, for the t-shirt, for the medal or even on a dare.  When times are tough, remember why you're doing it. And keep doing it.  But also set some shorter-term goals - that you will run 3 times this week, that you will do a 10km race in 50 minutes within the next month, that you will eat healthily for a week.

5. You have a certain pace built in.  

Marathon running is about tricking your body to be happy running at a quicker pace for longer.    The longer your run, the slower you will get so you need to keep working on tricking your body into being comfortable at a faster pace.  Here's how much you will slow down over a marathon distance, based on my typical figures:

5km - 22 mins
10km - 47 mins (+3 mins versus two times 5km)
Half - 1h 42m (+3 mins versus two times 10km + a 5 min 1km)
Full - 3h 50m (+26 mins)

The second half of a marathon is when you need everything you've got.  You'll see that my second half is quite a lot slower than my first half (it's slightly disguised here, I run the first half in about 1h 50m and the second in about 2h); I have tried several times to adjust for that but I seem most comfortable running a slower second half.  I only dream of negative splits.

6. Sometimes, just run, no music. 

Out running, my eyes are often drawn to the way other runners carry themselves.  But more often, I listen to the sound their feet make as they hit the ground.  Too many runners seem to slap their feet to the ground, as if they were clapping with their feet.  That's a waste of energy.  Of course, they're all listening to loud music and are oblivious to it.  So, every so often, especially early on, listen to how you run - especially when you're tired and so more likely to lose form.  If you can hear your feet slapping on the ground, you're wasting precious energy.

7.  Get geeky.

Record everything.  Record the distance, the splits, how you felt, what the weather was like.  Get a sports watch with GPS (I use a Forerunner 310XT from Garmin - I've tried pretty much every other watch and rejected them) or use your smartphone with Nike+ GPS, Adidas miCoach, Runkeeper or similar (trouble with the 'phone is that it's not always easy to look at how you're doing and the audio interruptions drive me mad, especially when I'm listening to an audiobook!).  Get some software to display all of your data - I use Rubitracks on the Mac; if I had a PC I would use Zone 5 software's SportTracks (again, I've tried all of the others and these are the best for me).

8.  Two kinds of run.

For all the talk in magazines and books, there are only two types of training runs.  Fast runs.  Or long runs.  That's it.  If you want to get scientific, you can run sections of fast run during your long run.  But it's still a long run.  If you get bored easily you will want to mix these up.  Go ahead. Run sprints between lamp posts, run hills, run track, run relays. It's all running and it all helps - just be sure to be geeky about it so that you know if you're getting better; if you're not, you need to do something different.

9. Trace out your routes.

I like to run the same few routes.  I'm lucky - I run along the River Thames so what I see changes every day, with the weather, with the time of day, with the traffic, with the buildings.  I can run a 25km loop starting eastbound and cross only 4 roads; i can run the westbound loop and go 30km or more crossing only 3 roads.  Starting off on any given run, I can make it 6.25km (the shortest loop), 10km, 12.25km, 15.5km, 16.6km, 21km just by extending the run a little and without covering the same ground twice - so if I'm feeling good, I can go longer.  If I'm not feeling so good, I can cut it short.  Inevitably what happens is that at the furthest point from home, it starts to rain of course.  Not everyone will be able to set out their routes like this and perhaps you will have to run multiple shorter loops (in which case, have as many different loops as you can so that you get variety).

10. Know your limits.  

If your head is right, you're training hard and you're healthy, the next challenge is how to push enough but not so much that you get in trouble.  if you get injured, you can't run. You will find that limit through trial and error.  If you're like me, it won't be the way they say it in the running books - there they say you should increase your running volume only a couple of miles each week. I increase it much faster than that, but I offset that by only running 2 times a week in the early stages and maybe 3 times a week in the middle if I have the time.  But you need to find what you can do, test how far you can run and how much rest you need.  It will, inevitably, be a very individual thing. 

11. Your shoes count for a lot.  

For all the talk of bare foot running and ultra-light shoes, unless you're Kenyan or less than 8 stone, you're probably not running in those.   I have tried every kind of shoe - newtons (that try and make you run on the front of your foot), lunarglides (I just get a sore knee), shoes that auto-adjust with a little motor, lightweight shoes, mizuno, new balance and all that you can think of. And i go back to Nike triax every time because I can run further, more consistently and with far fewer injuries.  Get the shoe wrong and you will probably injure yourself and set about fixing the wrong problem. Check the shoes first. 

12. Floss 

The biggest dent in your training will more likely come from illness, especially if you're training in the winter.  Now this might sound bizarre but, trust me, there's a lot of evidence to back it - floss regularly, daily if you can. The state of your immune system can be improved by giving it one less problem (I.e. gum infections and bacteria) to fight against.  The few points of improvement this results in can be enough to fight off your next cold before it stops you running. 

13. Halfway there.  

It really is all in your head from this point on.  Pretty soon, everything will hurt.  This is where those long runs, on cold, dark, wet days pay off.  Stay with it.  If you are behind your expected pace here, you probably can't make it up.  So knuckle down, keep going and let the crowd lift you along. 

14. Adjust but only a little.

You can and should adjust your running style.  But not much and not often. get it wrong and you're likely to consign yourself to the injury dump for a long time.  Be careful with gait analysis, orthotics and anything that suddenly adjusts your style. I am a sample of one (and therefore this is anecdotal at best) but I ran for years with little trouble, then had some analysis done that resulted in orthotics. Two torn meniscus cartilages later (after about 9 months of wearing them) and I went back to my usual shoes.  Your body has got used to working in a certain way - tendons follow certain grooves, muscles operate in a certain way ... Change that quickly and you will almost certainly get hurt. 

As you continue your training, as you get fitter and start to cover longer distances, your running style will automatically adjust at least a little.  You probably won't notice, but your form will improve and you will learn to run in a more efficient way.  You may also lose a little weight which will likely help too.

15. You do not run marathons with food alone

Supplements are essential.  It might be that you need energy drinks during a long run (or on a hot day) but it is also that you need vitamin pills, joint pills (I use Cissus as well as glucosamine), protein shakes after a run and so on.  You may also want to take a look at beta-alanine particularly.  Take it 30 mins before a fast run (one that you have done many times and know your pace) and see how you get on.  Some people, me included, get a funny pins and needles sensation from it but it helps me run a minute or so faster over 5km, all part of tricking the body to run faster routinely.   As far as I know, beta-alanine is not on the list of banned substances for any sporting body.

16. Run To The Beat. Sometimes.

Listen to audibooks, listen to classical music. I learned conversational Italian when running two marathons one year.  For races and really fast runs, switch to upbeat music.  And get anal about it - set up the playlist so that you have your favourite pieces at points of the race that you know will be difficult.  If you're very confident of your finish time, set a sequence of two or three tracks to play as your countdown to the finish. Corny, maybe, but I use "Gonna Fly Now" from Rocky to cover the last kilometre of any race I run; it's a huge buzz when i nail the pace that I've planned and that tune kicks in with 1km to go.

17. Run everywhere.

It isn't just about pavements.  Run on all sorts of surfaces, even though your marathon will most likely be on roads.  Run hills, run grass, run tracks and trails.  Just don't run on ice - that's a slippery slope. 

You don't actually need to "run everywhere" - I admire the people that run to work but I have no idea how they do it, where they keep their gear, how they handle arriving at work a crumpled ball of sweat.  But, golly, I admire them. 

18. The marathon is a race. 

So racing is part of your training.   Go to your local parkrun and run 5km as hard as you can.  and then run home from there.  My park run is about 18km away.  That run home is the hardest i ever do but it feels great when it's done.  Run a 10km race as part of your training and at least one half marathon, two if you can.  Getting ready for those races will teach you how you need to approach the big event - and will allow you to tune how you do it, what pace you can run at consistently, what gear you need to wear and how you're doing against your plan.

19. Dogs.  

Get used to them.  Don't get upset about it.  You will get chased by a dog sometime, perhaps several, perhaps regularly.  Get over it.  If you are chased, just stop dead and wait for the owner to get the dog under control.  Smile, laugh it off and carry on.  You weren't about to break the world record.  Speaking as a dog owner with a wayward puppy who occasionally likes to run alongside a jogger, I'm amazed at the anger that some folks display (at me, at the dog, at the world around).  I'm probably bias though.

20. Train as you plan to run.

I like to train on an empty stomach - to teach my body to run on low reserves.  Most of my runs are in the morning, because that's when most races are. On race day, i will have some protein (from a shake) and some carbs about 30-45 minutes before the race start - and I practice that for a few runs before the big day to make sure that my stomach can handle the food. Whatever you do, don't do anything new in the days before the big race and certainly don't do anything or eat anything new on the day itself.  Only disaster results when you do that.

21. Injuries come.

It's quite likely that you are susceptible to one particular kind of injury. The sooner you have it and take steps to fix the root cause, the faster you can get on with your training.  It might be shin splints, or ITB problems, or it might be plantar fasciitis. Or it might be that you just get a sore knee. When it happens, you will try and run through it and, usually, it gets worse. So find it, fix it and move on. 

22. Energy gels

Personally they don't do it for me. I see people with special belts with 6, 8 or even 10 gels attached on loops. It's not me.  I've run my fastest marathons, 3:45 to 3:50, mostly on water and a little lucozade (if it's a hot day, watch out for what happens near the lucozade tables on race day - the ground gets as sticky as Velcro!).  But figure out your own needs as you progress.  Energy gels generally taste poor and need water to wash them down with. So practice ripping the top off, squeezing the gel in and then drinking water long before race day.  

23. Bottles versus backpacks

During your training, don't carry bottles to drink. If you're going on a long run and especially if it's hot, invest in a camelbak or something similar.  Bottles adjust the way you run - they make you swing your arms differently or twist your hips and that might lead to injury. 

24. Booze

Before a half marathon I quit drinking for 2 weeks, before a marathon I quit for 4 weeks. There's no science in that, it's just something I do. The first drink after the run is always a very nice bottle of wine, or even an absolutely stunning wine.  And wow, is it all the sweeter for the pause. 

25.  Don't just run

Sure, you've got to run, and run a lot, whilst training for a marathon.  But don't just run.  There will be days when you just haven't recovered enough to run, but you could get a half hour on an exercise bike, or 45 minutes on a cross-trainer or 20 mins on a stairmaster.  Other times, you might run for 60 mins and then do another 60 mins on a cross-trainer.  The muscles you use aren't the same and it isn't the same as running, but it will boost your fitness, lesses the strain on your joints and, more than likely, round out some imbalances in your muscles.  Don't overdo it though.  Likewise, don't think that you can lift weights and gain muscle whilst you're running long distances - though do lift weights, again, to even out muscular imbalances and improve overall fitness.

26. Finish fast.  It's a race.

On every training run, pick up the pace as you approach home.  Even if you only do that for the last 50 yards at first, do it.  Gradually pick up the pace earlier and earlier.  Remember, you will be racing.  There will be spectators at the end.  They want to see you finish fast, like it matters to you.  Because, you know what, it really does. Crossing the line with a bit of speed will be a great feeling. 

Unless the event is a flight away from where you live, run the last mile or two (more if you can) of the race route during your training.  run it when you're tired.  you want to know that you can dance through those last couple of miles.  being familiar with that last bit will be a big help.  and when you run it for real, the hundreds or even thousands of people lining that bit of the route will lift your spirits in a way that you can't imagine until you experience it

26.1 Celebrate.

Raise your arms in the air, cry, look for your family, celebrate with another runner, get your photo taken wearing your medal.  Look at your finish time - be pleased whatever it is, be ecstatic if it is equal or better than your goal. All of those. Do whatever you need to do but keep moving forward. 

Within a couple of days you will already be wondering about the next one so make the most of this one. 

Friday, February 03, 2012

More on email

As a follow up to yesterday's post on email volumes in government.  Here are the figures provided by DCLG in response to my questions:

Q1. Total number of emails sent and total received by the DCLG central e-mail system – A1. The total number of DCLG emails sent (outbound) during September 2011 were 338,971. The total number of DCLG emails received (inbound) during September 2011 were 643,280.  
Q2. Percentage of each that were entirely within the DCMS domain    Q3. Percentage of each that were to or from other government departments (with GSI, CJX or equivalent domain names) - Q4. Percentage of each that were to or from the Internet 
DCLG’s email system cannot disaggregate information to the level of detail you have requested for questions 2, 3 and 4.

So DCLG's mail system handled a little over 982,000 emails in September 2011.  DCLG has 2,500 staff (and falling I gather).

On average, a DCLG staff member:

Received 257 emails per heard per month
Sent 135 emails per head per month

That's just under 12 per day received and 6 sent.

The figures for DWP are quite different:

Received: 6.876m
Sent: 3.318m
Headcount: 90,000 (I see figures between 80,000 and 100,000 so picked the midpoint)

Received per head per month: 76
Sent per head per month: 37

It is likely, perhaps, that not all of DWP's 90,000 staff have access to email, but I haven't seen any figures that show how many that might be,


Thursday, February 02, 2012

e-Mail in UK government

Last September I asked if anyone had any data on e-mail usage in government.  I got some useful data from friendly sources, and some from a small number of FOI requests. The conclusions are:

1) Few departments have any data beyond how many e-mails they receive and how many they send; they can't break down, for instance, how many come to or from the Internet.   Where I didn't get the data from a particular department, I've used the average of the other departments to blend all of the data - not ideal but seemed reasonable.

2) Departmental staff, if the figures are to be believed, receive between 30 and 80 e-mails a month and send about half that number.  I'm surprised by those figures - plainly the average hides a lot and there are likely users receiving and sending 10 or 100 times that many.

3) Roughly 60% of all e-mails in government are between users in the same department.

4) About 20% of all e-mails in government are to or from other departments who are on a secure network (such as the GSI, CJX etc)

5) Around 20% of all e-mails are to or from the Internet (e-mails received from the Internet are about twice the number sent though).  Remember that government anti-spam and anti-virus (still the same tool we put live back in 2002 or something like that) is good enough to ensure that almost no spam comes through (in 10 years of having a GSI e-mail address, I can't recall a single spam message getting to me)

It's been quite hard to get this small amount of data and I don't think it tells me what I was really wondering - that was whether a case for cloud-based e-mail could be made just from the headline numbers; more digging would be needed to get at e.g. the number of e-mails with "restricted" in the header (which I strongly believe would be ridiculously low, definitely single digit percentage, probably very low single digit) - but I suspect most departments don't have the answer to that (and may claim that because internal e-mails, by definition, go over a secure network, then not everyone labels properly - I would counter that they don't label properly even when they do take the time to label!)