The following was posted on a mailing list, I replied with comments.
Maybe there is something to be learned from this.

UML is a potentially great tool, but it's often misused, abused, or woefully inadequately introduced into organisations (and often for the wrong reasons too).
Read and shiver.

>In 1997, the Object Management Group (OMG) made the UML a standard
>modelling language for object-oriented applications. Since then, it
>has been seen as the dominant set of techniques for software
> analysis and design. So one might think that UML is widely adopted
> by software development organisations. In a recent poll, the Methods
> & Tools newsletter asked the following question: at what stage is
> the adoption of UML modelling techniques (use case, class, object,
> sequence diagrams) at your location?
>
It's been decided to use UML, period.
No rationelle has been given except that "using UML improved quality", just a dictate from board level that UML has to be introduced.
No budget has been provided for training or tooling, but it has been decided that training and tooling are needed (but projects aren't getting money or time enough to provide them).
As such it is a very typical process.
I got myself some tools and training by effectively diverting resources earmarked for other things.
I rescheduled some training time and funds to a software design course (from an implementation course that was being cancelled, we could have gotten a refund instead but I didn't tell that to HR), and claimed to need the tools for my certification study (where they indeed come in handy). In a large organisation with set in stone purchase trajectories that would have been impossible to organise for someone at my level.
With previous employers or customers I got the exact same impression. A decision to adopt UML is forced from up high by people who have heard it as a buzzword with the usual promises that when only you use UML all your projects will yield perfect results.
UML is then adopted for the sake of using UML by people who have no clue as to how effectively employ it.
Training consists of giving people a small tutorial (Teach yourself UML in 24 hours style) without providing them with the background skills needed, they learn only how to make some nice diagrams but don't learn the process needed to arrive at those diagrams.

As a result the people start to resent UML, the tools used, software design processes in general, and the company management for micromanaging them like that.
Soon UML is reported back to management as a waste of time, because projects are running even more over budget because people are spending weeks making useless diagrams instead of putting out code.

The larger the organisation the worse this situation becomes.
The reasons for that are several:
- management in large organisations often consists of people who have no experience creating software, they're therefore more vulnerable to fall for buzzwords (like one multinational where we got a directive from the CEO personally one day that from now on ALL projects MUST use XML, no rationelle given).
- management in large organisations is typically further removed from the people they're managing, causing problems to simmer for longer before they get their attention.
- large organisations are more rigid, so it gets harder for the people down in the trenches to do their own thing, set de-facto standards, as there are set procedures for everything that are impossible to work around unless you have serious clout with upper management (which IT people generally do not have).
- people working for large organisations tend to be less flexible, more literal in adopting the latest buzzword dictates. Possibly they're also less sensitive to the possible failure of their projects for the simple reason that a loss of a few hundred thousand Euro won't have that much of an effect on a company whose IT budget alone runs into the tens of millions for their department alone.

>
> Despite being the dominant techniques in the literature and being
> offered by a majority of modelling tools editors, UML is still
> ignored by some organisations. Nevertheless the adoption rate is
> very high. Around 50% of the participants told us that their
> organisation has adopted, totally or partially, the UML techniques.
> Around 16% are investigating it or conducting pilot project and only
> 4% of participants said that the UML techniques have been rejected
> after analysis.
>
75% of participants has used, is using, or is interested in potentially using UML in some fashion.
That's a pretty high percentage overall.
What surprises me is the low number of respondents who have used and abandoned UML. In my experience that is far more frequent for the reasons I outlined above (note that those reasons have less to do with the UML itself but the reasons and ways it is usually introduced into an organisation).

> UML's evolution as an open standard. The current discussions are now
> more on the processes themselves with the emergence of the agile
> methods. In many agile approaches, the analysis and design phase
> should limit the usage of modelling techniques. Requirements are
> defined by a close relationship between users and developers working
> with a prototype-like mode created by short delivery iterations.

And it's high time that the process should gain more attention rather than just the buzzwords and the diagrams.
Read above as to the why.

I now have had 2 training courses in UML.
The first one was a typical course (going from what I've seen in training brochures and books from others), and effectively existed of showing each of the diagrams and how to draw them without ANY indication of the process used to arrive at those diagrams.
So for example we'd get a list of the elements on a use case diagram and get told how they fit together.
But there'd be no attention at all to WHY one would create a use case diagram, what it means, or how to determine the use cases in a particular scenario.
This would be repeated for each of the other diagrams.

The second was almost the exact opposite, it treated the actual process as centric and used the diagrams as an end-result of that process.
As a result the students got away with a knowledge of what the diagrams actually mean, and some insight in how to arrive at them from reading (or getting in some other way) project requirements.

While it didn't make me an expert designer in any way (that can't be expected from a one week course anyway) it did lay down the foundations upon which one can build and experiment with employing the technology in a meaningful way.
That foundation IMO cannot be learned from just reading through a book, it needs a personal touch of an experienced trainer who has actually used what he is teaching (something most trainers haven't, being purely academic). Having such a person on hand during the first (or first several) implementation trajectories using the UML would be even better, to prevent a team from falling into bad habbits or making common mistakes that aren't taught in a short course.
Sadly that too happens very rarely indeed, mentoring usually means that out of a 10 person team 2 get sent to such a short course (and usually the first kind described) and are then designated the in-house experts who have to coach and teach the rest (while, being programmers or designers themselves, most likely being terrible teachers as well as totally incapable of effectively using the technology they're supposed to teach in a large realworld project).