Twenty five years of government IT project failure...

Last Friday’s Computer Weekly included an article by Tony Collins entitled ‘Twenty five years of government IT project failure’. It’s the same old same old – this time it’s the National Offender Management Information System, aka C-Nomis – half-a-billion pounds-worth of cock-up, on which (among much else) ‘nobody was sure how £161m allocated to the C-Nomis project had been spent’.

I’ve seen enough of large-scale IT programmes in the private sector to ask a few questions, however – if not in defence of public-sector IT projects then at least to suggest that the public sector is hardly unique in its talent for dire failure.

1. Who actually failed here? Who were the main delivery organisations for this and other notorious public IT failures? Were they not mainly private sector suppliers?


2. Where are all the private sector successes against which the public sector is implicitly being compared? I have worked on many large private sector programmes and I cannot remember one that was not massively over budget, late and signally failed to deliver what was promised? There is for example currently a very large private health company that is currently struggling to complete an IT programme that is 400% over budget, several years late and has been descoped by 70%.


3. Are we really comparing like with like? C-Nomis is spending hundreds of millions of pounds, whereas (in my experience) the private sector thinks it’s got a big job on its hands when it hits £100m. Public sector programmes are the size of minor wars – the private sector would flounder just to organise the tea breaks.


4. As for the underlying faults, regular talk of undefined requirements, politicking, interminable scope and mission creep, inadequate contract and supplier management, lack of accountability, ludicrous optimism, failures of core management practices and procedures – these only go to show how much the private and public sectors have in common.

The public sector indisputably has a lot to learn about large IT programmes, but I doubt that it has much to learn from the private sector.

You don't say? Sun tells it like it is

As part of what should surely be a UNICEF programme to name and shame those who would besmirch the human mind by destroying language, here is Sun's opening on the topic of cloud computing:

High-density horizontal computing — Sun is pioneering high-power-density compute-node architectures and extreme-scale Infiniband fabrics as part of our top-tier HPC deployments. This high-density technology is being incorporated into our large-scale cloud designs.

I feel this terrible urge to stone someone ...

Recruiting square pegs for round holes

Currently looking for a new client, and as usual most advertisements include the idea that the would-be employer will only consider consultants with a strong background in [insert name of business sector/activity/system here]. Looking at a potential client with a requirement to build IT management systems and processes in the London financial sector, they say that they will only consider candidates with a strong risk system background.

I have worked in lots of sectors – software development, credit cards, insurance, defence, manufacturing, insurance – and I can’ t say that knowing about how the business worked made any substantial difference to how they needed to build their IT development management systems – methods, tools, reporting, etc. Basically, this is one case where the nature of the solution that is being built has far more in common with other solutions of that technical nature (i.e., other IT systems) than it has with other kinds of solution in that sector. So all development methodologies tend to look the same, all project management tools, all reporting systems... And why not? 80% of the time, the code for a word process is indistinguishable from the code for a bank system or a helicopter command-and-control systems.

But of course the business knows best. So they ask someone who knows all about helicopters – or insurance policies, or whatever – to build their processes, and they get ... a lump of dead, mechanical ‘process’ that looks like it was written by Franz Kafka and goes down like a lead balloon with developers.

A related mistake is to recruit someone who is good at a job to build management systems that will help other people do that job just as well. Seems sensible until you ask yourself whether you recruit a racing driver – even a very good one – to design your car. I wouldn’t. I wouldn’t even care if they had a driving license, so long as they had a long track record in designing race-winning cars.

The value of validation

I just attended a workshop on testing procedures. It was a bit worrying – not that anything was wrong with the procedures themselves (in fact they were well thought through) , but it was a bit shocking that testers still need telling.

One topic the workshop didn’t address was the distinction between verification and validation. These terms are used in different ways in different environments, so I should start by saying what I mean by each. Verification is making sure that a production meets its spec. Validation is checking that, even if it does, it will also fulfil the original requirement it is intended, to meet. Not at all the same thing, not only in the obvious sense but also in the sense that step-by-step verification from the requirements to (say) the code you are reviewing would not be equivalent to validating the code against the original requirement. There is just no substitute for asking which requirement a piece of code contributes to – and how each requirement is realised in the code.

There are lots of reasons for this, of which the fallibility of previous checking it one. But there is (a mathematician friend tells me) a much more compelling one that should convince even the most hardened reviewer and tester. This is that it is (apparently) possible to prove mathematically that no two languages can be translated into one another such that the semantics is exactly correct.

This may seem an abstruse point, so here is a practical example I have used in training courses. There is a well known saying in English that, if you translate it correctly into Russian (again, I am told) and then re-translate it back into a possible but correct English phrase. One of the possible outcomes is the following:

The vodka is acceptable but the meat is off.

So what was the original English phrase? Give yourself a few seconds before you look at the answer, which is at the foot of this post.

Now look. Not quite the same, is it? Now it is essential to recognise that both the translations, from English to Russian and from Russian to English, were both 100% correct. Just like a model may correctly represent a requirement, a design a model and code a design. And yet it is clear that if you came up with the second English phrase (the code, as it were) rather than the first (the requirement), it would leave something to be desired. The problem is, requirements, models, design and code are all in different languages (in every sense) and not two languages (let alone four) are exactly equivalent.

Hence the critical value of validation as well verification. Your just have to do it, not because your verification (reviews, testing, static analysis, etc.) isn’t good enough but because it does a different job.

Not that you should validate everything. It’s expensive, and like verification itself, not always the most productive thing you could be doing with your resources. Like everything else in good management, what you look at should be determined by the risk it represents. So only validate the items that represent a real threat if they are wrong. By and large, focus on the critical, the complex (at any level), the novel (to you). After that, either an error won’t matter much or you should be able to fix it relatively easily.

Answer: The spirit is willing but the flesh is weak. Or, more completely, ‘Watch and pray, that ye enter not into temptation: the spirit indeed is willing, but the flesh is weak’ (St Matthew 26:41).

Implementing a methodology - do's and don'ts

An old friend sends me the outline of an IT methodology he is being expected to implement by a big client. It’s the usual bureaucratic behemoth and he asks me what can be done to make it work decently. My reply:

"Thanks for this. I read as much as I could bear and skimmed the rest. I can see why they’d hate it!

Going by this description, I had a similar problem at a large client financial services where I spent 2½ years implementing a global consultancy’s not very lovely methodology. They hated that too, but we eventually got grudging support and even commitment.

I guess that you could summarise what I would do as follows:

1. Insist on taking training very seriously – train everyone from top to bottom of the company, tailor the training to their exact needs, and as far as the delivery teams are concerned, don’t let anyone tell you can do this in less than a day for the introduction and a day for each major development stage (or discipline, perhaps). I personally trained more than 800 people in methodology at one client and they grudgingly agreed that it was money well spent. I think this which as because the training included lots of ‘whys’ as well as ‘hows’. That way people were constantly given the message that there really is a compelling reason to do this stuff, that this really is for your own good – as engineers, as professionals, and as people who don’t want to waste their own time or other people’s. The training has to be full of useful nuggets (eg, 40% of all software engineering is waste and rework, primarily for lack of decent processes), war stories, realistic exercises (ideally one big case study) and methods for finding that magic 80/20 position.

2. Encourage PMs to create tailored versions of the methodology for themselves. This is easy and reasonable and builds ownership. Given that it means cutting out waste and rework and building in the uniqueness of local areas, your client should want it too. After all, if the generic methodology includes stuff (as it always does) that doesn’t make sense in a given project context, they shouldn’t have to do it. And make sure that you build the process for tailoring the process into the main process (e.g., as a project initiation activity), make it a high priority item in training (for senior management too), and reward managers for being insightful and innovative.

3. Scale the methodology thoroughly – with a two-page checklist for truly tiny pieces of work, and a serious approach to low-risk work that really does require only a light touch. But never say that the process is optional. It is never optional. It is simply adaptable. Build in get-out clauses for compliance, take the maintenance people’s problems with project-size methodologies seriously, create massively simplified tools appropriate to very low risk situations. Make sure everything is driven by a clear sense that real risks are being managed rather than a formal procedure being complied with. But never let them do nothing – that’s just the thin end of the wedge.

4. Make the waiver/exception process as simple as possible. Quick, clear lines of authority (ideally as local as possible), 5 questions maximum, rapid response guaranteed. I would suggest simple answers to questions like:

• What do you want an exception/waiver from?
• Why do you want it?
• What will you do instead?
• Why is that better than the standard process?
• What residual risks does that create?

5. Ensure that the methodology is properly owned, so that there is someone to go to for a decision on what is really meant or needed by a specific item, or to approve an exception. This is crucial if the system is to continuously improve itself – someone has to have it as a high-priority responsibility to actually improve it.

6. Support users constantly by training a methodology expert or two (one of my clients had 6-7 for 600 engineers) providing training, internal consultancy, project management consultancy, explanations and ideas for quick wins. They also provide a powerful conduit for communicating new ideas between groups.

7. Build an decent wiki (not a fixed website) that provides high-level process flow models to remind people what to do, and which can be drilled down for more details, online forms, etc. This paper you sent me is a prime example of a format people just won’t read – even I felt ill just looking at the endless levels of heading number. On the other hand, it’s not a bad script for a training course, so it’s not wasted. Even something as simple as online PowerPoint presentations are very effective, although they tend to offend web purists! I have a couple I built for Citibank, Churchill Insurance, Amex, Accenture, etc., if you’d like the see them.

8. Build an effective lessons learnt system that completes the loop from project experience to the methodology and back (through rollouts and training) back to projects.

9. Finally, pure stick: Tie their bonuses to compliance with the methodology, as confirmed by an independent assessor. Brutal, unpopular, initially counter-cultural in many companies but amazingly effective. It provides a somewhat perverse way of dealing with the inevitable feeling on the software engineer’s part that they have little interest in complying other than simple obedience to a very dubious corporate rule – if all else fails, fine them for non-compliance. Having dealt with thousands of IT people, I can only say that it has its place in the methodology implementation toolkit.

I dare say that some or all of this could be sold to anyone who a) hated methodology enough; b) had no choice about complying; and c) could afford the likes of me to make it work!"

Don’t measure what you won’t manage

I would guess that everyone in business has been asked to fill in a timesheet with dozens of charge codes - one for this project, one for training, one for admin, one for this other activity, one for... The list is usually endless. And equally endless seems to be managers’ craving for more and more data. Right now I am working in an otherwise quite sane organisation where I am nevertheless expected to complete a timesheet in excruciating detail. Given that my time is not chargeable and I’m supposed to be the metrics and measurement guru around here, it’s all a bit galling, to say the least!

Asked what they use it for, the answer often turns out to be ‘Nothing at the moment, but it will be useful...’ Oh really? Useful for what? And when? Naturally I don’t push this too far – some things are just corporate obsessions, and it’s definitely a Career-Limiting Move to question them too harshly.

Yet there are times when this fetishisation of numbers becomes quite bonkers. Two variants are especially stupid – when the data is deliberately falsified, and when the cost of collection is wildly over the top.

Take for example a consultancy I used to work for. A timesheet was put in every week, and then our chargeability was reviewed by the board – of which I was a member. Then one day I found myself being firmly reprimanded by the Chairman himself to the effect that no one was supposed to book more 37.5 hours a week. In fact I had booked 62. So I asked him, Whose data would you like me to falsify? No answer was forthcoming, and I went on booking my real hours. But the accounts department had firm instructions to edit my timesheet so that it fell in with the Chairman’s lack of numeracy.

Of course, it’s a petty story - until you work out how much effort is put into taking, processing and reporting measurements of all kinds that are never used. Probably tens of millions of people fill in a timesheet or some other record every day/week/month, only to have it effectively ignored.

But sometimes the waste is staggering. I used to work for a big consultancy, in an internal management role. One day a bunch of consultants I had not met before rolled up and announced that they were going to ‘fix’ our project proposal process. It seemed like a good idea – we were a bit haphazard and it was not unknown for us to sign up to a real disaster we really should have seen coming.

But then they started to tell me what they were going to do, and it was essentially a process of gathering the opinion of practically every senior manager and partner in the company. I was especially surprised at the long list of data they were going to collect for me. But I don’t have any use for this information, I said. But it’s very useful, they replied. For what? I asked. It will be very useful, they insisted. For what? I reiterated (I’m not very creative when it comes to people who repeat themselves). They would not back down, and I was in no hurry to admit that there was any point in collecting data about things no one actually wanted to know about.

So I decided to investigate the matter a little more thoroughly. I went to all of the people these consultants said they we helping to evaluate proposals and asked them two questions. One, as decision-makers, which parts of the information they were being offered would they actually use. And two, as information-suppliers, how much would it cost to generate the data they were being asked for.

The answer was less than astonishing. On average, only about half of the data that was to be collected would actually be used by anyone, and the total cost of this whole process would be about £60,000 per proposal. So we would be wasting about £30,000 every time we looked at a new job.

The moral of this tale? Don’t measure what you don’t manage. And while you’re at it, don’t measure things you do manage either, unless you are perfectly sure that the measurements will really be used – ideally as the clincher, but certainly as an important source of knowledge. Not that I would expect many companies to observe such a rule – after all, how many administrations, programme offices and finance departments would survive the resulting purge?

The other moral? Don’t ask people to solve problems they don’t understand and of which they have no experience, just because they are clever people and at a bit of a loose end. But that is a subject on which I could write a book.

Management quotes

Well, everyone else seems to have a list of favourites, so ...

1. The way to secure success is to be more anxious about obtaining than about deserving it. William Hazlitt.


2. Some things that don't count are counted, many things that count aren't counted.


3. You can't rise unless you set goals that make you stretch. Tom Hopkins.


4. The greatest pleasure in life is achieving things that people say can't be done.


5. It is not enough to aim. You must hit. Italian proverb.


6. Activity is not achievement.


7. Nothing great was achieved without enthusiasm. Ralph Waldo Emerson.


8. Who begins too much accomplishes little. German proverb.


9. Quality is free, but it is not a gift. Philip Crosby, quality guru.


10. The best is the enemy of the good.


11. Either dance well or leave the ballroom. Greek proverb.


12. At the heart of every large project is a small project trying to get out.


13. Good project managers know when not to manage a project.


14. Failing to plan is planning to fail.


15. An individual without information cannot take responsibility; an individual with information cannot help but take responsibility. Jan Carlzon, CEO SAS Airlines.


16. A little risk management saves a lot of fan cleaning.


17. Do your duty in all things. You cannot do more. You should never wish to do less. Robert E Lee.


18. All successful men are men of purpose. They hold fast to an idea, a project, a plan, and will not let go. James Allen.


19. It's only common sense? Common sense is what you think when you're not thinking. RJ Robinson.


20. 'Begin at the beginning', the King said, very gravely, 'and go on till you come to the end: then stop'. Lewis Carroll.


21. No plan survives contact with the enemy.


22. Plans are nothing; planning is everything. Dwight D. Eisenhower.


23. Knowledge is no more to be found in data than a house can be found in a pile of bricks. RJ Robinson.


24. A good workman is known by his tools.


25. Nothing is impossible for the person who doesn't have to do it.


26. You can plan too much, but no one has ever been caught doing it.


27. A project without a critical path is like a ship without a rudder.


28. In NASA, we never punish error. We only punish the concealment of error.


29. You can only elevate individual performance by elevating that of the entire system. W. Edwards Deming, quality guru.


30. A badly planned project will take three times longer than expected - a well planned project only twice as long as expected.


31. Pareto’s Other Principle: The first 80% of the project will take the first 80% of the budget, and the remaining 20% of the project will take the remaining 80% of the budget. RJ Robinson.


32. Project management is like juggling three balls - time, cost and quality. Programme management is like a troupe of circus performers standing in a circle, each juggling three balls and swapping balls from time to time.


33. Of all the things I've done, the most vital is coordinating the talents of those who work for us and pointing them towards a certain goal. Walt Disney.


34. All successful men are men of purpose. They hold fast to an idea, a project, a plan, and will not let go.


35. Good estimators aren't modest: if it's huge they say so.


36. The sooner you begin coding the later you finish.


37. A verbal contract isn't worth the paper it's written on. Sam Goldwyn.


38. What is not on paper has not been said.


39. If you don’t know where you’re going, any road will take you there.


40. If you don't attack the risks, the risks will attack you.


41. The sooner you get behind schedule, the more time you have to make it up.


42. The more you plan the luckier you get.


43. A project is one small step for the project sponsor, one giant leap for the project manager.


44. Quantitative project management is for predicting cost and schedule overruns well in advance.


45. The philosophers have only interpreted the world in various ways; the point is to change it. Karl Marx.


46. Good project managers know when not to manage a project.


47. Metrics are learned men's excuses.


48. Good project managers admit mistakes: that's why you so rarely meet a good project manager.


49. Fast - cheap - good: you can have any two.


50. The more ridiculous the deadline the more money will be wasted trying to meet it.


51. The project would not have been started if the truth had been told about the cost and timescale.


52. The most successful project managers have perfected the skill of being comfortable being uncomfortable.


53. If it wasn't for the 'last minute', nothing would get done.


54. Warning: dates in the calendar are closer than you think.


55. There is no such thing as scope creep, only scope gallop.


56. If project content is allowed to change freely the rate of change will exceed the rate of progress.


57. If you can interpret project status data in several different ways, only the most painful interpretation will be correct.


58. A project gets a year late one day at a time.


59. The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man. George Bernard Shaw.


60. When you describe your approach as ‘pragmatic’, do you mean ‘I’m devoid of principle’, ‘I’m completely lacking in insight’, ‘I would settle for second-best’ or ‘I’m making it up as I go along’? RJ Robinson.


61. I know that you believe that you understand what you think I said but I am not sure you realise that what you heard is not what I meant.


62. It must be considered that there is nothing more difficult to carry out nor more doubtful of success nor more dangerous to handle than to initiate a new order of things. Machiavelli.


63. I love deadlines, I especially like the swooshing sound they make as they fly past. Scott Adams (Dilbert).


64. Work expands to fill the time available for its completion. Northcote Parkinson.


65. Brevity is the soul of wit. Shakespeare (Hamlet).


66. Strategy without tactics is the slowest route to victory. Tactics without strategy is the noise before defeat. Sun Tzu.


67. What you don’t know will hurt you.

Management quotes

Well, everyone else seems to have a list of favourites, so here, in no particular order, are mine...

• Good management systems are like good brakes: they help you go faster.
• The way to secure success is to be more anxious about obtaining than about deserving it. William Hazlitt.
• 99% correct is wrong.
• Some things that don't count are counted, many things that count aren't counted.
• You can't rise unless you set goals that make you stretch.
• The greatest pleasure in life is achieving things that people say can't be done.
• It is not enough to aim. You must hit. Italian proverb.
• 90% of your problems have already happened the moment the ink is dry on teh contract.
• Activity is not achievement.
• Nothing great was achieved without enthusiasm. Ralph Waldo Emerson.
• Who begins too much accomplishes little.
• Quality is free, but it is not a gift. Philip Crosby, quality guru
• The best is the enemy of the good.
• Either dance well or leave the ballroom. Greek proverb.
• At the heart of every large project is a small project trying to get out.
• Good project managers know when not to manage a project.
• Failing to plan is planning to fail.
• An individual without information cannot take responsibility; an individual with information cannot help but take responsibility. Jan Carlzon, CEO SAS Airlines.
• A little risk management saves a lot of fan cleaning.
• Do your duty in all things. You cannot do more. You should never wish to do less. Robert E Lee.
• All successful men are men of purpose. They hold fast to an idea, a project, a plan, and will not let go.
• 'Begin at the beginning', the King said, very gravely, 'and go on till you come to the end: then stop'. Lewis Carroll.
• No plan survives contact with the enemy.
• Plans are nothing; planning is everything. Dwight D. Eisenhower.
• Knowledge is no more to be found in data than a house can be found in a pile of bricks. RJ Robinson.
• A good workman is known by his tools.
• Nothing is impossible for the person who doesn't have to do it.
• You can plan too much, but no one has ever been caught doing it.
• A project without a critical path is like a ship without a rudder.
• In NASA, we never punish error. We only punish the concealment of error.
• You can only elevate individual performance by elevating that of the entire system. W. Edwards Deming, quality guru.
• A badly planned project will take three times longer than expected - a well planned project only twice as long as expected.
• Pareto’s Other Principle: The first 80% of the project will take the first 80% of the budget, and the remaining 20% of the project will take the remaining 80% of the budget. RJ Robinson.
• Project management is like juggling three balls - time, cost and quality. Programme management is like a troupe of circus performers standing in a circle, each juggling-three balls and swapping balls from time to time.
• Of all the things I've done, the most vital is coordinating the talents of those who work for us and pointing them towards a certain goal. Walt Disney.
• Either dance well or leave the ballroom.
• An individual without information cannot take responsibility; an individual with information cannot help but take responsibility.
• Good estimators aren't modest: if it's huge they say so.
• The sooner you begin coding the later you finish.
• A verbal contract isn't worth the paper it's written on. Sam Goldwyn.
• What is not on paper has not been said.
• If you don’t know where you’re going, any road will take you there.
• If you don't attack the risks, the risks will attack you.
• The sooner you get behind schedule, the more time you have to make it up.
• The more you plan the luckier you get.
• A project is one small step for the project sponsor, one giant leap for the project manager.
• Quantitative project management is for predicting cost and schedule overruns well in advance.
• The philosophers have only interpreted the world in various ways; the point is to change it. Karl Marx.
• Good project managers know when not to manage a project.
• Metrics are learned men's excuses.
• Good project managers admit mistakes: that's why you so rarely meet a good project manager.
• Fast - cheap - good: you can have any two.
• The more ridiculous the deadline the more money will be wasted trying to meet it.
• The project would not have been started if the truth had been told about the cost and timescale.
• The most successful project managers have perfected the skill of being comfortable being uncomfortable.
• If it wasn't for the 'last minute', nothing would get done.
• Warning: dates in the calendar are closer than you think.
• There is no such thing as scope creep, only scope gallop.
• If project content is allowed to change freely the rate of change will exceed the rate of progress.
• If you can interpret project status data in several different ways, only the most painful interpretation will be correct.
• A project gets a year late one day at a time.
• The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man. George Bernard Shaw.
• When you describe your approach as ‘pragmatic’, do you mean ‘I’m devoid of principle’, ‘I’m completely lacking in insight’, ‘I would settle for second-best’ or ‘I’m making it up as I go along’? RJ Robinson.
• Metrics are learned men's excuses.
• I know that you believe that you understand what you think I said but I am not sure you realise that what you heard is not what I meant.
• It must be considered that there is nothing more difficult to carry out nor more doubtful of success nor more dangerous to handle than to initiate a new order of things. Machiavelli.
• I love deadlines, I especially like the swooshing sound they make as they fly past. Scott Adams (Dilbert).
• Work expands to fill the time available for its completion. Northcote Parkinson.
• Brevity is the soul of wit. Shakespeare (Hamlet).
• Strategy without tactics is the slowest route to victory. Tactics without strategy is the noise before defeat. Sun Tzu.
• Vision without acting is daydreaming, acting without vision is only pastime.
• What you don’t know will hurt you.

Stakeholder management links

I have recently started to look at stakeholder management. As usual, I began by cruising the internet for useful sites. One helpful one I have found is the Project Stakeholder Management blog at http://www.projectstakeholder.com/. Its case studies and brief articles are especially helpful, as they include many substantial ideas and interesting examples, generally from outside management. I have certainly plagiarised it shamelessly (and I hope they will return the compliment).