Some are burned on previous implimentations that just don't do what they are supposed to do. Your #3 is that about project management software. Going more generally, the company may have put out a new process that was to solve a problem, but made it worse.
Sometimes the new solution has helped management see the business better, but made people at bottom take more steps (introducing more ways things can go wrong). I remember one place I worked where the managers used mice and the admin workers used keyboards for entry. The admin workers felt that they'd never be able to work as quickly and efficiently because they had to do several fancy mouse movements instead of a few key presses.
Discussion on:
View:
Show:
In most of the Indian companies, one most important reason to fail any project is the breaking up Hierarchy.
Lack of commitment from the organisation towards PM shows itself pretty commonly, all the others are to lesser or greater extents subsets of that. As the PM, it's part of the role to educate the organisation into committing itself; no mean feat at times.
Talking of lack of commitment, we get only 1 PM article on here every couple of weeks, many of them are pretty lame too, and this one's a repeat. The cheek...
Talking of lack of commitment, we get only 1 PM article on here every couple of weeks, many of them are pretty lame too, and this one's a repeat. The cheek...
I wouldn't say that #2 says it all but it's certainly a project killer. Many years ago I was given a major, understaffed, and ill defined project and as a team we agreed that before we jumped in feet first we had to clearly define what the project was supposed to accomplish and develop a plan. After a few weeks we'd made quite a bit of progress. We had wall charts, documented analysis, initial estimates, progress reports... Then our sponsoring exec read us the riot act saying (obscenties deleted) I haven't seen you guys do anything but draw pictures. Get to work and cut some code. It was nearly a career killer. I survived only by delegating and moving on to other things as the project struggled along for several years and died a slow, agonizing death. Of course today our execs are much more enlightened. Right?
Sadly, some execs seem to think that project management is a cure-all which just involves giving an overburdened junior line manager a copy of MS Project (without training, of course). Presumably these execs like to learn the hard way. However, it does leave open the question of how to convince execs otherwise, perhaps us PMs should learn more about a sales techniques.
Not sure that many of the execs taking the approach mentioned by tim_uk actually learn. In my experience, many seem to conclude that the failure was not their approach, they just gave the assignment to the wrong person (again and again and again.......). Talk about the insanity of doing the same thing over and over again assuming you will get a different result.
Sometimes the PM becomes too detailed in the tasks included. We had a project that ended up with over 10,000 tasks, and it was impossible to make time to just update your progression. Almost felt like I had to write down when I went to the bathroom!!
I learned my PM skills in a business that would track every task on a project of ?60m down to the half-our (including every half-hour task, and each and every task had it's own cost account). We had a small team of three managing the updates and an automnated process that linked the tasks the resources and the budgets. one PM, an assistant PM to cover the scale of meetins and coordination and one guy planning. If you need it, you have to staff for that too, if you don't need the detail don't plan it. You don't need to see every step of a serial activity, provided you can reflect a robust and realistic view of percentage complete along this path.
I think also that very often the project manager and all the people involved in a new project do not put in their planning the necessary time to work on the project.
It is a big mistake to believe a new project can be driven by people who are also dealing with their normal day to day work. The day to day will occupy the whole space and project management will be shortly reduced to zero driving directectly to a project failure.
It is a big mistake to believe a new project can be driven by people who are also dealing with their normal day to day work. The day to day will occupy the whole space and project management will be shortly reduced to zero driving directectly to a project failure.
You almost sound like PM is not normnal day-to-day (or dare I even say full-time) role.
My experience is if PM and operationsal activities are on the same individual, the operational must-do-now stuff fills almost all the avaialbel time. The PM must-do-now stuff urgent tends to be tied to reporting, the important stuff like risk-reviews, resource evaluation gets second step until an impact issue makes it urgent, by which time it's too late. If you don't have the scale for any project to keep a PM busy full-time, give all the PM functions from differnt projects to one PM who doesn't have operational roles. You will obviously need to separate the resource control to team leaders, but this takes the urgent stuff out the way of the important stuff.
My experience is if PM and operationsal activities are on the same individual, the operational must-do-now stuff fills almost all the avaialbel time. The PM must-do-now stuff urgent tends to be tied to reporting, the important stuff like risk-reviews, resource evaluation gets second step until an impact issue makes it urgent, by which time it's too late. If you don't have the scale for any project to keep a PM busy full-time, give all the PM functions from differnt projects to one PM who doesn't have operational roles. You will obviously need to separate the resource control to team leaders, but this takes the urgent stuff out the way of the important stuff.
...is pointing to the situation where the priorities have not been clearly set and the additional duties are expected to be accomplished in the same framework and priority level as all of their other work. Ponroy is addressing poor resource management and allocation.
(On the side, is anyone seeing these singlesnet ads on this page. Good Lord!)
(On the side, is anyone seeing these singlesnet ads on this page. Good Lord!)
The 5 point list pretty well somes up the key challenges.
Perhaps one dynamic that may have gotten over looked is the dependency that Project Management relies upon getting good time estimation from his/her SME's.
The key here is that the SME's both Developer & Sys Admin may not know how estimtate time. As the PM is dependant upon their judgement a gap may occur between the PM and Sr. Mgt over the schedule which leads back to point #1,#2 and #4.
Perhaps one dynamic that may have gotten over looked is the dependency that Project Management relies upon getting good time estimation from his/her SME's.
The key here is that the SME's both Developer & Sys Admin may not know how estimtate time. As the PM is dependant upon their judgement a gap may occur between the PM and Sr. Mgt over the schedule which leads back to point #1,#2 and #4.
Some corporations and government departments rely on project management implementations but only for IT solutions; there is no consideration within business or with organization-wide initiatives that project management can provide value, tactically or strategically. All too often, the more credentialed individuals are considered to be specialized and therefore must be an IT person. So many certifications, PMP (Project Management Professional) included are placed into a technology hopper because, like IT, project management practitioners need to focus more on business objectives and not inward at individual projects or IT solutions.
Project managers and their executives need a better "value equation" on how an effective project governance methodology can benefit the bottom line. If your organization has challenges in executing (getting things done) create a business case on how a PM methodology will deliver executive value. If your organization has a challenge in priority management or risk management; create a Portfolio (collection of business projects) scorecard based on project scorecards to identify challenges and risks, identify which projects are connected to the business plan and quickly focus executive energy on the critical few business projects that need their attention.
Only when corporate executives understand the business case of project management, the value that consistent project delivery can provide to their bottom line will inroads of project governance and delivery be made. It is up to the project management profession to consistently focus on what value and improvments they will bring to an organization.
Project managers and their executives need a better "value equation" on how an effective project governance methodology can benefit the bottom line. If your organization has challenges in executing (getting things done) create a business case on how a PM methodology will deliver executive value. If your organization has a challenge in priority management or risk management; create a Portfolio (collection of business projects) scorecard based on project scorecards to identify challenges and risks, identify which projects are connected to the business plan and quickly focus executive energy on the critical few business projects that need their attention.
Only when corporate executives understand the business case of project management, the value that consistent project delivery can provide to their bottom line will inroads of project governance and delivery be made. It is up to the project management profession to consistently focus on what value and improvments they will bring to an organization.
The Answer is it's the infrastructure. Business that doesn't fail is built on infrastructure that doesn't fail. The PM oversees the details to insure the infrastructure will not fail.
Infrastructure that fails results in business losses, downturns, and customers bailing on poor performance.
The time, effort, and funding in the front end equals less time, effort, and funding for maintenance and upgrades.
Hey! you got a two 'fer!
Have a nice day!
Infrastructure that fails results in business losses, downturns, and customers bailing on poor performance.
The time, effort, and funding in the front end equals less time, effort, and funding for maintenance and upgrades.
Hey! you got a two 'fer!
Have a nice day!
Agree with you Lorne - if you want PMgmt to be taken on board seriously by your executives you've got to present it to them in something they understand. The reality is as PM's we practice what we preach every day so it is hard for us to understand why our exec's don't get it - the reality is they don't have to because thats what we do. Our challenge is to present the case for PMgmt to them in a way that the understand. If they can see the value proposition they'll run with it and leave the detail to us.
Scope creep always happens, for management will keep adding things that they want in addition.
As agile software development methodologies have matured and become widely adopted we've found that scope creep is less of a problem. Assume that business needs and scope will change. They will. Assume that you can't plan a software project in excruciating detail up front. In most cases you can't. Agile does not mean unplanned. It means planning to manage change. This is very different from the usual project management approach which includes change management but tries very hard to keep changes out of scope.
Scope creep is inevitable with IT projects BUT the organisations that just want to do it (Nike)and dont plan enough upfront get into big trouble on this issue.
Define the scope upfront, make sure everybody understands what the deliverables/outcomes are. Imagine buiding a car and you don't know what it should look like or what size engine it should have. That is what a lack of scope on a project does.
Define the scope upfront, make sure everybody understands what the deliverables/outcomes are. Imagine buiding a car and you don't know what it should look like or what size engine it should have. That is what a lack of scope on a project does.
is the disease. Scope creep itself, is a natural consequence of attempting to define scope. 
Defining scope is a lot harder to do than to write.
The purchasing system will not integrate with the existing invoicing system, no poblem, clear and unambigious. OK so likely to creep all over that one.
We will collect order data (undefined) and use in ways that will enhance efficiency (no benchmark) as according to our mission statement (pulease).
A continual battle as to what the scope is, was, could be and may be.
Defining scope is a lot harder to do than to write.
The purchasing system will not integrate with the existing invoicing system, no poblem, clear and unambigious. OK so likely to creep all over that one.
We will collect order data (undefined) and use in ways that will enhance efficiency (no benchmark) as according to our mission statement (pulease).
A continual battle as to what the scope is, was, could be and may be.
We all accept that scope creep is hard to define, but the simple explanation if you will forgive me is that it has to be defined or else you will not know if scope crept. We often get poorly defined projects and this area is the worst especially in IT.
Secondly where scope does change, and it will mostly I agree, we do of course use change management to authorise and scope the scope changes.
Secondly where scope does change, and it will mostly I agree, we do of course use change management to authorise and scope the scope changes.
That's the one where what you have to do get's changed. But not the budget, the schedule, the people or any other already costed resources isn't it?
Of course we use...
Sorry but far too often to the tools of project management are only used to modify the plan, the reality usually lags.
Of course we use...
Sorry but far too often to the tools of project management are only used to modify the plan, the reality usually lags.
Or is it scope clarity? My experience has been that we substitute and blame scope creep for our inability, at least in software projects, to completely understand and document every requirement. So, when that clarity emerges as prototypes, wireframes and data models start to develop, we blame the end users. I think Agile's biggest promise is the acknowledgement that requirements and priorities change and need to be accommodated and embraced.
Communication between Project Management Lead and the developers is also essential. The developers need to know that they must follow the detailed plan. If they deviate from it, the product will not be what the user wants. Learning to communicate as a group will also help the PMO office move ahead with the project. Effective listening skills are also needed. If you are not hearing what is being said because you (a developer) are thinking of how to do something when the requirements are being written as the ???what the system should do,??? slows down the development also.
the top causes in a recent industry survey were:
#1 scope creep
#2 missed or poorly defined requirements
#3 unrealistic schedules and expectations
you can get the full report here:
http://www.jamasoftware.com/requirements_management_report_download.htm
#1 scope creep
#2 missed or poorly defined requirements
#3 unrealistic schedules and expectations
you can get the full report here:
http://www.jamasoftware.com/requirements_management_report_download.htm
Conflicts over resources can be an absolute killer to a project.
The conflicts seem to arise from time allocation, or accountability; and usually results in a functional manager butting heads with a project manager. This is a morale killer for both the functional and project teams.
You really need leadership in an organization that is committed to what's best for the overall business and maintains amicable lines of communication to make sure you don't fall into this trap.
The conflicts seem to arise from time allocation, or accountability; and usually results in a functional manager butting heads with a project manager. This is a morale killer for both the functional and project teams.
You really need leadership in an organization that is committed to what's best for the overall business and maintains amicable lines of communication to make sure you don't fall into this trap.
Good article. I agree with the points. According to me, Stakeholder Management (especially with large projects where are too many stakeholders involved), contract management (sales v/s delivery expectation management), scope management (what the project sponsor expects v/s what the delivery team understands), change management (which is related to scope management - out of scope requirements and changes to existing requirements need to go through a change management process) are the most important project management aspects where most Project Managers fail today. And all these aspects require good communication and negotiation skills! It is not easy to build these skills. It takes time and sometimes a behavioural change.
When the project sponsor has no understanding of project management, the wrong people are employed to drive the change and inevitably if fails. The blame usually falls on the employees who have been asked to implement an unworkable solution, and the old chestnut "people don't like change" is rolled out as an explanation. People don't like change when it is poorly planned and badly done and most have been burned in previous "restructures" etc.
Having been involved in a failed project that cost millions of dollars and thousands of man hours, I agree 100% with that assessment. The workers saw that the project, a move from a flat-file based system to a relational database, was not well thought out or analyzed, and understood that it wouldn't work from the beginning.
And guess what, those high school educated workers were smarter than the degreed upper management! They didn't sabotage the project--the manager in charge had basically committed all the sins on the list. The end result was unusable and eventually abandoned.
And guess what, those high school educated workers were smarter than the degreed upper management! They didn't sabotage the project--the manager in charge had basically committed all the sins on the list. The end result was unusable and eventually abandoned.
Differing Expectations are a killer - unless ALL key stakeholders (including the sponsor) have the same set of expectations (in terms of effort in- value out) - PM initiatives will die just like Projects themseleves
It has been my experience that many executives, as well as PMs, don???t understand the difference between project and product deliverables. Although the PM is accountable for the overall project???s success, the PM isn???t responsible for the product deliverables???the technical folks are. In addition, there is confusion to the difference between a Project Manager and Manger of projects. Thoughts?
Pat,
There are some excellent books out there on Project Management, among them Bob Lewis' Bare Bones Project Management, and I've read a few of them recently just to refresh and hone my skills.
What your subject points to is the lack of a definition and agreement by all parties as to what defines success, all preliminary and the final project closure success. If this is clearly spelled out and agreed upon by all, you know where your project is supposed to go and what it is to result in. Its more of things under #4, which I feel should be #1.
George
There are some excellent books out there on Project Management, among them Bob Lewis' Bare Bones Project Management, and I've read a few of them recently just to refresh and hone my skills.
What your subject points to is the lack of a definition and agreement by all parties as to what defines success, all preliminary and the final project closure success. If this is clearly spelled out and agreed upon by all, you know where your project is supposed to go and what it is to result in. Its more of things under #4, which I feel should be #1.
George
Organisations are willing to bear the cost of expensive tools but are unwilling to bear the cost of the most effective and important tool i.e. a competent project manager; they compromise on the cost, hence the PM skills and ultimately the organisations objectives and goals.
Ashish,
I agree with you completely, though its not likely true in every case. But your point would be an underlying cause for all 5.
A good, scrappy PM would handle or mitigate all of them.
George
I agree with you completely, though its not likely true in every case. But your point would be an underlying cause for all 5.
A good, scrappy PM would handle or mitigate all of them.
George
Top five reasons organizations fail at project management:
o many "experts" who think they know better than the project manager, who aren't prepared to listen and have meetings that exclude the project manager whilst making unilateral decisions that will affect the outcome.
o many "experts" who think they know better than the project manager, who aren't prepared to listen and have meetings that exclude the project manager whilst making unilateral decisions that will affect the outcome.
But how should one deal with it when it happens? If it's a technical group declaring independence I think it's good to delegate the work package to them as much as possible, so long as they realise that they are expected to report on progress and adhere to plan, productivity, quality standards etc etc, though the realisation of responsibility may not be taken so well by them. The tricky one is where it's a management group declaring independence, for instance I've had projects where a work package is being handled nicely by someone and then their line manager determines it should be done differently or that they should use the project to build up their areas processes too.
None of those things help of course, but the real reason for failure, is that most are set up so you can never succeed.
Even the best PM can't manage expectation (the terms that define success), when others in the organistaion refuse to accept that it's their success criteria that must be amended in order to achieve this elusive goal.
It either costs more, takes longer, you receive less, or the project gets canned at the get go because the estimates are too scary.
Until the above is accepted, PMs and the poor grunts who have to wave their wands in concert to grant the wish have no chance.
Even the best PM can't manage expectation (the terms that define success), when others in the organistaion refuse to accept that it's their success criteria that must be amended in order to achieve this elusive goal.
It either costs more, takes longer, you receive less, or the project gets canned at the get go because the estimates are too scary.
Until the above is accepted, PMs and the poor grunts who have to wave their wands in concert to grant the wish have no chance.
I think this would be the number one issue.
A more P.C. statement would be that they are stale or simply inexperienced in the technology the project contains.
Bias is another big problem, whether it be the old Windows vs Unix argument or a partiucular vendor.
A more P.C. statement would be that they are stale or simply inexperienced in the technology the project contains.
Bias is another big problem, whether it be the old Windows vs Unix argument or a partiucular vendor.
Good project management is essential to managing change. You comments show a lack of understanding. I hope you work in a small shop.
who knew nothing about technology and a great deal about managing expectation, than the other way round...
I'll explain the tech, it's what I do, the PM gets to explain what my explanation of the tech means to the project.
I'll explain the tech, it's what I do, the PM gets to explain what my explanation of the tech means to the project.
The primary reason ALL projects tend to fail or run into a lot of 'bad road' is forgetting to put the ultimate project manager in the middle of all things,GOD!
I haven't read all the responses and I will, because I want to hear what others think about this.
I do wonder why a newer edition of this article couldn't be provided rather than a 2 year old one.
I would change the order and add some others.
#4 should be #1, clearly in my mind.
Add to this insufficient risk analysis and mitigation strategy development.
#4 needs to be balanced with long, mid, and short term business pictures.
I have seen Job requirement specs looking for people who have managed a 5 year project. To my mind, in the current business environment, a 5 year project is doomed to failure or "projectus interruptus".
Paradoxically, technology has not been evolving at the same rate as the business climate.
To quote others before me....Its complicated.
George
I do wonder why a newer edition of this article couldn't be provided rather than a 2 year old one.
I would change the order and add some others.
#4 should be #1, clearly in my mind.
Add to this insufficient risk analysis and mitigation strategy development.
#4 needs to be balanced with long, mid, and short term business pictures.
I have seen Job requirement specs looking for people who have managed a 5 year project. To my mind, in the current business environment, a 5 year project is doomed to failure or "projectus interruptus".
Paradoxically, technology has not been evolving at the same rate as the business climate.
To quote others before me....Its complicated.
George
Wrong persons selected for project team. They are either inexperienced or not trained, or do not know the business side of the house. A mix of tech & business needed to suceed
Incompetency or plain old lazyness are much easier to hide and tons of excuses for not delivering can be provided in organization without formal project management methodology.
Harold Kerzner wrote: "Project management is the art of creating the illusion that any outcome is the result of a series of predetermined, deliberate acts, when, in fact, it was dumb luck".
I tend to agree with that more and more
Harold Kerzner wrote: "Project management is the art of creating the illusion that any outcome is the result of a series of predetermined, deliberate acts, when, in fact, it was dumb luck".
I tend to agree with that more and more
... there are a lot of excellent observations and statements, as I expected, but we're all basing our statement on our own experiences. Should it read "Top reasons..." or should it say "Most common factors experienced... based on generally published opinions".
I have seen projects fail for many other reasons as well, wrong people on project team and inexperienced/inefficient PM in charge or slightly in charge.
Its hard to draw empiricals in anything that has to do with people.
George
I have seen projects fail for many other reasons as well, wrong people on project team and inexperienced/inefficient PM in charge or slightly in charge.
Its hard to draw empiricals in anything that has to do with people.
George
And can come down to poor scope, poor resourcing, or completely unrealistic expection.
All of which feaure in the top five. Lets face it if your destiny is to fail before you start, a crystal ball of some description is unnecessary.
All of which feaure in the top five. Lets face it if your destiny is to fail before you start, a crystal ball of some description is unnecessary.
with management. 
The wrong people is a mis-allocation of resources.
A weak/poor PM is a catastrophic mis-allocation of resources.
A hamstrung PM, is a failure in scope.
Even if none of those are true, all you need is someone at the top to shave (usually decapitate) your initial estimates to get a green light on the project.
Last but far from least, those estimates, use this do that, here's a scientific method. Might as well consult a fortune teller.
The wrong people is a mis-allocation of resources.
A weak/poor PM is a catastrophic mis-allocation of resources.
A hamstrung PM, is a failure in scope.
Even if none of those are true, all you need is someone at the top to shave (usually decapitate) your initial estimates to get a green light on the project.
Last but far from least, those estimates, use this do that, here's a scientific method. Might as well consult a fortune teller.
- Keyboard Shortcuts:
- Prev
- Next
- Toggle
