Five Project Management Levels for respecting our diversity!

Could your approach to project management unlock untapped efficiencies and effectiveness within your organization? We're peeling back the layers on how the acknowledgment of diversity within project management roles and practices can revolutionize your operations. Our discussion traverses the complex roles of project owners, providers, and customers, highlighting why a one-size-fits-all mentality in project management is a myth. We address the unique challenges and perspectives across various industries and organizational departments, underscoring the value of tailored practices that align with specific project goals and cultures.

Elevate your project management skills by understanding the hierarchy, from basic task management to advanced life cycle models. We dissect the foundational level of task management, ascend through the nuances of stage and technical project management, and ultimately spotlight the comprehensive model of product delivery, which integrates the crucial pre-charter phase. As we navigate these levels, the conversation turns to the pressing need for continuous innovation and improvement in the field. This episode is a treasure trove for those ready to enhance their project management playbook, with additional insights available on our blog and YouTube channel - an enriching triad of resources for any project management aficionado.

Explore more project management insights at www.urukpm.com

Connect with Uruk Project Management:

Uruk PM | Blog
Uruk Project Management | LinkedIn
Uruk PM | Twitter
Uruk PM | Facebook
Uruk PM | Instagram
Uruk PM | Youtube

#UrukPM #ProjectManagement #Podcast

Transcript

Speaker 1: 0:07

Good day, howdy, and welcome to the 4pm podcast. My name is Munir Ajam. My core passion is project management in community. I come to you with at least close to 35 years of experience. My eagerness to share knowledge and to mentor and coach groups help organizations transform the way they manage project to a higher level. 4pm's tent in this case is shortened for us for what we call value, which means project, program, product and portfolios, so a lot of our topics will be around these 4pm. Let's get going. Welcome to the 4pm podcast.

Speaker 1: 0:55

This is episode 3 and in today's episode we will be talking about respecting our diversity. As an introduction to this episode, we always ask and at the end of every episode we've been asking a question, and so if you listen to the last episode, you probably heard this question respecting our diversity. What do you think that means in the project management context? How can we respect our diversity? And again, usually when we pose this question, we leave it open for you to think about them. So if you have not had a chance to think about this question, we will pause for a second and will advise you to pause and think about the discussion. Okay, so to discuss respecting our diversity and what does it mean in the context? We will be dividing this episode into 4 parts Part 1, and obviously each part would be very short. Part 1, we will discuss the differences between owners, provider, customers, and part 2, we will talk about the differences in how to manage project. In part 3, we will explain the levels and in part 4, we will offer some concluding comments. So let's dive in in part 1.

Speaker 1: 2:10

Part of respecting our diversity and the idea behind this is that we often think of project management. You know, we are, there, are guides and standard and sometimes we fall onto the trap of thinking that, hey, project management is the same and once you know how to manage project in one industry, you can manage project anywhere. Well, unfortunately, we don't agree with that. So, in order to understand, obviously sometimes we don't even agree or we don't have a common definition on the term project. I'm sure, if you ask people to define project, money can give us very good textbook answers. However, reality is different. The way we practice project management from one domain to another, from one company to another, from industry to another, is quite different. So, in order to understand the idea behind the concept of respecting our diversity and which we translate into a concept called the project management levels.

Speaker 1: 3:07

We need to understand is the difference between something we call owners, providers, customers. These are terms we use. So what do they mean? See, a project owner is any organization who is launching a project from the concept. They have it, maybe in their strategic plan, and they will end up being responsible for the output and the operation of that. For example, a hotel company will come up with an idea to launch a hotel and, at the end of the day, they will be managing and benefiting from the hotel. A restaurant, a hospital, the same, a software company, right, rook project management. We are developing Rook platform as a software. So in that case, we are project owners. Of course, service providers or providers and sometimes we use the term contractors are usually people who provide the service to a customer my partner, who is doing the actual software development as a provider, to me as a project owner. And if you follow the concept and the Pumbak guide, sometimes they talk about sellers and buyer. Well, that's not always a good description. So it's clear we need to distinguish between owner and provider.

Speaker 1: 4:25

Now, within an owner, there are different divisions, different departments and their view of project, and the project is different. It could be different. Obviously. Everybody cares about the ultimate objective. However, their interest and the work of a given department or division within a project owner organization might be different. So, for example, within the project owner organization we might have the business teams, we might have operation, we might have project management, if it exists. We might have different departments that might do the work internally or externally. So, for example, an HR department, an IT department. They are all department and each one of them might work on project from a different perspective.

Speaker 1: 5:09

So at the beginning we are basically saying that we need to understand there are things. There are organizations that could be classified as project owners, there are organizations who will be classified as service provider and within project owners there are different type of department that might have different interests in the project and as a result of that that finally, we need to talk about the word customers and we often use the word customer and automatically we think a customer must be external. Well, that's not always the case, because in many organizations a division within the company could be a customer and another company might be doing work for that division. So in that case we have an internal customers or, of course, if we have an external provider, then the customer could be the company that is their client, but within that client organization there could be some division that will be classified as customer. So, regardless of who the customer is, basically, whether internal or external that just a term we use often to refer to the people who we are doing work for. That concludes part one of this discussion. So, owners, provider, customers.

Speaker 1: 6:29

Now, building on that, we move to part two, and part two we'll talk about the differences in how to manage projects and, of course, set a function of the project Again, are we service provider or are we owner? So, if we understand the differences between managing part of the project and managing the whole project, now why do I say that? Because, obviously, if we are in a big company and we have a big project and we have different division, each division might be responsible for a different part of the project. A service provider might be responsible for a part of the project. An engineering company might be responsible for the engineering stage of a project. A construction company would be responsible for the construction stage of a project. A software development provider is responsible for the software development part.

Speaker 1: 7:26

So what we are saying here, I'm defining that. This is the. I'm defining that they are part of a project that could be managed by different entities and usually those parts could be part of stage or could be an entire stage. However, if I am the project owner, I am the customer, I am the one who is going to be benefiting from the outcome of this project, then in that case the project, my project, could be thought that, you know, it's not only a stage, it's not only a part, it's the entire project or the entire product or asset. You know, sometimes we use the term product, some organization might use the term asset. So I am concerned with the entire thing, not only a piece of it.

Speaker 1: 8:12

For example, an HR department might want to launch a training portal to its global operation. So therefore, the HR department must focus on that idea, that initiative, that change initiative from A to Z. What does that mean? They need to worry. Obviously they need to start with thinking about the trigger for that. You know. They need to find the justification for that. They have to define. They might do a project brief to explain the concept behind the project. They are likely to do a feasibility study for the project. They will need to define requirement. They need to have a project management plan or project plan, and then, of course, they will move into the implementation part, which is good, include software and non-software, right?

Speaker 1: 8:57

So there are many components as a result of that project. Somebody needs to manage that entire process and unfortunately that's what we see today as the biggest gap in our industry is that often there might be a customer, an internal customer or an owner for something like this. They are not necessarily setting up a project management function or setting up or assigning project manager to manage this project A to Z or A to Z depending on how you like to pronounce it Right. So they may not have that, although what we think they should and that is probably one of the biggest gap we see in practice today in organization they like to manage project but they don't necessarily have a formal project management process. So what often happen in those scenarios that the HR project, for example, is often enough we don't see project management formalized until the project might get to the IT department, who might need to work on setting up the infrastructure and maybe developing the software and basically the Watt portal and the software that is to support this training initiative. So what would happen probably is there in that area. Probably, project management is more formalized. However, if we notice, it's formalized only for a part of the project, not the entire project. So that's an example that helps us understand the difference in how we see project depend on who are we and who is talking and what type of organization we belong to.

Speaker 1: 10:40

So with that in mind, I'm almost ready to close part two of this episode, but, however, I need to define one more concept or one more variable that could have significant impact on the things we just talked about. For example, is it project management? You know when does project management formally start? Right as an IT department or was the HR department? The complexity we see here and we highlighted on that as a gap in practice today? Is that basically the question? Maybe we should put it in the form of a question does the organization have an established project management process as a method or not? Now, of course, if they do, now the follow up question might be do they do that for the entire product, delivery, from vision to operation, or only, for example, an IT department or some other department? They might be working on a piece of the project. So the main thing to close part two is basically that we highlighted that we need to understand that depend on who we are and where we are in the organization, the way we view project might be different, which led us to the concept of PM levels. So what are the PM levels? Part three of this episode. Well, obviously, first I need to clarify an important disclaimer what we mean by level, that doesn't mean well, that mean one is better than the other or that is one superior to the other. What we're saying here, this is more of levels, and for you will understand why we use the term level instead, for example, using the term category of category of project management. Right, so what we see is, technically, we see six level based on our Rookway or our Rookway of thinking. However, today we will only discuss five and briefly, we will not go into detail. We start with basically what we call level one. And to us, what does it mean?

Speaker 1: 13:02

In some organization, often enough, project management is still not formalized. There are no good procedures or method or processes or guidelines established. So often enough, project management and those situations are just managing tasks. You know, people can use some kind of task management tool and identify hey, we are, and usually this is work only inside a department, maybe within a unit or a provider. There might be said, okay, we need to have these. You know we divide a project into tasks. Basically they think of the project. In reality, though I'm using the term, they think about the project, but most likely they are working only on a piece of the project, but regardless, it could be very small, tiny project or it could be a piece of a bigger project.

Speaker 1: 13:53

However, often the focus in this case is on task management and there are many tools we call them project management software or project management tools in the market and reality. Most of those are just tools that can help with managing tasks or maybe assigning tasks to people and using things like Kanban or other things. I'm not going to get into tools discussion, but basically that might be one level. So it's very basic level. We are managing tasks. Now what we are saying here. Again, one level is not superior to another. If your job and your company, your culture, adjust to manage tasks, great, you know. As long as you're good at it, that's fine. However, obviously depend on the nature, some organization might need a different level.

Speaker 1: 14:37

The second level is what we call level two, which is stage management. In this case, maybe you are a service provider working on a stage only, maybe working on the software development component of a project. In that case you are managing the stage, so you might use things like the PMI or the ISO process group. You know, you initiate the stage, you plan the stage, you execute the stage work, you control and of course, you control throughout and then you close at the end. So in a way, here you are slightly have a higher level than task management, because now you have these five set of processes and in each one of those processes there could be many tasks. So that is level two Again.

Speaker 1: 15:22

That is, if your job is to manage a stage of the project that might be perfectly acceptable and good, then we move to level three, which we call where actually, before I say what we call it, most people call project management. Because if you look at Pimba Guide, the PMI work and many other literature on project management, we often hear that a project start with a charter and end with a delivery of an output. Now, if you've noticed, before I continue I want to pause and go back to level one and level two before I continue with level three. Now why did we use the term level. If you notice, here we use the term level and when you see the graphics on this on our blog or on our video, you will notice that we use an inverted pyramid. Basically, at the bottom is task management, where it is very narrow. So basically it's very focused on managing task and therefore the focus is very narrow focus on managing the task only when, as we go up to the stage management, the range get wider, because now we are just not focusing on task, we are focusing on the entire stage. So in a way, we have a broader perspective and a broader management.

Speaker 1: 16:52

When we go to level three, as we said, if you look at PMI Pimba Guide or many other guide or literature, we talk about a project start or project management. Focus must be from a charter to a delivery of an output. That's what many people call project management. Well, we see that we call it level three, but actually we call it technical project management. Now the word technical just basically what to say that we are being? In this case, project management is viewed as a technical domain responsible for a delivery of an output after the decision for the project has been made. So project management is not involved early in the project and they're not involved later in the project. Their job is just to execute in a way to execute and get the work done, deliver an output, and we're done. So if we go back to one level one, level two, level three we typically see that usually these levels are existing in service provider organization or maybe technical team working on a piece of the project.

Speaker 1: 18:05

Now time to go to level four and level five. Level four is what we call product delivery. So, if you remember, we said between level one, two, three and as we go up the levels our attention is broader. So in a way, instead of zooming in on a piece of the project lifecycle, for example, like a task in level one, a stage in level two, technical project management at level three, now what it means we need to expand that lifecycle a bit more. So in this case, the product delivery model, such as what we came up with years ago, it need to incorporate what we call the discovery phase of a project, which means from the time the project and organization have an idea for a new initiative, a new project, that mean idea, product vision of a new project, that mean the project start. So in that case they need to define the concept, they need to select maybe the option, they might need to do a visibility study. So there is a piece of work that is pre-charter yeah, pre-charter, if you follow the PMI way. Now PMI says that that stage phase exists, but, however, it wasn't the concern of project management. Here we back to disagree. That work is real work. That happened on the project and historically we find last episode we talked about project success One of the main reason that project fail is because we don't do a good job in that phase.

Speaker 1: 19:43

And why? Because traditionally we didn't consider that part of project management area of attention and focus. What we're saying. We should change our thinking and therefore we must start with the product vision. We must start with the justification, with the reason we do the project, the objective of the project. All of that should be done and should be done in relationship with project management.

Speaker 1: 20:12

So the project life cycle in this case does not start with a charter. It starts with the idea or the product vision. Now the focus obviously we go all the way to delivering the product. So there is a product. That's why we call it product delivery, delivery. Level four is product delivery. We are delivering the product, which means the output right and of course, we can go through some formal closure procedures and everything else. However, the focus mostly on the product delivery.

Speaker 1: 20:43

Now in ARUK we do a little bit more but I will leave it to the next level. Finally is level four, which is pretty much is. We call it value delivery and that is the model that is the foundation of the ARUK platform project management element. So, if you go to the ARUK platform and you want to manage project or program, the core focus, the model, the life cycle model we follow is the value. That you know we call it project life cycle. However, it's value delivery model. Now, why do we consider that? Again, remember, as we go up the level, our attention focus, broaden, goes wider. Our attention to the life cycle is now bigger.

Speaker 1: 21:30

So obviously in this case, like product delivery, we might be starting with the product vision, or maybe slightly before that. Maybe you know, analysis for justification, the trigger for the project, and goes all the way beyond completion of the project. In this case we include what we call the project success model, which the four dimension of project success. We will have an episode on that later. We touched on that in the previous episode is that, basically, you know, we are not focusing on delivering the product, only we want to make sure we go through an initial operation period. We want to make sure that we have basically prepared for operation and we assess success off the objective of the project, which often cannot be done until month or year after the project is completed. That is a value delivery model. We will talk about this.

Speaker 1: 22:29

We, I think I believe we are dedicating episode five to cover the Oruk way or the Oruk platform value delivery model. So, five levels each level is depend on when you are. Obviously, if you are a provider, maybe technical project management, level three is good enough for you. If you are project owner, like the HR department we mentioned earlier, you really need to be operating at level five. You know, or at least level four as a minimum. Again, level four product delivery focus as a minimum, the preferred way, and it's the Oruk way as you go all the way to level five and a value delivery model.

Speaker 1: 23:24

Okay, time to start closing this episode and we shift to basically some closing comment in part four of this episode, which is back to the idea of respecting our diversity. So, in conclusion, what is essential to understand, based on what we discuss, is that how we define projects and project management and how we manage project are not the same. I think that should be clear by now. Right Again, we're not saying one is better than the other, or I mean, obviously there are preferences, depend on, but again, depend on who you are and what type of organization you belong to and what kind of role you have.

Speaker 1: 24:13

Although we shared many concepts and processes in project management across the domain and industry and that's one of the reasons for example, you know, we, many of us know the process group in all of these things is that because there are common processes that are available everywhere, regardless what type of project you work on. You need to have a budget, you need to have a schedule, you need to have scope, you need to have quality, you need to have risk. These things are common everywhere. Just how we define them and the level of effort required and the methodology used is quite different, and we need to have a good understanding of that, otherwise we probably continue to struggle in project management. So how do you manage projects? It depends. We actually have a series of video on the idea of it. Depends, as you know, always a good answer to any PM question. Start with the word it depends. So, in the context of this episode, how you manage project. Well, it depends on whether you are a provider or an owner. It depends whether you are managing a stage or you managing product or you managing the entire value delivery, value delivery stream. So it depends, and the levels in this case help us understand where and how we manage project. In closing, we talked about respecting our diversity. We talked about the difference between owners and providers and customers. We talked about how we manage project and the different perspective for managing project from one division to another or one company to another. And with this we are concluding this episode.

Speaker 1: 26:02

But as a practice we've been doing, we always close with the question for the next episode. In the previous episode we talked about transformation and, and today we're talking about in order to transform, the reason. This, this episode, is there because before we can transform, we need to understand what are we transforming. We need to understand this concept of the different level. So, if you agree to the idea that project management need to go through some kind of a transformation or adjustment, whatever you, if transformation too strong for you, you know, think of other word, what should be our primary focus? Now, our answer is in two parts and we will cover one part in episode four and part another part in episode five. However, for time, we're not going to tell you about those parts in your mind.

Speaker 1: 27:00

If we need to change project management, if we need to improve the practice of project management, right, we ask before, is it? Is project management healthy? And we in the in the previous episode, we talked about the need for transformation, right? So if you agree with that, if you agree that we can do better, where should we focus? Final comment remember this episode is part of what we call the outreach trio. You have the blog site that is related, that all will include some related articles, and we also have our YouTube channel will include some related article. To find all of these things, the easiest way to go through is to go to our website. Our website is ourruchpmcom. Ourruch is u r u k p m dot com and until then, we wish you success today, tomorrow and always you.