Project Management Central

Please login or join to subscribe to this thread

Topics: Agile, IT Project Management, Organizational Project Management
Facilitation and Enabling vs Managing and control

In 2018 my co-workers joined 2018 Gartner Summit. One of the slides that they are sharing around the organization has a a title:

Facilitation and Enabling vs Managing and control, that seems perfect, no complains from my side. As a project manager we need to facilitate and support our team.

My big frustration is that after the title there are two columns:

Traditional Project Manager vs Agile Project manager.


I plan the project and resources.
I allocate or oversee the tasks.
I track actual versus planned.
I report to senior management.
I want to remove risk early and have clarity and certainty.
I am focused on time, budget and scope.
I am about managing and control.
I use the practices of Princes 2 and PMI.

Agile Project Manager
I support the team's intentions.
I remove impediments.
I help communicate and liaise with stakeholders and other teams.
I help navigate risk and uncertainty.
I help maximize value and opportunities.
I am about facilitating and enabling.
I respect the values and principles of agile.

The peers that interacted with me a few times in this site will know why I feel frustated each time that I try to explain that there is not traditional vs agile, that we are project managers and as a project manager I try to add value to my project and help my team and I don't spend all my day checking if we are on track. My co-workers and ex-coworkers know how passionate I'm about project/program management, however after a few attempts to explain why I saw this slide as toxic and not nice to share with management because if you aren't familiar with PM's, SM, BA's and their roles and responsibilities it can create confusion.

1- What are your thoughts about the slide?
2 - How I can debate with my peers about it?
3- Do you think that there is a "traditional" project management?
Sort By:

My first reaction is to say that Facilitation and Enabling vs Managing and Control has nothing to do with "traditional" (whatever that means) vs agile, it has to do with good management vs bad management. If I may borrow from the Agile Manifesto, it's not that managers never need to take control, it's that good managers focus on enabling, developing, and supporting their teams instead of micromanaging them.

Now I jumped on the Agile train a long time ago and I'll happily explain why to anyone who will listen, but the slide as you present it reads more like a consultant's sales pitch than an actual description of job duties. Regardless of how agile your organization is, they will expect planning and reporting from their project managers. This slide makes it sound like "traditional" project managers don't support their teams or remove impediments, and that "agile" project managers don't plan ahead or report up. All of these generalizations are false.

I agree with Wade: Facilitation and Enabling vs Managing and Control has nothing to do about project management "categories".

A proficient project management practitioner understands that projects require all four of those coompetencies. They are not opposites. They are leadership qualities that we need to learn to balance. It's what makes it situational leadership.

I think we have to distinguish an agile mindset which all PMs should possess from experience managing projects using an adaptive or agile lifecycle.

Thank you for your comments, I can't attach the slide, but thank you Kiron, Stephane and Wade, you comments make me feel that I'm not alone.

I think the slide is fine but taken out of context. When creating presentations, that are going into depth in some part of a subject, it is very helpful to have some slides to level-set what you are talking about. I could see that as the cartoonish depiction of both ends of a spectrum; there could be a 5 minute discussion behind it.

If you look at the top column, it is all about the project. If you look at the bottom, the actionable verbs are all value or people. Every time I've been given leadership training opportunities, they always stress managing vs. leading in the same sort of way.

I see "Traditional" PM as the structured formal set of processes and documentation that evolved over the last several decades, along with systems engineering. Everything is logically decomposed and documented in the right places and carried out as prescribed, or the documentation has to change first.

Based on prior problems, there is always a push to find and address problems much sooner. That pushes the process requirements earlier, which greatly inflates the SOW. You can't just talk it out and agree; you have paperwork and change boards and more process than change.

In my opinion this has nothing to do with agile vs traditional project management. This has to do with the level of formal authority the PM has as well as his domain knowledge and his own management style.

Most PMs have no formal authority over their project team members, and it is not uncommon for some team members to be more senior than the PM. Also, many of them lack domain knowledge. A PM in such a situation can't use a more directive style of management no matter the project uses Agile or a more traditional project management method.

A PM that has limited authority over the team members and limited or no domain knowledge can only support his project teams and act as a facilitator rather than a command and control type manager. This is true even in Waterfall projects.

A PM that has extended formal authority and good domain knowledge can choose his management style so at his own discretion can either be a facilitator or a more directive leader.

First thing to say is: there is not "traditional" and "agile" project management. Second thing to say is no matter the environment you work you will perform all things you put into the list.

The slide does not set a good tone. Independent of the approach, the role of a project manager is to adapt behaviors as necessary to best address the needs of the team at that time. Faciliation and enablement are not restricted to a specific approach to project management, rather, a core competency.

Please login or join to reply

Content ID:

"If a man will begin with certainties, he shall end in doubts; but if he will be content to begin with doubts, he shall end in certainties."

- Francis Bacon



Vendor Events

See all Vendor Events