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 please contact us.