By Peter Gilligan

There are a thousand reasons why projects fail. And people have written thousands of articles trying to explain why projects fail, quite a few of them fingering the project manager in charge. That's not exactly unfair, because we put Project Managers in charge expressly to achieve success, and poor project management plays its part in delivering failure instead. The PM's primary role is to shepherd their projects through the minefield of functional and technical challenges, budget constraints, demanding users, ridiculous deadlines, self-interested vendors and the other 994 dangers that need to be navigated. Not every PM is up to the task. I know I'm not the only person to have looked at a project and asked myself, "How did that PM get to be in charge?"

I found myself asking that question again recently. My natural first reaction was to criticize the PM who was clearly out of his depth on several levels. This time, however, I found myself wondering, "Who on earth would assign this PM to this type of project? It quickly became clear when talking to the PM that he had not managed anything like this before and that he was going back to the textbook to try to work out how to run the project, which is obviously not a good

approach when under time and budget constraints. I concluded that, fundamentally, the situation was not his fault. He never misrepresented his skills and experience, but his manager assigned this project to him anyway. What was the process his manager used to make that decision and how much thought was applied? No process, not much thought. The thinking was likely along the lines of: "I have a project. You have a PM job title. You're available. This one's yours."

Could that PM have refused the assignment? Possibly, but with potential career-limiting consequences. Will that PM succeed? No, but he'll be a useful person to blame for the failure.

Who gets to assign PMs to projects? The answer to this may provide some insight into one of the root causes of the problem, at least in IT projects. Across business, not just in telecom, systems have become so pervasive that everyone has an interest in their success. At one time, IT departments ran the projects and assigned the managers. Too often, those project teams had no business domain knowledge, important decisions affecting business department were made without business input, and managers were often dismayed at the uncontrolled cost overruns and time slippages created by what they saw as bloated IT departments. Some business managers saw internal IT power and control games wasting energy and decided that