As one would expect, there was a lot of angst from the PM community on this article. Here is my response to the tunnel vision that seems to plague majority of those posts:
"I find myself in the minority of agreeing with a lot of what Meridith wrote. Perhaps the article took for granted a point those of us in IT Management are painfully aware of, leading to most of the conversation so far to focus on the weeds.
According to Standish Group's CHAOS Report, 71% (+/-3%) of all IT projects are considered failed or challenged - and that metric has been stable for the past 8 years. Yet, stuff gets done. Things go into production, imperfect as they may be, and business moves right along. So there is a huge disconnect between project success metrics and reality. And that disconnect is likely caused by perception created by insufficient project success metrics.
For all the folks that keep harping on the "cop out" point, perhaps you'd like to offer up a suggestion to deal with the ever-changing requirements problem that doesn't involve telling the business stakeholders exactly where to take their ever-changing requirements, a.k.a. "project change management" or "art of saying no". Regardless of how you communicate "no", it will still be received as "I care about your P&L less than I care about integrity of my process", even if your stakeholders agree with the logic of that "no". One of the more common complaints from the business side is that "IT always says no". Business is business - needs change due to market and regulatory pressures, so requirements have to adjust on the fly as well. If we are to believe that velocity of information is increasing, then the pace of change is not likely to slow down today or tomorrow. Politically and culturally, I think we should avoid a scenario where project managers have to say "no" more often than they do today.
Trouble is, current metrics derived from project definitions simply don't take that kind of disruptive change into account. That's likely because neither construction nor aerospace, where project management has been grown, had to deal with this challenge. Historically, if a project was challenged in those spaces, there was usually a set of tangible deliverables worked on by people with standard set of education using standard set of methods. Stopping/realigning/restarting a project could be successful. If an IT project is challenged, none of those are usually present - assessing code completion and/or correctness is always a challenge (if you can find it), getting the necessary resources is a common complaint even with skill sets that sound like commodity (like developer), and there are few professional certifications that accurately predict someone's real expertise. Add the ever-changing requirements challenge, and it is quite surprising that even 29% (+/-3%) of IT projects can be measured as successful. And the same set of issues are now plaguing the aerospace industry - whether it's the Presidential Helicopters or F-22 programs, just to name two that have been in the news.
So the question is not whether change is used as a "cop out" or "cover for incompetence", as suggested several times above. That kind of thinking taken too far leads to rigidity of thought that can not consistently succeed in a change-driven world. The real question should be, how should the "project" itself evolve to withstand the impact of real world, and what metrics are then relevant to measure success/failure once that evolution occurs."