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

Mentoring

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.


Professionalism

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)

and

“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)

and

“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:

OGC PRINCE2

- P2 10.6.1 & 10.6.2

- P2 CP3, Closing a project

- P2 A16 Lessons learned log

- P2 A17 Lessons learned report

PMI

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

APM

- 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.


References:

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] http://www.aspireeurope.com/msp_prince2/?p=168

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 http://www.apm.org.uk/download.asp?fileID=1342

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] http://www.famous-quotes.com/topic.php?tid=773

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: http://www.projectsmart.co.uk/docs/chaos-report.pdf

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