Recently in Project Failure Category

Within the realm of project management--or any other complex system, for that matter--accurately identifying failure is difficult to the extreme. There are simply too many parameters to isolate, which makes writing about management a precarious proposition.  

Oh, there are certainly those cases where a project manager insists that no cost or schedule management systems be used, and it doesn't take long to drive that project into the ground. But in most other areas the link between act and consequence is not nearly so stark.

Renowned psychologist, B.F. Skinner, wrote that a variable rate of reinforcement virtually guarantees a behavior will continue. If that is so--and I believe it to be--then it follows that a practitioner who has experienced success using a particular technical approach may be inclined employ that approach over and over--even when it fails over half the time. That same practitioner might also be inclined to join with like-minded project managers to advance a new model or structure for success.

Their assertions may be correct and insightful universally, in some specific environs, or completely off base.

I entitled this post "Part 1" because I intend to take a close look at some conventions that may have been adapted in that spirit and without the scrutiny of an iconoclastic wise guy such as me.  

Next up:  Does risk management really help bring in projects faster, cheaper or with higher quality?

See relevant research from Project Management Journal® as reported in PMI Community Post: Avoiding Project Failure by Managing Organizational Culture

Project management practitioners who read the conventional wisdom on those things that threaten project success may be "getting sold a bill of goods" (a U.S. colloquialism meaning to be deceived).
    While project management-types usually don't stay in the industry for long before witnessing a project crash-and-burn firsthand, the ability to accurately identify and clearly articulate the proximate cause of that project failure is often elusive, with individual prejudices coloring analysis. Quality engineers tend to name a lack of quality capability as the main reason behind project failure, while estimators tend to believe inaccurate cost baselines or estimates at completion are the culprits.
    I have a pretty clear idea of the main, if not only, cause of project failure, but before I name it, let me tell you what it isn't:
•    No Six Sigma
•    Lack of Agile project management
•    Failure to engage stakeholders (see my previous post)
•    Inappropriate leadership style
•    Too few Project Management Professional (PMP®) credential holders
•    Insufficient procedures or written guidance
    I could go on, but this list should be sufficient to contradict the majority of management writers who are asserting the key causal factor in project failure.
    So, what is the main causal factor? The project manager and/or project team made bad decisions.
    This is not simply a semantic difference. The ability to make good decisions is absolutely critical to any and all project outcomes, including the ability to meet success criterion. This ability is influenced by several factors, including:
•    The education/capability of the project team
•    Some level of luck, certainly, but mostly:
•    The availability of adequate project cost and schedule performance information, which almost always clarifies the best project decisions
    So important is the generation and delivery of cost and schedule performance information that any manager who eschews such information has automatically signaled their incompetence, and inappropriate placement in any position of authority.
    I'm essentially calling out the anti-cost/schedule performance system crowd. (You know who you are.) If you have ever argued against the introduction of an earned value system on principle, stop calling yourself a project manager because you aren't one. Of course, I'd love to hear from anyone disagreeing with me on this, so, please leave a comment.

In 1971, a Stanford University researcher conducted a psychological experiment where 24 student volunteers were divided into the roles of prison guards and prisoners, and played out their roles in a prison setup in a basement at the university. The experiment had to be called off early, as the students given the role of guards began to exhibit sadistic behavior toward the students playing the prisoners, who began to show signs of psychological trauma themselves.
    While the set-up and conduct of the experiment have drawn criticism, it's hard to evaluate the behaviors observed without a sense of astonishment and horror at what some people with a sense of authority can do to others. I believe that a valid conclusion that can be drawn from the Stanford University prison experiment is that, over time, anybody perceiving themselves in a morally or intellectually superior role with respect to another specific set of people, combined with a sense of authority, will manifest monstrous behavior.
    And now, on a completely different subject, I'd like to evaluate if the people who audit systems and subsystems are subject to influences that might lead them to believe that:

• They are in a position of intellectual or moral superiority over the ones being audited
• They are in a position of authority, and
• These perceptions are consistently held over time.

    Because, of course, if conditions were endemic to the auditors' world (they are), then it stands to reason that their sense of proportion and perspective might be twisted to a point where they could not avoid monstrous auditor behavior.
    What do I mean by monstrous auditor behavior? Well, if a multi-million-dollar program office is about to have its reputation demolished (or future work denied) on the basis of a finding that focuses on a minute, legalistic "violation" that has nothing to do with the genuine advancement of project management, then the people who wrote such findings might want to do a quick check to make sure those who put them up to the audit are not wearing white lab coats and holding clipboards.

Those project managers who have accepted the quest of advancing project management capability within your organization need to be aware of a very real threat on their path. Implementation Trolls are skulking all about you, ready to bring you down.
    For example, one favorite troll tactic is to lurk beneath a bridge and attempt to eat unwary travelers who attempt to cross. If we take the action of walking across a bridge as a metaphor for initiating any change, then the Implementation Trolls destroy you in transit, usually by ginning up to the organization's nominal resistance to change. While it is beyond debate that the amount of time and energy that goes into setting up a very simple earned value management system (EVMS) pays huge dividends in useful management information, the Implementation Trolls will complain long and loud about how even that small amount of effort is overly arduous. These beings complain so excessively about largely contrived grievances they should be made honorary members of the Trial Lawyers Association.
    Then, once you've crossed the bridge and approached the castle that serves as the keep for your sought-after treasure, an advanced project management information system, you will encounter an entirely different breed of Implementation Troll.
    Far from picking off your comrades for making people do stuff that's supposedly way to hard, these trolls will insist that anything you bring them is not good enough. These Implementation Trolls are invariably armed with clubs that have the infamous 32 EVMS criteria etched into them, and they take great pleasure in pummeling all those who approach. The infuriating thing about these trolls is that they will often present themselves as erstwhile allies to your cause, but will then gleefully destroy your efforts as being sub-standard. Like their notorious counterparts from Norse mythology, Implementation Trolls have what can only be described as bizarre senses of proportion and perspective, and will inflict their damage while pretending to occupy the intellectual high ground.
    I'm very interested in finding out what the project management blogosphere thinks about Implementation Trolls.

The growing global financial crisis is having a negative effect on a lot of things. Stock markets. Unemployment rates. Banks.
    And now, IT budgets and projects.
    According to an October survey by CIO magazine, 40 percent of CIOs around the world plan to cut their budgets from last year. The survey of 243 technology leaders also revealed that 72 percent have postponed or are planning to postpone discretionary IT projects.
    And it gets worse. Twenty-three percent of those surveyed had already let go of employees, while another 11 percent planned to do so in the future.
    A scary thought for an industry whose reputation (warranted or not) for delivering projects on time and on budget has never really been stellar. In fact, I found an August 2007 survey by Dynamic Markets Ltd. that said 63 percent of IT projects failed. And during my regular reading of project management materials over the last few days I came across four separate stories about specific IT project that were either in trouble (over budget, falling way off schedule, etc.) or had failed altogether.
    The worst of those stories was about the U.K. National Health Service's "Connecting for Health" project. The £12 billion (yes, billion) project is four years late and racking up a lot of criticism. From the nation's Daily Telegraph:
     "The Government's IT programmes fail on cost, reliability and security grounds because Whitehall ignores the best practice in the private sector when designing systems."
    So while I can see the reason behind these cutbacks and freezes, I can only imagine at what cost they will come to the industry as a whole. Will quality really endure if money and people don't as well?
    This sounds bad, right? But, there is a silver lining: Innovation. PMI president and CEO Gregory Balestrero discussed the importance of "innovating our way out" of these tough times. And it seems as if the IT industry is trying.
    Bill Synder, an ex-contributor to PCWorld.com who covered tech stocks for TheStreet.com, says conversations with heads of technology powerhouses like Sun Microsystems and IBM are putting a postive spin (albeit a small one) on the present situation--and they are doing it with innovation.
    Initiatives like cloud computing that aren't afraid to break new ground are attracting major dollars.
    "Major firms are already planning a $1 bullion and $2 billion cloud initiatives...," Mr. Synder says.
   

Ah, the problem project. It's not a new story, and sadly, it's not as if we're surprised when projects seem to spiral out of control, especially when it comes to those in the infrastructure realm. But this certainly has to rank as some of the worst project news I've heard in a while.
    According to the U.S.-based Los Angeles Times, the $100 million sewage-treatment system project in Fallouja, Iraq is three years late, triple its budgeted costs and not even close to delivering on its goals:
    "Sewage continues to run in the streets, and the Special Inspector General for Iraq Reconstruction found that the system may never be properly connected to individual homes, lacks the necessary fuel to operate and is unlikely to ever cover the full city."
    There are certainly extenuating circumstances--and added risk factors--surrounding this project. But how did things go so wrong? An Associated Press story on the project points the finger at "unrealistic U.S. expectations from the start, repeated redesigns of the project, financial and contracting problems, and lack of good contractors to draw from."
    It's the kind of laundry list of issues that anyone who has ever done time on a "problem project" is no doubt familiar with. The true question is how do you recover?

I was doing a little research for this post and like every good writer these days I started with Google. I typed in "why projects fail" and came up with 16,700 entries. The first few pages were dominated with entries like "Top 10 Reasons Projects Fail" and "Why Projects Fail: Part 1." So what were some of the answers? Some articles blamed a lack of user involvement. Others said projects were started for the wrong reasons.

There was nothing related, however, to organizational fit or to measuring intangible benefits as part of your ROI. It made me wonder: Will the results of the Researching the Value of Project Management study change the way the profession thinks about project failure? Will things like the makeup of the organization--and how project management plays into that--become more important to a project's failure or success? And, how can organizations use the results to improve the way they achieve project results?

All good questions, right? And I hope to get the chance to ask the study's principal researchers, Janice Thomas, Ph.D., and Mark Mullaly, PMP, at PMI's North American Congress 2008 in Denver, Colorado, USA. It's coming up in October, and I hear they will be giving a special presentation on the research.