Category: Events

The future of P3O

Stuart 3 Comments

Where does P3O go from here?

I am writing this in advance of the PMO flashmob talk on the future of p3o by Eileen Roden the lead author of the the p3o refresh. I wanted to get my thoughts on P3O and where the profession should go down before I heard and got influenced by others.

What has worked?

The P3O manual has been really good for putting portfolio management on the map. It has enabled organisations to understand how having a portfolio office can really benefit their organisation. It has moved the role from a support office to an integral part of the organisation. In fact it has removed the word support from the vocabulary entirely.
It has given organisations a structure to setup their portfolio office saying how they can be organised.
It provided the PMO world with appendix F, which has been invaluable for all those discussions with people as to whether some was or should be a part of the PMO role. If it was in appendix F, then it could be part of the PMO role. If it isn’t then this is something that could be done by a PMO person, it it wasn’t necessarily part of the role e.g. Being a fire warden.

What hasn’t worked?

Through the training I did on P3O I found that at least half, if not more of the people coming along were not in a portfolio office. In fact some organisations didn’t understand the word programme let alone portfolio. The P3O guide offered little for the people who weren’t going to manage the P3O it didn’t tell you how to do the job. It didn’t show you how to do configuration management, risk, issue, change management or setup the structures that would be needed to make those things happen. So for a large majority of the people in a PMO it didn’t help them do the day job.
It also didn’t clearly define what the word PMO means, after all the guide is portfolio office, programme office and project office guide. Hence the P3O. Well at least it could be trademarked!

Where do we go from here?
I suggest that we don’t have a P3O guide. This is not to say that we don’t have a guide on what the role does, but more that we need different guides for the different jobs within a P3O structure. Along with that we need different names for those roles. I accept that these can do with some refining, and I am hoping that others will contribute to this, but my suggestions are:

Programme Delivery Office – this needs to be a companion guide to MSP (Managing Successful Programmes). This needs to define the role of a programme management office. It needs to build on what is already included in the MSP guide, include most of what is in the PPSO books and where possible include the work from the pop up programme office book. This has to be a practical book for people doing a PMO analyst role. The appendices for this should include what the roles for the PMO, junior, senior and manager are in a programme office. They need to list what is included in a progress report, risk log, dependency log, change log. There needed to be practical examples of what a configuration management role does, how it is setup, and perhaps even as detailed as some advice on how to setup a version control system.
This office is the temporary office that will close when the programme it supports closes.

Strategic Delivery Office – this needs to be the companion guide to the MoP (Management of Portfolios) and Benefits Management manuals. Quite a lot of the existing P3O manual could be used here. This manual needed to be aimed at the Portfolio Office analyst role that is currently defined within the P3O manual. This can include the techniques around prioritisation, resource plans, force ranking, knowledge management etc. As this is a permanent office it needs to include the Centre of Excellence functions that are currently in the P3O manual.

Setting up successful PMOs. – this is the guide for all senior managers and PMO managers. This can be what is left of the P3O manual once you have taken out the doing part. There is still the need for a guide for the PMO manager role, and that the P3O guide does do very well. In fact I think this should go further and describe how to setup the portfolio, programme, project delivery structure as well and how they can be linked together, as well as the team to support them.

Why the need for different manuals?
You may think that by dividing the P3O manual up you are just splitting up the role of PMO into all smaller portions just to get revenue from the different qualifications that would spring up around this. However I see this fit together in the same way that the ITIL framework does. You have a basic knowledge, which is the junior role and then you expand on this by getting the manager qualification. You can either come to the manager qualification through the programme or portfolio route.
There is still no definition of PMO that is agreed on, so I suggest dividing that up into the 3 main roles that exist. Support of a temporary endeavour along with the manager of that temporary endeavour (I will leave if for other to argue whether it is a project or programme). Support of entire group of temporary endeavours to help drive the organisation forward (portfolio office). Management of both of these groups, which would apply to the medium to larger organisations.

Is there anything else?

The only thing I see out there speaking to individuals who do a PMO role is those who don’t support just one project, but multiple as a permanent office. For these people I suggest they would benefit from the Programme Delivery Office guide, although they would not disband at the end of a project or programme they are doing the things that would be mentioned in that guide. If they are then asked to look at portfolio management, then they need the Strategic Delivery Office guide.
The other thing that isn’t included above are the softer skills that are required in the role such as influencing, negotiation, coaching, training, leadership and teamwork. But then again they aren’t in the rest of the AXELOS guide either. Perhaps it is time for the PMOs to lead on this and start to include these in there as well.

Ever since the APM BoK 6 came out a couple of years ago I have thought that what was needed for the PMO space were guides saying how each of those items in the BoK that are split by project, programme and portfolio also needed a PMO section as well. If the above books get written then perhaps that will happen.

I wait with interest to see what Eileen has to suggest.

Trainer, Mentor, Coach or Counsellor?

Stuart 1 Comment

I attended the PMO Flashmob the other week on coaching and the PMO. This talk was given by Suzanne Masden, who based on her qualification has had a bit of experience in being a coach to a variety of people, plus was once a project manager.

During the short talk one of the questions that came up was what exactly is a coach anyway? I am sure that you can go and look this up on the web, but the reason it came up was that it is an expression that we as PMO’s seem to use all the time. However we don’t have a correct understanding of what this really means. Most of the time when we say we are coaching the project managers, we aren’t actually doing this at all.

So I thought I would post something up which was my understanding of the difference we have between the 4 roles outlined in the title

Trainer Arrow
Assistance spectrum

 

 

Trainer – at this level a PMO would be teaching something to a project manager. e.g. This is how to fill in the progress report. Most likely to say: “Do it this way”

Mentor – normally a more experienced PMO person who is assisting the project manager with a topic, based on their own personal experience and giving the knowledge as though they were the individual in the job. e.g. This is how I would deal with stakeholders when going through the design stage of the project. Most likely to say: “This is how I would approach it”

Coach – an individual who is qualified as a coach (yes there are qualifications) who will assist the project manager by asking them questions about how they are likely to achieve their goals. e.g. How can you get the best out of your project team? Most likely to say: “What can you do to improve?” or “Is that working for you?”

Counsellor – an individual who is qualified as a counsellor who can help and individual reflect on what is happening to them and consider alternative ways of doing things. As such this individual will not be dealing with items specifically linked into the world of project management, but will be looking at an individual’s life problems and how they can be overcome.

There was an interesting part of the discussion where we talked about the difference between the mentor and coach roles. Based on the experiences of the individuals within the room it is most likely that when a PMO individual is saying that they are coaching project manager, what in fact they are doing is either training them or at best mentoring them.

I came away feeling that a coach would be very useful in all sorts of circumstances, and it shouldn’t be limited to just PMOs coaching project managers, but should be PMOs coaching other PMOs, or at least PMOs seeking coaching for themselves. This was where the difference was made between a coach and a counsellor. In order to be coached the person being coached must want to make some changes to the way that they are doing things. If changes are required, but the individual is unwilling to want to make any changes then that will go into counselling, and is above and beyond what a coach would want to do.

I thought the session at the PMO Flashmob was informative, and I have gone away with a fresh understanding of not only what I do, but also what I could do to develop myself. After all isn’t that why we go to such events?

PMO Competencies

Stuart

At the PMO Flashmob last night we were talking about PMO competencies. It was good to start a discussion on what is required to be a PMO person. If we can start as a profession to understand what is required from the role then we can start to get people who can improve and lead the profession onwards.

However as a group of people gathered in the room we found that difficult to do. I found it interesting that we found it easy to talk about some of the technical competencies that were required for the role e.g. updating logs, registers, dependency maps, starting projects.

What we found difficult to do was to put down anything around the soft skills (not sure why they are called that as they are quite hard to get right). On a lot of the linked in discussions I see we talk about what is required for a successful PMO. The answers seem to come back to the same things. It’s about the behaviours that people demonstrate. This includes leadership, influencing, learnability, inquisitiveness, pragmatism. Not sure that some of those can exactly be linked to competencies. However it surely has to be worth a try.

As a starter for 10 we looked at the competencies that have been developed for project managers, which gave a framework we could look at. We had a discussion about how different was the competencies required for a PMO person from that list. It should be noted that the list didn’t have behavioural attributes on it. I suggest that this is probably missing the competencies that you might find in an Analyst role,

I do wait to see what the Flashmob make of the consolidated lists that will come out, and I would like to see if we can get the necessary people together to get a competency framework together and off the ground. That then will give us something to judge ourselves against.

 

The Agile PMO

Stuart

As part of the PMO flashmob I went along to a talk given by Jennifer Stapleton the author of the agile PMO pocketbook. Jennifer has a background in agile having been involved with DSDM since its beginning 20 years ago (which on my estimation makes it older than PRINCE2). In this session Jennifer talked us through what a PMO can do to support agile projects, rather than what makes a PMO agile.

There are various things that PMOs can do to support agile, including using some of their techniques when prioritising projects. Using a MoSCoW method for selecting which projects are more important, and this can be used on agile and non agile projects together as part of a portfolio role. Jennifer did suggest more than once that by selecting an agile project that would of course mean that benefits come earlier with the initial delivery from the agile project. Jennifer discussed the sorts of things that a PMO may need to do differently when looking at an agile project, including reporting and gate reviews. These she said can still be done, but they would focus on different things, with the reporting looking at velocity and user engagement rather than focussing on a Gantt chart and finances.

There were over 20 people present from different PMOs, not just those who were running a PMO with agile projects, but those people who were doing a project manager role and those people who were looking to find out more about agile.

Having received a copy of the pocket book that Jennifer I think it is a useful practical way of looking about how a PMO needed to change to be applicable to the agile world, giving actual examples of how some of the things that a PMO get asked to do can change for the better. In fact Jennifer said that actually having a PMO involved with an agile project was a benefit for the project. Although Jennifer was unable to stay for the social at the local pub afterwards she was able to answer everyone’s questions as part of the session.

The other thing that struck me was how some of the subjects that Jennifer mentioned about user engagement, focussing on what is important for the project rather than what is important for the PMO and having the PMO adapt to organisation style were important regardless of whether the organisation runs agile projects, non agile projects or a combination of both.