Tuesday, February 1, 2011

The Stealth Gorilla

Or- How to enact change control under resistance.

The office was deserted. Only a few lights burned like pools of florescent haze.Using the light cast off of my monitor to see by, I typed furiously at my keyboard. My masterpiece was nearly complete. I lovingly stroked the cover of a book lying just outside the illumination cast by the monitor. "Soon, soon my precious we shall have them following process. We shall have the one true way." Sliding the book into the light, I gazed at the cover. The MoPRoK, the Management of Projects Repository of Knowledge* would make all things right. Tomorrow we would start fresh, we would wipe the slate clean and start following the plan from A to Z. Finally we would have process and all would be good!

I was about to release a maniacal cackle of glee when my thoughts were shattered by a flash of steel and the dull thunk an object striking something. Looking down I saw a shimmering metal star vibrating in the cover of my beloved MoPRoK. Spinning about in my chair I caught site of Hogarth. At least I was fairly certain it was Hogarth, I couldn't be certain with the absurd black outfit he was wearing. But it was hard to mistake those mischievous eyes peaking out from the cloth over his face.

"Hogarth, what the hell are you doing?"

Striking the most absurd pose I've ever seen on a gorilla, and that is no mean feat, Hogarth hissed "I am Neeeeenjhaa!" He made a series of moves that I could only construe to be his interpretation of martial arts moves. I must stress "interpretation" when I say this. Gorillas were not designed to be Bruce Lee.

"What on earth are you talking about?" I asked.

Sliding towards me, Hogarth began speaking. His lips were moving in rapid succession as he did so in an obvious, but poor, attempt to mimic bad comics mimicking bad martial arts movies, "I am the process that slips through the dark. I am the template that appears unbidden. I am the change that happens when no one is looking. I am, Stealth Process!"

I rolled my eyes with a groan. "You can't be serious? I am not going to don a set of black pajamas and sneak through the office."

Hogarth pulled a bright yellow banana from a hidden pocket and perched on my desk. "Oh I definitely don't recommend the black outfit, people already see you as the harbinger of creative death."

"What? Now listen here, I'm just following industry standard process. There are hundreds of thousands of MPs using the MoPRoK. There is a process and it works."

Hogarth spoke around a mouthful of fruit, "Uh huh, and if you were setting things up from scratch, then that might just work. But you're not and it won't. This team is about as open to change as Fort Knox. You're trying to change a raging river with nothing more than a kayak paddle. It ain't gonna happen."


Sigh… And once again the ever practical Hogarth spoke true words of wisdom. The Stealth Gorilla was here to show me the errors of my ways. So now we take a practical look at how to bring about change in an organization that is resistant to change for any number of reasons.

Process can be good. Process can be great. Process can be wonderful. It can create predictability, accountability, reliability. It can assure proper communication. It can help define just what is "done". It can do everything but walk the dog (well maybe it can). But no process works in a vacuum.  And when your team is highly resistant to change it won't matter what process you roll out, it will meet resistance.

You can't just wholly drop a new process into any organization. And when you have a change resistant organization, then the challenges increase ten fold.

Enter the Stealth Gorilla.

It's a fairly simple process, which ties into one of my Gorilla Project Management  maxims. "First step is to get it done, then figure out who owns it."

Several companies back I had the pleasure of interfacing with the Sales organization. I processed special exceptions to what was supported in our products. We'd originally had no process around this at all. This was good (sales always got the exceptions they asked for) and bad on many levels. Sales was never really sure if they had buy in on the exception. Support felt they got dumped with all the weird stuff and Engineering found itself fixing bugs on things they never intended to support. So we needed a process, but getting the Sales team to adopt any kind of process was akin to getting the UN to agree on the definition of Hurly Burly.

The first was to start documenting everything. The only process we had was Sales sending an email requesting (and expecting) approval of the exception. So I started there, documenting everything they asked for. Picking up the phone and calling the sales guys to ask questions and make sure all the information was captured. I went back through the backlog of old requests and updated those as well. All this was posted in a common location, so everyone knew what was out there. Now the company had a common understanding of what had been promised to customers. I kept doing this for several months, slowly refining a submission template.

Then I started sending the template back to sales with questions, "Do I have this right?" I particularly worked with the major thought leaders in sales, showing them the value of complete data by ensuring request that had all the data were fast tracked through approval. Eventually I started getting pre-filled out templates. After another few months, we flipped things around and Sales had to fill out the formal request form to even have an exception looked at. From there we slowly ramped up process on the approval side. I'd work with the sales rep to understand the business impact, we'd compare that to the cost of supporting the change and so on. Eventually, we would make it to a point of making fully qualified cost benefit analysis on the exceptions.

"But that's so much work, I don't want to work that hard."

No one ever said project management was easy. If we wanted an easy job, we would never have taken on a role that often has mountains of responsibility and a kids shovel of authority. Yes, it is hard work I will not deny that. But it is effective work and effective is what matters. In my example, we created predictability, common understanding, a formal approval process (we even started turning down many sales requests) and in the end we took the process from roughly eight to ten weeks, to, on average, twenty days. With a little investment in time and effort, we created a process that worked for everyone and made the company more effective.

If we'd just slammed down a process and mandated Sales go through it from day one, I have little doubt they would have just stopped asking and figured out a way around the system. Instead we made them a part of the process and they ended up owning the process just as much as everyone else involved.

When you run into resistance, take a page from mother nature and practice a little erosion. Work slowly and make it easy to start. Then, like a good video game, add more and more complexity until you have a complete process everyone is bought into.

Joel BC
Veteran, the Project Manager wars
Want me to talk to your gorilla? Send me an email
You can follow me on twitter, @JBC_PMP


*The MoPRoK is an entirely made up name intended to represent any number of "bibles" for how to do project management. There is nothing wrong with bodies of knowledge and I support them fully. It is all in how you implement them.