# Who Is a Project Manager?
Source: https://www.yegor256.com/2016/05/24/who-is-project-manager.html
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...
{% jb_picture_body %}
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. Wt _is the world_,
at the moment t. A project transforms the world, moving it from one
state to another.
[PMBOK](https://www.pmi.org/PMBOK-Guide-and-Standards.aspx) 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.
{% youtube zaKTNK8g2-M %}
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_. The electricity black out could have happened, right?
The machine could have broken, right?
In theory, there was an unlimited amount of risks, including a zombie riot.
However, the majority of them had very low _probabilities_, that's why 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 was waiting for a date tonight? How much of a success was your project
to _him_?
{% quote A project is never a success or a failure; it is either dead or alive, that's it %}
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
judgment 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 judgment_. 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 a budgeting software to calculate how
much money you will owe to the roommate. You might use a few risk identification
and planning algorithms, etc.
{% quote You must try to predict the future with as much accuracy and precision as possible %}
Most of such tools are mentioned and explained in the PMBOK. They are even
grouped there into so called "knowledge areas:" for predicting
time, money, risks, people, etc. It's not important how exactly 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 what was 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.
{% quote Project sponsors need to know whether the project is worth going forward %}
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 stand-ups]({% pst 2015/jan/2015-01-08-morning-standup-meetings %})?
What about walking around the office and motivating all the
[office slaves]({% pst 2015/oct/2015-10-06-how-to-be-good-office-slave %})
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]({% pst 2015/jul/2015-07-13-meetings-are-legalized-robbery %})
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]({% pst 2015/sep/2015-09-22-micromanagement %})
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 judgment, just
like you did while making that coffee.
{% quote A good PM finds a way to organize resources in such a way that their future becomes predictable %}
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]({% pst 2016/aug/2016-08-23-communication-maturity %}) 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.
{% quote A charismatic project manager will inevitably ruin the project %}
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](https://en.wikipedia.org/wiki/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]({% pst 2014/sep/2014-09-24-why-monetary-awards-dont-work %}),
according to the plans and
[rules]({% pst 2015/oct/2015-10-13-competition-without-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.