Sunday, 15 April 2012 00:00

Changing the World One Project at a Time

Rate this item
(0 votes)

Image of impossible road sign

Change is difficult. Regardless of who you are, it is tough. Recently, I challenged readers of this blog to improve how they tie their shoes. I can confidently wager that a large majority have stayed with their old habits. It takes significant force to reprogram out brains, affect the cultural inertia, and gain acceptance to change, tolerance of occasional mistakes, and, eventually, achieve an organization steeped in transformational principles. Nowhere is it more apparent than when delivering projects that alter the way people perform daily tasks. The reason is that, all too often, the goal is to deliver the project; it is someone else's job to gain adoption.

We Work in Systems

Recently, I read a white paper by Deanne Earle entitled Principles for Intelligent Transition, which nicely underscores this point. She summarizes the issue in a sentence, "[our teams] deliver a good project but can forget what has to happen in business operations once the project is over." This is a result of the errant view that the envelope of the project's methodology insulates the team from the rest of the organization. Nothing could be further from the truth. Projects are a disruptive force in a larger system. Even with the best preparations, too often they are dropped on users in an immediate and abrupt fashion. The recipients react to the change in a multitude of ways—some adopt, some adapt, and others simply reject.

A few years ago, I was privy to a project to integrate a number of subsidiaries into an acquiring company. The client missed the need to start the merger by creating a common company culture and now they needed to replace redundant operational systems with the ones used at the head office. There were the usual issues with any software implementation—undocumented corporate processes, minimal inter-departmental test procedures, over-promising vendors, and so forth. The installation was only slightly behind schedule and, otherwise, ran pretty much as planned. Acceptance testing ran well and everyone seemed pleased as the project was completed. Five weeks later, inventory shortages plagued the assembly line. Assembled-unit's shipping dates started to slip. The problem? People were still using the spreadsheets to keep track of parts and sub-assemblies and they refused to enter parts consumption into the new ERP system; hence, inventories dwindled. Some tried to excuse their behavior by claiming how familiar they were with their spreadsheets, while others simply detested cowing to corporate. The culture in the US failed to account for the reaction in their foreign office. In Deanne's article, this is the third of her six principles of transformation.

The Six Principles of Transformation

Averting issues with post-implementation acceptance requires a change in culture. The concepts of doing this are simple; the execution is more of a challenge. Deanne outlines six basic principles in her approach. The Six Intelligent Transition Principles are:

  • Transitioning a project is straightforward.
  • Identifying Opportunities for Transformation.
  • Determining Transition Success.
  • Gathering External Intelligence.
  • Understanding Human Behaviors.
  • Creating an Intelligent Transition Plan.

Change With Direction

The most critical of these principles are identifying the opportunities and defining transition success. This is where an organization's leadership and innovative nature play the largest role. It is impossible to change if issues cannot be identified; and, nothing completes unless there is a defined goal. These are the mission and the vision; the start and the end; the goalposts for the organization's transformation. They must be clearly defined and widely disseminated. History is laced with stories of inadequately defined and misguided implementations that ignored these principles.

The Rest of the Story

American radio broadcaster Paul Harvey coined the phrase "And now for the rest of the story" for his trademark radio show that would highlight little known facts about historical events. Project deliveries that call themselves complete upon implementation without looking at the adoption, truncate the project's true story. It only takes a quick retrospective to find a multitude of shortsighted implementations failing to define the transformational requirements adequately for successful acceptance. The rest of the story is the effort required to, as Deanne says, "Alter, Transform, and Integrate." Pay the price during the project or suffer the greater expense as it ends up in the anecdotal history of after-the-fact troubles. I suggest you read her white paper.

Read 6906 times

Related items

  • Process Mapping

    Process is at the core of any business. It makes work predictable, repeatable, and transferable. Without it we cannot scale our businesses. However, process can be a bane to making progress. Processes that work for a $10 million company have difficulties supporting a $30 million company. Trying to scale them to a $300 million company will not only fail but not address the issues that larger companies have that were never dreamt of in a smaller organization. Processes need to be discarded, revamped, and built—all of that without creating an overburdening bureaucracy.

    Anytime you need to go someplace, you first have to know where you are. Processes are never static and your company's current state is probably far from where you think it is. Hence, the first step is mapping out you company's current state followed by defining the future state. This is more than a logical map of the process; it must also include physical maps. Whether your process is solely to provide a service (say, website development) or physical (say, manufacturing) there are logistical issues that complicate the process flow. Without fully understanding those nuances, future state processes will not reach the desired efficiencies.

    For more information about process mapping fill out the form to the left and we will get in touch with you.

  • Success vs Culture

    The other day a Latvian student contacted me for my views the connection between culture and success criteria—an important and intriguing topic. After working in Taiwan, Singapore, Korea, Japan, Israel, United States, and Canada, I wear many scars of both blatant and subtle cultural violations. I also know that within a culture one person's success is often another person's failure. So, after dispelling concerns about clicking on some random email link, I completed her survey (please feel free to take it yourself). In the process, I struck up a friendship with the student, Kristine Briežkalne, who is studying at Riga International School of Economics and Business Administration . She has some interesting views and presented me with a Venn diagram showing four frames to a project (business, client, project management, and growth perspectives) and how they intersected. As the diagram is part of her Master's thesis, I will let you ponder the how to label the overlapping areas (an eye-opening exercise).

  • Kill The White Knight

    There is a reason we do not teach classes on fixing failing projects. Many a cynic feels that we simply do not want to teach our trade, however, our reason is far nobler—we should be teaching prevention rather trying to create white knights to save the day. It is the same philosophy as building a fence at the cliff's edge rather than an emergency room at its base. Our language is replete with idioms telling us to look past the symptom and address problems at their root cause. 'An ounce of prevention versus a pound of cure' or 'a stitch in time saves nine.' Please, feel free to supply your own in the comments. Unfortunately, most of our businesses loathe this philosophy, waiting to address an issue until it is irrefutably broken.

  • Comparing Organizational Change Management Models

    A few weeks ago, I set out to write a post on the comparison of various organizational change management (OCM) methodologies and realized that would be a disservice to my readers. It would simply drag you down the path of implementation while failing to focus you on building the foundation. The pressure was too much and I have relented to numerous requests on making that comparison. The caveat is that juxtaposing these models is not comparing different varieties of oranges or even apples and oranges; we are surely comparing the peel to the fruit they contain. Hence, comparing methodologies like Kotter's model (the peel), Prosci's ADKAR (the core), and General Electric's Change Acceleration Process (the whole fruit) need a different approach.

  • The Executive-Project Manager Gap

    It was such an innocuous question, "Working on an article; what is the biggest problem you see with project governance at orgs? Can you comment?" Can I comment? Really? That is like cheese to a mouse. Where could I start—bureaucracy, draconian process, poor executive sponsorship, disengaged leaders? Plenty of fodder, because they all lead to project failure. I fired off, "Creating an over bureaucratic morass stifling innovation & implementing process instead of cultivating leaders." Then the maelstrom started and it went directly to the gap between the executives and projects managers. Naomi Caietti, Robert Kelly and I had a great conversation. Most of the thread is below.

Leave a comment

More Info on Project Recovery

Tell me More!

Please send me more information
on fixing a failing project.

Rescue The Problem Project

Internationally acclaimed

Image of RPP

For a signed and personalized copy in the US visit the our eCommerce website.

Amazon logo
Buy it in the United States Buy it in Canada Buy it in the United Kingdom
Buy it in Ireland Buy it in Germany Buy it in France
Buy it in Italy Buy it in the PRC
Buy it in Japan
Book sellers worldwide.

Upcoming Events

Other's References

Sitemap