I suppose we could use split beer mats, but I am more of a traditionalist when it comes to materials. You just can’t beat the back of a Capstan Full Strength packet when you are scoping out a multimillion IT spend.

And, it seems, I am not the only traditionalist, if you look at the proceedings of the House of Commons Public Accounts Committee, which recently* challenged Peter Gershon, former OGC Chief executive, over his concerns about major projects that seemed to have been planned on the back of cigarette packets.

Of course, Mr Gershon’s comments in an earlier speech were probably made for dramatic effect, rather than as a matter of record. But you never know.

We may well find in another 40 years or so that we see a whole raft of declassified fag packets made available for public scrutiny. Future technologists will examine their cryptic hieroglyphics, desperate for clues and insights into why government computing in the early 21st century cost so much and took so long.

Perhaps one day the British Museum will juxtapose a grubby Silk Cut carton alongside the Rosetta Stone of ancient Egypt and we will all marvel at the quantum leap in world knowledge derived from these apparently disparate artefacts.

An amusing prospect indeed. But with a serious undertone because in my experience some of the best IT management ideas have been those that were hastily scribbled on fag packets, beer mats and table napkins.

Very often our most incisive and decisive plans can be scribbled on ephemeral objects, such as whiteboards and flip-charts, only to lose their intellectual strength and integrity when transposed to a more formal medium for presentation to others.

I don’t know any IT director who would feel comfortable laying out a strategic plan to the board while clutching a crumpled fag packet or a soggy beer mat. It would be like walking naked down a crowded street so we instinctively reach for our high-tech comfort blankets: powerpoint and colour laserprints, to sell our idea “properly”.

And yet the original scribbled notes are probably the most valuable view of the plan because they were conceived in innocence, before being translated and traduced for the intended audience. Too often we will dilute and disguise a concept during translation from the fag packet to the board pack, in the hope that we will gain stakeholder acceptance, sometimes at great cost to project integrity.

Too often, I have seen excellent first-cut project plans that have been doctored to produce politically acceptable outcomes, at least in terms of cost and timescale, by injudiciously tweaking resource estimates until budget and calendar objectives are met, rather than by de-scoping activities and deliverables.

It’s no wonder then that so many projects subsequently over-run some or all of the three key measures of cost, time and quality; because we have compromised our original, and probably most accurate, vision of the task and the effort to achieve.

Perhaps we should get cigarette manufacturers to put a suitably large warning message on their packets. Something like: “Cutting project resource estimates without descoping activities can seriously damage your project…”

Don’t knock the ideas scribbled on the back of cigarette packets. That’s when they’re at their freshest, and start to dull from the moment they are translated to the flipchart or Powerpoint presentation.

[*I wrote this article in May 2004 but the principles remain valid]

You may also like to read:

• misalignment of business and personal benefit
• there is no ‘f’ in leadership

I have heard much talk recently about the apparent difficulty of attracting young people to computing. Some of the UK commentators hark back to the early 1980s, the heyday of the ubiquitous micro computers, such as the BBC Micro and Clive Sinclair’s budget computers (ZX80/81 and Spectrum).

The Micro generation of the early ’80s were keen to make computers do things, their boxes had to be programmed and the kids soon picked up the skills and the principles involved.

No wonder then that our schools responded to the technology bow-wave and brought computing to the classroom. The kit was there and the kids were there.

Thirty years on, though, the DIY micro has long since given way to the games console – plug-and-play devices which need no understanding of, or technical facility with, the technology.

So we have successive ‘Console’ generations who just like playing games and are less likely to want to know about making computers do things, apart from achieving a higher score, a higher level or perhaps an even quicker cheat.

If we really want to get back to fostering computing skills from an early age, we don’t need another games console. We need a ZX80 or BBC Micro for the 21st Century

You may also like to read:

• Ten Essential Skills for an effective CIO

Of course, it is rare for any enterprise to be entirely self-sufficient so our value chains are usually forged from an intricate mesh of internal and external contributions.

Where the external linkages are formalised, say by contractual relationships and clearly defined service levels, it may be somewhat easier to gauge the mettle of our partnerships.

However, the internal workings of our own organisation are generally predicated on a presumption of willing and active participation, or collaboration. A reasonable presumption, for sure. And particularly one that most stakeholders will take as a ‘given.’

But how often is this presumption of internal collaboration truly warranted?

Do we always pull together, in the same direction? Or do we sometimes get distracted, disjointed and disconnected beneath the waterline?

Collaboration is a worthy aspiration and one which we might expect as achievable. However, I am sure we have all encountered enterprises where external collaboration initiatives quickly founder upon the millstones of weak internal collaboration.

You may also like to read:

• The Irrational Enterprise
• Eleven keys for aligning IT with business strategy
• Enterprise Aliens

However there is a whole herd of elephants sitting in the middle of the room, including: the political policy/ service fulfilment lag; fanatically policed organisational boundaries; privacy/ security/ legacy data issues; national and supra-national procurement regulation; ‘heritage’ contracts etc. etc.

I came to the conclusion some time ago that the most plausible approach is to create a NewGov.uk, founded on proper Systems (with a capital S) principles, in parallel to the legacy estate, rather than just hoping that GCloud technology will resolve the serious organisational inhibitors that have long created so much unexpected cost and disappointment in government IT.

You may also like to read:

• Cost of Government IT is a smoke-screen
• IT’s time for a paradigm shift
• TCO = TRUE cost of ownership