How PMOs can smooth the path of projects, to help make changes more “sticky”
A while back I attended a PMO FlashMob discussion facilitated by Ranjit Sidhu of ChangeQuest and hosted as usual by Lindsay Scott of Arras People.
This session was on how PMOs can help projects to deliver organisational change more effectively. There were several interesting take-away messages, of which I found the most interesting to be:
- If you want a change to “stick” (without people reverting to the old way of doing things), it is just as important to get the people ready for the change (Change Management) as it is to get the change ready for the people (producing project deliverables).
- The most successful Change projects allow stakeholders time to “grieve” for the old ways, and time to become familiar with the new ways. These projects put in consistent effort to maintain momentum on the journey from the “as is” to the “to be”, until the post-change ways become “the new normal”
- Small pilots (preferably including some vocal objectors) can generate early successes that can be used as good news stories to spread the word and help to form positive opinions.
- Change projects may well be asking BAU workers to carry extra work above and beyond their “day jobs” (with all its targets and objectives). During major changes, a significant proportion of people experience sufficient stress so as to pose a risk to their mental health. What can projects do to help organisations come through the Change experience still healthy?
- Just telling people about the Change and what will happen will only get you so far. Listening to stakeholders and demonstrating what you have done with their feedback will get you much farther.
PMOs (especially PfMOs) have a unique position on the interface between the projects being carried out to effect organisational change, and the people out in the wider organisation who experience the change happening to them. So PMOs can help changes to stick by:
- Including change management themes in project reporting (at least as a RAG category, or preferably as a measured deliverable).
- Devising and delivering approaches to express change management as a quantified KPI.
- Becoming the “eyes and ears” of projects; picking up informal stakeholder views on projects.
- Project and Programme PMOs can also make change easier internally by providing good quality inductions for new project team members.
So those were the key points for me (Lindsay’s are here) from what was a very informative and useful session on how PMOs can help to make change “sticky”.
© Copyright Pragmatic PMO Ltd, first published in 2015
How learning groups spontaneously form and disperse…
A while back I attended an APM focus group facilitated by Dr Michael Moynagh of CPD Futures Ltd on developing strategies to improve the way that project professionals approach continuing professional development (CPD). One of the topics that came up was that established approaches to CPD (including the approach promoted by the APM) are somewhat rigid and introspective, and lack a social dimension. The suggestion arose that some sort of group learning approach might be helpful, e.g. creating a PPM Community of Practice.
I have seen this happen with some success (albeit rather briefly!) in the following situation:
- The organisation had stated its aim of raising the standard of the organisation’s approach to Project Management (and hence the professionalism of the individual PMs)
- An entire department of PMs had been through some comprehensive PM training (delivered very professionally and capably by Michael Nir of Sapir Consulting)
- Following the training, all the PMs were given the opportunity to go on and attempt to gain the PMI‘s PMP certification, which a good proportion of them (including me) took up.
- For those going on to take the certification, there was a fairly hefty exam in prospect, preparation for which involved a fair bit of study and exam practice (I guess this is the CPD / Learning Community equivalent of a “burning platform”).
As a result, a group of us set up “Lunch ‘n’ Learn” sessions every week or so for several months, in which contributors would take it in turns to give a short (20 mins or so) refresher presentation on a topic (say earned value) and then ask some example PMP questions – all over lunch in a spare meeting room.
This worked quite well, but tailed off as the people sat the exams and either passed (in which case they had little interest in attending further) or failed (in which case they generally didn’t attempt a re-sit). It was good while it lasted though, and produced a few learning points for me:
- Communities of practice form spontaneously where there are shared interests and objectives.
- Participation is maximised when there is an opportunity for (or even an expectation of) contributions from all.
- For a community of practice to thrive, contributors must have a genuine interest in the development of both themselves and of others. Don’t be surprised if a significant proportion of potential participants don’t have such an interest. You can lead a horse to water…
Have you seen PM communities of practice? How were they formed (were they organised or spontaneous)? How long did they last? Were they successful? What approaches do you recommend? Let me know in the comments.
Image by WOCinTech Chat, flic.kr/photos/wocintechchat/25392513823
Licence at http://creativecommons.org/licenses/by/2.0
|Full title:||Project Psychology - Using Psychological Models and Techniques to Create a Successful Project
|Author:||Sharon De Mascia
|Publisher:||Gower Publishing Ltd, Farnham, Surrey
£60 RRP (electronic review copy provided free of charge)
This book addresses a gap in the Project Management literature – how people and their behaviours contribute to project failure, and shows the reader how psychology can improve the chances of project success.
Continue reading “Project Psychology (Book Review)”
|Full title:||Gower Handbook of People in Project Management
|Author:||Edited by Dennis Lock and Lindsay Scott
|Publisher:||Gower Publishing Ltd, Farnham, Surrey
|RRP:||£100 RRP (electronic review copy provided free of charge)
Let me start by saying that this is BIG book. As it would take me a very long time to read the whole thing (and I doubt that the book is meant to be used that way) I will base my review on a selection of chapters that appeal to me rather than the whole thing.
Starting with Chapter 17 – The Project Office Environment, this is not as I was expecting about the business context of the Project Office, but all about the physical aspects of the office (lighting, desk layout, even carpet!) and how they can affect a project team’s performance. Most of this would apply to any office environment of course, but the chapter makes mention of special factors (such as the visibility of the project manager or director) that have special significance for projects. Some useful points are raised – for example the provision of a dedicated, lockable meeting room that can be used as a “War Room” for a particular large project or programme.
Chapter 6 – Project Management in the Private Sector outlines that projects in the private sector could be run according to a variety of methodologies (as opposed to PRINCE2® which is commonly used in the public sector), and in many cases also using the bare minimum of documentation required to get the project done quickly but in a robust manner – these documents are often made pre-requisites to obtain project funding. Private sector PMOs are also more streamlined than their public sector equivalents, and are often tightly focussed on budgets and delivery. Private sector PMOs will prioritise new projects based on financial return, and the seniority of the sponsor (although these people will see project sponsorship as a relatively low priority). Project managers are likely to get caught up in organisational politics, and may find themselves the scapegoats for projects that have “gone wrong”.
Chapter 16 – People in Supporting Roles covers those roles that do not involve directly managing projects, and that may not be dedicated to a single project or programme – typically these roles find their home on the PMO. Amongst other things, the PMO is interested in: ensuring a consistent approach to the management of projects; development and provision of PM templates; development and maintenance of corporate PM methodology; training of PMs; demand / capacity management; estimation; planning; project control and administration. In a large PMO these functions may each be performed by one or more dedicated people, or in a smaller PMO each person may cover a wide range of roles. This chapter also covers some of the functions in the wider organisation that will support project activity.
This book has 63 chapters that average at about 13 pages per chapter. Each chapter has an introduction, some discussion and a conclusion, and is written by a current practitioner. I think that rather than being read from cover to cover, this book should be treated more like an encyclopaedia – it could be the first place you would go to in order to research a topic, to be followed up in more detail if need be. In this application, the book does a good job across a wide range of subjects. The £100 RRP is high enough to cause a sharp intake of breath, certainly, but it should be borne in mind that for this price you are getting at least 3 times the content of a more standard-sized book. This would be a good book to have on the shelves of a university, an organisational PMO, or a PM practitioner looking to develop their knowledge of the people aspects of PM.
I recently saw a great example of spontaneous teamwork. I was making my way up one of those very long escalators you find in London tube stations. Some way above me and ahead of me, a woman took off her hat and put her hand on the moving hand rail, but without realising it let go of her hat. The hat slid quickly down the steeply sloping polished surface next to the hand rail. It slid past several people but a man about ten rows behind the woman caught the hat. The hat was then passed forwards by various people and within little more than ten seconds was returned to the delighted and grateful woman, who until then had not even realised it was lost.
I noted several observations from this little scene:
- This team formed completely spontaneously – no-one was assigned roles or organised from above (but then this was a very simple little task)
- Nobody told the team what to do – they saw there was something that needed to be done, and they did it
- No-one in the team had anything to gain from their actions, except the satisfaction of doing something good, and of seeing the woman’s smile when her hat was returned (although granted they were there anyway and it was very little trouble to them to help her). She was positively beaming – I think it was an expensive hat!
- The recipient was delighted with the result because she got something she wasn’t expecting.
So how can we apply these observations to teamwork in project management? Here are my thoughts:
- If you are lucky enough to have an experienced and mature team, let them organise themselves as far as possible – show them what needs to be done and then hold back, only stepping in if it looks like it’s not going to work.
- Explain to the team what the end goal is and that you need their help. They will feel more motivated to contribute if:
- they can see what the goal is and agree it is worthwhile
- they can see how their actions contribute to reaching the goal
- they will receive recognition for achieving the goal
- If you want to delight your sponsor, you can deliver a little something extra that they didn’t know about (but that is easy and cheap for you to provide, that the sponsor finds desirable and that they didn’t have to pay any extra for!). B.Be careful here though, as they may expect similar extras in future that are difficult and expensive for you to provide, and providing too much as free extras could lead to your sponsor undervaluing the delivery they did pay for.
What do you think? What PM lessons occur to you from this little scene?
|Full title:||A Practical Guide to Dealing with Difficult Stakeholders, as part of the “Advances in Project Management” series
|Author:||Jake Holloway, David Bryde, Roger Joby
|Publisher:||Gower Publishing Ltd (Farnham, Surrey) 2010
£26.50 (review copy supplied free of charge by the publishers)
This book aims to improve Project Managers’ understanding of their projects’ stakeholders, and in doing so to improve the quality of engagement and hence project outcomes.
It starts by stating the obvious (but easily forgotten) truth that project stakeholders are all human beings (hmmm, not sure if I can say that applies to all the stakeholders I’ve dealt with…) with all the emotions, personal agendas, hopes and fears that entails. It crucially points out that they may not care about or really support the project (even if they say they do), and that behind the scenes they may even be working really hard to ensure it fails.
The book analyses the various motivations for this type of behaviour (which differ according to the stakeholder’s relationship to the project, and their position in the organisation). It deals with each type of stakeholder in turn (Sponsor, Team, internal/external Clients, internal/external Suppliers), using psychological and business research to explain various ways in which that type of stakeholder may behave. It then suggests practical ways in which these stakeholders can be engaged to improve their interaction with the project and increase the likelihood of a positive outcome. It adds colour (and spice!) by illustrating these approaches with real examples drawn from the authors’ experience.
Here a few key “take-aways” that resonated with me and my experience:
- Accurate reporting may be suppressed or prevented if they differ from the perceptions of a powerful stakeholder (I have seen this in the form of Green Side Up reporting)
- Changing stakeholder attitudes may not be possible; focus instead on changing their behaviour
- The most successful approaches for dealing with project saboteurs are generally those in which the saboteur appears to win (or at least not to lose)
- Project Team members are also stakeholders, with their own motivations, agendas, and objectives. Make sure they are motivated to deliver the project! (the book contains approaches to deal with everything from one or two uncooperative team members to all-out mutiny)
- When delivering a project for an external Client, make sure they understand you are only delivering the product; it is up to them to use that product to realise the benefits.
- Enlist the project’s End Users, give them a voice, and use it to influence the Sponsor and Project Board.
- Pay attention to project Gatekeepers (PMO, Finance). Engage with them, provide what they ask for and follow their procedures as far as possible, and they will be more sympathetic if (when?) you need to do something that breaks The Rules or doesn’t fit inside them.
At 90 pages of actual text, this is not a long read, and is easy to follow and understand. It gave me several “Aha!” moments (NOW I understand why that person behaved that way on that project, and how we could have handled it better…)
I would say that this book is probably most likely to be useful to someone who has a few projects under their belt, and wants to understand and relate to their stakeholders better.
Price per page may seem a little high, but at £5 or less per actionable insight I would say it represents good value for money.
As a project manager, there are a few things you want in a project sponsor:
- A genuine interest in the success of the project
- Sufficient “clout” and credibility to argue for the project’s priority against other projects
- Availability to give ad hoc direction, sign off key documents, etc., as and when required
Failure on the part of the sponsor to fulfil any of these criteria can cause the project serious problems.
You might think that the sponsor’s interest in the success of the project could be taken as read, but this can be lacking, especially if the sponsor did not initiate the project but was “volunteered” for the role (usually by their boss). If there are multiple potential sponsors for a project, the most enthusiastic supporter of the project is likely to be the one that has the most to gain from project success, or the one who would wake up in the middle of the night in a cold sweat if the project was not done!
“Clout” usually comes from the project sponsor having seniority, or at least from having good connections with those in seniority, so from this point of view the more senior the sponsor, the better.
Availability sounds like a simple requirement, but the lack of it can seriously affect the successful delivery of the project. A sponsor who is too busy to give ad hoc direction on the best business approach to take in a crisis, for example, risks the project going down a blind alley. A sponsor who cannot give the time required to review and approve a business case will not get their project started; a sponsor who cannot devote a little time to removing project roadblocks will not get their project delivered.
It could be argued that a lack of sponsor availability to the project implies a lack of interest in the project, but this is not always the case. Sponsors who hold very senior positions may get bogged down in “Business as Usual” matters, particularly if they are detail-oriented people or adopt a “hands on” management approach with their BAU roles.
One approach that I have used successfully is to anticipate the sponsor’s potential lack of availability, and persuade the sponsor to delegate a significant chunk of their role to a deputy (ideally a right hand man/woman) who can handle the day-to-day sponsorship duties, with the more senior sponsor only being called on when unblocking is required or when the project is fighting for survival. The deputy will have better access to the sponsor than the PM, and thus the sponsor can influence the project through their deputy.
The senior sponsor is then called upon only when they are really needed, and the project benefits from the sponsor’s oversight, albeit through their deputy.
Are your sponsors just too important to be effective, and if so how do you handle it?
At a recent PMO FlashMob event, I got chatting with a few FlashMobbers about what can be done with the Lessons identified in project closure reports. There were split opinions in the group:
- Some thought that Lessons are usually specific to the Project concerned, and are only useful in later stages of the same project, or in running future projects that are very similar to the one from which the Lessons were learned;
- Others (including me) thought that it is possible to extract more generic learning from at least some Lessons that can be implemented across many projects (even those that are different from the project that identified the Lesson), perhaps by adding or making a small change to a checklist, template, approach, BAU process or corporate PM methodology, or by including the Lesson in PM training or coaching.
I have written before about Lessons Learned and my ideas on how to use them, but I thought it might be fun to try an experiment, with which I would be grateful for your help.
I have written a web survey containing a number of Lessons learned from projects (some very loosely based on my own experience, and some completely made up) – please take a look at them, and for each one let me know:
- Whether you think it is possible is to draw any learning from the Lesson that can be applied to projects beyond the same type as the original project, and if so
- What learning you would take from that Lesson and how you would apply it.
On completing the survey (which should only take you about 5-10 minutes) you will see a summary of all the coded responses so far (the survey doesn’t allow respondents to see the free text responses). I will also give you the password to a follow-up article outlining my own thoughts on the examples, which I will update periodically with the best quality outputs from the survey.
So why not make yourself a cup of tea, take the survey
and find out how closely your approach to applying Learning from Lessons compares to that of others in the PMO Community?
…a Case Study showing one approach to evaluating whether a project should be cancelled or completed.
First, some context…
Some years ago I was managing a project to design and manufacture about 20,000 pieces of equipment for a household name client (let’s call them ClientCo) of the engineering manufacturer I was working for (we’ll call them MyCo).
MyCo’s project costs were to be factored into the selling price of the units (rather than invoicing ClientCo as we went along), and it was crucial to the financial stability of MyCo that we would sell the units at the end of the project.
Part way through the project, ClientCo restructured. Budgets were revisited, and question marks appeared over my project that was a “nice to have” for ClientCo but a “must have” for MyCo.
The challenge I was set by MyCo was to demonstrate to ClientCo why they should continue with the project and make their cuts elsewhere.
We needed them more than they needed us
Design-and-manufacture Projects deliver the benefits right at the end. There’s nothing to be gained from owning component tooling and assembly jigs – you have to make, and use the finished product in order to realise the benefits.
Calculate cost:benefit of completion vs. exit
I laid the finances on the line, preparing a breakdown of the cost to complete the project with a statement of the benefits to be gained, vs. the cost to exit the project early (comprising remaining project costs, plus costs to make the tooling for component manufacture, which had already been contractually committed to). I added this cost information to my (weekly) Project Status Reports.
Let the Client decide (after all it’s their money…)
Initially, the exit cost was considerably less than the completion cost, but exit would have been embarrassing for my customers at ClientCo as it would entail expenditure without benefits. I explained my ClientCo customers that as the project progressed, the completion cost would decrease in relation to the exit cost, and benefit realisation would draw closer. The project remained in funding limbo for a couple of months (with my ClientCo customers explaining the journey towards benefit realisation to their own Sponsors), but it soon became apparent to ClientCo that it was better to complete (and realise the benefits) than it was to exit, and the project continued right through to manufacture.
Have you been in a similar situation to this? What approach did you use? How did it go?