|
|
 |
| |
 |
I
have been witness to many ITnization (IT enabled transformation)
projects that fail to deliver the expected results.
And I have been asking myself and others, WHY SO? when
so much is known about best practices in change management”.
What I could see is that, organizational transformation,
like personal change, is always difficult, even when
known best practices are followed.
This led to a belief that:
‘ITnization is a package of ideas about
how people should work differently’.
However, organizational change theorists tell us that
organizations behave the way they do because they have
found that behavior successful in the past. Thus any
new IT initiative that contains an idea about organizational
change is an implied threat. Less well understood is
that IT contains change ideas packaged in vehicles technologies
that have only some of the conditions necessary for
change.
|
|
| Let
us, consider the change ideas in some typical major
IT projects: |
|
Development
of a logistics system for a regional manufacturer.
This project is expected to improve customer service
and reduce cycle time while decreasing transportation
costs substantially. It changes component supply
and product delivery to and from every business
unit companywide. It conflicts with established
reward systems and the performance standards for
promotion.
|
|
Implementation
of an enterprise wide groupware or information-sharing
package (like Portal Services). Such a project
is intended to promote teamwork and information
sharing across departments and divisions. But
it may run afoul of a culture that promotes interpersonal
or inter-unit competition. Users may have difficulty
understanding the purpose of this technology relative
to existing communication systems and more structured
management reporting systems.
|
When
used as intended, well-built IT makes it easier
for users to perform some improved work practice
and makes it harder for users to continue ineffective
methods. But IT does not — and cannot —
ensure that users will use it as intended. Ultimately,
only users behaving mindfully can achieve appropriate
and effective use of IT. Users must understand
and accept the idea of and reasons for change.
They must also thoroughly understand not only
how to use IT but also how to use it to accomplish
the desired results. |
| The
role of the change agent is to bring together all
the necessary conditions for IT-enabled change. |
The
role of bringing together all the necessary conditions
for IT-enabled change is not easy because it involves
changing people’s minds. As in the expression
about leading horses to water, a change agent
can’t make people think, but he or she has
to try. |
| Nature
of Change in ITnization |
I
have developed a belief that “Change in
ITnization is a contact sport.”
The ‘ magic
bullet theory’ is seductive
to many IT specialists and line managers because
it allows them to disembody change ideas, package
them as technologies, and distance themselves
from the hands-on sport of helping people to change.
Change ideas packaged as new technologies are
much easier to deliver to the people likely to
challenge them than verbal demands are. So technology
provides ready-made opportunities for would-be
change agents to avoid speaking about the hard
facts of organizational performance and change.
By initiating a new technology project (intended
to reduce costs), some executives feel relieved
of the need to say: “I’m dissatisfied
with our costs, and I expect to see the following
improvements.”
The convenience of using packaged ideas to avoid
discussion comes at a high price. Real issues
are not confronted and are almost never resolved.
I know of several organizations that have attempted
the same IT- enabled change repeatedly —
and have repeatedly failed. |
|
 |
Belief in
the magic bullet theory can lead to situations
in which effective change management techniques
are not practiced, and the intended organizational
transformation never occurs. The problem stems
from the roles and behaviors that the theory
prescribes for executives, IT specialists, users,
and IT itself. Executives are supposed to define
the change idea or devise improved “systems.”
IT specialists are supposed to select or build
technologies that, when used as expected, will
produce the desired results. Users are supposed
to use technologies as expected (and not to
have competing solutions for organizational
problems). IT is supposed to work — like
magic. |
|
| 1.
Change Agents as IT Facilitators |
People,
not technology, create IT-enabled organizational
change. In order to make real lasting
improvements, people need more than good IT;
they also need to use it in line with clear
organizational goals. Agents of IT-enabled organizational
change bring together all the necessary conditions
for successful change: good technologies,
supportive organizational conditions, and knowledgeable,
mindful users. Whenever possible,
they also empower all kinds of people (technologists,
users, executives) about IT. They expand their
opportunities to learn more about IT and organizational
change and to participate effectively in IT
decision making. Most of all, they foster a
state of mind in which people accept responsibility
for their IT-oriented behavior, however great
or small their potential impact on organizational
results.s |
|
| 2.
Change Agents as IT Advocates |
IT can enable
organizational change, but change is created
by people who know the objective and how to
use their tools to achieve it. Agents of ITnization
can see clearly how the people in an organization
can achieve better performance by adopting different
work practices and using certain kinds of tools
in certain ways. They are tireless, inventive
promoters of the effective use of IT to achieve
organizational goals. They use whatever tactics
seem likely to work to change people’s
minds about the goals, the means, and the outcomes
of their everyday actions. They convince them
through constant repetition, persuade them,
and use all the rewards and sanctions within
their legitimate organizational authority. Agents’
tactics pay off; eventually, they get results.
However, they let others take the credit for
the success (a tactic that pays off in credibility
when it’s time for the next big idea). |
|
| Who
Can or Should Perform This Role? |
Change Advocates
are not necessarily people who would be tapped
for top management positions; they include “the
seemingly low-profile go-getters who always
get the job done.”. Thus both mid-level
line managers and functional specialists can
play the IT change advocate role. To get under
the skin of this critical role I offer a realistic
metaphor of the Trojan horse. |
|
Greek warriors faced powerful
resistance at the walls of Troy when they attempted
to recapture their queen. They respected their
enemy’s fighting skills, valor, weaponry,
and defenses. They knew that they would have
to fight hard, even if they succeeded in breaching
the walls. They needed an edge, not a magic
weapon. They improvised a clever idea grounded
in sound human psychology. They built supporting
technologies — a great hollow wooden horse
and a wheeled carriage to get it to the walls.
Then they executed their plan flawlessly. Brave
trained warriors hid inside the horse, while
others pulled the horse to the gates at night.
In the morning, the curious Trojans brought
the horse inside their walls. The warriors inside
the horse remained quiet and ready until night
fell again, and the Trojans went to sleep. Then
the warriors climbed out of the horse, slew
the guards at the walls, and opened the gates
of the city to the rest of the invading force,
who were standing by, ready to finish the job.
There was no magic bullet here. The Trojan horse
was a highly coordinated effort in which warriors,
temporarily playing different roles (creative
initiators, skilled builders, highly trained
fighters, and a strong support staff ) all worked
together to achieve a difficult task. They did
not have narrowly defined roles, they were all
just warriors. All had to remain alert to new
opportunities and challenges that would necessitate
changing their plans.
|
|
|
 |
| ERP
Project Management Services |
Undertaking
a large ERP project is one of the most significant tasks
a company can undertake. Metanoia Consulting
can help you ensure your ERP project success. |
Handling
the technical and functional aspects of an ERP implementation
is just one component of a successful ERP project. The
business and people aspects are the areas that are commonly
overlooked, which can result in project failure. That's
where Metanoia Consulting can help. |
| We
can help you make an ERP project successful by delivering
measurable business improvements in the following ways: |
|
Measure ERP readiness |
|
Facilitate the ERP vendor and software selection
process |
|
Develop ERP business requirements and business
case |
|
Provide project planning and program management
support |
|
Facilitate ERP business process changes and stakeholder
decision-making |
|
Implement comprehensive ERP benefits realization
programs |
|
Employ ERP organization change management to ensure
user acceptance |
|
Provide independent Quality Assurance over technology/implementation
partners |
|
Provide post-implementation business performance
measurement |
|
|
| |
|
| Copyright
2006 by Vivek Singh. All rights reserved. |
|
|
|
|