Best and Worst Practices in BPM and SOA

In his article, author Peter Woodhull presents the following 3 worst practices and 3 best practices to implementing BPM (Business Process Management) and SOA (Service-Oriented Architecture):

Worst

1. Buying software first without understanding the business needs and requirements.
2. Discounting the organizational change effort required to make the solution work.
3. Trying to "boil" the ocean, trying to do all at once.

Best

1. Start by defining and validating the problem and the business process in question.
2. Use BPM and SOA as part of the solution instead of THE solution to complex business problems.
3. Start with a mission critical process to ensure the necessary executive sponsorship and priority.

One could argue that Woodhull's observations apply to any business improvement initiative whether process improvement, new product/service introduction, adoption of new management philosophy or business model, or organizational restructuring, not just new technology implementation. I believe that our collective experience confirms Woodhull's observations.

To add to his points, a common thread running through his article is change leadership and change implementation. My question is...why is it that good practices (forget best, good would be great!) in leading and implementing change continue to be the exception rather than the rule? Based on my own observations, I'd like to offer four potential root causes. I realize there is more to it than this and that these are not always culprits. I'm just pointing at them as 'common' root causes.

1. Denial to see the problem as it really is. It's much easier to "buy" a solution than to confront the fact that a process might be broken or that there are complex dynamics at play that are difficult to address (particularly when they involve relationships, turf, etc.). When this is the case, buying a solution such as new technology, restructuring the organization with the help of expensive consultants, 'leaning' the operation, etc. might provide temporary relief but not lasting improvement.
2. The tangibles (schedules, budgets, contracts, forecasts, cost savings, etc.) rule, though it is often the intangibles (buy-in, clarity of purpose, engagement, etc.) that create the most value over the long run (see Ulrich's "Why the Bottom Line Isn't").
3. The urgency to show results fast often forces inadequate planning. Dictates from 'top management' or the perception of urgency pushes implementation teams to start work without a comprehensive view and understanding of the change they are embarking on, its implications, and the effort required to make it happen.
4. Activity trumps process thus giving a false sense of security. Scheduling meetings, attending meetings, documenting meetings, etc. somehow makes it look like 'things are happening, moving along.' Quite often it isn't until it is too late that we realize that the wrong people are attending these meetings, the meetings are not leading to the right course of action, and consequently, that nothing much else is happening! I'm using meetings only as an example of an activity tha tmay lack substance because process has been ignored. But I use this example because it is in meetings where typically a lot of the work gets done, decisions get made, processes get documented and changed, problems get defined and solutions crafted, etc. but if the process isn't working, the activity won't yield the results. It's not a choice of one over the other, it's both.

Of course, this is not an exhaustive list, there are other root causes but clearly knowing how to effectively lead AND implement change is an important, even critical aspect of business but often overlooked. Change leadership and change management are considered 'soft skills' but they have 'hard' implications. Schedule and budget overruns, delayed ROI realization, or worse, implementing the wrong solution are all too common place representing millions of hard dollars wasted. A soft skill? Maybe, but one worth investing in...and the earlier the better.