Welcome, and thank you for joining me.

I would like to share an experience from my consulting career that began as a technology challenge but revealed something much broader about how organizations operate.

As you follow what happened, I invite you to consider how you might have approached the situation, what you might have noticed, and what questions you might have asked along the way. 

The Initial Situation

Let me take you back to 1998.    A major South American financial institution was experiencing serious difficulties with a network migration project.  The bank had invested approximately $6 million in equipment to migrate from its existing IBM network transport environment to TCP/IP technology.  Three teams, comprising approximately 60 engineers, administrators, supervisors, and project management personnel, were involved.

 Several certified technical specialists had already been engaged.  Yet after approximately nine months, very little progress had been made.  The bank was preparing to cancel the equipment order.  The technology company supplying the equipment was searching for someone who could help recover the initiative.  Somewhere in that search, my name was recommended.

I do not know who made the recommendation, but it led to a conversation about taking on the engagement.  I was given three months.

 Before I continue, consider the situation.  The institution had committed substantial financial resources. Qualified technical people had been assigned. Teams had been organized. The initiative had been underway for nine months.  Yet the expected progress was not occurring.

If you were entering this engagement, what information would you normally request?  Take a moment to consider that question.

 Before accepting the engagement, I established one condition.  I needed direct access to the person with ultimate authority over the initiative.  I did not want to work through someone who would repeatedly have to say, "Let me find out."  I met with the bank director responsible for the project.  I asked the director:  "At the end of these three months, what would you want me to have accomplished for you to say, 'Great job'?"  The director explained his expectations.

I then asked him to communicate those expectations to his direct reports and make clear that I would be representing him in carrying them out.

What Was Not Yet Understood

 I now understood what the director expected, and the people involved understood the authority under which I would be working.  But I still needed to discover what was happening inside the project.  I met with executives from the bank and the technology company.  Then I began meeting with the three teams responsible for the implementation.  I asked the people involved whether they understood what the project was about.  Most understood their assigned responsibilities and the tasks they were supposed to perform.  But they did not understand the larger purpose of the initiative or how their individual work contributed to the overall result.

 I spent at least a full day explaining the purpose of the project, its scope, and the relationship between the different activities.  I wanted people to understand not only what they were doing, but why they were doing it.  When you examine an initiative, how do you discover what the people involved actually understand about its purpose?

 As I continued meeting with the teams, I began examining the capabilities of each individual.

I wanted to understand what people actually knew and what they were capable of doing.  I discovered that some individuals assigned supervisory or project management responsibilities had capabilities better suited to other activities.  Other individuals had capabilities that made them more suitable for supervisory or project management roles.  I began realigning responsibilities accordingly.  Some people moved into different roles. Others assumed greater responsibility.  Where particular knowledge was missing, we developed training to help people perform the work.  The equipment had not changed.  The technical objectives had not changed.  But the way people understood the project, and how their capabilities were being used, had begun to change. 

Looking Beyond the Technical Requirements

Before beginning the network implementation changes, I also wanted to establish a baseline. At the conclusion of the engagement, management would need to understand what had changed.  But before deciding what to measure, I had another question.  Why had the bank decided to make this investment in the first place?  I began asking managers and supervisors about the reasons behind the decision.  Through those conversations, I learned about feedback the institution had received from its branches and customers.

 There were concerns about slow response times, packet retransmissions, transaction delays, network availability, and the time required to distribute software updates to devices.  Other concerns included transaction failures and retries, network-related support incidents, and recovery time following communication failures.  Our discussions produced approximately 20 parameters.  These were not measurements I had selected simply because I considered them important.  They reflected conditions the bank wanted to improve.

There was another important consideration.  Before my arrival, backup and backoff procedures had not been adequately organized.  What would happen if an installation failed?  Could the previous configuration be restored?  Were the necessary procedures documented and tested?

Backup and backoff readiness became part of our evaluation.  These capabilities are easily overlooked when everything is functioning normally.  Their importance becomes visible when something goes wrong.  We documented the starting conditions before implementing the network changes.  That gave us a basis for comparing the original environment with the results of the engagement.  When your organization begins an initiative, how do you determine what should be measured?

Approximately two weeks into the engagement, the bank director asked me: "How did you get the people to start working?"  I explained what I had discovered and the changes we had made.

We had clarified the overall purpose.  We had examined people's capabilities.  We had adjusted responsibilities.  And we had introduced training where it was needed.  The director asked me to mentor some of his managers in my management approach.  Approximately four weeks into the engagement, after observing the progress, he instructed the people involved to follow my direction.  The project that had struggled for nine months was beginning to move.  What do you notice about the changes that had occurred?

From Understanding to Implementation

The bank had approximately 2,000 branches.  Completing the entire migration within three months was not realistic.  We needed to develop a process that other engineers could follow across the branch network.  We began with the first branch.  During that implementation, we tested every procedure, including equipment configuration, installation, verification, backup, and backoff.  We examined what worked and what needed improvement.  We revised the procedures and developed training documents based on what we learned.  We then provided those materials to other engineers who would perform implementations at five additional branches.  Those installations gave us an opportunity to observe how the procedures performed when different people applied them.  We made further refinements.

This continued through successive implementations.  By approximately the twentieth branch, we had developed a fairly solid process.  I use the words fairly solid deliberately.  The procedures had been tested and refined through actual implementations. The configuration, backup, and backoff processes had been documented and tested.  But that did not mean they were permanently finished.  New equipment would eventually be introduced. Software and operating systems would change. Network speeds, data formats, and operating requirements would evolve.  What worked under one set of conditions would need to be examined again as those conditions changed.  The purpose was not merely to create procedures that could be repeated.  It was to establish an approach in which those procedures could continue to be tested, examined, and refined.  How does your organization determine whether a process is ready for others to use?

By the end of the three-month engagement, approximately 100 branches had been equipped, configured, and tested.  The migration across all 2,000 branches was not complete.  But the institution now had a tested implementation process, training documentation, and engineers who could continue the deployment.  We also compared the results with the baseline established before implementation.  Every parameter we had tracked showed improvement.

The measurements reflected the operational concerns that had originally prompted the bank's investment.  Management could now examine the results in relation to what the institution had wanted to accomplish.

What the Experience Revealed

At the conclusion of the engagement, the bank director said:  "We thought we hired you for your technical expertise. What you gave us was a change in our business culture."  I have reflected on that observation many times.  The engagement began with a stalled technology migration.  The bank had invested millions of dollars, engaged qualified specialists, and assigned people to carry out the work.  Yet progress had been limited.  As I became involved, the work required more than examining the technology.  It required understanding what the director expected, what the teams understood, how responsibilities were assigned, why the bank had made the investment, and what evidence would demonstrate meaningful improvement.  It also required developing processes that could be tested, transferred to other engineers, and refined as conditions changed.  Technical expertise remained essential.  But it was not the only consideration.

Thank you for spending this time with me.  Every organization has its own history, people, responsibilities, and circumstances. What we discover in one organization may not be exactly what we discover in another.  But there is value in examining how we approach the situations we encounter.  If this experience has prompted you to look at something within your own organization from a different perspective, I would welcome the opportunity to hear what you discovered.  And if you would like to explore a situation your organization is currently navigating, I invite you to begin a conversation. 

Begin A Conversation

Sometimes, a conversation is where an entirely different understanding begins.