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.
The Good Project Manager
21–26 of 26 posts
Re: The Good Project Manager
#22A 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/
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,…
> There's nothing particularly long-winded (it's only a thousand words or so!)
Using a thousand words to say 200 words of content makes it long-winded.
> 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's an entirely pointless and off-topic criticism. You're only holding yourself back if you refuse to learn from anyone who doesn't make you feel warm and fuzzy.
Every one of the original signatories of the agile manifesto are well-respected coders who have produced major successful pieces of software. Arrogance is unearned confidence and I don't think you can reasonably accuse them of not earning their confidence. If you're judging them as arrogant based on the word "manifesto", that sounds a lot like anti-intellectualism.
Re: The Good Project Manager
#23A 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/
As much as I appreciate the agile manifesto, your suggestion seems a little like teaching the fundamental axioms of mathematics and leaving it at that. Yes, those principles are useful, but it's a lot easier to reach practical conclusions with more specific guidance.
Yes, but this is establishing a whole new set of principles ("Communicate like a pro", "Be a chameleon", etc.) without coalescing them down in any way. It's one thing to talk about a principle and then give specifics examples of how to apply the principle, but this hasn't bothered to coalesc coherent principles.
To steal your analogy, this is like stating principles: "When a triangle has a multiple of 3 length and a multiple of 4 length next to a right angle, the remaining side is a multiple of 5." "When the hypotenuse is a multiple of 13 and a side near the right triangle is the same multiple of 5, the remaining side is the same multiple of 12." People get lost in a bunch of random examples when all you really need to solve for the sides of right triangles is the Pythagorean theorem. A few examples help, but if you don't relate them back to coherent principles they're pointless.
Re: The Good Project Manager
#24Earlier quoted context omitted.
You've just described "individuals and interactions over processes and procedures". The agile manifesto isn't the cluster fuck that Agile has become. Agile methodologies directly violate the agile philosophy, but that's no reason to pretend that we're just now discovering that methodologies suck. It's in the manifesto.
What I've described are ideas that predate the agile manifesto, and are not subsumed by it.
Of course the agile manifesto didn't arise ex-nihilo. But it's a much clearer, more concise statement of what you said.
Re: The Good Project Manager
#25A 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/
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,…
> 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.
Re: The Good Project Manager
#26Earlier quoted context omitted.
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,…
> 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 expecta…
The second part of what you're saying is:
"Responding to change over following a plan."