Types of project manager

Should employers recruit diverse types of project manager, if so what types are there?

None of this is scientifically proven or suggested, it is purely personal observation, but as scientific proof often involves observing behaviours I might not be far off the mark.

I have observed five basic types of project manager, namely, the Documenter, the Controller, the Diplomat, the Expert and the Hero.

The Documenter

This project manager is able to actually capture and document everything needed, as PRINCE2 includes twenty six different documents for a single project, they will definitely be qualified there. Twenty six sounds outrageous, but in reality it's not as extreme in practice, this is because PRINCE2 has a document for everything and everything should go in its correct place and if you use them all appropriately then anyone can audit the project.

Regulatory compliance projects need to show auditable change and therefore this is where the Documenter becomes essential, proving to a regulatory body that we have complied with the ever growing list of rules we need to demonstrate compliance with. 

As for the twenty six documents, that’s nowhere near enough sometimes.

The Controller

These project managers are quite common and one could even argue they are the most common. This is NOT however, a micro-controller of people, more a controller of things, parts, components and/or modules. They love to keep things under change and version control, everything is clearly (to them) named and numbered. They are probably not what we would call a ‘people person’ they can usually be spotted by their use of email to communicate almost everything.

If your project has strict cost control requirements, in commercial contractual obligation projects which require this, then the Controller is for you. If something changes, they are the ones who will be able to demonstrate the impact of the change and the dependency networks they are able to prepare help to manage complex situations amazingly.

The Diplomat

Diplomats are able to negotiate with a broad range of complex stakeholder demands. Stakeholders come in all sorts of shapes and sizes and whilst not all projects have complex stakeholder mappings, they all have an impact on somebody somewhere, if they didn’t they probably wouldn’t be considered a project anyway.

Diplomats are needed in highly politicised environments and there are many types of those in the public sectors definitely but also in the private sector where senior managers and possibly shareholders will need pacifying or reassuring during a change to any business.

The Expert

Most project management methods take an approach that states a project manager needs to be an expert in project management, and if they become good at that, then they can manage any project anywhere without technical skills. This may be the case, but this is not the Expert we are talking about here.

The Expert has a deep understanding of the complexity of the work involved in the project, they know the in’s and out’s of the technical processes and procedures. They many be experienced software developers moving into management, they may be building site supervisors who have come up through the ranks, they could actually lay bricks and write code themselves if push came to shove. If your project has experts who like to confuse us with jargon, the expert project manager is for you.

The Hero

Finally, this project manager is the one who’s documentation is out of date at best, not produced at worst. Their plans are drawn on flip charts and whiteboards. Nothing is named or numbered properly, they understand nothing about the technologies, they couldn’t really care less about the sensitivity of the political masters who they view as parasites anyway.

But, they get things done, they are able to relate to the people doing the actual work, they inspire and trust the teams at the coal face. They will take them out for a beer if needed, organise a sports event or something similar. They work incredibly hard in the background to remove any blockers and give all the credit to the team who they allow to self-organise. Sounds like a PRINCE2 Agile project manager?

There is one more type of project manager not yet mentioned, the Perfectionist, they combine all the above when the time is right.

I hope you enjoyed this, please share it if you did, and comment below either way.

Here’s some simple tips on how to make your portfolio office more agile (simply)

Agile PMO's (Simply) - Apple iBooks

https://www.amazon.co.uk/dp/B0BH5477LM - Kindle edition

If you want a book that takes a very simple view of how agile can be used across an organisation to deliver essential changes. 

There are other views of agile, all tend to be complex and very detailed and this leads to confusion and inevitable conflict.

Agile Risk Management Approach

 PRINCE2 Agile Risk Management Approach

Introduction

This document describes how to manage risk within an agile/PRINCE2 project environment.

Risk management procedure 

 

Tools and techniques 

Identify risks using the PRINCE2 Agilometer 

Records

The risk register should be visible and clear for all to see and use, like this one:

 

Each risk should be written on a post-it note and put onto the whiteboard in it’s appropriate grid location, depending on the probability/impact assessment

Reporting 

Risks will be discussed during daily standup meetings or with the project board when they visit the project room.

Timing of risk management activities 

At the end of management stages, after any significant release, a re-assessment of the environment using the agilometer will help. However, risks could be identified and discussed at any time.

Roles and responsibilities 

Everyone is responsible for identifying risks and everyone collectively should help the manage risks, however, some would need escalating for further help, see the risk tolerances below.

Proximity 

How close a risk might happen is referred to as its proximity they can be categorised as: 

    Imminent - will potentially happen within a sprint, 

    Within the management stage, 

    Within the project, 

    Beyond the project - after release into operations

Risk responses 

We can respond to risks this way:

 

Early warning indicators 

The project manager and board could monitor the behaviours of the team and look to see if they are appropriate, and the team should monitor their own behaviours openly and honestly.

Risk tolerance 

The team can manage risks that are in the purple boxes themselves.
Risks in the blue boxes should be raised and discussed with the project manager.
Risks in the yellow boxes should be discussed with the project manager and project board.
Risks in the red boxes should be discussed with corporate management.
Security risks should be raised with the cyber security team no matter where they are on the grid.
Health and safety risks should be raised to the department H&S officers.
Reputation risks should be funnelled through the communication management team.

Risk budget 

Due to the low risk to delivery, a risk budget is not necessary.

Here’s some links to simple tips on how to make your project or programme office more agile (simply)

Agile PMO's (Simply)

https://www.amazon.co.uk/dp/B0BH5477LM

Outputs, Outcomes, Benefits & Dis-Benefits are Agile?

There has been several discussions about the correct definition of these words but most seem to understand that an output would be a deliverable from a project which lead to outcomes when something changes and these things should be beneficial in some measurable way. 

Dis-benefits are negative outcomes that almost every change experiences in some way. I’ll come back to these. 

Let’s take an example that differs from most of the examples provided. 

Locally we have had more freezing temperatures lately and the footpaths have been dangerous to walk on, particularly for elderly or disabled people. 

Our local council has done nothing whatsoever to make the footpaths safe and ice free. This is a true statement but the objective of this blog is to help understand the reasoning behind the relationships rather than critical of the council.

Let’s launch a project to grit the footpaths.

The main roads are gritted because they are legally obliged to do so, that is out of scope here.

Government is trying to discourage us from driving in many ways but if we don’t drive to work we need to walk or cycle, so there is a clear need to do something otherwise we will all be driving again. I am personally biased here because I am one the very few who is in the fortunate position of actually walking to work.

The output is a little intangible but we could state something like “Thawed footpaths” or “gritted footpaths” 

Outcome: Safer footpaths, fewer people falling over and fewer people driving which reduces emissions. 

Benefits? These should be measurable improvements in something related to a strategic objective. This is where things get tricky because where’s the benefit to the council?

Fewer people falling over and getting injured is a benefit to the NHS and the individual concerned, and we could argue that this is not a benefit for the council, even if it should be. 

Fewer people driving to work is a benefit to the road capacity but how much money is actually saved by a few less cars? Even if 50% of drivers decided to walk? Savings in road maintenance is probably almost zero. 

Reducing the use of vehicles will contribute to net zero and one could argue that this is a benefit, but where is the cost/benefit analysis.

Where’s the cost/benefit in this? If we are going to invest time and money into a project, then there should be some return on that investment, that is the logic behind project business cases.

Are there any dis-benefits here? Yes, gritting the footpaths would prevent people using them whilst the gritting is in process. 

Let’s look at this in another way, the way that has justified many government projects. 

The changes that the government has implemented to discourage driving particular vehicles, such as the road tax costs based on engine capacity and emissions. 

The congestion charges move the traffic from the city centre to the ring road. Recently they have introduced fifteen minute zones which discourage driving.

Improvements in public transport could be considered an option but many of these have been larger capital projects such as installing trams on existing highways which tend to also discourage driving. That is a huge capital expenditure and I am not sure any have actually paid back the initial investment, but I do not know for sure. I do recall, as a child, my mother taking us to the centre of Birmingham to watch the last ever tram to leave. 

Why did they close the trams? They were too inflexible in a rapidly changing cityscape. 

This blog, like lots of projects has drifted in its scope, away from why the local council did not grit the footpaths, but in a nutshell, there’s nothing in it for them.

Congestion charges, equals more revenue.

Fuel price hikes, equals more revenue.

Road tax based on engine size, equals more revenue.

Fifteen minute zones, equals more revenue.

Trams discourage driving and encourage public transport also equals more revenue.

Bus lanes mean more revenue for the buses that travel along them and the additional traffic congestion uses more fuel and therefore also equals more revenue.

Gritting the footpath does not equal more revenue, it equals less revenue from fuel tax.

Investment in Outputs, is one thing, if nobody used the footpaths after gritting, we’ve wasted money.

When people change their behaviour, they walk to the shops or work and we have the outcome we are seeking.

Those outcomes lead to measurable benefits (and this is where some manipulation of the financial rewards takes place)

In an agile environment the developers would decide that the output had value for a customer somewhere, not necessarily as a cost/benefit business case, but it has value.

Therefore we could argue that agility is more likely to achieve the long term outcome, because they are prepared to invest without an immediate return on investment.

Here’s some simple tips on how to make your project or programme office more agile (simply)

Agile PMO's (Simply)

https://www.amazon.co.uk/dp/B0BH5477LM

There's No “i” in Team

 What it is this statement meant to do:

To help people understand that they can perform better when working as a team and taking the views of other team members into consideration. 

Executive Summary (of the reality of this statement):

A telling off for anyone brave enough to show some initiative and do something that the boss didn’t tell you to do. Daring to have an opinion. Disagreeing with the boss.

The detail of this statement in use:

Attempting to locate the source of this statement is quite a challenge because almost every manager and, more appropriately, management consultant, has used the term, but all would deny it. But, if they hadn’t used the term it wouldn’t be as well known.

Some people work better in teams, some work better alone, not everyone appreciates how important it is to work in a team when in business, almost every type of business requires team work, almost everybody would benefit from working in a team and almost every team is made up of individual characters.

The term has been used a gentle reminder to team members that others have some value too. A reminder that a team can only perform to its peak performance when we all work together towards a common goal, optimising performance of the individual by working as a team.

I was a manager of project managers at one time and during a particularly fraught team meeting, desperately trying to get them to manage their projects in some standard sort of way, so that I could plan and prioritise the project portfolio. Back to the story, well, I was getting more than a little frustrated with the constant excuses why they couldn’t comply with my perfectly reasonable request to standardise. 

I said it, “THERE IS NO i IN TEAM”

They looked at me in horror, stopped them dead in their tracks, they were dumbstruck.

Then one of them replied:

“There’s no F in team either”

Here’s some simple tips on how to make your portfolio office more agile (simply)

Agile PMO's (Simply)

https://www.amazon.co.uk/dp/B0BH5477LM

Expose or cover up?

Should a PMO Expose or cover this up?

This is not a 100% true story about a PMO but it is factual about the sustainability of biofuels.

In my neighbourhood I walk my dog and my daughters dog whenever I can. We’re lucky enough to be just 10 minutes walk from open countryside. 

Around ten years ago the government funded a biofuel power station 25 miles away and since then the fields around my town are now covered with a biofuel which locals call elephant grass I’ve no idea what the correct biological name is. 

The fields previously grew food crops that changed each year to keep the soil fertile. Today the monoculture biofuel is grown every year and cut down with huge machinery and then transported in massive bales by the truckload on a 50 mile round trip to the power station. In addition, the soil structure seems to be degrading each year and, rather bizarrely a local farmer was prosecuted because the biofuel once cut into little pieces is considered a pollutant. 

That’s the background, now we come to the dilemma for the fictional PMO particularly now we have an emphasis on ESG (Environmental Social Governance) 

These fields have huge irrigation systems that were used when the biofuel was originally planted, but after the first year or two they are now sitting unused, rusted and degrading. The electric motors on every wheel base have no doubt copper coils that are seized never to turn again. They have large rubber tyres that are potentially polluting the ground around them. Plastic pipes for the water are broken by the summer sun and winter frost. 

These are massive, and the photos don’t really show how large they are. The one dog that you can see is about 3 feet tall to give some perspective. There’s three of these devices in the one field all sitting doing nothing anymore. 

The dilemma for the PMO is about the ethical decision to expose these dis-benefits or not?

I see the choices being:

1. Let everyone know that claiming that this biofuel is sustainable and environmentally friendly might not necessarily be true. 
2. Keep the information quiet because the long term effects are more important than the wasted energy used to build the structures, they have been funded with taxpayer subsidies and to move it requires even more. 
3. Capture lessons from this and make sure it doesn’t happen again. 
4. Measure the amount of carbon saved from fossil fuels while ignoring the fossil fuels needed to produce the structures and transport the crops that way we can contribute to net zero. 
5. This is not a PMO issue, the project has finished its now a problem for business as usual operations.  

They’re maybe some people who will dispute that this is the case because they see anything green through rose tinted spectacles so here’s another photo showing an oak tree growing to approximately 9 feet tall and they grow at a rate of between 1 and three feet a year after two years of acorns sprouting and establishing themselves. 

What do you think a PMO should do in this circumstance?

Is this one of the reasons why the latest P3G portfolio governance guidance from the TSO includes a principle to separate decision making from stakeholders? 

Finally, does biofuel contribute to net zero, if so how does it NOT emit CO2?

If you want to be greener I wrote a little help to help you be the change you want to see:

https://apps.apple.com/gb/app/ru-green/id6444596173

Here’s some simple tips on how to make your portfolio office more agile (simply)

Agile PMO's (Simply)

https://www.amazon.co.uk/dp/B0BH5477LM

User Stories in project management and more...

 User Stories

Agile teams use a concept called User Stories which is a simple concept and structure:

As a … (role)

I want … (some feature)

So that … (some value)

Here’s a reasonable example

As a project manager

I want scrum training

So that I can improve my relationship with the developers

That would NOT be considered ‘Ready’ because we have no idea what effort is required, no idea what level of training is needed, no idea about the current relationship and no idea what type of projects they manage. Once we have this information the User Story (or Backlog Item) would be ready for someone to start work.

The structure of a user story is simple enough and can help a team understand how features add value. 

As a phone user with an almost flat battery 

I want my charging lead to not work because it is not an official Apple one

So that I am unable to use it until I get home. 

As an ear bud listener 

I want to have to re-select them

So that I keep the caller waiting for a response. 

As a music listener 

I want to be deafened by the screen off button 

So that it disturbs my listening pleasure 

As a LinkedIn user

I want my posts scanned for political content

So that the fact checkers can check the checkers

Edit Jan 2023: 

As a MacBook Pro user

I want a software update that crashes the thing at least once a month if the battery get low 

so that Apple can force more updates on me

Now of course most of the above stories are not real ones, but it is an interesting way to see the value that user stories hold, and here's a little tip, if you are raising a help desk ticket or logging a complaint about anything technology related, try using the user story format, you would be surprised how the support teams will react.

As far as a PMO is concerned, the user story concept is a great way to start thinking about your projects and programmes, it gives a very clear vision from day one.

Software developers might balk at some of the user stories, complaining that they are too large, these are called EPICS, but the format is the same and epics get broken down into smaller user stories in a similar way to breaking our projects into stages and programmes into tranches.

User stories are similar to PRINCE2 product descriptions, the main difference is that a product description is usually a document formally signed off and agreed. User Stories are a starting point they do not fully define anything, they encourage, deliberately, further discussion with the customer or product owner. How is that any different from most project mandates?

Agile, scrum in particular, starts with the premise that the work has already been justified in someway. User stories include the “so that…” which implies value is being delivered and one could argue that this does, to some degree, justify the work. Also the product owner and customers have asked for these features to be developed which also justifies the development. The danger for project and programme managers is they try to put measurable benefits on every user story, this is usually not needed and the bigger picture project is where that should happen, not at the detail.

I hope you enjoyed this and gained some value from it, should I put any measurable benefit on that value? 

For more help on how to make a PMO (Simply) more agile please try this:

Agile PMO's (Simply) - Apple iBooks

https://www.amazon.co.uk/dp/B0BH5477LM