Project managers generally fall into two distinct types: facilitators and demanders. As someone who has worked for project managers as well as having them work for me, I feel confident making this distinction.

Facilitators

Facilitators actively contribute to getting tasks done. They play a hands on role in delivering results and often get involved in the finer details of the project. Their effectiveness is apparent when they go on holiday: productivity may slow or even halt because their direct involvement is crucial to progress.

However, facilitators have a notable weakness—they are often too immersed in the process. This closeness to the “coalface” can make it difficult for them to maintain an overarching view of the project. It can also hinder their ability to transition seamlessly between projects since they are deeply embedded in the operational details.

Demanders

Demanders, on the other hand, take a more removed approach. They don’t do much hands on work themselves; instead, they push, chase, and pressure others to deliver. Their value lies in their ability to maintain momentum, as they often accelerate delivery timelines by holding team members accountable.

Interestingly, when demanders go on holiday, tasks may still get done—albeit at a slower pace—because their presence primarily serves to keep pressure on the team. Their absence gives the team a breather but doesn’t stop progress entirely.

Distinguishing the Two:

At first glance, it can be hard to tell facilitators and demanders apart. However, their behavior and approach reveal key differences:

Facilitators:

• Provide actionable solutions.
• Offer hands on help to overcome obstacles.
• Criticize constructively by identifying steps to resolve issues, e.g., “This can be done if we contact X and Y to address these dependencies.”.

Demanders:

• Focus on dates and deadlines, and how this effects perceptions of the project by the wider company.
• Use corporate jargon like “root cause analysis” often without direct knowledge of the production process.
• Sometimes use blanket statements: “We’re missing deadlines, This isn’t acceptable”.

Ultimately, facilitators are deeply engaged in the delivery process, while demanders rely on oversight and pressure to drive results. Recognising these distinctions can help organisations understand how to better utilise their project managers for different challenges.

As most companies and corporations start pushing everybody slowly back to the office full time ¹. It turns out that there are a couple of hidden and not so hidden costs to this, and moreover, they only effect those that are good at remote working.

1)

If you are an efficient remote worker, you plan your days out, and tend to actually commit the same amount of hours to your day working from home as you would for a full office trip.
To explain that better. Once I have my shirt and tie on, I am in work mode. If I’m in my home office, that means I can use that time for calls, emails or genuine work. From my client office, however, that means I waste the first and last 30 to 90 minutes of that day travelling. ²

On a number of international projects I have been a member of, it has reached the level requiring H.R. involvement for permanent members of staff, as meetings that have been going on successfully for years at the very beginning and end of the day due to time zones, suddenly have terrible attendance because people are travelling during those times.

2)

A far more insidious impact, and one that both helps and harms the delivery of work for corporations but requires a long term view , is the time taken to actually socially collaborate with your fellow office drones.

If I go into an office with a clear list of things I’m going to do and how long I will take to do them, i will have to add about 2 hours to that estimated time because I’m sharing a work place with fellow humans not just loud motivational music.

And if you only think like that, for a full week in the office, I would loose 10 hours worth of delivery just being a paid up member of the human race ³.

But then it starts to get complicated. Sometimes, a quick face to face conversation solves hours of meetings and emails, an over heard chat 2 desks down stops you making a costly blunder or makes you aware of something.

All this variance means that there is no clear absolute winner for the move back to the office and no one size fits all. But the points I take away having to manage it for both clients and team members are:

• Full time in the office hurts the productivity of efficient or hard working people, give the people that plan their days out at least 1 day a week to get their head down and clear backlogs.
• Measuring improvement based on being back in the office is a long term game, as in the short term there is often a drop on what people actually get done.
• Much as it is irritating to some team members, if you have made them come in, then make them sit together as if they all go an hide in little booths and corners you have just made the whole thing pointless. If they state they need that space then let them work from home and move to a more delivery focused measurement of work to try and evaluate that.
• Realize that people are different and just because you as a manager like everyone sitting around you, does not mean that others do and are more productive that way, you are not helping yourself by pulling such people in.

1. .Denials from the powers that this is not the case are not fooling anyone[↩]
2. with a bit of emailing done on my mobile.[↩]
3. .ignoring the lost hours due to travelling from point one[↩]

White glove service, is a service offered unofficially within a corporation or large company for items that are classified as important from a business or process point of view, but don’t have a genuine importance from a hardcore finance or business impact.

An example of this would be if you had an issue that would stop a project release to production. This is very important to a project and to the leadership team, but does not result in an immediate financial or regulatory cost to the business. Therefore, you could not merely raise it as a Severity 1 issue, and let the existing incident processes manage it.

These needs however are important, but not in a traditional sense, and you need what is often called a white glove service to deal with them.

What does a white glove service consist of?

A white glove service consists of a number of allocated, named individuals. These then take responsibility for issues, they will own such issues and work with the stakeholders or people that raised them to ensure that they are completed.

At no point until the issue is resolved can they let go of it, even if it’s beyond their control, they have to hold on to it until It’s completed.

• They do this by ensuring departmental walls are breached to reach a solution.
• They consistently provide reports to the stakeholders, even if there has been no change to report (often the update period required by a stakeholder is far more frequent than there are updates to provide). Communications, however, must be managed.
• They must be effectively on support call. There is no clocking in and out if an issue is raised, regardless of when it is, they must respond. (It is recommended that there are at least 2 named individuals for each of the 3 main global time regions. Asia Pacific, Europe, The Americas to cater to this).
• They must maintain trust between the different areas of the corporation , if such a person comes seeking a teams assistance, it will be for a genuine reason.
• If the issue is caused by a process or other genuine reason (and not merely poor stakeholder and management planning), they must produce a root cause once it is complete.

Skills needed:

Strong areas of knowledge: it must be at least 2 of the following:

• Business process knowledge and what is important to the business.
• I.T. knowledge in order to be able to negotiate with the various silos within the corporation
• Internal process knowledge, who to go to, where to go to, what processes need to be done in a perfect world,

Things a White Glove service must not do:

• Use up the time of valuable subject matter experts: they must not occupy more time than they save for existing resources, and should stand in for technical and business people on calls to actively free up time to complete requests.
• They must never be seen as a threat, only as an assist. They must never use words like escalate or name drop, or anything that triggers a defensive reaction.
• They must not devalue existing processes and people, to do so will just make the problem worse. They must always be someone who can explain the truth to power.
• Just become a status report proxy, they do not ask subject matter experts to do any admin tasks, they take on such activities e.g. ticket raising, and allow experts to complete genuine work.

How do you get people to do this pain in the butt role in a corporation:

For External Staff Members: Money normally does it for both independent contractors and vendors; they are happy to do this function and do it well if the price is right.

For Internal Staff Members: A stint on the ‘white glove’ service grants broad understanding of your company’s needs at a practical level and shows commitment, this can be used on yearly evaluations, and helps to identify people who should be fast tracked.

Back in the old days, we had very strong development to production demarcation rules, and this was very simple, because there was very little integration. In fact, usually the only time that we had blurred lines was the use of email, where if you got a test email wrong, it would escape into the world and cause never ending troubles.

Then along came the cloud. The cloud comes with its ability to spin up multiple instances of the same type of environment to apparently make the lines between Dev and all other environments very clear cut.

But inside a corporation, you’ll find that this is not the case, because underneath all of your nice, neat environments there is the same infrastructure with the same shared services, so you soon find out that when you request something, what you think is a simple and limited development environment request will actually mean weeks of justification and the full change release process.

The most common of these is firewalls. If you want to open a firewall between you and another environment, such as a vendor service. That is actually a change to a production area and will be treated as such. You will find this will be true of most network situations, and particularly with most data transfers to things in the cloud, which will even for simple proof of concepts require sign off by your security services. So if you are planning that, do not assume that a request for dev access will be instantly acted on, you will have to do the same justifications, as if you were dealing with production.