Project Management a science?

[nzric]

Hi

I have joined the Project Management Institute (PMI) and am doing research for a presentation as part of my CAPM accreditation study group.

There's a lot of articles on the net that say the average success rate of projects is approx. 30%, which has astounded me!!

Which leads to my question - do you think any field of knowledge which claims an average success rate by its practitioners of only 30% can call itself a "science"?

'Maybe' 70% of people aren't following the PMBOK methodology, so the project 'would have' succeeded had they project managed effectively. And maybe as a young field of knowledge, the failure is on the part of people's incorrect understanding of project management compared to the agreed (by PMI) definition & practice.

On the other hand a devil's advocate would say that a 70% failure rate points more towards a serious flaw in the methodology itself rather then how well the practitioners implement it.

Thoughts?

[quixotecoyote]

I'm not familiar with project management as a discipline. How much of PM theory is empiricially derived and how much is theoretical/philosophical naval gazing? As someone studying communication, I know it's often tough to filter that stuff out.

[rjh01]

I would not call project Management a science. See this for a definition of science http://en.wikipedia.org/wiki/Science. Project Management is a tool.

There are many reasons why projects fail. However it boils down to not being able to predict the future. The better you can predict the future the more successful the project will be.

For example if you want to build a large building of a unique design then the unknowns will be huge. However if you build 100 buildings that are almost the same then by the time you build the 100th you will be able to predict most things (excluding things like unusual weather). If you use project management correctly then the building should be built on time, within budget. Without project management you are building 100 buildings for the first time.

Project management is not new. I know it was used in the 1950s.

[Almo]

There's a lot of articles on the net that say the average success rate of projects is approx. 30%, which has astounded me!!

I sincerely doubt 70% of all projects fail. There's either a goofy definition of "succeed" or someone's trying to sell you something.

I work in the game industry, and I've seen a few projects canned. But nowhere near 70% of them.

[Steve]

There are many reasons why projects fail. However it boils down to not being able to predict the future. The better you can predict the future the more successful the project will be.


Agreed.

My experience with project management is is the construction industry. In very simple terms, a construction project manager will work with the owner/client to set the budget and the time frame for the project and then work to complete the project within these parameters. A project that is completed on time and within the budget is generally considered to be successful. With this broad definition in mind, in my 35 years in this business I have seen a number of projects fail to meet one or both of these parameters, but the large majority of projects have been successful.

In construction I think that successful project management is as much an "art" as a science. Getting all the players - owner, engineers, construction trades, building officials - to work as a team is probably the most difficult job in construction ( and no, I am not a construction manager, just a lowly mechanical systems designer).

Perhaps nzric could elaborate on how "success" and "failure" are defined in the OP, and or whether these high failure rates apply to a particular business or industry.

[shadron]

Project management is just a systematic way of thinking through a complicated process through completion. Like most such tools it is designed to capture, or allow for the capture of the kind of arcane details which normally are known to, say, three of the engineers on the project and no one else, and to get these taken care of at the proper level at the proper time. Finally, it also allows for the capture for historical study of a particular project and the problems it (presumably) overcame, instead of loosing that to fable. In your quote about 70% of projects failing, I would hazard a guess that most never heard of PM (and I don't believe the statistic anyway).

[Spindrift]

I sincerely doubt 70% of all projects fail. There's either a goofy definition of "succeed" or someone's trying to sell you something.

I work in the game industry, and I've seen a few projects canned. But nowhere near 70% of them.

Just because a project doesn't get canned doesn't mean the project is a success. I would guess that one definition is meeting it's original objectives including deadlines. How many projects in your industry actually meet their original deadline?

[Wudang]

http://www.bcs.org/server.php?show=conWebDoc.1167

Worth a read.

Also as Spindrift says a non-canned project is not necessarily a successful project. A success means on-time, to quality and to cost.
And good project management includes canceling projects because the requirements have changed, the business drivers have changed, more detailed analysis shows that the cost/benefit ratio isn't as good as first analysis showed etc.

[Almo]

Just because a project doesn't get canned doesn't mean the project is a success. I would guess that one definition is meeting it's original objectives including deadlines. How many projects in your industry actually meet their original deadline?

Meeting the "Original deadline" is an artificial goal. When My Word Coach didn't ship on its originally intended date, it was because it was decided we could make it a better product by delaying its release. It got delayed 3 times.

The DS version (the one I worked on) sold roughly 2.5 times as many as we needed to break even. So, we missed our "original deadline" 3 times, but made a healthy profit. That's hardly a failure. I could cite many other projects our studio has made the missed their deadlines, yet became very successful. I've personally been on one that was canned, one that made enough profit to pay us a bonus, and one other that failed to break even, so I'm not pretending that all our projects succeed.

There's another issue in our industry; sometimes consumers don't "get" a product, despite it being a successfully realized product. Amplitude (http://en.wikipedia.org/wiki/Amplitude_%28video_game%29) and Rez (http://en.wikipedia.org/wiki/Rez) are well-known examples in the industry of brilliant games that didn't sell. These projects were successes from a project management point of view, but for whatever reason, they just didn't catch on in the market. Both games got rave reviews, won awards, and are well-respected in certain circles of the industry as accomplishments in the art of game-making.

So I stick with my original assessment: "There's either a goofy definition of 'succeed' or someone's trying to sell you something."

[Denver]

...So I stick with my original assessment: "There's either a goofy definition of 'succeed' or someone's trying to sell you something."

There may even be a goofy definition of 'fail'.

A well-managed project of a significant size includes acknowledging that there will be oversights, unknowns, and missing or changing requirements and constraints. A project that gets underway, and then it is found that WHOOPS, we forgot something, and the project has to backtrack, is not a failed project. It is a normal project.

A project that never delivers what it promised the end user, is a failed project. A project that has cost and time overruns may not be a failed project, if those are handled well.

[nzric]

Looks like the definitions on the internet of 30% "successful" projects is those that were delivered within the constraints originally planned. If a project was delivered "successfully" but ran over scope/time/budget/etc, it wasn't classed as a "failed" project but it is not graded as a success.

This could come down to project managers over-confidently designing a project or putting too much faith in their original estimations, rather than doing what some people in above posts have mentioned, i.e. "progressive elaboration" of a project to lock down estimates only at the right time.

Catch 22 I suppose. On the one hand, you're going to lose out to a more confident project team if your pitch sounds wishy-washy, but if you over promise and under deliver, the end product could be worse.

You could blame the sponsor for lack of understanding of what and how accurately a project manager can deliver a result, but I still think that there seems to be a lot of "spin" to misrepresent a set of useful tools as some kind of science.

[fishbob]

Project managers are not supposed to design or estimate projects - they are supposed to build or construct or develop the designs of the engineers or architects.

Got to have somebody to blame when the job goes south.