Thursday, 22 September 2011

How do you juggle sand?

I was just chatting to someone who asked me how to go about juggling sand.

Juggling sand is really like project management, if you spend some time planning how to do it, think laterally, and have a little experience in the subject area, then it is quite achievable!

I'm not going to explain how I would juggle sand for the moment - like projects, there are a variety of ways of achieving your aims...I know how I would do it, but perhaps there are some suggestions from readers out there? ;-)

(Update 18Feb12 - Just so that people don't think that I don't know how to achieve this, I would mix the sand with water and freeze it so that the sand is solid, and then juggle it!)

Wednesday, 13 July 2011

Can you project manage a baby?

I recently became a father for the first time. (or as I recently said to a colleague "I was given line management responsibilities for a baby")

As a project manager, I wondered if you can "project manage a baby".

We did a pretty good job of preparing the things that needed to be prepared and making sure that we knew if we were having a boy or a girl – no blue outfits for girls in our house!!  I also arranged a pretty good baby shower for my partner and her friends.

After the baby was born, it was a different matter.  I hadn’t quite fully grasped, is that babies are “drum resources” and that you have to completely fit your life around them.  Before becoming a parent, my only experience of looking after children was when I looked after my niece.  We could hand her back at the end of the day and that was the part of being a parent that was the biggest shock.

I started the “project” by researching lessons learned by other people.  Colleagues and friends were invaluable in this respect, but I firmly believed that it wouldn’t be possible to manage the culture shock of having a newly born baby in the house, so we didn’t do very much to prepare for the sleepless nights and just kept reminding ourselves that the importance was to be flexible and open to the changes.  This is very much like an Agile project – you can’t 100% know what’s required, so you accept that you won’t get it right in the first instance.  You have to plan that the project is a journey where you have to learn and refine things as you go along.

You can easily manage resources being delivered “to site” before you need them, although having stocks of things that are too large seems to be a bit of a mistake.  I never thought that she’d have gone from newborn sizes to 0-3 months and from size one nappies to size two in 14 days, but she did!  I recently went to watch cars being manufactured at Jaguar/LandRover and I wholeheartedly believe that the “just in time” approach which is being applied to vehicle manufacturing there would work equally well with a baby.  Luckily, they don’t have to change the wheels every two weeks because the hubs have grown!

I learned a massive lesson about the importance of being patient.  I mean, I thought that I was patient, but I realized quickly that what I thought was patience, was just a thin veneer of patience over the top of a core of pure selfishness.  It’s not the same as with a partner, where you can both take it in turns to be selfish – you have to really pull together as a team.  If you don’t do that, and act in a selfless manner then the baby will suffer and that’s not good.  Putting the needs of others above yourself is really difficult to do, but it helps that the baby is a vested interest.  The closest thing to the experience was being a member of a mountain rescue team, in the way that it was charitable, you often got woken up in the middle of the night by a wailing noise (pager) and you knew that the reason for having to get up was usually more important than your sleep.

I also learned the true value of communication difficulty.  Without the ability to communicate properly, the baby will just cry to signal that there’s something wrong.  It’s like having a car dashboard with no gauges, speedometer, rev counter but only one warning light that signals a problem, but has no symbol.  You have to work out what’s wrong yourself, and this makes things very complicated at the beginning, when you can find yourself muttering “come on, help me out here” to the screaming child.

This makes the baby very much like user politics.  Users will often complain/take issue about one thing, when they really have an entirely different issue at heart.  Luckily, the baby is only motivated by food, toilet, hugs and sleep at the moment, so everything else that might be wrong seems to fit within those headings.  I look forward to being able to develop a process for looking after babies.

So, can you project manage a baby?  Once you accept that control is an illusion, you can happily say “yes”.

Tuesday, 17 May 2011

Lessons learned (cont'd)

I went to a seminar today, and one of the other people mentioned that we didn't share Lessons Learned properly. As you'll have seen from some of my older posts, sharing Lessons is something that I'm quite keen on.

I'm determined to take this forward, so I'm going to develop a "Lessons Learned Network" within our organisation.

Friday, 22 April 2011

2 years experience required

I was just in a teashop today and saw that they were advertising for staff.

The advert specified "2 years waiter/waitress experience minimum". This led to an interesting discussion over lunch about what you'd have learned during those 2 years of experience.

As I am a bit of a process freak, I quickly summarised it into the following:

Greet and seat customers
Hand menu to customer, say you'll come and take their order in a couple of minutes
Return, ask customers if they're ready to order
Write down order on pad, take note of table number
Take order to kitchen
When food/drinks are ready, compare items with order, then take items to table if correct
Return after a couple of minutes, ask customers if everything is OK
When customers have finished, ask if they'd like anything else
Clear table, take used pots to the kitchen
Prepare bill
Process payment
Wipe table
Reset table for next customers
Repeat until closing time

I reckon that you could hone it further, but that's just my initial take on the concept.

The rest of the learning has got to be more complicated than that, I'm sure, but I don't think that it's particularly difficult to make tea and coffee and put buns onto plates. God only knows what people are like at home if they can't manage that sort of thing.

Anyhow, I'll give you 5 minutes to memorise the routine and then you can say that you're fully trained. Don't forget to smile and be friendly as though you want to work there...

Tuesday, 19 April 2011


I'm sure that I am not alone when I admit to you that I procrastinate from time to time.

I was at work today when a colleague asked how I keep myself motivated. Well, the short answer is that sometimes...I don't! Thankfully those times are few and far between, but I firmly believe that "you need to know when to surf and when to wax your board". Some days it won't all come together and some days it'll all flow along like a dream.

The wonderful Brian Tracy describes it as "Eating the frog" - basically about picking off the biggest and most horrible tasks first and then doing the smaller ones that you'd really prefer to do last. Most people fill up a little too much of their day by doing the smaller tasks first, which means that they have to leave the bigger ones until tomorrow because they've not enough time to complete them today. Classic procrastination!

I was at a but of a loose end today, no meetings or places to be - and for times like that there is nothing better than having a location specific to-do list. I hammered away at a few "frog eating" tasks that I'd been meaning to do for a while, but had put them off and was starting to feel a bit bad about not completing them. After a couple of items, I noticed that I'd started feeling really good about the effectiveness of the day.

By the end of the day, I'd done about 10 things that I'd been putting off for ages and you can imagine how great that feels. I was in such a good mood that the next day I came into work fired up to do the same all over again.

So, next time you are at a loose end, think of the positive feeling that you'll get by crossing off a few of your worst tasks, take a deep breath and then just crack on with them!!

Thursday, 3 March 2011


The Institute for Government published a report today called "System+Error", which basically highlighted that government IT should be commoditised where possible, and IT projects should be run with an Agile approach.


I imagine that this will result in a raft of cash being spent on Agile training and people blathering on about how bad PRINCE2 is. The bottom line is that for successful IT, you have to understand the needs of the user. You have to accept that you also cannot fully know what the users want, but this isn't because you are an idiot - it's because the users do not know themselves.

It is obvious (to me, anyway) that IT projects should be run in an iteratively developed manner, with close attention to the user feedback. It totally makes sense - why deliver what isn't needed, requested or whatever, just because you think it's a good idea.

If you're sitting there in the private sector, thinking that this issue is just a public sector thing, you have to know this basic information:

IT spending accounts for over 50% of capital spending - worldwide.
IT is not usually user-driven.
IT projects usually fail (CHAOS/ComputerWeek)
IT projects focus on IT delivery and not organisational change. (HL Markus, 2007)
Late adopters usually spend less on IT, but get the same out of the process.
Project alignment is usually done badly. (Hartman and Skulmoski, 2000)
No-one observes lessons learned properly. (Sawyer, 2011)

So basically, what I'm saying is that almost ALL IT change comes as speculative change from within IT, not from the user community and that is utterly wrong.

To fix it, you need to go to the users, (not the user's managers) speak to them and really find out what they think they need. Then you go to the firm (and the internet) to see if there are any lessons learned or case studies out there to inform you. (Hint: there are loads) Then you give them the basics of a system and develop it (using COTS where possible) over a short period of time with a target group, honing the requirement as closely as possible. Once they're happy, you can roll it out further, but you have to realise that the listening and development needs to continue.

You also need to heed Markus' warnings that you need to embed the change within the organisation by ensuring that training, benefits and reward packages and generally 'the whole kit and caboodle' lines up to give the maximum chance of people actually using the system in the way it was intended.

I'm more than happy to discuss this, and please feel free to disagree!

Friday, 25 February 2011

Organisational change and transition

Change is difficult to get right.

In my MSc class today, we were asked to work on a case study to amalgamate two offices.

It was interesting to see how complicated people made the whole thing. Multiple communication techniques and strategies, loops, groups, etc - arrows everywhere!!

As someone who has been involved in moving people to different locations and merging functions, I found the best thing to do was to keep it all very simple, open and honest.

I focussed on the idea of trying to get everyone together, briefing them together, (briefing from the "big boss" about the grand vision) then breaking up into small groups to discuss strengths, weaknesses, opportunities and threats - then collating the ideas so that they could be fed back into the centre.

From there, it was about picking the best ideas, communication of the way forward and dealing with threats to the project. Obviously there will be people who think that this is a bit of utopian view, but it does work well in practice.

Thursday, 10 February 2011


Another mentor meeting today, great to chat to another PM within the organisation who fully understands the in's and out's of our business.

We had a chat about some PM gripes and I got some really useful advice on how to progress the issues involved.

We also discussed some of the MSc work that i've been doing and I agreed to send copies. It's really promising as the relationship is working both ways, showing that the MSc is paying off in the real world.

I also got a chance to have my project measured up against OGC gateway 0 (my mentor is an experienced assessor) and was pleased to see that there was nothing to worry about. Another really positive day!!

Monday, 7 February 2011

Lessons learned about 'lessons learned'

At the 2010 APM conference, Sir Peter Gershon stated that public sector projects “do not fail for novel reasons, they fail for the same boringly repetitive reasons”. (APM Project magazine, Nov/Dec 2010: Pg 4)

As the previous head of the Office for Government Commerce (OGC) and a current board member of the government’s Efficiency Reform Group (ERG), Gershon is a leading figure relating to projects within the UK. As the comments relate to public sector projects, I will use details of the OGC’s PRINCE2 framework where possible to illustrate some of the issues.

It is frequently reported that 70% of projects fail. (Standish Group, 1995) Although the measure of success or failure is highly debatable, it is undoubtedly the case that projects frequently fail to deliver the promised benefits.

Why is the lessons learned process so important?

It is important to learn lessons from previous failures so that improvements can be made. When lessons are really learned and shared, issues do not continually re-occur.

Kolb’s study (1984) suggests that in order to learn, we gain experience by testing concepts that we have learned, reflect on them and then form further concepts, based on those reflections. In project terms, we would be recording issues, solving problems, observing the effectiveness of the solution and then recording results in the lessons learned log. This would then be shared with others as the lessons learned report. The explicit knowledge of the report should work both ways – learning from previous projects and feeding into future ones.

For this reason, it is suggested that more attention be paid to the lessons learned process during projects.

PRINCE2:2005 (OGC, 2005 p162) states that:

“Successful organisations learn from their experiences with projects. This is more likely if the lessons learned are somehow preserved beyond the end of the project”

This suggests that if an organisation wants to improve their project success rate, they should learn from their own experiences and the experiences of other organisations. Putting this into practice would be likely to show as a reduction of project failure over the course of time. (Kotnour, 2000)

If project managers and organisations learn from their mistakes, then why do the failure rates remain high, and people like Sir Peter Gershon suggest that lessons are not being learned? It would seem that the simple answer is that those important lessons are not being learned at all.


The Association for Project Management (APM) is the professional body for project managers in the UK. The APM Professional Code of Practice states:

“2.2…Professionalism is demonstrable awareness and application of competencies and qualities, including knowledge, and appropriate skills.” (APM, 2009)


“4.1 Members shall exercise relevant competence in accordance with the association’s professional standards and qualifications, as underpinned by the APM Body of Knowledge…” (APM, 2009)

This suggests that APM members should follow the best practice techniques contained within APM’s Body of Knowledge.

Lessons Learned are covered within APM’s Body of Knowledge (BoK) in section 6.6: Project Reviews, setting out the aims of a review as:

“Establish lessons learned and actions arising from them” (APM, 2006: p96)


“Raise any concerns and agree corrective actions” (APM, 2006: p96)

So it is established that in order to comply with APM’s guidance, project managers should carry out the lessons learned exercise throughout the project and during the closure process.

The purpose of this is to allow learning within the project - “intra-project learning” and also to pass the knowledge on to others at the end of the project - “inter-project learning” (Kotnour, 2000)

This improves the quality of work and avoids re-occurrence of the same mistakes. An added benefit is that it also improves the reputation of the project manager in the eyes of management, the customer and the project team.

Use of frameworks, such as OGC’s PRINCE2

APM is not alone in its suggestion to follow a regime of constant improvement. Most other guidance and frameworks also suggest that the lessons learned process should be carried out.

Most frameworks come from “best practice”, designed and written by professionals and academics to address project issues and common areas of poor performance – so it is useful to follow a framework which allows a common structure, language and repeatability to be brought to the process.

Examples of some commonly used frameworks (and their reference to lessons learned) are shown below:


- P2 10.6.1 & 10.6.2

- P2 CP3, Closing a project

- P2 A16 Lessons learned log

- P2 A17 Lessons learned report


- A guide to the Project Management Body of Knowledge (PMBoK), section


- APM BoK 6.5

- APM BoK 6.6

HM Treasury

- Green Book Section 7, Evaluation

Many organisations use PRINCE2 as their project framework. PRINCE2 was developed by the UK government for use on public sector projects, but is free for anyone who wishes to use it.

As an example, PRINCE2 (OGC, 2005) suggests that a log (product A16, lessons learned log) should be kept during the project and compiled as a report (product A17, lessons learned report) to be shared with the organisation at the end of the project. Following Kolb (1984) it is clear that PRINCE2 should mandate practitioners to seek out previous lessons learned at the beginning of a new project, but this is not specified in PRINCE2. This is felt to be in some part because PRINCE2 treats projects in isolation and not as individual projects, which are part of a programme or portfolio. (Aspire Europe, 2000)

One of the problems often encountered is that the lessons learned log is not completed or updated, leading to a lack of evidence to feed the lessons learned report. Even with the relevant evidence (and supportive management) it is quite difficult and time-consuming to write a detailed lessons learned report, get it signed off by senior management and circulated. In many cases, the management and PM will be keen to get onto the next project, so the report will be neglected and eventually abandoned before completion.

Many people dislike the use of project frameworks, as they like to have freedom from restrictions and like to believe that they know best. Despite this, it is clear that project frameworks are capable of providing many benefits to project organisations.

From experience, there seem to be two cores of people who do not learn from their mistakes. Firstly, there are those who are ignorant, with a lack of understanding of the benefits. Secondly, there are those who are aware, but do not track the lessons and report on them. (Aspire Europe, 2000)

View of LL – Organisation

For an organisation to be successful, it is important that it has the correct staff, structure and training at all levels. The organisation also needs to have the maturity and risk appetite to take on project work. Sometimes those risks will pay off and other times they will not. It is therefore important to assess what causes some projects to succeed and others to fail, then learn from those mistakes.

“The project Achilles heel: Misalignment” (Hartman and Skulmoski, 2000) suggested that for maximum chance of success, projects should be aligned with the organisation’s goals in relation to a number of factors:

- Project definition – what are we doing and why

- Critical success factors – determine what constitutes success

- Define key stakeholders and their requirements

- Alignment with corporate goals

- Follow a widely-known methodical process

- Project mission, goals, objectives and tactics

- Seek “win-win” solutions to problems

By correctly aligning the project, issues arising should be of minimal social and political complexity.

Lack of alignment suggests low project and organisational maturity and poor processes, which do not create a good environment for openness and learning. So, if lessons really are being learned, why is alignment still an issue? Experience suggests that the issues are usually caused by one of the reasons below:

- Lessons are not learned

- Lessons are not recorded

- Lessons are not analysed

- Lessons are not shared

- Lessons are learned but forgotten

The immature organisation also views mistakes as a threat, which encourages people to cover up the mistakes, rather than learning from the experience and also to avoid seeking advice from others, meaning that ‘the wheel’ has to be repeatedly re-invented.

View of lessons learned – Typical management comments

“Managing projects is the PM’s job, that’s why I pay them”

This is indeed true, but the PM needs visible support from the management team. Other staff and managers need to see that the project is important to the organisation and management supports it. This includes the processes behind it and any recommendations it may produce.

“I don’t want to know about what went wrong, it’s all solved now”

One of the important things is what caused the problem – why were they such a big issue? If these can be fixed so that they don’t happen in future, then it is likely that the organisation will improve and run smoother. Projects can fail for a variety of reasons - perhaps the project was badly aligned, or the PM did not know who to speak to in order to get things done. All these things can be learned and improved for the next project.

“I don’t have time to read this”

It is important that managers take time to read and understand lessons learned reports, as it can often provide an insight into underlying issues within the organisation. If you do read the report and think “I already know all this” then well done for having your finger on the pulse.

“I know what the PM’s weaknesses are, I’ve seen them in practice”

Some of the lessons learned will be about what the PM can improve and some of it will be about what they need in order to do their job more effectively and what impeded their progress. Perhaps some small changes could be made in order to improve things. If a PM is highlighting issues and learning from them, it shows a high maturity level which should be encouraged.

“We don’t make mistakes here”

Everyone makes mistakes! To admit those mistakes allows the organisation to explore why they occurred and how to prevent them. It is established that organisations who learn from their mistakes are far more successful than those who do not.

“All men make mistakes, but only a wise man learns from those mistakes” (Winston Churchill)

Lessons learned is an important part of learning, both within the project and to inform future projects and organisational behaviour.

“We’ve always done things this way and we’re not going to change now”

Just take a moment to consider how you would feel if, as a manager, an employee said this to you. Openness to change is critical to organisational success. Constant evolution helps to develop and maintain competitive advantage, keeping the company one step ahead. (Hansen and Nohria, 2004) Most good suggestions come from the customers or the “shop floor”.

View of lessons learned – Typical individual/PM comments

“Lessons learned is too time consuming to complete”

We do not have time to do things right, but we also often have to find time to do them twice! It may be slightly more time-consuming to keep a lessons learned log and write a report, but no-one says that you have to write a novel about it. It can easily be done as a table, or bullet-pointed.

The main advantage of doing this is that you will be able to inform subsequent projects with your learning, saving time in the future.

“Why should I help others? I had to learn the hard way” OR “Knowledge is power”

Indeed, but think of the benefits of being helped and how grateful you would have been if others had helped you! The Chinese have a saying “Help others to help me” which is based on the theory that if you help someone else, it eventually comes back round to you.

“learn to succeed; and, then give a hand to those still struggling to catch up” (Air Marshall Sir Reginald Harland, 1989)

If you help others where you can, it helps with your mental wellbeing and is advantageous to you as others will regard you as an “expert” or a “guru” in your field. There are many people who have built their businesses on this principle of their “expert power”, especially in the modern world of social networking and blogging.

“No point in doing lessons learned, the management don’t listen”

There are several reasons why you should do the lessons learned log and report, even if no-one else reads it:

- It shows that you have a high project maturity.

- It shows that you are willing to learn.

- It helps consistency.

- It helps you realise what improvements can be made.

- You can provide a copy of the report on request, or if you know that they’re starting a project.

- It may be more time-consuming than doing nothing, but it will help save time and effort in the long term.

- Finally, the APM mandates good practice in their code of conduct, and lessons learned is considered to be good practice in all frameworks and guides.

“If I highlight my weaknesses and errors, it will affect my career”

This is a lessons learned exercise, showing the issues and difficulties that you tackled. Whether you got it right first time, or would do it differently in future, you still have learned important lessons and this is important evidence of your maturity level. You may not fit into a company below this level, but they would not look good on your CV anyway.

“I might get some feedback that I don’t agree with”

Most people will be positive if you’re showing that you’re receptive and are learning. If they are not, it mostly reflects badly on them as they are demonstrating their own immaturity. Others do notice this sort of behaviour. Be prepared to give and receive feedback, but be aware that sometimes others like to be destructive.

Learning from mistakes

It is extremely important to be open about mistakes during projects and share the learning points as widely as possible so others do not repeat those mistakes. The project professional is encouraged to do this by keeping a log during the project (PRINCE2 document A16) and then to produce out a thorough analysis in the lessons learned report (PRINCE2 document A17). PRINCE2 also advocates the sharing of this knowledge with “interested parties” (OGC PRINCE2, 2005: p164) as part of process DP5.

There are many ways in which the learning can be shared, but the following methods are popular:

- lessons learned reports

- presentations to the organisation and others

- advice/guidance – Anecdotal stories/examples (Amtoft, 1994)

- papers/blogs/wikis

PRINCE2 suggests the content and structure of the report, although there is no compulsion to follow a set format, or even carry it out at all. The optional nature of various processes may be more of a limitation than a benefit, as people can claim to use the PRINCE2 methodology, but then allows them to avoid carrying out many of the most useful processes. Turner (2010), refers to this as PRINCE In Name Only (PINO).

Adoption of lessons learned can be improved by having top-level support (Young, 2008) which understands project methodology and encourages the learning experience at all levels of the organisation. (Kotnour, 2000)

Why don’t people improve?

Often, people don’t improve for a number of reasons. They may not know that anything needs to change. If there is no review process or feedback, then there will be limited opportunity to improve. Others will receive poor feedback and shut down to the whole opportunity.

In the case of an immature organisation, there is no incentive to learn. Fear of criticism is a powerful motivation to hide mistakes and avoid exploring new methods of working.

Conclusion - Lessons Learned about Lessons Learned

Start by research to see if the learning already exists

A few hours searching for existing lessons learned will pay dividends.

“…it is no good learning only from one’s own mistakes, no matter how many are made. Learn how not to make mistakes by learning from others – what they have done right and wrong, and how those ‘lessons’ might be affected by changes in circumstances” (Air Marshall Sir Reginald Harland, 1989)

It is very rare that we are inventing the wheel. Even projects to develop innovative products will have their roots and learning set in the past. (Kozak-Holland, 2005)

Follow a methodology

Tailor whatever methodology you decide to use by depth, rather than by missing out any of the processes. PRINCE2 is scalable, but many people interpret this as being able to carry out the process in an incomplete manner. Ensure that others within the organisation know which methodology is being used, so that they can work in with the system.

Accept that lessons learned is a useful and necessary exercise

It is undoubted that carrying out the lessons learned process is a useful exercise, even if it is carried out privately and not shared with others. Where the process really excels, is to get people thinking and talking, to improve the way things are done. For that reason, it is important to share the report with others within the organisation (Kotnour, 2000).

Compile the log throughout the project

It is important that the log is compiled throughout the project, otherwise useful lessons may be written off as trivial and not recorded. The obvious disadvantage of solving problems and not recording the method or outcome is that only one person learns from the experience. It is also the case that these problems may not be dealt with effectively in the future and this causes waste and perhaps even organisational failure.

Recording the issues also demonstrates that even senior PM’s have difficulties, although the way that they deal with them is undoubtedly different than how a junior PM would.

Learn and apply as you are going along

It is important that the project is a continuous learning environment, rather than seeing the issues but only tackling them at the end of the project.

Development is rarely successful if done by ambush and it will look much better in the lessons learned report to document project issues that were identified and tackled during the project and proven to have been successfully fixed.

Discuss and agree contents of the report with management

As previously mentioned, the lessons learned report should not come as a surprise to anyone. The contents should be discussed and agreed first with the senior management team and should be written in a positive, constructive manner. Any attempts at destructive criticism or politics will almost certainly be met with a closed, defensive response.

Be honest but constructive

It will often be the case that staff performance issues need to be dealt with during a project. This should be done in a private and constructive manner, focussing on the unwanted behaviour rather than the person who is exhibiting the behaviour. (Metzger, 2002)

If this is not carried out, the behaviour may deteriorate further, spread to others and may even lead to official complaints about the PM or the team.

Circulate as widely as possible

Without circulation, the report will be of limited use to others within the organisation. As previously stated, “successful organisations learn from their experiences from projects” (OGC PRINCE2, 2005: p162) and failing to share this learning misses an important opportunity.

Many organisations have intranets or wikis where the information can be published. If possible, the information should be suitably sanitised and shared internally and externally, so that the community as a whole can benefit. Blogs and journals are an ideal place to demonstrate this learning process and the associated lessons learned.


Amtoft, M. (1994) ‘Storytelling as a support tool for project management’ International Journal of Project Management, Vol. 12, no. 4, pp. 230-233

Aspire Europe Ltd (2009) Why are lessons learned never learned. [Online] [Accessed on 5th January 2011]

Association for Project Management (2006) APM Body of Knowledge. 5th ed., Princes Risborough: Association for Project Management.

Association for Project Management. (2009) APM Code of Professional Conduct. Princes Risborough, Buckinghamshire. [Online] [Accessed on 5th November 2010] Available from

Association for Project Management (2010) ‘Time to deliver on project success, government advider tells conference.’ Project Magazine. November 2010. P. 4

Book of Famous Quotes. (2010) “All men make mistakes, but only a wise man learns from those mistakes – Winston Churchill” [Online] [Accessed on 8th Jan 2011]

Harland, R. E. (1989) ‘Training project managers in the UK’ Project Management, Vol. 7, no. 4, pp. 197-198

Hansen, M., and Nohria, N. (2004) ‘How to build collaborative advantage’ MIT Sloan Management Review, Vol. 46, no. 1, pp. 22-30

Hartman, F. and Skulmoski, G. (2000) ‘The project Achilles heel: Misalignment’ Cost Engineering, Vol. 42, no. 12, pp. 33-37

Kolb, D. (1984) ‘Experiential learning: Experience as the source of learning and development’ New Jersey: Prentice Hall.

Kotnour, T. (2000) ‘Organisational learning practices in the project management environment’ International Journal of Quality and Reliability Management, Vol. 17, no. 4/5, pp. 393-406

Kozak-Holland, M. (2004) ‘Lessons from history: Titanic lessons for IT projects’ 1st ed., Oshawa, Ontario: Multi-media Publications Inc.

Metzger, M. (2002) ‘Learning to Discipline’ Phi Delta Kappan, Vol. 84, no. 1, pp. 77-84

Office of Government Commerce. (2005) Managing Successful Projects with PRINCE2. 4th ed., Norwich: The Stationery Office.

The Standish Group. (1995) The Chaos Report. Northampton: Project Smart [Online] [Accessed on 5th January 2011] Available from:

Turner, J., Huemann, M., Anbari, F. and Bredillet, C. (2010) Perspectives in Projects. Abingdon, Oxon: Routledge.

Young, R. and Jordan, E. (2008) ‘Top management support: Mantra or necessity’ International Journal of Project Management, Vol. 26, no. 7, pp. 713-725