Creating a sense of urgency is a necessity if you are to implement successful change in your business. Why? Well, for starters, a sense of urgency from a C-level sponsor creates the initial boost needed to give birth to a new initiative. That boost can help ensure the project kicks off on the right foot (strong sponsorship and commitment, proper funding, and the right resources dedicated to the project). It can also provide a kick in the pants where needed.

But most of all, in my experience, a sense of urgency creates energy. It creates an atmosphere that motivates people. It brings excitement. It creates something to connect to and gather around. A sense of urgency also inspires us to do something, to do it better, to do it smarter, to do it now!

Great — so how do you create a sense of urgency? I like to use business cases or cost-benefit analyses. Business leaders like, no scratch that, they need to understand the analytical rationale for agreeing to pursue something new — a new product, a new market, a new system, a new process… A business case helps you to articulate what’s happening in your business, what needs to change, how it ought to be changed, the benefits of doing it, and the costs to get there (giving you some semblance of an ROI). Granted, high-level estimates often leave much to be desired but a business case can get people excited… create belief in the story and form the basis for a sense of urgency to do something about it.

John Kotter, author of Leading Change and a pre-eminent authority on organizational transformation, believes (and I happen to agree) creating a sense of urgency is critical to successful change. The video below is a 2008 interview with Kotter in which he gives his insights on urgency and how to create it… Take a look.

It was a Friday in July of 2006; it was about 1pm on a hot and humid day in greater Boston.  I was just finishing my 12th consecutive month of weekly travel (and feeling a little irritable).  I was the change leader for a very large CRM implementation.  Bill was the Program Director, Bob was the Business Lead and Tony was the Partner from our integration partner.  “You can’t play Jenga with a house of cards,” remarked Bob… (reminder below)

The back story… We were in month 16 of an 18-month odyssey to bring a new CRM system to 5000 professionals located in every corner of the world.  In many ways, the project was a success story.  We had strong sponsorship.  We had (mostly) adequate funding.  We had (moderately) a solid team.  We had excellent engagement and commitment from stakeholders, especially from our field organization (probably the best I’ve ever been involved with).  System development, on the other hand, had been bumpy; forever behind schedule.

On the Friday morning before we’re scheduled to kick-off end-user training in London and Munich… we’re notified that our training environment (shoddily built by the way) has crashed.  They’re confident they can get it back online in time for training on Monday.  What do you do?  (note: this was not the first environment issue this project had experienced).

The discussion we’re having is (A) what to do about next week and (B) what to do… period… about training.  Our training program was developed on a model of direct practice in the system.

“You can’t play Jenga with a house of cards.”

The system and its instability was the house of cards…

I was extremely “bearish” on this system.  Had been for some time.  There was always something problematic with it… And we’d gotten a big black eye during our train-the-trainer program when we reluctantly used the development environment to conduct hands-on training. I had the pleasure of being in a classroom full of senior folks in Paris when our system crapped out.  Sorry doesn’t really cut it.

As the leader of the change team, the front line to the users, my team and I were feeling the wrath of anxious users who’d been burned by IT projects before.

So what did we do?…We cancelled the next week’s training… another mis-step would have erased what little confidence our users had in the system.  As I said, they’d been burned before by past projects.  That would have been a disaster for the $30M program.

Early the next week, after 72-hours of work by our tech team, we made what would turn out to be the best under pressure decision we made on the project.  While our tech guys were saying “everything should now be fine,” we weren’t convinced.  We scrapped the entire 5-week training program and set out on a plan “B”.  In short — 2 words: do over.

We replaced an instructor-led, classroom-based model with a completely web-based program.  In the span of a few days, we developed a “good enough” product to bring to the masses.  And build a new support model to provide coaching and assistance — user-led training isn’t as rich in content so we expected more support would be needed by our users.

It was a tremendous collaborative effort between business people, subject matter experts, IT folks, our trainers, extended project team, power users and our core team.  And, to paraphrase my now “former” brother-in-law… “it all worked out.” (it didn’t for him… hence the “former“).

Reasons for success:  (1) we gathered as much information as we could in the short time we had, (2) we were rational about what “could” be done – we did not try to be heroic (like many project teams do when faced with a critical issue), (3) we were honest with our stakeholders about what happened and how we would fix it (and we apologized to them for the inconvenience our issues had caused them and their teams), (4) we worked day and night to make it right, and (5) we thanked and rewarded the team of people who made it happen.  I had a lot of thank yous to our process leads, their teams, our consultants, and my team…

As with anything related to change – you have to put people first.  If you do that, and always do it, a lot of good things fall into place.  And while you still have a lot of work to do, you’ve got people working together toward the goal.