Tuesday, 5 March 2013
The best thing about it though, is the difference it's made at work. Only had a couple of opportunities to apply the techniques so far, but it's powerful stuff. I've done two requirements interviews and one mini-workshop so far, and it's been great. People are so grateful that someone has come to speak to them, and not only that, the person is listening to them, and has a real conversation about their requirements for things.
It's a real 'win-win' because I get to reduce the risk to my projects and the staff get listened to and get their views heard. I'm confident that I did things before pretty well, but the new techniques are much better.
Now I'm looking forward to doing a bit more process mapping, swim lanes, use cases, and requirements cataloguing, and seeing how it improves how the projects work. Let me know if you've had any success with the same.
It's really simple, all you have to do is:
- Start with a fully shuffled pack of cards, face down
- The clock starts when you pick the cards up
- Sort cards into suits red, black, red, black
- Each suit needs sorted into ascending order, starting with the Ace and ending with the Jack, Queen and King.
- One joker needs to be on the top of the pile and one at the bottom.
- The clock stops when the cards are placed back on the table, sorted correctly, face up.
You may use any method to sort the cards out, but you must try and complete the sort as quickly as possible. I'm really interested in how you complete the task, as well as how long it takes, so you need to film the sorting and post it on YouTube or similar for the timing to count.
Tuesday, 15 January 2013
It's not that I don't want to work either. I'm happy to put in a solid days work at the kitchen table, doing most of my work by phone and on the mobile device.
So what is it that makes me want to avoid getting out of the house and to the office?
It started off as me not wanting to get up and iron my shirt. The front room is so cold in the morning and the bed is so warm.
So I started ironing my shirts in bulk and removed that blocker. No excuse now, just roll a shirt up, stick it in the bag and go!
Except that I'm still reluctant to get out of bed.
Perhaps it was the cup of tea that just had to be made and drunk prior to leaving the house. Or could it be the bowl of cereal that needed to be savoured? Perhaps it could be the second bowl...after all, cyclists do need extra energy.
So I dumped those too and I just get up and go. So do I feel better when I just rush out of the house without those things? Probably not, but I do manage to get out of the house. I certainly feel better once I've achieved my goal!
This is like anything that needs to be achieved in life. There will always be things that get in the way of us achieving our goals, whether those goals are getting out of bed or becoming Prime Minister. You just need to work at removing or reducing the barriers to success.
Friday, 14 December 2012
I guess this comment comes from the team meeting where a colleague had been looking for training/guidance on completing job applications and so had found himself on a shortlisting course. He felt that this was inappropriate for his needs. I disagreed, because by understanding how the shortlisting is done, you can learn how to write better applications.
There are plenty of opportunities for informal training out there. Many people don't seem to see this and are losing out. It's not too difficult unless you don't want to learn. For example, I spend a fair amount of time writing stuff because I realised that I'd become inflexible in my writing.
There are loads of opportunities out there to sharpen your axe. Don't waste 'em!
Thursday, 13 December 2012
So I went along out of curiosity.
The meeting was more of a workshop, run by Graham Oakes (@GrahamDOakes) who is a PMO consultant.
The scenario was that we were a team leading a review, and were given an hour to simulate a 3 day review. There were three briefing pages where we got an overview of the Organisation, the people and the project - and then we had to decide who we wanted to interview, what docs we needed, etc.
As soon as we started the simulation, the scenario was abundantly clear. ICT-driven development without user engagement. That old chestnut. So we ran through the thing requesting the Business Case, PID, Comms Plan (no Comms Plan) Risk Register, Benefits Case, etc. Each request yielded a card (or cards) prompting conversation and it was lively.
The project scenario was a real dog. It was sucking up time and effort from all PM resources, it was spiraling out of control and yet the risks, milestones and EV all would look normal to the PMO - unless the surface was scratched.
The interesting thing was that there was a really massive focus on 'is there a valid Business Case?' when it was obvious that even if delivered to time/cost/quality, it wasn't going to ever be accepted by the users, they'd clearly not been properly consulted and there was rumour in abundance.
One of the best comments I remember in for use in this case is "If you're trying to do change based on a user driven problem, speak to the users. If you're trying to do strategic change that is not user driven, speak to the users."
This is real wisdom. Users can make or break any change, whether it is emergent or strategic. If you work in HR and you believe that you can railroad change simply by changing policies, then you are sadly misled - because in this case your Organisation does not work how you think it does.
The truth is that people will be asked to do something and then they'll tend to optimize their own work. You need to reflect and support that. I always like to ask the question "If people here decided to work to rule, what would happen?" - would the place grind to a halt, or could you happily say "bring it on!"?
Sounds antagonistic, but there is a real basic truth in this. Do your processes fit the work, or do you expect people to follow broken processes? In the latter, I believe that your processes will not match the jobs being done. This means that people won't be able to understand how other departments work and how to relate to them or get things done.
So whether we get asked to solve a user problem, or a strategic one the key is to speak to users, find out what's actually being done at the moment, map the processes and then discover how we can change things and what users will accept in terms of change.
Then we can base change on that. But the business case will be much easier to write because we really understand the 'as is' and the 'to be' situations. We can easily articulate the problem and the situation because we actually know what the problem and the solution is!
I was explaining this to someone the other day and they asked me about a project they were working on "So where did this problem come from?" Ultimately the problem in question was strategic, but to choose the right solution they need to find out what the users need and will accept. This obviously takes longer than thrusting change on people, but actually takes less time overall and is more successful because (as Covey said) we "start with the end in mind" - i.e. what does a successful outcome look like, and who will use the products that people produce?
So, back to the PMO workshop. Brilliant and very thought provoking. Thanks to Graham for developing and facilitating the session, to Lindsay Scott (@projectmgmt) for arranging it, and to MMU for hosting it in their fantastic new Business School building.
Friday, 23 November 2012
Then I see that person sitting around and I think "Why don't you spend this time doing something more productive?" This apathy or lack of ability to move forward is like a sickness. The more you do it, the less able you become. Once you break the cycle and get productive, it becomes a great buzz to achieve those things that you were putting off.
Those of you who know me, know that I was in a Mountain Rescue (MR) Team. I learned a load from doing that, but one big thing was overcoming the inertia of apathy.
When you stepped out on the hill, you knew that your feet were going to get soaked, which was both wet and cold - totally horrible. But it was going to happen anyway, so better to get it over with and get them wet as soon as possible so at least your feet could warm the water up.
Apathy at work is like that. The more you put things off, the more difficult they become to get going. How many jobs have we put off at work or at home. It becomes like a joke that they've not been done!
One of my first jobs when I left college was to work in a telesales office. You knew that you were going to get shouted at, but you had a target to meet, so you just needed to accept that, take a deep breath and get started. After a few calls, you'd be 'in the zone' and the day would fly by.
So why can't people seem to get over this apathy barrier? My only guess is that they don't want to. Why?
I believe that most people want to do a great job. Give them a task and empower them and they'll get on with it without the need to micromanage. Tell them when they're doing well (when they are) and challenge unacceptable performance.
You'll always get people dumped on projects, but how well you motivate them is up to you!
Sunday, 7 October 2012
My feeling is that Britain is great, but we shouldn't see those who disagree with change as being wrong or somehow un-patriotic. No-one likes change when it affects their 'back yard' in a negative way. But what about when the change is in someone else's back yard? Are we quite as sensitive in that case?
As people involved in projects, we need to be sympathetic to people's needs. People who are affected by HS2, extra runways, nuclear power stations, etc are all entitled to their views and they should be listened to as stakeholders. There are always ways to ensure as many people are on side as possible.
We also need to consider - are we doing the right thing in the first place? There is often the biased view that what we're doing is right, even though sometimes it isn't. We may even have nagging doubts about if we're really doing good.
So, as change begins at home...what am I going to do about it? Well, I am already on my way in terms of this. I always consult the customer widely on proposed changes, but I also sell the concept of Business Analysis at all levels. This means that I seek to look at the existing process and find out how to improve it using the customer input.
What about massive changes? Well, I think that changes like that have to be approached collaboratively and I also think there is usually a middle ground between the two extremes - it's usually just a case of trying a little bit harder to actually find a practical solution that suits everyone.
Tuesday, 2 October 2012
That person is definitely in the wrong job. Don't get me wrong, I don't spend all weekend wishing that it was Monday, but I certainly don't wish the week away. I'm usually so busy that the week goes by in a flash!!
I'm constantly thinking "how can I deliver more for the organisation?", whereas I've noticed that some people seem great at telling others what they're planning on doing, but never delivering on those promises.
I'm amazed at the lengths people will go to, in order to make excuses about not delivering. It's like the old joke excuse 'the dog ate my homework'. My ex and I used to say 'random excuse #654' when we just couldn't be bothered, suggesting that we couldn't even be bothered to make up an excuse.
Friday, 7 September 2012
I just thought that I'd update to let people who may follow this blog, that the MSc Dissertation is completed and submitted!! If you helped me by completing a questionnaire, or forwarded it to others to complete...many thanks for your help!!
It's been an interesting process, and I've learned a lot during the last 6 months of writing and reading for the final assignment.
A few people have asked me to post the results, and I plan to do that once I've got the marks - wouldn't want to feed you the wrong information! There are some really good tips, probably common sense to most of you out there, but they represent the main things that you need to keep on top of and I will post that as soon as I know that it's all OK.
Tuesday, 28 August 2012
Wednesday, 15 August 2012
Many thanks to those who completed the survey fully!!
I'll post results once I've got all the data loaded up into the database, analysed it and completed the dissertation. Not sure yet whether the results will prove anything of statistical relevance, but if not there are still some excellent opportunities to pick up some good practice from others in the industry.
Overall, I hope other PM's, (especially new ones) will be able to learn something useful from the answers that some of the more experienced people gave.
Tuesday, 24 July 2012
There are some really good answers - not just half-completed or empty responses.
The issues are really not much more than what I originally thought. I think that it's going to break down pretty much as I expected, but it's still important to ask. The process is totally worthwhile, as it gives the users a voice and encourages them to get involved.
The moment that I think that I don't need to consult users, please direct me right back to this post!!
Tuesday, 19 June 2012
Once I've done some analysis on the results, I will post the results on this blog.
If you've done a partial completion, please take the time to go back and complete the answers fully, as I need the full picture from you in order to ensure that I can actually get something useful from the survey.
As I promised, fully answered questionnaires will be entered into a prize draw for a £30 Amazon voucher, but you have to complete the survey fully to be eligible!!
There are some interesting results so far, and I am hoping that the analysis will uncover some really exciting points. I have already thought of some ways in which I may be able to improve the survey, such as country where the PM works, and putting the e-mail address at the end of the survey - but unfortunately I can't edit a survey that's currently running without losing all the data!!
I might also change the 'fail modes' section to 'check-box' quantitative-type questions, but I didn't want to bias the results by giving a limited number of options for people to tick off. By leaving the advanced questions as qualitative, open-ended questions, it gives people a chance to give their own answers, and not be biased by mine.
I was also surprised that someone ripped off some of the questions from my survey and posted them in the APM group. The funny thing is that the perpetrator wasn't doing it to help me, and he wasn't helping other PM's, students, academia, or even himself, as there is no way of drawing anything further out of the answers except the respondee's opinion - no way of discovering how the answers link to the level of experience, risk, age, sector, industry, professional body, qualifications, etc. Normally, I wouldn't respond to the challenge, but I felt that I had to post a response because the guy was risking biasing my entire MSc work. On the whole, a bit of a nightmare!! I will need to have a look and see if there's any element of 'groupthink' after the time when the guy posted the questions, and also have a look at what the responses from group members are.
Anyhow, as usual...many thanks for reading!!
Monday, 18 June 2012
I'll publish the results here once I've got enough responses and I've had chance to analyse the results!!
Thursday, 23 February 2012
We follow these principles:
Saturday, 18 February 2012
There was a great deal of discussion about the benefit of virtual teams, i.e. how wonderful they are, all the benefits of them, etc. People were suggesting things like "you can have 24/7 production". Well, that may be true, but that is not really an argument for virtual teams and outsourcing.
The reality is that virtual teams and outsourcing is good if you are only bothered about the cost of the item that you're producing. Everything else is a disadvantage, re-framed as a "cool feature". For example, videoconferencing as a benefit. It's a benefit if you or your organisation has outsourced production somewhere else, but if you're just on one site, then it's unnecessary! What I'm saying is that by trying to save money in production, you've shifted the cost (and problems) to somewhere else, i.e. having to get around the issue that people are spread across multiple sites and timezones.
That's not to say that if you are a global organisation, you shouldn't do things like that. All your programming talent may be in India, or wherever and you want to utilise their skills instead of using staff locally. Or maybe you have a PM who is only available in another country or location. I understand that. But perhaps you should just produce the product in one place? I just don't really see that virtual teams are really that much of a benefit apart from an attempt to reduce cost.
Perhaps I've missed something though, so I would welcome your input/discussion of this. You can either reply here, or on Twitter to @jugglingsand
Thursday, 22 September 2011
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!)
Sunday, 4 September 2011
Wednesday, 13 July 2011
Tuesday, 17 May 2011
Friday, 22 April 2011
Tuesday, 19 April 2011
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.
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
Friday, 25 February 2011
Thursday, 10 February 2011
Monday, 7 February 2011
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 10.2.2.4
- APM BoK 6.5
- APM BoK 6.6
- 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)
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] 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