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.
