Towards the middle of 2002, Xpdian was involved in
the rollout of Enterprise Architect in a large enterprise
environment. Enterprise Architect (EA) is a UML CASE tool that
allows enterprises to model their business and system processes
using the popular UML notation.
From the onset, the project was plagued by
problems, primary of which was related to the modelling knowledge
of participants in workshops and training sessions. Our primary
task was to introduce and demonstrate EA. Since the customer
previously had used another UML tool, the brief described the
employees as being experienced in UML
modelling.
In the first few sessions it became apparent that
their UML knowledge was not as extensive as described in the brief.
It also became apparent that the UML was seen to be synonymous with
the tool we were replacing, since people were referring to ****
diagrams (**** being the name of the previous modelling tool). With
a negative attitude prevailing and a shortage of experience among
the customer's employees, we decided to suspend all sessions and
regroup in order to plan a different approach.
With our plan revised, the new approach was
launched a week later based on the following
approach:
The employee staff members were subdivided into
several groups that included the following:
-
People
with a working knowledge of the UML
-
People
that have been introduced to the UML but have not used it for
modelling
-
People
that have never seen the UML
These groups were placed on different education
tracks to ensure everyone had the same conceptual knowledge of the
UML and how it can be modelled using EA.
They were then allowed to play around with the
tool and model some of the business and system problems that
existed. After two weeks we scheduled follow-up sessions with the
purpose of testing the implementation progress.
To our surprise we found that relatively few
people had experimented with modelling. To ensure experimentation,
we obtained the permission of management to allocate assignments to
be completed before the next feedback session. Once EA was used and
some UML models were being modelled, the level of understanding
increased rapidly.
The next challenge was to channel the way of
modelling into achieving a standard way of modelling. With this in
mind, we identified the more knowledgeable UML modellers and
initiated a UML forum.
The purpose of this forum was to establish a
standard to guide the way in which future modelling would take
place among all UML users. After several sessions with the key
persons, a UML standard emerged that was in line with the
principles of good business and software engineering. The
purpose of the standard was to guide modelling, rather than
prescribe a way of modelling.
This led to the next major education cycle within
which all UML modellers were trained to model using the newly
established standard. Over the next few weeks several review
sessions were held to ensure the successful adoption of the
standard.
Once all business and system analysts were fluent
in using the modelling standard, the training of other stakeholders
started. Users and customers were involved in several workshops and
education sessions that introduced them to the UML notation and
method.
This culminated in a full scale acceptance and
rollout of the UML and the EA tool to the affected departments
within several more weeks.
Lessons learned
Although the project was considered a resounding
success, there were a few bumps along the road that led to
learning. Lessons we learnt from that were:
-
Never
assume prior knowledge. Even though the customer assured us that
UML knowledge was present, it was not to the level of expectation.
Experienced employees' knowledge were rusty, key persons had left
the company and a whole generation of people moved into the
organization without knowing the UML. When experience is claimed by
the customer, it is to the consultants' advantage to test the
knowledge of key customer modellers to verify the level of
knowledge rather than make assumptions.
-
Watch
out that customers do not associate the UML tool with the UML too
closely. Because of a bad experience with the previous tool there
was initially some resentment against the UML which spilled over to
the use of EA. This was managed away quickly when the user
friendliness and intuitive nature of EA was
demonstrated.
-
Give
assignments. When left to their own devices, people have generally
got more important business to conduct than experimenting with a
tool they might or might not use in the future. Giving assignments
created expectations and were effective to get people
modelling.
-
Allow
time for learning. Initially people will not be sure how to use the
tool in their environment. Over time as understanding solidifies,
they will become more adventurous in how to apply the notation in
their environment.
-
Once
learning reaches a certain level, establish a forum of like-minded
modellers to establish a standard. The UML as a language is
extremely flexible and as such open to interpretation. A standard
guides modellers in their use and interpretation of the UML. It
also serves as a base from which new employees can be
trained.
-
Once the
modellers are fluent, it is time to introduce the UML to the rest
of the stakeholders. To introduce the UML concepts to the
stakeholders too early creates expectations whose realization is
delayed. When the modellers can model and converse about the UML
comfortably, then the time is right to introduce it to the other
stakeholders. Tip - the stakeholders do not need to understand the
UML in detail. The must understand it well enough to discuss the
results of the UML, not model the diagrams.
For more information, or to find out how we can
assist you in your UML implementation and other requirements,
please contact us at info@xpdian.com.
