The implementation of any new tool or technique in the organization usually carries with it a
change impact. Stakeholders have to adapt and learn new skills, which often disrupt business as
usual for quite some time. If this transition process to the new tools and techniques is not properly
managed there is always the danger of the new implementation to fail.
Within Xpdian's customer base, we have had, on several occasions, the opportunity to implement a
UML tool in an environment where other UML tools and/or other modelling tools have been
implemented, and have failed. This put us into environments where modellers not only were
intimidated by new tools and techniques, but also cynical because of past failures. This has given
us some opportunities to experience and understand the following:
Lesson 1. Introduce learning
The success of the implementation is rooted in learning. Learning is not just training, but also the
experience that comes from using training. Don't be tempted to provide too much training too
early. Learning occurs in cycles. Define the training need in such a way that stakeholders can
attend training, assimilate the knowledge shared, understand how the new methods and
techniques can work in their environment, try all of the new knowledge out on the new tools and
techniques, and finally have enough time to ask questions and clarify misunderstandings. Once
stakeholders are comfortable due to the experience gained by experimentation with the new tools
and techniques then it is time for the next cycle of learning.
The UML notation intimidates most stakeholders facing it the first time. In most cases the new
notation is accompanied with new tools that have complexities of its own and both notation and
tool are used within a new approach or method. Trying to teach stakeholders too much, too quickly
will confuse them. Start with the concepts first. Once the concepts are well established, only then
introduce more complex topics. What to include in the concepts and advanced topics will be
different from one environment to another.
Lesson 2. Understand that stakeholders need time to learn
When faced with new tools and techniques, stakeholders tend to go through an emotional cycle
that determines how quickly they learn and adapt. At first they will experience concern, based on
their lack of knowledge and skills, or maybe because of cynicism based on other tool and
technology experience. This may lead to confrontation as stakeholders are dragged out of their
comfort zones with the adoption of the new tools and techniques. This confrontation may be
compounded by the shared feelings of doom between different stakeholders as they experience
and discuss the consequences on the business as usual.
At this time the implementation is closest to failure. Lots of assistance and mentorship from
knowledgeable consultants/mentors will help stakeholders gain insight into the new tools and
techniques, leading to knowledge breakthrough, clarification and insight. With this new insight, a
foundation for learning is established upon which stakeholders can then internalise the new
knowledge. Once knowledge is internalised, the next cycle of learning may begin.
The most important factor in letting stakeholders move to insight and internalisation is time. They
need to be able to work trough the initial emotional impact to understanding, and eventually
acceptance and positive experience. Not allowing enough time will deprive stakeholders from
emotional acceptance, which will in most cases lead to failure of implementation.
The UML with its different diagrams and relationships between bewildering arrays of element types
can be very difficult to be mastered by the UML novice. After formal training it is important to have
experienced consultants/mentors to help stakeholders master the learning curve. As stakeholders
experiment with the different diagrams and techniques they will, in time, be more comfortable with
concepts and become ready for more advanced techniques.
Lesson 3. Worry if no one disagrees
When new tools and techniques are introduced and no one disagrees or resist the changes, it may
be for a number of reasons, all of which should concern the implementation owner. Disinterest
occurs when stakeholders think that the change to new tools and techniques is not going to affect
them. This may be a result of the implementation message not containing all of the details
required to make the disinterested stakeholders understand that their environment will be affected
as well.
When disinterest is noticed, every effort must be made to determine if the disinterest is because of
a lack of learning, resistance to change or if one of the above reasons applies. It may be because
stakeholders are not seeing the change as significantly important. If a change is not seen to be
significant to the stakeholders they may not make the effort to disagree. This might be because
the significance of the change is underestimated, or the change is insignificant.
The biggest concern should be if the significance of the change is underestimated. This may mean
that the message to the stakeholders are either incorrect or that they are in need of more
learning. The message and the change should be reviewed in terms of the anticipated effects and
benefits. Should the message be inappropriate, it must be changed to ensure that it is properly
understood. If the implementation owner has overestimated the significance of the change, a call
has to be made on how the initiative should go forward. One way of dealing with it is to tie the
change to other change efforts in the same area. Another way is to decide to reinvestigate the
change in the light of the new evidence and based on the outcome, to reinstate the change
initiative or to cancel it. It is important to not become emotionally attached to the change purely
for change sake. If a change does not make sense or shows significant benefit – abandon it.
At times stakeholders will not show interest in the change because of their conviction that the
political forces will stop the change effort before it affects them. This is most often seen in
situations where change has been initiated before and did not succeed. For these stakeholders the
change effort is just “going through the motions” without real change that will occur. They do not
resist the change because it will reflect negatively on them and they are not willing to take that
chance. When the suspicion exists that this may be the case, the executive commitment to the
project needs to be reviewed in light of the historical projects. If a history exists of projects that
attempted similar change efforts and have failed, it is important to understand why they have
failed and whether the current project is doomed to fail in a similar fashion.
The other extreme opposite is that stakeholders will not disagree with anything on the change
project/effort for the simple fact is that their expectations of the anticipated results is so high that
they do not, and are not willing to see anything that can stop, or detract from, the project. It is
tempting from the point of view of the change owners to let this go on because it is one less group
that needs management. This is particularly dangerous especially if the anticipated and expected
benefits are not close to the expectation of what is going to be delivered and will always fall short.
This will create bitter resentment that will affect change projects that follow. Should this situation
happen the relevant stakeholders should be targeted for more communication and education to
rectify their perceptions and expectations.
The paradox with a UML implementation is often that the more experienced modellers are the ones
that struggle most with the new techniques. They tend to try and use known (non-UML) techniques
and force that into the UML with disastrous results. They typically are also the group that may not
pay as much attention to the education and learning, because of their background in modelling
creating a false sense of comfort. Knowledge of other techniques and/or tools may also prejudice
them against the tool that is being implemented.
Lesson 4. Understand the structures
Within the implementation organization there are two major networks structures that the
implementation owner must take cognizance of. There is the informal network that has no
relationship to the formal network or structure. This network exists because of personal
relationships, common interests, hobbies, religion and other interests. The informal network is
particularly powerful because people associate with them out of free will and as such can be
influenced more extensively from within these groups than through the formal networks. News,
rumours and other messages normally flow very rapidly through the informal network because of
the fact that the network is relationship based from an individual and personal perspective. For the
same reason people will also give more credence to messages that arrive through this network.
The formal network is built around the formal structure of the enterprise. Information and news
that flow thorough these channels are more business operational and project related information.
Topics of interest to the enterprise will also flow through this network. This does not mean that
other news does not flow, but that the focus is more on the work as usual. Formal networks may
have an informal network associated to it if the enterprise promotes mentorship programmes.
Once the dynamics of the formal and informal structures are understood, the next logical step
would be to identify the role players in these networks. There are a few categories of role players
in both networks.
-
The leaders are those who lead the parts of the networks. In the formal network they will be
the appointed managers and supervisors. In the informal networks they will normally be the
charismatic consensus-based appointed leaders. In both types of networks these leaders wield
power that can either benefit or disadvantage a change initiative. They are extremely
important and valuable role players if they support the changes introduced by the
implementation owner. The leaders in the informal networks are particularly effective if they
are open to, and enthusiastic about the changes. In the UML implementation these persons are
valuable if targeted as sponsors, or mentors. They have the unique ability to create an
atmosphere and environment conducive to change.
-
Influencers are people whose knowledge and regard by peers give them a voice that is
respected and whose opinion may sway decisions. Although they may be within the formal
structures, the respect that they command is mainly from the informal networks. Their power
lies in the fact that people respect what they say and as such may be valuable or damaging to
the change initiative. They are a group that need to be convinced of the change message.
Their conviction will benefit the change initiative. They function well as UML mentors and
members of the UML forums because of their ability to relate to, and work with other
stakeholders.
-
Followers are those that move with the group because of the perceived benefits they gain
from the association. The leaders and influencers would make up their minds (the followers
'minds) in most cases. It is important to take note of their progress in a UML project because
they will be the main cause of inertia. They will dictate the pace of learning and growth.
-
Lone wolves are those people that are part of a group either voluntarily or as part of a team.
They are normally there out of a strong self-interest or by appointment. They stand out from
the followers in that they are associated with a group because of the knowledge gained and
not necessarily for social reasons. They may, or may not, be influencers. It is likely that they
may alienate some or most people they work with. It is difficult to reach this group, since they
might not always hold with the collective viewpoint of the groups they associate with. At times
they might be destructive to the projects because of their nature. It is important to monitor
this group closely.
With UML implementations the social structures as well as the formal structures can be leveraged
to ensure project success.
Lesson 5. Avoid being sidetracked
Often when the UML project is launched, there will be stakeholders that are not completely
committed to the idea of the new project. They may provide reasons as varied as: they were not
consulted; they do not agree with the anticipated benefits/approach/methods; or it was not their
idea to start with. They may demand proof of concepts, prototypes or fundamental rethinks.
Submitting to initiatives such as these is very time- consuming and if not approached properly my
have the potential to seriously slow down and even stop the implementation project.
Lesson 6. Communicate
Nothing frustrates a new UML user as much as not understanding a problematic environment and
not being able to talk to someone about it. Many stakeholders may not be forthright enough to
come out and ask questions. In the beginning it is important to have a very structured
communication approach, in order to inform and elicit questions from learners. The mentors and
knowledgeable stakeholders must be encouraged to spend a lot of time baby-sitting initially. Over
time as the concepts become entrenched the need for support will change and require less and
less time.
Other mechanisms for support may include formal help desks, bulletin boards and tips-and-tricks
newsletters.
Lesson 8. Pro-actively manage resistance
In the course of implementing the UML and the modelling tool there will be resistance from the
stakeholders. Some may resist harder than others. There are two ways to deal with resistance.
There is a positive way in which the stakeholders are guided and become part of the
implementation initiative through own free will or because of benefits they received. There is also
a negative way and should only be used when all efforts at positive management has failed.
There are many positive ways in which stakeholders may be managed when they demonstrate
resistance. Core to managing the stakeholder in a positive way, is the patience that need to be
applied to the situation.
A first step in managing anticipated resistance is to ensure that all layers of leadership in the
enterprise agrees on the benefits of the implementation and publicly endorses it. The danger is
that should the public endorsement just be lip service, it could damage the project because
stakeholders will notice that while the leadership is agreeing, they do not act on it. People
impacted by a change must be given the opportunity to participate in formulating the
implementation of the process. People are less likely to resist a change to which they have
contributed to. Positive resistance also includes proactive communication and learning as detailed
above.
At times positive approaches to managing change simply do not work. After all of the positive
techniques have failed there are a limited number of negative approaches that may be tried.
Normally when you get to this level, you are dealing with people that will, in all likelihood, not fit in
comfortably with the new tools and techniques. The likelihood that these persons will leave or will
be asked to leave the enterprise is also high.
Negative approaches include coercion and manipulation. Coercion is where you put someone in the
situation where they have to change without regard for how they feel about it. It is basically the
"this is how things are going to be from now" approach. This will not create happy stakeholders
and the process of change will be difficult, both for the implementation team and the person
involved. This approach is likely to cause a great deal of unhappiness and resentment.
Manipulation is a technique as dangerous as coercion. With manipulation colleagues and the
environment is used to force someone to change. This also leads to resentment and loss, because
like in coercion the stakeholder is not in control of his own destiny.
In conclusion.
When all is said and done, the UML project, or any other project, is about people. People are
influenced by people around them and how they are treated. It is never easy to leave your
comfort zones which are the cause of the majority of resistance. Resistance should be anticipated
for and planned for whether your implementation of UML is targeted at three people or three
hundred.
