This book recommends that project practitioners should consciously view projects through multiple “lenses” or “filters” to gain different perspectives. This approach directs attention to project aspects that might not otherwise be considered, which will affect the action taken, and hence the results obtained.
Considerable repetition of the principles and case study content (mainly to make it easier to use for reference), and overlap between the images caused me to have several déjà vu moments in reading it straight through, but the approach should be useful to PMs (on projects and programmes) and PMOs (to challenge PMs on their view of projects, and to think about portfolios) at all career stages. Continue reading “Images of Projects (Book Review)”
by Melanie Franklin, IT Governance Publishing, Ely, 152 pages, £24.95 RRP (review copy provided free of charge by the author)
Pragmatic PMO Rating: ****
This book is intended as a practical guide to understanding and managing change that will benefit your business. It covers the differences between change management and project management, and how to integrate the two.
It starts by loosely defining change management (making a large change to a business that involves a large proportion of the organisation), and breaking it into four stages (understanding; preparing; implementing and embedding). Each chapter of the book deals with one stage before finishing with a look at the alignment of change management with the project management that underpins it.
Chapter 1 (Understanding) suggests reviewing the business case to understand the drivers for change, and comparing the “from” state with the “to” state to understand its scale. It recommends cultivating support using a vision statement as early as possible to increase participation and reduce resistance.
Chapter 2 (Preparing) proposes producing a road map to the desired final state, listing what will stop, what will continue and what will start as a result of the change. This “paves the way” for the change and smooths the transition. Plans should be built constructed in both top-down and bottom-up directions, and will not need many updates. Plans should be communicated to stakeholders often enough to ensure the message gets across, and tailored to their needs.
Chapter 3 (Implementing) describes building the change team and ensuring various team roles are represented. It discusses potential emotional reactions to the change, and offers ways to address these to help those affected to move through the change smoothly. It maintains that change managers need more “friends” than average, and offers ways to cultivate this.
Chapter 4 (Embedding) describes how the change progresses from “new” to “normal”. It recommends measuring adoption, and dismantling the old ways. This can be encouraged using financial incentives, celebration, coaching for stragglers, and a managed exit for those who cannot or will not adapt.
Chapter 5 (Alignment with project management) highlights that whilst project teams generally deliver change enablers (e.g. a new IT system), it is others that take these enablers and embed them into organisational culture. Thus the change life cycle is related to and analogous to the project life cycle, but distinct from it.
This book draws useful parallels between change management and project management whilst highlighting differences. The use of voices from people who have “been there” makes the advice real, and the liberal use of diagrams helps to explain the various concepts. At 152 pages this book takes <2 hours to read; with a RRP of £24.95 it is likely to pay for itself many times over with application of just a few principles. Recommended for project managers who want a better understanding of how their projects fit into the bigger picture.
|Full title:||Business-driven PMO setup - Practical insights, techniques and case examples for ensuring success
|Author:||Mark Price Perry
|Publisher:||J Ross Publishing, USA
|RRP:||£60 RRP (electronic review copy provided free of charge)
The stated aim of this book is to show the reader how to create and maintain a business-driven PMO, because PMOs that are driven by the needs of the business succeed, whereas when PMOs that are driven by other motivations fail.
The book sets this out in a pattern of alternating chapters – one explaining a point from a theoretical or academic perspective, which is then supported by a shorter chapter or two demonstrating that point working in practice.
Rather than go through summarising each chapter, I thought it might be more helpful to list some interesting points or “Aha!” moments that I found in this book (and there were many).
On projects and project management generally:
- Involve operations early in projects. Document operational concerns and deliver against them. Get handover documents signed, and exit project staff as quickly as possible.
- Don’t use part-time operations staff on projects, as their primary loyalty will always be to operations. Make dedicated project people accountable with project-specific targets, contracts, etc.
- Project managers should focus more on managing relationships and taking action, and less on managing RAID logs and keeping documentation up to date. Aim to produce the desired result rather than the planned result (although if these are the same then so much the better!).
On PMO setup and development:
- A PMO should articulate its business value at or before inception, or expect to defend the additional cost.
- Don’t “sell” the PMO to Management. Ensure the PMO delivers real business benefits, and let these speak for you. The main source of inadequate Senior Management buy-in to PMOs is probably the result of them having been “sold” a PMO they didn’t really want or need.
- Most PM methodologies are geared towards large complex projects, but these often make up a tiny percentage of the PMO’s project portfolio. A PM methodology needs to be flexible and scalable to suit the size and complexity of the project being managed.
- Methodologies should only be used at all if they improve results – “Best Practice” may not be a good fit for your organisation and its projects.
- Not really an “Aha!” moment but one I very much agree with (see my posts on Watermelon and Green Side Up reporting) – if a project continually reports green RAG statuses across the board, then the budget and timescales were probably inflated – you should expect to see a range of RAG statuses in the lifespan of any project.
- Project KPIs should reflect the needs of the business, not some internal, myopic, PM-specific measures. As people work to targets, you may as well direct their efforts to truly desirable outcomes.
- Measure quality not in terms of how closely the plan was followed (it may have been the wrong plan), but how satisfied the customer is with the deliverables.
To sum up, some books once read get passed on to a colleague or put on the shelf and never looked at again. For me, this is not one of those books. Now that I have finished writing this review I will be reading this book again from the start, but this time with a highlighter pen in one hand and a pad of sticky bookmark tabs in the other!
I didn’t pay for this book (it was a gift – not from the publishers!) but I think it is well worth the cover price.
|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)”
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?
Following on from my post on watermelon reporting, I wanted to share another, related, phenomenon with you – “green side up” reporting. This describes the phenomenon where the health of programmes and portfolios is reported more favourably the higher up the organisation the reports are circulated; that is to say that in the project world everything looks green when viewed from above.
As with watermelon reporting, it’s not my expression but I can’t remember where I heard it.
So what are the factors that might lead to this progressive greening of status?
- Programme Managers want to be perceived as being in control of their programmes, so although the programme may contain one or two amber or even red projects, they want to avoid the unwelcome attention of the CxOs, and so they report the programme as green overall;
- The amber or red status of one project is diluted by the green status of other projects in the programme: if a programme comprises say ten projects, how many of these need to be amber or red before the programme overall is considered amber or red?
- As with watermelon reporting, the problem probably really should have been reported (perhaps as amber) some time ago, and to report it as red now would expose that it wasn’t as amber reported before;
- Also as with watermelon reporting, there’s still an opportunity to turn it around before the next report and due and then no-one will need to know anything was ever red, will they?
Leaving aside factors shared with watermelon reporting, which I have covered in a separate post, Green Side Up reporting is a Bad Idea because:
- The organisation’s executives (CxOs) will think that everything is always green (in the same way that VIPs and Royals think that the whole world smells of fresh paint all the time!). This could mean that CxOs only become aware of problems when it is already too late to do anything about them;
- The organisation’s executives (CxOs) will not believe the reports they are receiving.
So what are the alternatives? Here are a few possibilities:
I think the last one is probably the most practical and pragmatic. What do you think? Have you seen Green Side Up reporting? How is the health of your programmes related to the health of their constituent projects? Do you have any options to add to my list? How do your CxOs stay informed about the real health of their programmes? Let me know in the comments.