If you’re looking at the framework overall, the PMP is the standard for a reason. Learn the rules to break the rules. The PMP is too comprehensive but a core tenet is tailoring down the scope to what your project or company needs. But it is, generally a fabulous baseline.

Software project management is pretty contentious. So there isn’t one book I think everyone would agree on. The agile manifesto is a lovely ideal but it’s hard to put into practice and requires leadership buy in.

Understanding the concepts behind scrum, sprints, Kanban is useful even if you don’t want to use those methods.

If you want to learn more, but not go into the whole PMBOK, read Scrum and Sprint and, really, The Lean Startup

Phoenix Project is good if you want to learn about what to do when things go wrong. Agile manifesto is good if you want to learn how to not make things go wrong

The agile manifesto is lovely, just difficult to apply in practice if you’re looking at hard, tactical project skills or dealing with business demands that don’t allow for it.

I agree with Owen in principle.

It’s more about knowing first principles and being able to apply them.

Brady Dibble

It’s just not something you can crusade on your own, you must work within the constraints of the business.

Most people do waterfall in the end, yes.

Here its’ reserved for Government contracts

Where you get paid either way

When in doubt, overcommunicate and use a spreadsheet.

If it’s not working, more communication and more spreadsheets.

Just outsource it. Projects are hard

That also works.

Oh, also, if it is still a question about ‘what’ to build I recommend User Story Mapping.

All of these books are heavy for what you’re trying to do, it’s in aggregate that they start

MVPs are good for that. Build something and let the customer tell you whats wrong about it. Easier then asking them what they want :slightly_smiling_face:

Or read the true bible https://en.m.wikipedia.org/wiki/The_Mythical_Man-Month WikipediaWikipedia The Mythical Man-Month The Mythical Man-Month: Essays on Software Engineering is a book on software engineering and project management by Fred Brooks first published in 1975, with subsequent editions in 1982 and 1995. Its central theme is that adding manpower to a software project that is behind schedule delays it even longer. This idea is known as Brooks’s law, and is presented along with the second-system effect and advocacy of prototyping. Brooks’s observations are based on his experiences at IBM while managing the development of OS/360. He had added more programmers to a project falling behind schedule, a decision that he would later conclude had, counter-intuitively, delayed the project even further. He also m… Show more https://en.m.wikipedia.org/wiki/The_Mythical_Man-Month

Nothing in software engineering project management has really changed for 50 years

I remember before Agile. That sucked

It sucks after agile too but hey

Agile supports fail fast. Better to fail early and fail often (edited)

When it’s ‘called’ agile anyway

Agile is a little tricky or even ill advised for Enterprise software though… At least for, say, an OS. :heh:

We can move to a pure form of it for some of our new products and we should. Brady Dibble

Once we get proper customer feedback mechanisms in place.

Updated: