CIO Magazine, by way of Slashdot, has an
article on the state of IT projects. It compares the latest results of the famous/infamous Chaos Report from the Standish Group International with the results from the first report in 1994.
In 1994 the report said that 31% of IT projects were outright, absolute failures and did not make it to completion. Only 16% of IT projects were "completely successful", delivering on-time, on-budget, and with no significant change in features.
The latest 2007 reports says that only 19% of IT projects are outright failures, and 35% are "completely successful".
Some of these improvements in overall performance are because of agile processes, and tools like UML and better project management software. But that still leaves 46% of projects that do not fail but are "challenged".
Project Managers are judged and evaluated by the success factors of their projects. But according to the Project Management Institute (PMI) and the Project Management Body of Knowledge (PMBOK), unless the organizational structure is projectized with the team members and resources solely assigned and dedicated to the project, and under the project manager's direct authority, there is too much of a possibility of a power-play and the resources being pulled off to work on something else, which is one of the biggest causes of project delay. And very few organizations use a projectized format.
Project quality is affected by the "triple constraint" - project scope, time, and cost. Change one and the others will need to change. It is challenging to deliver a project to meet all three and still respond to change. Indeed, the Standish Group's stats for 2007 show that 65% of IT projects will not meet requirements or will be outright failures. Tough, lopsided odds for a positive outcome. I have seen many project managers do a great job of managing change, getting additional resources when the project falls behind, and deliver a huge project that meets most of the success factors, only to be dinged in the post-project performance review because the project was not on-budget or on-time.
Alot of that would depend on the culture of the company. What happens to a project manager after the project? Is he retained and the lessons learned applied to the next project? Or is the project manager let go, or a contractor who is released at the end of the project? Many of the dedicated PM jobs in my area are contract.
Culture also plays a role in how a company handles the news that a project is behind schedule (the willingness to handle bad news). A proactive company wants to know what the project status is, and has processes in place to handle variance in cost or schedule, as well as the change requests that drive those changes in cost or schedule.
BTW - one of the quotes I like from the article in CIO is the acknowledgment that agile processes discourage using overtime to make up the shortfall in the project timeline.