Category Archives: Teams

Reviews: There is no "Gorilla" in "Team"

Posted on by
3

“That’s it! Kill me now!” Throwing myself into one of my office’s guest chairs I directed an exasperated look at Hogarth.

 

Sitting in the corner, fichus on one side, bamboo on the other, he looked at me with placid eyes. Not say a word to me, my gorilla chewed slowly on a head of lettuce.

 

Trying to not think about where he got a head of lettuce I gave a deep sigh and waited.

 

Hogarth kept chewing.

 

I threw my hands in the air, “I mean it! Just put an arrow right through my heart. It’s just not worth the trouble of trying to go on.”

 

Hogarth set the lettuce down. Good, now maybe he’d say something outlandish so I could get angry and him and distract myself from my misery. Looking at me for several long seconds, he then picked up the remains of a fichus branch. Beginning to pick his teeth with the denuded branch he continued to stare at me mutely.

 

“Oh, fine! I see how it is,” I snapped. “When I don’t want your pithy words of wisdom I can’t get you to shut up. But when I actually want your help you just sit there and remain mute?”

 

Hogarth shrugged. “Well I’m a poor archer and I’d really rather not get blood on my fur, so I’m not going to kill you. Lacking any other information, I have a leaf stuck between my molars.”

 

“Argh!” He was so infuriating. Couldn’t he be a normal and reasonable human being? Right… 800 pound imaginary gorilla. What was I thinking? Sigh, I hate it when he’s right.

 

“We’re headed up on year end.” Hogarth nodded in agreement. “That means annual reviews.” He nodded again. “And it means my agile teams have just become a pack a ravening piranha out to be last fish standing.”

 

Hogarth cocked his head to the side, “Fish don’t stand and isn’t the whole point of an agile team that they all pull together?”

 

I jumped up and pointed a finger at him, “Precisely!” Realizing pointing at a gorilla was probably not smart, I lowered my arm and continued. “That’s the whole problem. The review process measures individual goals. Suddenly all my agile team members are scrambling to show how good they are and fighting for credit of who improved the database, or made the UI fixes, or identified the root cause of the uRay issue.” I waved towards my office door, “productivity has plummeted, morale is holed and I’ve even had to break up a couple of yelling matches.”

 

Hogarth shrugged, “Sounds like the review process is broken.”

 

“Give that gorillas a cigar!” I exclaimed. “Only it’s not really broken, it’s just the way it is. Yet another process that doesn’t match with agile. I’m doomed. Agile will never work outside of small startups.”

 

Hogarth shook his head, “No, it’s broken. You don’t measure your spaghetti one noodle at a time.” I stared at him in abject confusion. Seeing this, he said,  “when the four man bobsled crosses the finish line fastest, who wins?”

 

“The sled team of course. What’s that got to do with this? They are all in the same sled.”

 

Hogarth nodded, “Good point.” Hah, I had him now. “What about the four hundred meter freestyle swimming relay? Michael Phelps carries the whole team, everyone knows that they couldn’t win without him. Why give the medal to anyone else?”

 

“Hogarth that’s silly. He couldn’t win without them.  It’s not like he could have swum all 400 meters himself.”

 

Hogarth nodded again. “Yes, that’s right. There is no ‘I’ in team.”

 

“I know that!” I snapped. “We’re doing agile after all. It’s all about the team. Team empowerment, team accountability, team rooms, we even have team plush toys for Ghu’s sake!”

 

“Then why are you measuring individuals and not the team?” Hogarth asked.

 

Huh… Why indeed?

 

 

Agile Reviews for Agile Teams

 

The average corporate review process is an almost myopic focus on the individual. What have you done? What goals did you achieve? What milestones did you meet? You, you, you. Almost like a bad country western song. Everything is focused on the individual worker and what they did. You don’t get credit for being part of a successful launch team. No, you only get credit if you led the team, or did some great thing ,that no one else did, to save the launch.

 

And that’s the good companies. There are companies out there (I hear Microsoft is a big sinner here) that use stack ranking. If you have a five person team, you can only give one person a five star rating and by the same extension, you have to give someone a one star rating. How do you think your team is going to behave when their literally is no points for second best?

 

Traditional review styles are murder on normal teams. Just imagine how much worse they are on an agile team? Agile teams promote the team owning the deliverables. The team does the work. The team commits. The team delivers. Until review time, and then hold on tight because it’s every developer for themselves.

 

It doesn’t work. You’re killing your teams one review at a time.

 

We don’t have a choice, it’s the way HR does reviews.

 

First of all, go read last weeks blog. If one junior captain can change the US Navy, then a manager can certainly change how his team is measured.

 

As for how to do it, well that I can’t take credit. I learned of this from an agile training house here in Silicon Valley. Agile Learning Labs has factored into my own agile journey many times. The founder, Chris Sims, is one of the people who took it as a challenge when I said “You’ll pry waterfall from my cold, dead hands” (Oh yes, I did say this, once upon a time). I took my CSM course from ALL and learned about the real value of agile for the first time, while getting the straight talk on how effective a CSM is (not much, you should still get one, from a good teacher, it’s a great way to learn).

 

Agile Learning Labs was asked to help a company that was facing just the issues we’ve discussed. The company had gone completely agile and was very happy with the change. Unfortunately, when it came time for reviews, they experienced significant disruption across the company for the entire review cycle. I’m guessing for a time after the cycle ended as well, as people digested their reviews.

 

So ALL worked with the company and implemented a new review process. No fancy math, no weird hoops or process and absolutely no touchy feeling trust falls.

 

Each employee had their review divided into two equal parts.

 

The first 50% rated them on how they met their individual goals. These were goals created with their manager (Oh, hey how about the Manager Tools Coaching Model) and focused 100% on things that were only about that employee and their development as an employee. Things like “Will become proficient in Ruby,” “Will present to an audience of at least 50 people,” “Will be on time to work 95% of the time” (Sometimes your goals are not big and earth shattering). Most importantly is none of this 50% had anything to do with their work on the team.

 

The second 50% was how well their team did. The team was measured on how it succeeded in its  business objectives (shipped the product, fixed the defects, shortened the release cycle by 25%, etc.). And then every single person on the team was given the exact same rating. The exact same! If the team did poorly, then everyone might get 20%. If the team was a rockstar band, then 50% all around.

 

That’s not fair! One of our team is a total slacker!

 

Then even money says you don’t really have an agile team. Still, let’s give the benefit of the doubt here, shall we? If one of the team is not performing, then it’s the team’s responsibility to deal with the issue.

 

Let’s head back to the Olympics, shall we? The swim team analogy probably isn’t the greatest. The relay is based on who is fastest on the Olympic team. These guys are rivals most of the time and don’t train together except at the Olympics.

 

Let’s look at the sculling team (that’s rowing, people). A four man sculling team trains together year round. They are a true team in every sense. If one of the team is not performing, do the Olympic judges say “Hey, you’re a horrible team mate, out of the boat”?

 

No, they don’t. That team mate never makes it to the Olympics. The team takes care of it. Sure, they may have help from their coach (Coach, hmm. Could that be a manager?). The team takes care of the problem and they make it to the Olympics.

 

If it works for an Olympics sports team, it can work for a software development team (or hardware, or marketing, or…).

 

Let’s go back to Agile Learning Labs and the company they were helping. A year later, the company went through the first full review cycle. They’d been using the new model all year and everyone knew this was the model and got reminded through out the year. What happened? It worked. It worked great. The details that ALL has shared is that morale went up, productivity went up and teams didn’t miss any strides during review time.

 

Want to know more? I hear Agile Learning Labs is available for hire.

 

 

So take the “I” out of the team and start measuring the team, as a team.

Gorillas can be Agile with any project

Posted on by
1

Some days I was so thankful for the fact I worked in a three story building. It made the urge to toss myself off it, to end the misery, so much less. Unless If I  was really lucky I’d just end up hurting myself and that would just add to the miserable condition I was in.
Hogarth was right… Oh how I hated to think those three words. It was becoming such a common occurrence that I was considering adding to the law’s of nature. The sun comes up in the east, politicians are lying when their lips are moving and Hogarth is always right. This time it had to do with my implementation of Agile. Agile may be the silver bullet of development but I hadn’t had the first idea how to properly implement it.
So I’d swallowed the pill and went out and figured out just what Agile was. Leaning back in my chair I took in the remains of that discovery. Highsmith was leaning on Adkins and the two were threatening to push Cockburn off the desk. Larsen and Cohn were glaring at me from under the coffee cup perched on them. The books stared back at me mutely, mocking my pain and despair. Tilting my head back to stare at the ceiling I moaned. “Kill me now…”
“What and miss all the fun?”
I kept my eyes closed and used every ounce of my will to imagine away the voice that had spoken.
“Not gonna work,” Hogarth replied. “Your subconscious really likes me, so you’re stuck with me.”
Pulling my gaze from the acoustical tile I fixed Hogarth with a baleful gaze. “Remind me to schedule myself for a lobotomy.”
Hogarth was perched on the large window ledge. His black fur shimmering in the afternoon sunlight and his face was split with a contended grin. “Now why on earth would you want to give up all this?” His huge paw swept in an all encompassing arc that took in my cube and then the rest of the office beyond.
“Because there is no way on earth I’m going to get the company to adopt Scrum for real!” I poked at the stack of books. “It’s a far cry between some structural artifacts and the real meaning of Agile and the company is about as unagile as you can get.”
Hogarth nodded, “Well yeah, I think we covered the whole artifacts part already” He snaked an arm out the open window and broke off a branch from the tree outside. Snacking on the branch he said, “You’ve recognized the real problem so what’s the issue?”
“There is no way on earth I’ll ever get this company to go agile.”
“Agile or Scrum?” Hogarth asked.
“What’s the difference?” I shot back.
“A single sapling a forest does not make…”
Scrum is an Agile Framework – Scrum is not the only way to practice Agile.
When these kind of comments are thrown out, the typical response is something like “Well of course, there’s Kanban, Lean, or XP.”  And those folks are right, these are other frameworks or methodologies  of Agile. And at the same time I think we end up missing the bigger picture. To understand this, we need to look into the roots of Agile.
Agile has two foundational roots. The most obvious is the gathering of software luminaries that created the Agile Manifesto. Agile wasn’t some earth shaking new concept. What it was, was the joint thinking of seventeen software developers who had been practicing various lightweight development methods and how what was the common, foundational values of these methods.  At its heart Agile was a new language to explain long standing best practices, values and principles. If you think about it, in a light weight Agile way, it is the Agile PMBoK. (Remember that the PMBoK is also not a methodology, but a set of standard terminology and guidelines for project management.)
The other foundational root goes back to the precursors of Lean manufacturing, to the Toyota Way. Like the Agile Manifesto, it was not until 2001 that Toyota published the “Way.” But in Toyota’s case it was not for lack of use. Toyota revolutionized automotive manufacturing with their unique style and for decades US companies tried to match it. It’s not as if Toyota was a walled garden. They cheerfully gave tours of their plants to any and all comers. Why? Because they knew the artifacts of their process were not the key. The key was their six underlying principles, such as “Respect for People,” and “Add value to your organization by developing your people and partners.”
So what’s your point?
Ah yes, this is not a history lesson and I am trying  to make a point.
Today I read a great blog that sums up my point nicely. Ben Horowitz wrote about Lead Bullets, on TechCrunch. The kernel of this is to not go looking for the silver bullet solution, instead use the bullets you have and shoot better.
I’ve heard stunning success stories in the use of Agile Methodologies (Scrum, XP, Lean, etc.) In nearly all of these instances, the support and engagement was across the board high. It was the right time, the right people, the right need and so on. The Perfect Project Storm. In these cases the silver bullet was the only bullet and it was a dead shot.
And I’ve seen people try and use the Agile silver bullet and have the organization smother them alive. I like to remind people that silver bullets only work against werewolves. If you are facing a ghost, you’re kind of out of luck. When faced with an organization that is highly resistant, highly process driven, highly dysfunctional, etc. trying to dive into the deep end of the Agile pool tends to only end up in the Agile project and team being drowned.
I’m even more depressed now, wasn’t there a point?
Yes! The point is Agile isn’t just an umbrella over methodologies,  like Scrum and Lean. Agile is a set of guiding principles that can be used ANYWHERE. Where is it wrong to have good teamwork? When is it wrong to make sure the customer is getting what they want? If the process plan says to roll the parts cart around the outside of the building twice, before entering, is it wrong to ask “Why?”
Enter the Agile Manager. You don’t have to be using Scrum to be Agile. You can use the principles of Agile anywhere . You can make any team better, if you try.
In short, don’t let bad methodology get in the way of good management.
Focus on the team and the project will improve. That’s Agile.
Joel Bancroft-Connors
The Gorilla Project Manager
Want me to talk to your gorilla? Send me an email
You can follow me on twitter, @JBC_PMP

No one expects the Gorilla Retrospective

Posted on by
2
Jake was pinned to his seat by the spotlight’s intense beam. “Where were you when the code check-in introduced four P1 bugs?”

“I, uh, what?” Jake stammered.
I spun the spotlight and speared Bob with its white light. “The requirements document failed to take into account the Fergusson account. Why?”
Bob shifted in his seat. “It was Jane’s fault, she didn’t file a sales report for Fergusson!”
Jane’s mouth dropped open and she reached for her cellphone. Somehow I didn’t think she planned to text Bob with it. Not from the way she was holding it over her head.
Now I was getting somewhere. This post-mortem was finally getting to the bottom of things.
But before I could turn the spotlight towards Jane, a figure leaped onto the table and blocked my view. Jumping back, I looked up at the strange visage before me. Yards of red satin swirled about, all but obscuring the figure beneath it. A red galero covered the figure’s head, its deep crimson so dark it nearly blended with the black hair that lay beneath it. The darkness of satin and hair offset the brilliant white teeth of my interloper, making him suddenly recognizable.
Hogarth struck a preposterous pose and declared, “No one expects the Gorilla Retrospective!”

The Post-Mortem:
If you have ever sat through a grueling multi-hour project post-mortem, you probably wished for the inquisition to sweep in and put you out of your misery. The very term means “after death.” What a delightfully pleasant term for this meeting. Let us examine the corpse of the project and see what killed it. Let’s not trouble ourselves with the fact that the project actually shipped and is a success. No, that would be pointless.
The purpose of the meeting is to tear apart the project and find everything that went wrong. As the project manager, you will assemble a mammoth document that goes into sickening detail. Even if you tell people “we aren’t here to blame anyone”, blame will be assigned and buses will be thrown on top of people (or something like that).
And when it’s all over, the report is dutifully filed in some file cabinet (real or virtual) and promptly forgotten. No one goes back and reviews it. No one wants to remember the painful experience of exhuming a successful project for failures.
A rose by any other name:
Okay so we won’t call it a post mortem. How about lessons learned or a retrospective? Yeah, that’s the ticket. Now who’s fault was it that we shipped with no user documentation?
You can slap lipstick on the pig and it will still be a pig. Changing the name of something, but not how you go about doing it, is just going to make folks dislike the new name as much as the old.
So many companies look back on their projects to find what went wrong and fail to try and do better the next time.
Break off that rear view mirror:
I’ve met no small amount of people who think the George Santanya quote “Those who cannot remember the past are condemned to repeat it” means we have to live in that history. Relive every mistake and wrong to determine exactly why it happened.
Not so. The horses are already out of the barn. Grilling the ranch hand on why he left the door open isn’t going to do much. It doesn’t get the horses back and it doesn’t really do anything about the future. Manager Tools recently did a podcast called “There is no why in feedback.” The Feedback Model is a manager tool for communicating about both the good and not so good things your directs do. The big key to it is that it doesn’t focus at all on the past behavior. It just focus on the future.
 An example:
“Don, can I give you some feedback? <wait for answer> “When you are late to the meeting, we start late and can’t finish the agenda. This means not everyone gets a chance to be heard. Do you think you could change that next time?“
Read the last sentence again. “Next time.” The manager doesn’t dwell on the previous issue, instead he dwells on it not happening again.
And that’s the secret to a great retrospective. Focus on the future. Don’t assign blame. Don’t dissect every problem. Don’t get lost in the spilt milk. Focus on doing better the next time.
Forward looking:
When I do a retrospective I pull out another tool from my Manager Tools bag. On the left side of the white board I write “What Went Well.” On the right side I write “Things to Look At.”
The latter is important and I always stress it. TLA isn’t about blame, it isn’t about why, it isn’t even about negative. It is simply things we want to look at for the future. This can mean you end up with things people would generally refer to a “positive” on the Things to Look At side. After a good retrospective, I often have lines drawn from items on the WWW side to the TLA side. Things that were not part of the normal process, that had a good impact and the team wants to do it again.
The next step is to lay down the brain storming rules. When using the brain storming rules there is no “No”, “But”, or “I don’t agree.” Brain storming is a safe zone where anyone can throw out anything and there will be no discussion, no argument and anything goes. If someone yells out “Pepperoni Pizza,” my only response is “Is that a ‘Went Well’ or a ‘Things to Look At’?”
When you’re done collecting your WWW-TLA you then give everyone something to vote with. Small teams can use markers, larger teams work well with stickers or even post its. Let everyone vote two or three times on the TLA side. Then you tally up the votes and you’ve got your top things to look at changing for the next time. Short, sweet, to the point and very effective.
Don’t make your retrospectives a full court trial. Don’t dwell on the past. Do make it safe for people to reflect. Do focus on the future.
Joel Bancroft-Connors
The Gorilla Project Manager
Want me to talk to your gorilla? Send me an email
You can follow me on twitter, @JBC_PMP

Wake up and smell the gorilla

Posted on by
3

Or: Finding my own business philosophy and what matters

The training room was packed. Nearly everyone from the department was there and we were all interested to know what the all hands meeting was about. Things were going really good. The company was doing great. We’d gotten past the uber release of the year and were all breathing a sigh of relief. My job might not have been exciting or “filled with growth opportunity” but it was nice and safe.

Then boss of all the bosses in the room stepped up to speak and we all settled into quiet. Our eyes open and ears listening.

I know he said other things, but somehow everything he said was lost in an unrelenting roar of six words as they repeated in my head, over and over again. “Your services are no longer required.”

My jaw dropped. That’s okay though, the floor had fallen out from under me and my jaw was just trying to keep up with the rest of my body. What happened? This was a safe job! How did I miss the writing on the wall, I mean there’s always writing on the wall. Isn’t there?

“Of course there is.” I turned to look for the source of the voice. I didn’t recognize it, but the voice was somehow familiar. It was almost like I should know and was just having amnesia.

“Selective amnesia, sure I’ll give you that.” The voice was attached to two rather large, extremely hairy feet. Said feet were propped up on the table next to me. Following the feet back up the equally hairy legs I was eventually greeted by the visage of an 800 pound gorilla.

“What the hell are you?” Not exactly the most sane response to meeting a talking gorilla but I can’t imagine Elwood P. Dowd handled meeting Harvey much better.

“I’m your fairy career gorilla.” He grinned, showing a mouthful of blindingly white teeth. “Well technically I’m your ‘So blindingly obvious you can’t avoid it’ combined with ‘That problem you know is there but would rather ignore, gorilla.’ Course you could just call me Hogarth, that’s my name.”

“I must be hallucinating. Or maybe this is just a bad dream. I’ve been under a lot of stress lately, this is just stress giving me bad dreams. Yeah, that’s the ticke…”

Smack!

I think I’ve mentioned before how unnerving it is to be smacked by a figment of your imagination. The first time was no less so. And it’s damn  hard to ignore a figment of your imagination that makes you see double. Blinking, I looked at the fuzzy image of two gorillas. “How long have you been sitting there?”

Hogarth folded his ample hands over his chest and spoke serenely, “I have always been here, you just were not prepared to see me.”

“How the hell can you miss a 800 pound gorilla in the room?” I asked in complete disbelief.

Hogarth’s reply was to wave about the room. All about me were faces in shock, disbelief and sadness. HR Minions, the dislike of their current job evident on their faces, moved about the recently dispossessed like clerics ministering to their flock. But no one paid any attention to Hogarth. “People see what they want to see, they understand what they want to understand.To truly understand the source of a problem, one must be prepared to look for it in ever increasing circles about oneself”*

*This quote is paraphrased from Mark Horstman

 

MY AHA MOMENT- I’D BEEN CAREER COASTING 

And so was my “aha moment”, my “game changer”, my “Waterloo”. Or in normal speak, it was getting laid off from this “safe” job that finally made me stick my head up over the cube wall and look around.  

In the days right after the event I went through the normal five cycles of grief, denial, anger, bargaining, depression and finally acceptance. It was with acceptance that I found out something fundamental. Something that changed how I looked at everything. With acceptance I gained the realization that getting laid off was the best thing that could have happened to my career. I felt like that guy in the romance comedy movie. You know, the one who’s in love with the super perfect, if not a little boring, woman and is devastated when she leaves him, only to realize his best friend has been the girl of his dreams all along? Being shaken from the safety of my job made me realize how much I was to blame for where I was. 

For some of us, it takes a two by four to the head to see the blindingly obvious. My two by four was being laid off and what I ended up seeing was Hogarth. Okay, I didn’t really see a 800 pound gorilla, but what I did see were things that had been right in front of my face all along and I was too focused, blind or in denial to notice. 

And so I began to make the changes to take control of my career. At first it was the absorption of knowledge I’d ignored for so long. Reading books I’d long owned, long had looking impressive on my office shelf and had never read. Checking in with the real world and what was going on. And discovering new voices that spoke words of common sense, words I’d been deaf to before. 

And then I began to realize I had everything I needed to take charge of my career. I learned enough to see that I already knew how to be more than what I was. I started to understand I already had a set of principles, a personal business philosophy. I just needed to start following my own inner gorilla. 

Over the last two years I’ve put to writing my own guiding business philosophy. Covey might call it a mission statement, Agile calls them values and Manager Tools just calls it being Effective. They are still a work in progress, but they color my daily work and the blogs I write here.  

The one caveat I should give is that this isn’t anything new or profound. This isn’t rocket science, or as the fine gentlemen at Manager Tools like to say “Management is boring, but it is effective.” I’m not the guru of a new world order, I’ve just put some common sense into a coherent form and am doing my best to follow my own guidance. 

The Gorilla Philosophy:

1- People, not projects

2- Communication is 100% your job

3- Process is a tool, not a roadblock

4- There  is no, one, right way

4- Everything leads back to the Customer (Stakeholder, End User, etc.)

 

Stick your head up and look around, is there a gorilla waiting to talk to you?

 

 

 

The Stealth Gorilla

Posted on by
Reply

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.