But exorcising the demons of amateurish project management is not that easy.

Problem one is choice of orthodoxy. For example, there are at least eight process maturity frameworks, each claiming to be “best practice”. Yes eight, and each convinced of its orthodoxy. There are many delivery methodologies to choose from too, e.g. waterfall, agile, DevOps, SAFe or lean. And as there are important differences in approach, you’ll need to decide which best suits you. But which one to choose and why? Standards organisations, like churches, have preachers and disciples reciting from sacred texts asking you to heed the word and repent your ways. And make no mistake, choosing a standard or methodology is buying in to an orthodoxy that sets itself above all others as the one true way.

Problem number two is abstraction. In the nature of sacred texts, project governance standards or methodologies are quite abstract. Project management frameworks don’t come with instructions specific to your situation, so once you bought in to one, you’re on your own. You could, of course, ask for advice, but you’ll likely be inviting in a preacher to evangelise to the natives. Which brings you back to problem number one, the choice of orthodoxy.

And problem three is that orthodoxy is not the same as truth, despite what the high priests would have you believe. Even if you have “seen the light” and decided on a standard for instance, because “best practice” is open to interpretation, different assessors will rate the same organisation differently.In other words, you could be rated at maturity level two by one assessor and level three or four by another to the same standard, especially when it comes to sub processes. Where is the truth?

So, what do you do?

Let’s deal with the abstraction problem first, or how to turn a theoretical model into something you can use. You should be pragmatic rather than dogmatic. Abstract debates about standards or methodologies are about as useful as debating the merits of a hammer versus a screwdriver. It’s got to be situated in action; implementation focussed. So, the debate about which methodology to use is best solved by asking what difference it would make whether you took one approach rather than another, for a specific situation. If there is little difference in the implications of different standards or methodologies, then there’s not much at stake in the debate. If there is a big difference, then that’s pointing to where you should go.  And if you need help thinking through the practical implications of the alternate methodologies or standards, take a small sample of projects or tricky decisions through the competing frameworks in a desktop simulation and see what comes out at the far end.

The second recommendation, though no less important, is to focus on the business problem to be solved rather than the methodology, system or standard to use in solving it. And be as specific as you can. A clear statement of the problem, ideally with metrics, is a big step forward. If you can describe a problem, debates about framing aside, you can set about solving it. If you then map the problem to the processes that underlie it, you can get some valuable clues as to why the problem exists, and so start to fix it. The methodology or standard might be useful now. You can go back to step one, test which approach works best and adopt that. A further test to apply is the extent to which solving the problem would deliver value, that will help you calibrate how much effort to put into dealing with it.

Third, think about how the methodology might fit with the culture of your organisation. For instance, if you have what could be described as a “clan” culture, where there is a strong sense of group cohesion and collaboration, with mentor figures who have deep technical skills, then a command and control approach to governance could alienate the very people it tries to help.  So, a good understanding of the culture you’re dropping these new governance structures into, should heavily influence the initial design of those governance structures. And a good view of the future state of the culture you’re looking for will help with future state project governance design.

Getting project governance right is important, so choose your faith wisely. And may the force be with you.