
The Good Project Manager - notadocta
https://teamgantt.com/guide-to-project-management/
======
kyllo
After reading _Waltzing with Bears_ I really think that any discussion of
Project Management that doesn't focus on risk management at all is incomplete.
It's important to make an honest list of all the risks to your projects and
the estimated probability of each of those occurring, identify what will be
the indicator that a risk is materializing, and have a plan of action for
preventing or mitigating each risk. The project schedule _must_ build risk
factors into the calculation.

~~~
netghost
And recognize or communicate uncertainty. Too often I think that people like
to brush uncertainty under the carpet, and then forget that their nice clean
plan is just one of many possible outcomes.

~~~
kyllo
That and understanding the relationship between risk, uncertainty and reward.
If a project is not risky at all, there is probably no reward to doing it
either. Risks contribute uncertainty to the schedule, so both the probability
of those risks materializing and the time and monetary costs of mitigating
those risks must be factored into the schedule and budget.

------
McUsr
I liked this write up on the overalls of being a project manager very much.

First of all, it was written in a not boring tone, and it also conveyed at
least one point that gave me an "AHA" namely "you are just the PM".

The impression I am left with is that this is first of all written by someone
who knows what they are doing, that are also capable of writing in such a way
that grasps the attention of their audience (me).

I am going to read all the chapters, I am sure there are nuggets in there.

Thanks for sharing.

------
copsarebastards
A lot of this is just long-winded and self-contradictory. It's not all wrong,
but I'd simplify it down to the agile manifesto. [1] If you understand and
internalize the actual principles of the agile manifesto, everything useful in
this article becomes clear.

This article does get it more right than most.

[1] [http://agilemanifesto.org/](http://agilemanifesto.org/)

~~~
tjradcliffe
There's nothing particularly long-winded (it's only a thousand words or so!)
or self-contradictory about this. Good communication, clear setting of scope
and expectations, good communication, team buy-in, and good communication are
key elements of the PM's job.

I also liked the low-key tone. In contrast, anything that calls itself a
"manifesto" is apt to sound a little arrogant and abrasive out of the box.

That said, I have to admit that anything associated with the word "gantt" puts
my back up, as Gantt Charts are almost never an appropriate tool for project
management: they were developed to plan the invasion of Europe, and on that
scale they are necessary and useful. For typical software projects they are
like swatting a bug with a nuclear weapon.

So even while being ill-disposed toward the author from the outset, I found
myself agreeing with the thrust of the article.

~~~
jbergens
> Creating realistic project plans, estimating time and effort, rocking a
> spreadsheet your own way... those are all things you MUST do as a good
> project manager, and those skills are easily learned.

I don't think a PM should do much estimating. It is the team that should
estimate the effort when given goals.

>SET EXPECTATIONS AND NEVER ABANDON THEM

This somewhat contradicts the agile way. Yes, I do think that expectations
should be discussed and set but I don't think you can promise to never change
them. People can change their minds, communication may have been
missunderstood, technical difficulties may be larger than the team first
thought, etc. I think you need to be able to change scope and/or expectations
in a project.

~~~
copsarebastards
The second part of what you're saying is:

"Responding to change over following a plan."

------
blazespin
Can't stand list managers. Give me mature developers, architects, product
managers, and jira. If someone wants to help take notes, that's fine. But dont
confuse that with leadership.

~~~
pc86
To me this just shows a misunderstanding of what project management is (and is
not). Good PMs do to a certain extent manage a list of tasks, dates, and
features. But it's a small part of what they do.

And just because a lot of us would rather not spend half the day emailing
C-level folks in our organization does not mean that it's not important.

------
phodo
This article is about project management. It also utilizes the abbreviation
PM, which in tech, also means Product Manager. Some thoughts: \- PM is more
likely to mean Product Manager than Project Manager \- But Project Manager !=
Product Manager \- They are two very different roles. \- Please don't confuse
the two (not saying the article confused them, but it is a common point of
confusion). \- Project Management is about tasks, good Product Management is
about leadership / product sense. Project Management is typically a small part
of Product Management. But many Product Managers may not be Project Managers.
Project Management can also be part of Engineering, and when that is the case,
they might work with Product Managers, but they, themselves would not be
Product Managers.

------
noddingham
Not sure if submitter is the author but I think "queues" should be "cues" in
the second sentence of the Be A Chameleon paragraph.

