Here’s an article sure to start some firey conversations. It’s tongue-in-cheek style goes nicely with it’s difficult message, please read the whole thing. My favorite parts, compared and contrasted with classic systems development thinking (as well as observations from a current major project):

Step 4: Ah the subtlety … classic change management says get the buy in; classic RAD technique encourages participation with the ultimate end user to guarantee buy in. Unfortunately, the requirement for buy-in can drag on and introduce many implementation delays. You must have a reasonably well-thought out “change” to roll out, but you cannot wait for 100% buy in – sooner or later, it’s get on board or get off the train.

Step 6: I have to disagree here – in my experience, change efforts struggle when there is no clarity around roles and responsibilities.

Step 12: Ah, the pain of reason (c), the classic fallacy of “our organization is unique because …”. So much painfully twisted custom development, unreadable process manuals, non-scalable integrations, etc. is due to this common delusion.

I could blog/whine/yap for days about resistance to change in many projects, even current ones, but wouldn’t get far. Better to add the experiences, the successes and failures and learnings, to ye olde experience reservoir, and move on to the next thing.