Images of Projects (Book Review)

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)”

What has the PMO ever done for us?

What has the PMO ever done for us

With all due acknowledgement (and apologies) to Monty Python’s Flying Circus, whose film The Life of Brian inspired this post.

THE INTERIOR OF A DIRTY CITY PUB. A SHADY BACK ROOM WITH A CONSPIRATORIAL ATMOSPHERE. We join a meeting of the Project Managers’ Revolutionary Front, where Brother Reg (the chairman of the meeting) is proposing a motion to the members (all Project Managers), and a CxO guest.

REG (gesticulating at a complex diagram on a flip chart): …So we break into the PMO, set fire to the methodology and sabotage the automated status report reminder email! Who’ll second me so we can take a vote?

[Apathetic silence]

BRIAN (a project manager): Are you sure we should actually be ransacking the PMO, Reg? I mean, some of the stuff they do is really quite useful…

Reg: Useful?!  Don’t make me laugh! What has the PMO ever done for us?

Brian: Well, the project management methodology makes sure we all talk the same language; before we had a PMO we didn’t know whether we were using PRINCE2® or the PMBoK®!

NIGEL (another project manager): That’s right Brian, and they update the methodology with Lessons Learned so it’s relevant to our projects and not over-bureaucratic…

SISTER SUSAN (another project manager, under her breath): Unlike these meetings…

[Sniggers all round]

Nigel (quickly): They do health checks to identify where our projects may be at risk, and help us to bridge the gaps.

Susan: And they develop user-friendly document templates to save us time

Reg: OK, so there are two things the PMO has given us…

LORETTA (a CxO): Well, they distil all the project reports into concise, executive-friendly information so that we know what’s going on.

Brian: …and they build project plans that we can actually use, rather than just stick on the wall and ignore like we used to…

Loretta: …and they prepare exec-specific views of the plans…

Reg: Well yes obviously planning, but what else?

Nigel: They keep an eye on the details for us…

Brian: And that’s where the devil is, isn’t it people?

[Nods and murmurs of general agreement]

Nigel: Yeah, like actions for completion; risks for review…

Brian: Exactly! They liberate us to manage our teams to deliver on time, to quality, and within budget.

Reg: Alright, I accept the PMO vitally underpins delivery of the project portfolio, but apart from methodology management, terrific templates, intelligent information, practical planning, and monitoring the detail, what has the PMO ever done for us?

Susan: Well, remember those “zombie” projects that we should never have started but that just wouldn’t die? They got those stopped…

Loretta: And that freed up some budget for projects that actually deliver benefits!

Reg: Hmm, this meeting isn’t really going the way I planned it.

Susan (just loud enough for everyone except Reg to hear): Maybe he should have got the PMO to run it!

[Amused guffaws. Reg looks frustrated. The laughter fades into awkward silence; the meeting seems to have rather lost its purpose]

Reg: All those in favour of going for a curry?

Project Psychology (Book Review)

by Sharon De Mascia, Gower Publishing Ltd, Farnham, Surrey, ISBN 978-0566089428, 181 pages, £60 RRP (review copy provided free of charge)
Pragmatic PMO Rating: ****

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.

Chapter 1 begins by looking at the skills and attributes needed by the project manager and the project team members. It covers how these might differ from those needed by Business As Usual (BAU) teams and managers, and how to factor them into recruitment or team member selection using psychometric tests.

Chapter 2 covers project leadership, exploring how successful leaders use emotional intelligence to build relationships and trust with colleagues, furthering their engagement and motivation.

Chapter 3 explores the nature of teams, from the roles that people adopt within them to the relationships that form and that can help or hinder project success.  It covers the characteristics of high-performing teams, and how to foster a vibrant team culture.

Chapter 4 describes how team leaders can develop and motivate team members through coaching, and the skills needed in order for this to be successful.

Chapter 5 looks at the importance of stakeholders and how to engage them effectively. It covers how to negotiate with them and even coach them whilst maintaining good relationships.

Chapter 6 examines the methods of communication now available to project teams, and how emotions and non-verbal communication affect the transmission and perception of messages. It gives practical suggestions to improve communications with team members and other stakeholders.

Chapter 7 examines the psychology of risk, covering human behaviours to be considered alongside formal risk management. This includes the effect of single personalities within a team, and effects arising from the team itself.

Chapter 8 covers conflict, offering techniques for using it positively; for example using a coaching approach to understand the reasons for conflict and to facilitate a win-win outcome.

Chapter 9 looks at change management, and this can be used in project management to ensure that change is sustainable through winning “hearts and minds”.

Chapter 10 examines ensuring the project board provides sufficient levels of appropriate challenge to ensure that the project steers clear of “groupthink”.

Chapter 11 looks into why organisations find it so difficult to learn from mistakes, and how to improve this using public wikis or learning logs, and reducing defensive behaviours.

Chapter 12 covers project closure, describing measures that may help with this emotional time, especially if the project was not a success.

The book closes by summarising what has gone before, identifying the underlying principles and suggesting some behaviours that project manager can use to improve their own results.

I would not have thought of buying this book, but am glad I have read it. It gave me several “Aha!” moments (of understanding) which I am sure others would have too. It offers a good balance between psychology theory, and practical techniques to improve project results. Recommended for all project managers seeking to improve their people skills.

Related articles

Gower Handbook of People in Project Management (Book Review)

by Dennis Lock and Lindsay Scott, Gower Publishing Ltd, Farnham, Surrey, ISBN 978-1409437857, 908 pages, £100 RRP (electronic review copy provided free of charge)
Pragmatic PMO Rating:  ***

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.

Related articles

 

When the Project Sponsor is just too important to be effective

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.

Photograph of a door with

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?

Related articles

How to create a streamlined project management methodology

How do you develop a project management methodology that isn’t too heavy or too light, that respects the experience of project managers, and that is accessible? Here’s how I approached it…

How to create a streamlined PM methodology

I was made the PMO Manager of a department of about 20 project managers. Although I didn’t have responsibility for the project managers or the portfolio of projects, I did have responsibility for the methodology they were working to and for the reporting of project information to the project portfolio board (comprising most of the organisation’s senior management).

Review the “As Is” methodology

At the time I was appointed, I assumed responsibility for managing the methodology – this was a comprehensive rulebook, spanning over 125 pages and including over 30 document templates, that was updated roughly quarterly. This rulebook was generally either blindly implemented in full (by the less experienced project managers, potentially impeding project delivery) or cheerfully ignored (by the more experienced project managers, potentially increasing the risk to delivery).

Seeing that this was not an ideal situation, I reviewed the methodology to identify the key control points and templates that delivered the most value, either for the project managers or for project and portfolio stakeholders.

I involved the project managers, who helped me to identify where things were inefficient and could be improved. I asked some of them to help me develop and test-drive new improved multi-purpose templates and more efficient ways of reporting, that removed the old cut-and-paste consolidation.

Develop the “To Be” methodology in consultation with stakeholders

To improve ease of use (and uptake) I represented the entire project management approach as a process flow diagram or “framework” on a single A4 page, with hyperlinks to the latest templates for each section. I identified the steps and documents that would always be required for the type of projects generally undertaken, and made these items part of what I called the mandatory “backbone” of the new approach. Everything else I made either conditionally mandatory (depending on project dimensions such as size, risk, complexity, etc.) or fully optional elements. These optional elements could be selected from the “toolkit” or not, as the result of a discussion held early on in the project between the project manager and their line manager (who typically was responsible for the project management of a section of the project portfolio). I designed a document to record the choices made and the reasons why any optional element was though not to be relevant or useful to the project; this empowered the project manager to make choices, but also made the project manager accountable for those choices.

Implement the solution and train users

I trained the project managers in the new approach and published it on the organisation’s intranet. I encouraged project managers not to print paper copies of the guidance or templates or to re-use old completed documents, instead pointing them to the intranet site so that they would always be using the latest versions of the PM approach and the templates.

Review performance, and tune the methodology

I carried out regular post-implementation surveys and facilitated review meetings, and integrated the lessons learned into the framework. I abandoned quarterly releases of a weighty manual, instead making changes to templates and guidelines as often as these were appropriate (and informing stakeholders of the changes and why they had been made).

The new framework gave increased flexibility to project managers whilst ensuring their accountability for their project management approach. The project management community bought in to the framework as they had been closely involved in its development.

So that’s my approach to refreshing a project management methodology, learned through experience. It this approach useful to you? Let me know in the comments.

If you would like to have the benefits of an approach like this but prefer not to have to worry about this sort of techy stuff, why not talk to us about taking care of it all for you?