Archive for the 'failed projects' Category

Project branded as “A master class of misadministration”

There have been many articles in the press and on TV and radio complaining about the Single Payment Scheme which has culminated in a damning report by National Audit Office (NAO).

The report published has hit the headlines here in the UK for another poorly delivered project and suggests that:

“The implementation of the single payment scheme encountered difficulties that could result in the European Commission imposing a sizeable penalty.” In addition, the main complaint from UK farmers has been they have had to wait inordinately long times to receive payments. “The difficulties in making payments have caused distress to a significant minority of farmers and undermined the farming industry’s confidence in the Agency” suggested the report.

Switch now to the Editorial in Computer Weekly who commented on the report:

“Nothing changes. When a department gets covered with opprobrium by an NAO report, the relevant minister goes on BBC’s Today programme with what could be a yellowing script.

The routine is to disparage, in measured tones, the NAO’s figures, and then say that good progress is has been made, ideally topped with a generous helping of statistics.
MPs, the media and the public are left with no inkling that parts of the department are in administrative anarchy.

It’s not surprising then that the NAO’s Director Philip Gibby expressed his frustration, at a press conference last week, at having to revisit the Single Payment Scheme in a third report. Each time he is assured that progress is being made.

So can we trust the government’s assurances about the IT? Can we trust the government’s assurances on the state of any big IT-based project or programme?

We believe that government IT failures keep happening largely because they operate in a sunshine-and-roses universe in which truth and reality are poisons nobody goes anywhere near. Not departments. Not their agencies. And not their ministers. Thank goodness then for the NAO.”

There are some incredibly strong words in the Computer Weekly Editorial about a UK Government project :

“….failures keep happening largely because they operate in a sunshine-and-roses universe in which truth and reality are poisons nobody goes anywhere near…

It left me wondering whether your company operates in an area where truth and reality are places where people openly go. How much effort and energy is put into creating truth and reality or is it simply an area where few people go?

The full NAO Report can be found here

 

Do we really apply lessons learned to projects?

Peter Honey is a highly respected Chartered Psychologist, a dedicated lifelong learner who has written well over 20 books, numerous articles - all on learning.

He writes an informative and regular column in ‘Training Journal.’ In his latest article he asks whether lessons are ever really learned. He says: “I’m fascinated by the number of times you hear people …say things like “lessons have been/will be/must be learned.”

Peter suggests that so much informal learning goes on at the subliminal level and that people claim to learn something new each day but, if you ask them to describe what they have learned, you rarely get a convincing answer.

He asserts - and it is certainly my experience, - that if you can articulate learning:

• the learner becomes clear what he has learned
• the learning is shared, making it a trigger for others to learn
• the learning is more easily converted into action plans
• the learning is amenable to quality assurance

So what has this all to do with project management?

There are too many examples of ‘failed projects (however you define the word fail). How much learning follows from these failed projects? How much learning is shared with successful projects? My experience suggests very little.

Few companies can boast a robust project learning process. Lessons learned fail to be captured and shared, and defeat the whole learning process. My experience also shows that project closure meetings/processes rarely happen so how can learning be built into the overall project management process

Peter Honey suggests that is not easy to articulate real learning. I believe we need to go beyond ‘the Honey line’. He says: “when someone claims that lessons have been learned, we should ask what lessons have been learned and really probe further.” My suggestion; build into projects a much stronger process to capture and share learning

Honey says: “When they wriggle, we should insist on getting a thought through answer within 24 hours.”

We will continue to make the same mistakes if we do not, as Honey suggests realise what we have learned. Often, people need help in identifying learning. This is where a neutral facilitator (Training Manager) can possible help.

No learning and the same mistakes will be made…… over and over again?

How to fix government IT projects

Computer Weekly went out of its way in this weeks leader column to praise the out going Government’s CIO Ian Watmore suggesting “he is like a cool breeze entering a hot stuffy room”. They talk about his “plain speaking, lack of fear when taking sensible risks. More than that he is open about past mistakes, analyses them, and tries to apply what he has learnt from them”.

Computer Weekly expands on the Leader with a 2 page article saying that Watmore gave MP’s the most credible account of what is wrong with public sector IT, what needs to be done and how innovation can be stimulated.

So, what did Watmore suggest or say:

• he put the differences between the public and private sectors simply; “the government has too many initiatives”

• he suggested that Gateway Reviews should be published (something long advocated by Computer Weekly)

• departments are wasting money. How? By hiring consultants “to say things civil servants don’t want to say”

• the government are keeping alive failing projects too long when they could be stopped earlier and cheaply

• keep people in their roles for longer. He does realise, though, that few people will stay for 5 or 6 years - the duration of some projects. He did suggest a better way of grooming successors

• to stop projects from failing Watmore suggested having them run by experienced people who have made mistakes, and have recognised where these mistakes have been made

• he also suggested the government has had its fingers burnt by making policy announcements without understanding the problems of implementation

Continue reading ‘How to fix government IT projects’

Annual report on projects

Every quarter I schedule a ‘clear out day’. I go through all my files and throw away (actually recycle) those papers that are no longer required or relevant.

While going through one file labelled articles I stopped. I re-read one article and thought; this is too good to throw away!

It was written by Marc Mardell (it was a Blog in ecademy) and it is far too valuable to throw away, it needs sharing with others.

I think will stretch many organisations. In his article called An Annual Report on Projects. He asks an important question:

“Big government projects are scrutinised so why not those in big business”. He goes on to say:

“To what degree are projects in big business scrutinised i.e. how do we actually know that projects within big business are any more successful (by time, quality, cost) than in government?”

He further suggests in the article:

 would it be positive if in fact all businesses had to publish some audited project information as part of its annual accounts?

 having figures will give the company some comparative figures across industries

He goes onto ask:

“I wonder how many Blue Chip executives could lay their hands on (project) metrics for their business?”

Pretty revolutionary stuff!!

Companies can hide behind their annual reports however readers of this blog will know of projects that are way off delivery date, over budget or will not meet client requirements.

Who pays? As consumers, we all pay in the end!

Do read this article, it makes fascinating reading

Those Olympic estimates will not go away

The row about the cost of the 2012 Olympic Games goes on. Today a report by the Public Accounts Committee (click here for the full 40 page report) criticises the government for the escalating costs of the games.

Costs have risen from a bid price of just over £4 billion to a revised estimate (March 2008) of £9.325 billion! Now my guess is that the arguments around the true cost of the games will continue for many years up to and beyond the games themselves.

I am not going to try and argue which side is correct or who made big errors, if any have been made, I want to use this as an example of what can happen if your estimates are wrong - time, money or resources.

We work with many professional staff who in their words estimate poorly or use guestimates. So what can be done to ensure you have more accurate estimates?

*break it down - on our courses we stress the need to break down the overall project into manageable chunks. We encourage people to use work breakdown or product breakdown techniques. If you are going to put estimates against an activity the activity needs to be small enough to put an estimate against e.g. if you are carrying out all of the administration for a conference it is easier to estimate how long it will take to hire 4 projectors compared to organising the whole conference.

*who has the skills to provide you with the knowledge of what is involved in the project and how long each task will take. Use financial experts to help you identify the financial estimates.

*you are not alone - sometimes you are working on a project which someone within your organisation has worked on before. Ask them how long the project took. Ask them for the work breakdown; look at the cost estimates and actuals.

*documentation - the above point highlights the need for project documentation. Keep up to date records

*post project review and project meetings including lessons learned reports - these should include the level of accuracy of your estimates (of all your estimates - money, time, resources), what you have learned while working on the project. Share this information with others.

Make sure you spend more time estimating. Avoid the poor publicity or the consequences of spending too much money, delivering late with the wrong results.