Frank WintersPhotographer and ConservationistSandwich, Ma, United States
In your experience, what are the primary causes of project failure? I have my personal top ten list, what's yours? In particular, what can be done to improve the abysmal success rate of IT projects? If we solve this conundrum, let's move on to world peace! Saving Changes...
These are the deadliest of project management enemies.
As a project manager I am used to structure - a predetermined schedule with predetermines objectives - but when whom I called the Project Owner (he who bankrolls the project within your company and is its ultimate ?owner?) is overcome with creative orgasms over the weekends or when going to vacations the project goes south.
This is my real life experience. My former boss was the ultimate project owner and over the weekends he would have "ideas" regarding the project. This led to his changing the direction, the objectives of the project SEVERAL times during its development.
The result was his derailing the project going way over the deadline at higher costs.
As a project manager I was able to talk him out of an idea 2 out of 3 times, but 1 out of 3 was enough to destroy the project and specially the teams morale.
So, is there anything you can do about it? How do you go about controlling the projects "owner" when you're a wage earning employee? Saving Changes...
Frank WintersPhotographer and ConservationistSandwich, Ma, United States
Giving lip service to good project management practices occurs in organizations that allow it to happen. I agree that this is a cause of failure, a very important one. Truth be told many senior managers don't believe in discipline, they believe in winging it 'cause its more fun. If that's the case there will be little or no pressure to follow the methods or standards we say we will follow. The article about creating a supportive environment is pertinent as well. The culture/environment has everything to do with how we behave. Leadership is needed but I like to think that at least some of it can come from the ranks of project managers themselves and the pressure can be peer pressure. To say "nobody does a WBS" and call yourself a Project Manager sounds odd. What does it mean, then to be a PM? We have been shocked by the level of cynicism and chicanery at the senior levels in business recently. Are we in middle management no better? Saving Changes...
Dr Mike O'CallaghanCoach & Project Manager| Relevant InternationalCape Town, South Africa
Hi Frank
Research has shown that, although PM ability (skills and experience) is the number one issue in determining project success or failure, the organisational environment in which projects are undertaken influence the PM's ability to perform. This might easily suggest that the PM is not fully responsible for project failure, but I don't think so. I believe the problem does lie with the PM, but s/he is a product of his environment.
Much 'real-world' project management relies on the PMBOK view of projects. This view was originally developed in the mid 1970s and reflects the project management needs of the American state of being at the time. These projects were highly specified, relating largely to NASA or US Defence needs. This can be seen in the structure of the PMBOK and the literature and training under the auspices of the PMI.
Ten or fifteen years later, times had changed and projects needed to be more business oriented. It is in this different environment that the British Association of Project Management came into being. Although the original methodologies were developed in support of UK government functioning (e.g. PRINCE), the 'APMBOK' is structured a little differently. Perhaps the information contained in both BOKs are similar, but emphasis is different. http://www.apm.org.uk/pub/bok.htm
In my view, the "APMBOK' knowledge areas result in a far more effective project manager. S/he should be able to manage the project within the constraints of the environment in which the project operates. Saving Changes...
Frank WintersPhotographer and ConservationistSandwich, Ma, United States
Hello Mike,
Thanks for the very helpful post. I agree with you that the environment(s)the PM is working within have lots of influence on behavior and performance. This is why no set of standards by itself is sufficient guidance for the PM. When a project plan is being created, standard methods provide the framework for the creation of the plan and its supporting methods. This is one reason so much depends on the PM today. I've always found it beneficial to remind myself of first principles when dealing with a project issue, then looking for a standard practice to facilitate the use of the principle involved, then modifying the practice to suit the situation. The PMs that are most in danger of failure are those who are unaware of the nature of first principles regarding the art and craft of project management. Saving Changes...
I've found this discussion thread to be pretty much spot on -- hard to disagree with anyone's points. It's a complex business world we operate within, with technology, processes, organizational structures, etc. that don't necessarily align to help promote success in IT initiatives. I'd like to add a couple of points for consideration.
I've been quite shocked at the emphasis given lately to "certifications", especially the PMP. While I'll never argue against education or certification, my experience has been that some of the most "questionable" PMs I've come across always to seem to have PMP or other certification.
This brings up of the issue of "art vs science". The technical toolkit that a PM uses (WBS, change control, scope mgmt etc, etc) are really just the basic hygiene portion of managing a project. These can be done either in an academic or real-world setting. However, the real art of project management is in how one utilizes that toolkit within the organization/environment that one is trying to deliver the project. This is where the experienced PM, who goes beyond managing by PMBOK will be the best bet the project has in succeeding.
I also have to agree with the comments that effectivenes of the PM is highly influenced by the organization they are working within.
Here's some food for thought. Most organizations put more planning, thought, focus, and committment into a major office move (say moving 200 people from one building to another) than they EVER do in implementing a new IT system. Saving Changes...
Frank WintersPhotographer and ConservationistSandwich, Ma, United States
Good food for thought, Kevin. Maybe the reason people will plan a simple move better than they plan a complex IT project is that the move deals with things that are more tangible than the IT project does. There are still many people who believe software and systems development is so completely art based that it can't really be managed. Sort of like telling Michelangelo when to finish that ceiling! Saving Changes...
Anonymous
I have a few points to add on the possible reasons for the failure of (Information Systems) projects in particular. These points maybe more relevant to those organizations where IT projects are carried out by (IT novice) Project Managers/leaders. In case of more bureaucratic (government) organizations these situations are more likely to occur.
In such cases, some of the failure reasons could be due to the fact that the Information System (IS) implementation projects are led by "IT Enthusiasts" who:
(1)are keen to adopt technology, but unaware or ignorant of the dynamics of IS project management. In doing so, they ignore or avoid some of the key aspects of any IS implementation (for e.g., user participation, preparation for minimizing user resistance to change, maximum communication with all the key stakeholders, process improvement, Risk Management, etc.)
(2)are convinced about the benefits technology can bring to the organization, but lack the specialized knowledge to go about implementing IT based Information Systems. This knowledge is a blend of knowledge gained from IS theory (i.e., academic stuff) and practice (hands on experience of IS project management). Such IT enthusiasts cum project managers may have very rational and scholastic approach towards problem solving but the very nature of IS project implementation is still a new field for them. Hence the finer points of IS project management are missed by them and failure of IS project becomes imminent.
(3)evaluate the progress of IS project on the basis of hard aspects like status of software code, number of computers available, availability of IS books in the organization, etc. While doing so the "people" who are going to be the users of technology are viewed as unimportant or irrelevant and little or no attention is paid to issues like user expectation management, communication across the organization/project team, etc. Saving Changes...
Frank WintersPhotographer and ConservationistSandwich, Ma, United States
Good points in the post by anonymous, pointing out aspects of training that many PM's have not been exposed to. There is a tendency to over emphasize technical capabilities when assigning project managers. Senior management is often so concerned about "will the new technology even work" that they do not pay enough attention to the project holistically; especially the human and political concerns that more completely prepared PM's are able to deal with. Ironically, this points to a need for the senior managers to be a bit more technically aware, while the PM's need to be more politically astute. Saving Changes...
Mike Cooper PMPPrincipal Project Manager (retired, sort of)| New England Project ServicesWestford, Ma, United States
Regarding the last couple of posts, there was an excellent opinion piece by Patricia Keefe in the April 7 issue of ComputerWorld, called "Credibility Insurance". The beginning three sentences sum up what people miss when they are too focused on the technology, or lack an ability to match technology to business need.
To quote: "Life would be infinitely easier for IT if there were no such thing as an IT project. And in fact, there isn't. Any project worth doing has to serve a business need, which in effect makes it a business project."
She goes on to point out problems that occur when business / IT is somewhat disconnected, and proposes some approaches to fixing this.
IT departments these days have come a long way towards better integration with business, but there is often still a long way to go. Understanding the challenge is one thing, getting everyone (and I mean everyone) in the department to think this way is harder. And of course the business side needs the IT component understanding, as Frank mentions. Saving Changes...
One of the biggest causes for failure is a change of direction or loss of direction after the planning stage.
Once the project has passed the planning stage and has started on the operational phase is not the time to change the plan.
One technique that has worked in some areas is a sign-on contract. With a sign-on contract, the stakeholders (or their representatives) must sign onto the plan before the go ahead is given. This means that all stakeholders have agreed to the plan and that all stakeholders have to agree to make a change.
With a sign-on contract, the only way to change the project is by agreement by all of the stakeholders. At that time either the contarct is changed or a new sign-on contract is created.
You would have to determine the best method for your company, but by forcing all stakeholders to participate, you are less likely to need to change your vision and are more likely to succeed. Saving Changes...
