What is the big picture of Project Management?

In this episode, we share our thoughts on the Big Picture of Project Management.

We start by sharing our agility, resilience, and agile development story. Here, we discuss the ideas and approaches to developing products, including Big Bang, Iterative, and Incremental Development.

Then, we offer our counterpoints to some of the myths and narrow thinking associated with waterfall, agile, hybrid, and traditional project management.

We presented the myth of early and fixed detail planning.
Next, we addressed the myth of lack of communication in a non-Agile environment.
We addressed other points that Agilists often portray as anti-traditional Project Management.

Well, traditional project management IS project management. It has always been adaptive!

Speaker 1: 0:08

Welcome to the 4pm podcast. My name is Munir Ajam and I'm the founder and CEO of Aruq Project Management. My core passion is project management and community development. I came to you with decades of global experience. I have worked on projects in various industries, countries and roles. In this podcast, I aim to help you and your organization transform how to lead your change initiatives with the 4pm. What are the 4pm? 4pm stands for project program, product delivery and portfolio management. It is all about integrations to deliver value. We want to hear from you, so please share your feedback and suggestions. Enjoy your listening. Good day and welcome to the 4pm podcast Today's topic.

Speaker 1: 1:12

I'm going to give it the title of seeing the big picture of project management. In other words, in order to see the big picture, we have to respect our diversity. I usually structure my topics and I like to go through a specific part. Today, I'm going to do it freely. It's something that has been nagging me for a while and I feel like I need to get it out. It could be part of venting, but, however, we will always keep it professional and educational at the same time. However, in this episode, I will be offering many counterpoints to some of the misses and the argument that we see online today in the project management community. First, as you know, we call this podcast the 4pm podcast in order to have a view of the big picture, which means project management is all about managing project program product portfolios. It's about establishing PMOs to build the OPM. If you haven't been listening to project management podcast before, you might find these abbreviations annoying, but I'm sure most people here would know. What I mean by PMO is that project management office, and OPM is organizational project management. In order to see the big picture of project management, we need to understand it's in the broadest sense of the term. It's not about managing a single project or managing a task or managing the stage of the project. It is a holistic view of project management that includes the 4pm, as I mentioned, the PMO on OPM.

Speaker 1: 3:09

So before I go into the happy part of the topics, I would like to do a disclaimer, but the best way I can do that disclaimer is through a story. For those who've been following us and following me, they know that I am the founder and CEO of OOP project management, a company we established few years ago to build OOP platform as a digital solution to manage the 4pm. So when we started the company. Obviously I will be doing at UT Data Project Management Symposium in May. I invite you to register and join that event. I will be presenting a case study of founding OOP PM and building OOP platform and that will be a case study that focusing mostly on strategic project management, launching a business startup, program management, project management, agility All of these topics are combined into our case study and I'm just going to give you a preview of that in probably one minute. When we launch OOP project management as a change. Strategic initiative for me and my partners is the idea we started as a business, we use strategic program management, but I'm not going to focus there right now. I'm going to focus on building the OOP platform. If you like to learn the whole case studies, you're welcome to join us in Dallas or maybe sometime in the future you will be able to hear or read my paper on that topic Building the OOP platform.

Speaker 1: 4:33

Here I have to remind everybody of something in the agile manifesto that everybody you know a lot of people understand it differently to mean different things. The agile manifesto and most literature I've seen on agile and the argument for agile talks about basically delivering working software to the customer, adding value continuously. These are some of the principles and values that are discussed in the manifesto the idea of delivering value to the customer, delivering value to the product owner, basically delivering working software. Right, and this is our. I'm stressing this word for a purpose. So, when we started to build the platform, obviously I'm in this case, I am the business, I am the customer for the development team, but I am my customer is you the people who would use my platform in the future? Right, so you don't get any value from my software until you start using it? Okay, and even me, as if I am the customer of the development team, I don't get any value from the software until the team give me a product I can put out in the market. Okay, let's reflect on what I just said. Right, the ultimate customers, the end users. They cannot get any value from the root platform and to subscribe to it. And me, as the product owner or the customer of the development team, I get no value from the software until it's released. I can release it to my customer so I can sell it or deliver value or even grant it right as a free service for people. Okay, so with that in mind when we start to build the platform.

Speaker 1: 6:22

My development team is using Scrum, so it's a form of agile and they do sprint and Instagram it. However, that is not agile project management. That is basically how they develop the product. However, that is not fully beneficial to me. So what we have done is that in the very beginning. Obviously, the first few months is when we are building the proof of concept. Yes, the team were doing a sprint and increment and they were showing them to me and all of that stuff.

Speaker 1: 6:57

However, if we talk about from a business perspective, not just technical project management hat, that is of no value to me. It's accumulated, maybe they're building. It's like when you're cooking a meal right, you start cooking something, you put one ingredient, you add more, you put some spices, you heat, you lower the heat, you do different things and if you try to eat from that food before, either you're going to burn your tongue or you're going to get a bland or tasteless meal, right, so there is no value on that until the full meal is finished and complete and is ready to be eaten. Okay, same thing. So, when the team was working on my proof of concept, they are releasing me. They are building the Lego pieces, they are building the sprint and the item for me to view, to review, to test whatever the case might be. But there is no value until they deliver the proof of concept. Now, I cannot sell the proof of concept, so I'm still not getting a commercial value from it, but at least I can start to get my people, my team, some potential customers, some potential friends out there to test and use. Right, so in a way, that is what we call Big Bang, what we call in a room right, because there is no product. The product was being built in piecemeal, but it wasn't released until at the end of the day, a few months later. Here you go, munir, this is the proof of concept, right, so what we call that in a room again is Big Bang. At the end of the day, one deliverable. And after that point, and we start to test and use, we start to collect information, so we start to basically do iteration, right. So basically, from proof of concept, from the point of a proof of concept to the point of where we have a minimum viable product, right, there will be many iterations because you identify bugs, you fix, you improve something here, you improve something there and you also add increment. Those were actually what we call iterative development, incremental development, or in other words, agile development.

Speaker 1: 9:03

Now, notice, everything I'm talking about here is about development, right, agile development, not the management method, not the project management method. Now, why is this relevant? I can tell you is very clearly. If it wasn't for agility here, not agile, for flexibility, for being resilient as a company, we would have shut down a long time ago. When we started, we started just before COVID hit. Covid affected us significantly because we cannot go out and communicate anymore. People were going through turmoil to adjust to the idea of everything is remote, zoom, whatever the case might be, and at the same time, my partner got sick and later on, died. Then, when we finally get our act together again, we resumed our operation. All of a sudden, money dried out, invested and not investing anymore. So if it wasn't for us to be extremely resilient, agile or being, you know, adapting agility to the maximum, we could have shut down a long time ago. However, we are here today.

Speaker 1: 10:13

So in this story I shared with you, I've talked about agility and I've talked about agile development. Notice, it's not agile project management. I must repeat that it's not waterfall project management right. That is where we can work in an adaptive way. That's why we always and as a recent article, the episode we published we talked about basically project management, traditional project management has always been adaptive. It's not waterfall.

Speaker 1: 10:48

Now, with that story in mind, let us move to the next part of the discussion, which is some of the argument we hear from agile a jealous promoting agile project management. Recently, we're seeing a lot of trend for hybrid and even, jokingly, we've seen something called digital project management and I don't know what else. There are many things out there. Now, what are some of the argument they always make? That they are so much more than just a little bit of a joke that they are the best, they are the answer, they are the future, right, and waterfall traditional. All of that is garbage and we should throw away. One of the things they talked about is that we often talked about is that, oh, waterfall is bad because the plan is fixed in the front.

Speaker 1: 11:43

We spend a lot of time detailing, planning, doing getting charged, doing extensive detail and then, at the end of the day, basically we fix the plan and we're not allowed to change, and if we need to change something, we have to go back all the way. Well, obviously, clearly, anyone who is listening now, who have worked on capital project or work in many industries, understand that some of that stuff is bullshit. And I'm going to be straight bullshit. Why? Because we never do that way. There is nothing there is where we never work on something called fixed plan. We work in very early stages, very detailed planning. We do something called PMI used to call it progressive elaboration and unfortunately, even PMI forget where they came from. In the Pomba guide they used to talk about progressive elaboration. In my community we didn't use that term, but that's a good term.

Speaker 1: 12:41

We call it rolling wave planning. In other words, when we start the project, we try to visualize it even at the idea stage. As a good, competent project manager, we visualize the whole project. In a way, we'll have a very high level plan for the whole project, but it's very high level. It's more about we need to do this stage before this stage, before this stage, or we need to do this, or these are some of the key decision points. That's it. Then the project manager was done and said what do I need to do? I need to focus on what I need to do next, the next three weeks, four weeks a month, I will come up with more. Maybe I need to do stage. For the first stage, I need to have a semi-detailed plan. Then I'll have maybe a detailed plan for the next week or two. This is what we call rolling wave planning. We do this part.

Speaker 1: 13:31

When we start a new project, we start with the concept, the statement of work, and then we collect requirements, we evolve. Even when we finally have a relatively planned that we can use to go get funding, that plan is not fixed. Once we go into implementation, we implement something called change management, project change management, where any ideas for change it's collected, reflected on, reviewed and approved or rejected. This is one way. There is nothing set in stone. Detailed plan in the beginning and then if you move a second out of the plan, everything will fail or you'll have to go back and do everything again. This is a lot of garbage that is being promoted. The problem is because it's being promoted by people who probably never done it, or actually they're saying this is bad, but they've never done it so they don't understand it and yet they label it as bad. So, fixed plan, it's nothing. We do something called rolling wave planning, progressive elaboration.

Speaker 1: 14:44

Another argument we've seen from agile people in the past is talked about basically, oh, there is no customer interaction except at the end point, like at the beginning and at the end. I work in capital project, which is highly predictive and, if I want to use the language these guys use, I spent 15 years in that industry in the oil and gas industry, petrochemical industry and I can tell you, in the first 10 of those years, eight of them was working out of the contractor office. Now reflect on that. What does that mean? Remember the argument oh, we only customers and contractor only talk at a certain milestone. Right, we were working from the same office. You know what that mean? That mean we see each other for breakfast and dinner and sometimes even on evenings and weekends, and we do team building together. We're always together. If I want to talk to my counterpart, I was on the owner side. I want to talk to my counterpart on the contractor side. I just walked down the hall, I grab a cup of coffee and we chat. It's not like we talk about, you know, once every blue moon. We talk regularly. We have weekly meetings, so it's a continuous interface. So again, the people who argued that in waterfall, or predictive or traditional, there is no communication. Again. Another bullshit. Later on I will stop saying that. I'll say BS and you get the picture.

Speaker 1: 16:24

Another one that a Wanderer's PMI came up with a few years ago is the idea of predictive. Oh, we have predictive and adaptive Again. What a piece of C. You complete the word. What is predictive? Yes, if I want to build a building, I'm predicting that I want to have a building. But can I predict my performance? Can I predict that I will be delivering the building exactly? Can I predict, or I'm certain, that no changes will happen along the way? It's impossible.

Speaker 1: 16:58

Yes, we follow a certain methodology. There are certain things that guideline rules, ground rules that we must follow, but there's nothing we can predict. I mean ideally, yeah, I mean we predict what we like to have Now. Would we have it Exactly as we imagined it? Most likely no. Would we have it for the same costs and schedules that we exactly imagined? Probably not right. So what does that mean? Let me predict it doesn't exist.

Speaker 1: 17:30

We go back to the idea that traditional project management has always been adaptive. I keep repeating this and I will be repeating this probably for the next. And the lie die. Predictive doesn't exist. Adaptive project management is adaptive. We follow competent project manager that work an organization with good, mature system. That's how I define traditional project management, because there is no clear definition. A lot of people equate traditional to waterfall. I don't agree with that. Right To me, traditional is the way we've always done it, as competent project manager working in an organization with good, mature project management system, which mean we understand they need to be adaptive, to be flexible, to be dynamic, to allow change where it makes sense. Again, where it makes sense.

Speaker 1: 18:23

We're just not gonna add changes and allowing scope creep and allowing no planning and no estimate and a lot of that stuff that we've been hearing. We will not. We need to have some structure. If you drive on a highway, you might over speed, you might drive a little bit crazy, right, but as long as maybe you're breaking the law. But if you're breaking the law with a reason, right. If you're deviating with a reason, police will probably let you go. If you go become crazy, then when police need to maybe step in. So there are some ground rules and some rules that we can deviate from somewhat, whether we are driving, cooking or building project. However, there are certain rules we cannot violate. So we need to establish the ground rule and we define what is set, what is standard, what must be followed and what are those things that are flexible and we can change.

Speaker 1: 19:16

The third miss we talked about, I just repeat, with the first miss. We talked about fixed plan. Second one we talked about no customer interaction. Third one I just talked about predictive versus addictive. Adaptive I was going to say addictive. Maybe some people are addicted to being so.

Speaker 1: 19:34

Now time for the first one servant leader. How often we see all of these debate about, ah, the scrum master is a servant leader, the HI Goche is a servant leader and they probably dictators in hiding. I don't know right, but what I know is that since when servant leadership is a project management topic? Okay, or if it is, I mean, obviously servant leadership is a leadership topic which is extremely relevant to us in project management. But these people who promote servant leadership is an agile thing. What do they think? We think we are on the capital project industry or the traditional people who follow traditional project management dictators?

Speaker 1: 20:21

Command, and they do think that way. That's why, at some time, we hear about command and control. What command and control? Command and control is a management style that existed years ago and is dead. No one. I've been working for 40 years and rarely where we have command and control. I don't remember ever working in an environment where I had to be, you know, the boss order me and said, yes boss, yes boss, yes boss.

Speaker 1: 20:49

There's no command and control. People are human, they're intelligent, they have input, they have value, they can weigh in, they are part of the planning, right? Except in situation, maybe, where there is a need to be more directive. That depends. That's not. I had nothing to lose. Project management. It's all situational. Actually, leadership is situational. Sometime I need to be a servant leader. Sometime I need to be more directive. Sometime I need to be more supportive. Sometimes I need to be just a friend and a coach or a mentor, right. So that is what servant leadership.

Speaker 1: 21:24

But who made it exclusive agile thing? It's in every industry, in every domain. It's up to the management and organization culture and the people involved whether they follow. That has nothing to do with the methodology Number five, self-driven team and self-managed team. Whatever the case might be, how does that work?

Speaker 1: 21:43

I walk down the street and I see few looking people and then say, hey guys, why don't you come and work with me and we will have a project? And you know, come with me and then we figure out a project. Maybe Hekasson work that way. They bring in strange people together, say, okay, think about something, but at least somebody will give them a theme. Right, it's not like this.

Speaker 1: 22:02

People work in an organization. They don't decide on project. They don't decide that A, b and C and D are gonna work together on project X, okay, and F and G and H gonna work on project Y. We don't do it that way. Organizations have culture, have structure, have sponsored. When we work on project, we assemble a team to work on something. Now, whether we are an eye and, by the way, there is no one team If we follow project life cycle across the life cycle, stages from beginning to the team will change. We might start with a business team, with a market research team, then we might come up with maybe Design team, then we come up with maybe with an engineering team, so the team change over the life of the project. Now, if you are working on a stage and that maybe I need to, probably I will end. This forecast was going back to the idea of respecting the diversity and project management level is that the team would typically change unless you are working in one stage when we come together and we work.

Speaker 1: 23:05

But even with that, let's say you are an IT department and you come together to work on a project and that project is you call it a project and the reality you are working on a piece of the project because you might be implementing a software or an app for the HR unit or for the finance unit or for the engineering unit. So in a way you are, you receive that project after it has been deliberated for a while and guess what, when you start your project, you are probably starting with a product backlog, correct? Where did that product backlog come? From? Ghosts? No, it came from the product management team, the team who did the development of the concept, the requirement for the product. Before that they should have done the feasibility for the product, before that they should have done the business case of the project. That is traditional project management. If you are only involved in one piece of it, which is a stage or managing a few tasks, that does, and then you see that as project management something is wrong, then in reality you are working from a narrow perspective.

Speaker 1: 24:26

Now here I need to share a fun story quickly before I go back to respecting our diversity. One of the reasons I called this article, this episode, is that the big picture. Recently someone and, by the way, this, this episode, is not a response to a person or to anybody, just the title was triggered by one person that basically posted something about the new innovation of the project, the new innovation of project management, the great project management, the future of project management is digital, using Trello and Jira is that is the future of project management. That's the amazing discovery these people find that are each so when I basically commented to that person, that person basically a joke responded in a way, in a very insulted way, that basically that I'm old fashioned and I don't see the big picture. I mean, after you know, I was going to do this at the beginning of the episode and I decided to put it at the end because, as you see, when I'm talking about is that we need to see the big picture. We need to see the big picture which is a project.

Speaker 1: 25:32

Start was an idea, not with the product backlog, unfortunately in the agile movement and now the hybrid movement, or maybe the digital movement, right or the movement, I have no idea. Every day we keep coming up with a new flavor of you know, of this ice cream and then we lose sight of the big picture. Yet those people who are coming from an extremely narrow picture see people like myself and I'm not alone in this as old fashioned and don't see the big picture. The big picture is to understand project management is not limited to software development in a service provider organization. I mean, most of what we see today come from that angle, from that narrow angle. Software development service providers that mean they're not even the project owner. Because if they were the project owner, they will see the project from the idea, from where it originate, from business planning, from HR, from finance, right Project start. There there is a business case start, there is a feasibility study that need to be done. After that they need to define the business requirement, they need to define some technical requirement. Then they will end up basically with the product manager and the product owner and developing the product backlog. Then we get hey guys, I T come on board and start building right. So when we see things from that angle and projected to mean the whole thing, that is where we are narrow minded and we are not seeing the big picture, and this is very important. So, again, this is not about this person. This is about many of the argument about the agile people who say agile transformation you must transform or die or who need project manager anymore. Now we have scrum masters, right. All of these argument in the way that we've seen is misleading.

Speaker 1: 27:22

Now I said I'm going to close was going back to my respecting, my respecting our diversity. First I go back. I did a an episode on this before and that episode I talk about the project management level as five level Task management, stage management, technical project management, product delivery management and value delivery management. How well are respecting our diversity is not limited to the PM level is also about understanding that we need to manage project as organization. We're not here as individuals. We need to understand the four PMs. We need to understand what the organization project management systems all about. Right. We need to understand that project don't come only from it service provider. Right. Project could be in pharmaceutical, could be in medical, could be in defense, could be in oil and gas, could be a renewable energy, and every sector, every type of organization have its uniqueness. So we cannot take what the software or it service provider view of the word, which seems to be dominant in organization like the am, I and others Okay, control the big picture of project management.

Speaker 1: 28:34

That is where we spent years and decade of my life in my career focusing on something about the idea of tailoring which I did not invent. Bill Duncan and the 1996 edition talked about tailoring. I don't know if he invented it or he bought it as well, but we built on each other right. This 1996 edition of the Pumbak focus greatly about tailoring and the need for tailoring, and 2007, when I start working on methodology, I had that as a core principle that we need to have. Project management has to respect the diversity of different industries, domain, type, size, complexity of project. We must reflect all of that and our tailored method was this. I'll end it here and I wish you success today, tomorrow and always. Thank you.

The 4PM Podcast

What is the big picture of Project Management?

Listen to this podcast on