The myth of managing projects by the numbers

In my years of managing projects in one fashion or another, I've employed multiple methodologies or frameworks (PMI's PMBok, Agile, CMMI, RUP). None of them claim to be overly prescriptive, instead the stated mission is to structure best practices in a way that make them repeatable. The desire is to reduce project risk and variability through providing guidance for both depth and breadth in dealing with potential 'gotcha's'. They are all taking lessons learned by multiple practitioners in multiple industries and distilling them in an essential (if sterile) form that is waiting to be rehydrated with project specifics.

The problem arises when practitioners put too much faith in the methodology. I call it the silver bullet syndrome. The more structured the methodology, the more entrenched the feeling of security given by it. If I planned for all the practice areas, I'm guaranteed success. Of, metaphorically speaking, if I paint the mandated colors in the mandated areas, I will come up with a masterpiece.

In fact, good management is a more of an art rather than science. If requires continually honing your craft through intelligently listening to feedback. Feedback can come in various shapes and forms: it can be learning from mistakes. Some monumental failures offer the best opportunity for valuable lessons. It could be from really understanding variables that are not obvious immediately - such as corporate culture or the 'real' balance of power in an organization. It would be learning that influencing (and knowing how to do it) is a lot more valuable than dictum authority. It could be taking a humbling experience and turning it into actionable insights for the future. Furthermore, the craft is enhanced through incessantly tinkering with the levels. Project managers have finite availability; figuring out where to place your attention at any given time is methodology or framework independent.

So what does this mean for structured methodologies? It means that a tools is only as good as the skills of its operator. Methodologies are like tools. They are useful for certain tasks, but they are not irreplaceable. You might find it useful to have a paint brush and some outlines to paint a landscape, but the same can be accomplished painting with a painter's knife (or a different brush). More importantly, given the same set of tools, there will be a wide range of individual, non repeatable craft that practitioners will bring to the table. This craft, this individual 'alpha' of the project participants (as well as how the skills of various participants mesh together) is just as important if not more important than the methodology. The craft of the project leader becomes even more essential. As the person whose decisions and steering affect (positively or negatively) the widest range of project aspects. Hiding behind the false sense of security that the methodology offers is even more pernicious if done by a project leader.

Methodologies also provide a framework for collaboration, a common language of sorts. Having all the project practitioners understand the same ceremonies removes friction. If everybody understands interaction etiquette in the same way, it removes a project impediment and allows the team to concentrate on value added tasks instead. But again, this is not the silver bullet. Collaboration frameworks reduce friction, but they won't compensate for poor understanding of the client's needs or for incapacity of seeing the project risks (or where to look for them). But they can give everybody that false sense of security. A tool can only get you so far; the rest is superior craft that can only come from experience, from every project participant, but especially from the project leader.