I've just found out that i've passed the BCS Business Analysis Certificate. I'm really happy about this as it was four modules of applying the theories of process mapping, requirements capture/recording, process modelling and business theory to scenarios that are based on real businesses and real problems.
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.
Tuesday, 5 March 2013
Card game - "Card Sorting World Challenge"
I was recently on a course where we played a simple card game and I thought that you might like to try it.
It's really simple, all you have to do is:
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.
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
Dump the procrastinators
I've been lacking the motivation to get up recently. I'm not depressed or anything, it's just that the temptation of a warm bed often seems too good to leave on these cold winter mornings!
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.
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
Mr Course
Someone called me "Mr Course" yesterday. I must say that I prefer "Mr Self Improvement" though. You don't need to improve yourself by courses, although they can often help.
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!
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
PMO scenario
I went to my first PMOSIG meeting last night. I'm not employed in a PMO, but rather that I am ultimately governed by a PMO.
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.
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
MSc Outcome
Just got the MSc results, and I passed with a distinction!
If you helped by completing the questionnaire, I'd just like to say an extra-special thanks for your support.
If you helped by completing the questionnaire, I'd just like to say an extra-special thanks for your support.
Overcoming the apathy barrier
I often come across people who seem to take apathy to the next level, you know the kind...constant excuses for why things haven't been done, often more effort than doing the task in the first place.
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!
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
Change good?
Just watching a programme on TV about infrastructure projects. There was a clip on there of ex-Prime Minister Margaret Thatcher saying that people shouldn't moan about change, they should be celebrating change and saying how Great Britain is.
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.
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
Wrong wrong wrong wrong wrong
Overheard on the train on a Monday evening - "Yuk, it's only Monday. Another four days left to go"
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!!
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!!
Big effort?
What makes people into 'bigging themselves up' without delivering?
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.
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
MSc Dissertation Complete!!
Hi all!
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.
Thanks,
Dave.
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.
Thanks,
Dave.
Tuesday, 28 August 2012
MSc Questionnaire Prize Draw
I am pleased to announce that the MSc Questionnaire Prize Draw has now been run.
The winner was chosen by generating random numbers using MS Excel. The unique ID of the first person who had fully completed the survey won the draw, as per the draw rules.
Brian Goulding of Pygma Consulting, South Africa was the winner. After a brief e-mail exchange, Brian kindly asked that his prize be donated to benefit another PM student, so I am looking to donate a book (or books) to the value of £30 to the Manchester Metropolitan University Business School library.
Brian left the choice of books to me, so after some thought, I picked out two key books that have been particularly of use to me during my PM studies - Project Management by Dennis Lock, and Business Analysis by James Cadle (and others). I have contacted the university to find out how I can get an extra copy of one or both of these books into the library.
Once again, thanks to everyone who was involved in the questionnaire. Your contribution to my work was much appreciated. I will post results (and perhaps the full dissertation) on my blog once my MSc work has been submitted, marked and moderated.
Wednesday, 15 August 2012
MSc research
Well, the survey is now closed.
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.
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
The Big Survey
Just published my latest consultation survey at work. Got 35+ responses within an hour. Only three weeks left to go. Woohoo, I reckon that we should get at least 150 responses - which I think is not at all bad for this kind of thing!! I am so glad that people are getting involved with the work.
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!!
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
MSc Questionnaire
If you've arrived here after completing my MSc questionnaire, I would like to say a big "thank you" for your efforts.
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!!
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
Questionnaires for business
I seem to be creating quite a few questionnaires for business at the moment.
I'll publish the results here once I've got enough responses and I've had chance to analyse the results!!
Getting the most out of the participants is quite a skill, but I believe that I'm getting better with each piece of work that I carry out. Although I would say that I'm far from an expert, I really enjoy finding out what the users need and then working out how we can deliver that using a project.
Many projects don't have a very good User Requirement, or stakeholders haven't been fully engaged with prior to the project starting and this can have some major effects on the chance of success.
If you're reading this because you've recently completed my MSc research questionnaire, then many thanks for participating in my work. I would appreciate any comments which you have. On the other hand, if you haven't completed the survey yet, help me by completing it here:
***Link removed***
***Link removed***
I'll publish the results here once I've got enough responses and I've had chance to analyse the results!!
I've learned a lot during the last two years and plan to carry on a similar rate of learning as time goes on and I get to use the MSc learning more and more in my daily work.
Thursday, 23 February 2012
The Agile Manifesto
Principles behind the Agile Manifesto
We follow these principles:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals.
Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development.
The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity--the art of maximizing the amount of work not done--is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
(Courtesy of http://agilemanifesto.org/)
Saturday, 18 February 2012
Virtual teams - benefit or disadvantage?
I was recently at University (MSc course) where the topic of virtual teams and outsourcing was discussed.
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
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
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!)
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
Procrastination
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.
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!!
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
System+Error=?
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.
(http://www.instituteforgovernment.org.uk/news/article/197/the-16-billion-question-whats-wrong-with-government-it)
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
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
Subscribe to:
Comments (Atom)