Monday 11 November 2013

Juggling Leadership (continued)

In the previous blog, I was asked some questions on leadership in projects.  There were some follow-up questions and here they are, with answers:

1. You write that it's important to "continuously improve". Do you have any good tips for how to do that? After all it's a bit of a mind-set shift for many PMs right? How can they start to do it and encourage their team to always be learning and thinking? Giving the team permission to make mistakes is part of the answer; but how do we strike that balance of experimenting and ensuring it has a purpose?

I think that you have to be continuously listening, reading and learning in general.  I've met a few PM's that seem to think that just doing things is enough.  HSE (Health and Safety Executive) say that competence = learning x experience, so I like to balance the two.  I've studied best practice and then gone out to try and deliver it, thereby embedding it in the mind and experience.

Projects are great, because you can apply the learning from this one to the next.  Keep building from one to the next, but remember that you need to have an input that helps you to improve.  You have to remember though, that projects are complex systems and unlike operating a chemistry set, you can't just do things the same each time and get the same results.  Get mentoring from inside and outside the organisation.  Ask questions and really take time to listen to the answer.


2. You write that "If I'm being briefed up and the Business Case isn't obvious, then I'll ask if they'll let me test the Business Case first". How do you do that? How do you test it? What is the secret to writing a good business case?


I think you have to look at the benefits and see that they're there.  If not, why are we doing it?  That's not to say that we can't do things if there aren't obvious benefits, but where there aren't enough funds to do everything, we have to be selective and do the things that give the best bang:buck ratio.  The secret to writing a good business case is to start with the benefits of what you're trying to achieve and work back from there.  Make sure that you have a User Requirement and also make sure that you're aligned to the organisation's goals.

It's worthwhile getting a copy of "Business Analysis" and reading the section on Business Cases, because that's a great primer on writing them.  I also like to remember who I'm writing the Business Case for.  It's not for you, it's for them, so write in a way that they want to read.


3. How do PMs avoid taking on a project which is just about "delivering technology"? What tips do you have for how they can start to "look at the change holistically"?


It's not about avoiding things, it's about ensuring that you have the ability to add the cultural change aspects that you need, in order to ensure that the benefits are delivered.


Keep your eye on what delivers the benefits and then make sure that you include modules in the project that ensure those benefits will be delivered.  No good installing a new computer system if it doesn't get used!!  I have people working right now to ensure that the features in our projects are actually facilitated into use through training and closely mentoring people who will be using the systems.


4. Do you have any tips for PMs who feel overwhelmed by it all like you initially did?


Be patient, and remember that it won't happen overnight.  Get some learning, speak to people in your management and get a good mentor.  Talk through problems and ask loads of questions.  Discuss things and be honest about what you do/don't understand.  Ask for help.  Only idiots don't ask for help when they need it.


5. In which ways do you go about building trust with your stakeholders?


I think you've got to talk to them and listen to what they're saying.  If you're honest about what you're trying to achieve, you have a good User Requirement and compelling benefits case, then people will come along with that.


6. You write about the PM Masters (MSc) that you did and the impact it had. What it your approach to projects that changed, was it new tools and techniques you learned, was it people skills or all of the above? What is important in order to make it a success? I suppose it was important that you could go back to work and directly try out the things you learned? What is the advantage of doing a master as opposed to PMP for instance?


I think the Masters route first teaches you how to think critically and then asks you questions designed to give your brain a good workout on some key topics like outsourcing, cultural change, user requirements, benefits, scheduling and planning and many more!!  You have to be able to back up everything you write, so you need to know what the key arguments are and both sides of it.  Thinking about both sides makes you understand why best practice is best practice.  I'm not sure that other qualifications do that.

I really recommend doing a masters (MSc), especially if you consider yourself a 'deep thinker'.


7. What's the best way of learning soft skills? Other than learning over the years through experienced, is there something more proactive PMs can do?


I think you've got the language right there, because some suggest that you can't learn soft skills and I really disagree with that.


Active listening is one of the best soft skills that one can learn.  If you don't listen properly, why would others listen to you?  Doing loads of requirements interviews helped me to learn that, but I'm always learning.  As an ex-technician, I tend towards giving answers and it was really difficult for me to put the 'answer mode' on hold so that I could fully understand the problem.


8. What do you mean by "I see people who've 'learnt the rules' on a daily basis and you can spot it a mile away."?  What is it that PMs do wrong? What's the best way to get "beyond the rules"?


By 'the rules' I meant that people sometimes try to shortcut the pain of learning.  Go out there, observe what others do badly or well and build your own skillset.  Don't try to manipulate people, just be honest with them.  There are no ninja mind tricks. 


9. Regarding "benefits management" - do you have a top tip on that? 


Yes, I would recommend that people read Gerald Bradley's book on Benefits Management - it's £70, but it's an excellent book!  Luckily I reviewed it for Gower and got it free.  Basically, my top tip is to make benefits maps which are aligned to the organisational strategic objectives.  If you can't see the benefits in what you're being asked to do, it's probably best to think about whether it's worth doing the project or not - and certainly worth thinking about which bits to do in either case.

Gerald talks regularly at Project Challenge Expo (UK) on this topic, so if you get chance to attend, it's certainly worth making the effort to get the techniques from the horse's mouth (so to speak).  Gerald contributed to the benefits work in MSP and other books, so it's worthwhile getting on top of these techniques.  Portfolio benefits management seems interesting and a great way to work out which projects to do and which to drop.


10. Do you have any particular ways in which you learn from the past? Do you have a certain way of running post project reviews or other great techniques that work for you?


Start each project with looking at lessons learned from other projects.  End each project with a lessons learned review.

Accept that you're going to get criticised by people, that's inevitable.


11. How do you communicate to the team on day one "which behaviours are good and bad from your perspective"?


Talk with them!  I generally know much of the project team and they know what I'm about, but in the case of new people you need to be specific about what you expect and how they fit into that.  Having regular meetings is worthwhile but you don't always have that luxury.

No comments:

Post a Comment