Over a million developers have joined DZone.

What is a Project Manager Really?

DZone's Guide to

What is a Project Manager Really?

The author argues that project managers aren't leaders, and only serve one primary purpose.

· Agile Zone
Free Resource

See how three solutions work together to help your teams have the tools they need to deliver quality software quickly. Brought to you in partnership with CA Technologies

A project manager is very often confused with a leader. However, they are two very different things. A project manager is the one who predicts the future, while a leader is the one who builds it. And, in my opinion, a perfect project manager is much more valuable for a project than a leader. If a leader is valuable at all...

There are three things I want to define: project, project management, and project manager. Once they are clear, my previous statement will become obvious.

A project is a vector from W1 to W2, where Wt is a set of all resources and risks in the world at some defined point in time t. Wtis the world, at the moment t. A project transforms the world, moving it from one state to another. PMBOK defines projects as "temporary endeavors undertaken to create unique products, services, or results," which is just a specific case of my definition. Mine is more abstract, I believe.

Consider this example. You woke up in the morning and made yourself a cup of coffee. That was a project. When you woke up, the world was in W1 state. There were some coffee beans in the bag, some water in the tap and some electricity in the power station. And there were you standing in front of the coffee machine. These were the resources (including yourself). There were also risks. An electricity black out could have happened, right? The machine could have broken, right? In theory, there were unlimited risks, including a zombie riot. However, the majority of them had very low probabilities, and that's how you managed to make that cup of coffee.

When the coffee was ready, the world appeared to be in W2 state. There were no coffee beans in the bag any more, the water was used, and so was the electricity. However, a cup of coffee was created. We may call that project a success, but that's not really important and is not correct. What's important is that it's finished. We successfully transformed the world from state W1 to state W2. You may be surprised to hear that the project was not a success. Indeed, it was not. It was a success only for you, one of its stakeholders. How about your roommate, the owner of that bag of coffee beans, who asked you yesterday not to use them because he is waiting for a date tonight? How much of a success was your project to him?

So, a project is never a "success" or a "failure." A project is either dead or alive - that's it. Success is a subjective category and can only be measured per stakeholder. And even a small project has many stakeholders. Think about that electricity company who sold you a few kW/h and made some profit out of it? The project was definitely a success for them. What about mother nature? Your project was definitely a failure for it, since you produced a few kilograms of CO2 while making that damn coffee. As you see, success is very subjective.

And we're in line with the PMBOK definition. Our coffee making project was indeed a temporary endeavor undertaken to create a unique product, which was a cup of coffee.

Did we have a project manager? No. Were we doing any project management? No. Well, not explicitly. Obviously, you were the project manager, but you didn't realize that.

Project management is a set of tools to predict the outcome of a project. Planning is one of those tools. Guessing is another one. Expert judgement is yet another one, which you were using while making that coffee. You were an expert and knew how to use the machine, the electricity, and the water tap. You didn't need any other tools except your expert judgement. And it worked. In bigger projects, we would need more powerful instruments and methods. For example, we could use some scheduling software to plan when to put the beans into the machine, when to put that cup under the dipping point and when to press the button. You might also need budgeting software to calculate how much money you will owe to the roommate. You might use a few risk identification and planning algorithms, etc.

Most of such tools are mentioned and explained in the PMBOK. They are even groupped there into so called "knowledge areas:" for predicting time, money, risks, people, etc. It's not important exactly how you predict the future, how many tools you're using, or what knowledge areas you break them into. What's important is that you must try to do it with as much accuracy and precision as possible. Here comes the definition of the main guy.

A project manager (PM) is the one who predicts the future. The PM knows in what state W2 the world will be when the project is finished. If the PM doesn't know or is in doubt — it's a bad PM. If the PM knows and is certain about it — it's a good PM. That's it.

And I have to say, in that coffee making project you were a lousy PM. Did you know the probability of the project being finished without a cup of coffee made? A good PM would say that "after an analysis of 230 risks I predict the probability of that coffee being tasteful as 87.4%." Obviously, you didn't have that information. Next, did you know what would be the total monetary value of the project after its completion? Did you calculate all incurred costs, including the price of environmental damage your coffee machine made? A good PM would say that "the total cost of the project is expected to be $1.09." Were you able to predict the duration of the project precisely? Well, maybe that one you were rather good at.

There is only one reason why we want to put a project manager on top of the project. I'm sure you will be surprised to hear it: the only purpose of a PM in a project is to help its key stakeholders (also known as sponsors) to make a decision: to kill the project right now or to let it stay alive for a bit more. That's it.

You didn't need a PM in your coffee making project because you, as its key stakeholder, were fully committed to finish it only when the coffee is ready. But imagine another situation. The coffee machine suddenly breaks, the water stops, the electricity is blacked out and some zombies are knocking at your door. And you still want that cup of coffee. Well, you're not entirely sure what's more important now, the coffee or simply finding a way to survive. You will need a more or less accurate prediction of how much that coffee will cost you and when will it be ready. If it's just a few minutes and everything will be fine again, you will keep waiting for it. However, if the prediction is five hours and a risk of failure rate is 93%, you had better terminate this project and do something else.

That's exactly what is happening in software development projects and all other projects. Project sponsors need to know whether the project is worth going forward or it's time to stop it and do something else. That's what they hire project managers for. This is the only reason of that millions of PMs existence — to predict the future so that we were able to kill our projects before they kill us (read "eat all our resources").

You may ask — what about the coordinating part? What about morning standups? What about walking around the office and motivating all the office slaves so that they don't get lazy? Isn't it the primary responsibility of a PM?

Not really. This is what a PM does in order to better understand the situation and predict the future. But it's not what a PM is paid for. Indeed, a bad PM goes around the office and calls multiple meetings a day. This is also known as "staying on top of things" — a perfect term to define an amateur PM. A bad PM becomes the future, instead of predicting it. He micromanages the team by telling everybody what to do, since this is the easiest way to know what will happen and when, in the short-term. But the long-term future stays absolutely unclear. A bad PM mostly relies on expert judgement, just like you did while making that coffee.

A good project manager is a completely different creature. A good PM finds a way to organize resources in such a way that their future becomes predictable. The key word here is "organize." A good PM organizes people, money, time, risks, stakeholders, and many other things. He uses planning and budgeting software in order to better see the future. But he doesn't become the future and he doesn't build the future. His people do that, he just observes. He only collects information from many possible sources and estimates what will happen, how much it will cost and who will suffer most and least. At any moment in time, he knows exactly when the project will be finished, how much it will spend, how many results it will produce, what the quality will be, and what the accuracy of that prediction is.

A good PM doesn't personally give orders to the team and doesn't meet people to tell them what to do. Instead, he makes sure that all communication is happening through a project management information system (PMIS). Moreover, in a perfectly organized project, a PM won't even need to give any orders to the team. Work orders will be created, approved, assigned and verified by the team itself. The PM will make sure that the workflow is seamless and disciplined. But he won't be personally responsible for telling people what to do.

A perfect PM won't even be visible to the team. Everything will be obvious and clear: plans will be available, work orders explicitly defined, risks identified and documented, concerns properly reported, stakeholders informed in time, etc. This may sound like utopia, but that's the true meaning of a "project manager" role.

I believe it's already obvious that project management has very little to do with leadership. They are just two orthogonal skill sets. I would say that a perfect PM won't even need any leadership skills, while a lousy PM will need a lot of them. As far as I understand, being a leader means having enough inner power (also known as "charisma") to make people do what you need. But that's totally against what we just discussed. A project manager doesn't want people do what's needed because of his charisma. Instead, he wants people to be leaders of their own tasks. They have to move forward driven by their own motivation and selfish interests, according to the plans and rules defined by the PM. A charismatic project manager will inevitably replace the rules by his or her own personality and the entire idea of project management will be ruined.

This is my understanding of project management.

Discover how TDM Is Essential To Achieving Quality At Speed For Agile, DevOps, And Continuous Delivery. Brought to you in partnership with CA Technologies

project management ,project managers

Published at DZone with permission of Yegor Bugayenko, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.


Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.


{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}