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.
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.
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.
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.
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.
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.
> 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.
> 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.
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.
But a good PM has to be able to manage projects using more than one methodology. Agile (or at least, agile as it is commonly practised, because I just know that someone is itching to say "No, the reason that's not working is because you're doing agile wrong") is inappropriate for many projects.
Starting your post with "But" makes it seem like you're disagreeing with what I said.
"Agile as it is practiced" is not what I was talking about and has very little relation to the agile manifesto. The agile manifesto isn't a methodology, it's a philosophy. I would go so far as to say that "Agile process" and "Agile methodology" are oxymorons if you're using "agile" in the "agile manifesto" sense.
Everything you said in your post is a direct consequence of prioritizing individuals and interactions over processes and procedures: the first statement of the agile manifesto.
I realize I am being one of those "you're doing agile wrong" people, but only because I feel that it's worth rescuing "agile" from "Agile" because otherwise we're just rediscovering the same principles under a different name. I would rather fight to remove the pollution of "Agile methodologies" from the actual meaning of the agile manifesto than reinvent the wheel, and run into the same issues where people coopt the principles and pretend they support whatever flavor-of-the-week methodology they are espousing.
This is important. The idea that some sort of methodological silver bullet exists that will solve your projects problems "for you" is as pervasive as it is naive.
A big part of a good PM's role is knowing what approach is appropriate for which project(s) and knowing how to implement it practically with the team(s) they have.
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.
The difficult part of being a good PM in a team is that Agile is hard to do right with real humans. Even if it can be reduced to the Agile Manifesto, putting it in practice is difficult and takes work, time, and skill. The ability to consistently create good practices are what differentiates the good from bad PMs.
So while I agree with you that it does reduce to the Agile Manifesto, I'd also say that from a PM's perspective, that's not the point.
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.
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.
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.
