Project Management Frameworks

Your projects don't fail because someone failed to implement Agile, Scrum, SAFe or any other out-of-the-box methodology that claims to solve all your problems.

Let's be clear: There is nothing inherently "wrong" with these methodologies, and for inexperienced project managers, following them can provide a useful set of tools and routines which can help to ensure important boxes are ticked, and important activities aren't overlooked.

However, I've seen my fair share of "trouble" projects throughout my career - often being called in to fix them. So I can say with some confidence that not once has a project gotten into trouble because the burn-down chart wasn't done correctly, or the scrum meetings weren't held the right way, or the team didn't calculate sprint velocity and choose their story points correctly. This is because these things are secondary mechanisms invented as tools to help project managers manage projects, but they are not - at their core - project management itself.

Without fail, the things that have led to project difficulty have always been more "core" to the project itself, either the work being done, or the people working on it.

For example, I've seen projects fail because of a lack of clarity around scope during the planning phases, leading projects where the team isn't even sure what they're delivering or why.

I've seen projects fail because the people on the project team have separate priorities or ideas about what the project actually should be.

I've seen projects fail because the project team had some ulterior motive for not wanting the project to be completed successfully.

Invariably, a project succeeds or fails based on the team working on it, how well they are aligned, how well they understand the desired outcomes and the work to be done (and, just as importantly, not done). These human factors are, without fail, the things that make or break a project.