The Gorilla always sits in the front row

I stuck my head into the room to cast a quick glance around. The presentations wouldn't start for another hour and the room was empty of all save some facilities people setting up the AV. Smiling, I ducked through the doorway and made for the best seat in the house. The middle of the back row.

I merrily pulled out my laptop, chortling at my luck.

"You do know that they don't expect more than fifty people and this room can hold one hundred?"

Good seat luck, bad gorilla luck, guess you can't win them all.

To read the rest of the blog, head over to The Gorilla Coach

So long and thanks for all the bananas

"Keep coming, straight back, doing fine. Oh, you might want to watch out for…"  <crash> "that lamp…"

Doing my best to not tip over the moving dolly I glared at Hogarth. "A little more warning would be helpful."

Hogarth gave me a shrug. "What do you expect from an imaginary gorilla? Besides, when have you ever listened to me before a problem happened?"

I sighed, he had me there. With a shrug, I wheeled the boxes around the broken lamp.

Plenty of time to clean up the mess, we were going to be a while after all.

Breaking a branch off one off my newest fichus, Hogarth said. "No place like home."

Moving Day

On November 05, 2009 I published the first of Hogarth and my adventures in blogging. With a motto of "I've done a lot of stupid things, no reason anyone else has to." Google Blogger made getting started very easy and I've enjoyed my time here at "The gorilla is named Hogarth.

Yet all good things must come to an end. And with an end is a new beginning. Today Hogarth and I moved into our very own space. Moving forward you'll find us at "Thegorillacoach.com."

Thank you, Google and we'll see all of you on the Gorilla Preserve.

Joel and Hogarth

The Gorilla Hero- Project Management's Super Power

“Preparing shock, move away from the patient! “

What the? The sound was muffled by the partially closed door to my office. I shoved open the door of my office to see what was going on. And promptly wished I was still in the quarterly business review being grilled by the CFO.

A massive gorilla was kneeling in the center of my office. His massive torso obscured my view of what was beyond him and only made me more concerned as all I could see were a pair of human legs that I assumed were connected to a body lying on the floor.

“Shock will be delivered in 3, 2,…”

“Hogarth!” I rushed into the room, trying to see who my personal gorilla was leaning over. My mind praying it wasn’t Bob as he still owed me the initial set of product owner user stories to start release planning. In retrospect, not the most compassionate thought, but it was the heat of the moment. \

“Shock delivered, it is now safe to touch the patient.”

I cleared Hogarth to look down on his victim. Only to find the empty eyes of a CPR dummy staring up at me. A portable AED was lying next to the dummy, it's cables snaking out to the test pads stuck on the dummy's chest.  

“Hogarth!, what are you doing?” You’d think I’d get tired of asking this, given how often I find myself asking it in any given week.

Looking unnaturally large as he hovered over the mannequin Hogarth pointed at the device. "Practicing," he said matter of factly. "Don't you remember the CERT training is coming up? I want to be ready when we go."

"Hogarth, I'm not signing up for the Community Emergency Response Team." I stepped over the CPR dummy and made my way to my desk.

"Really?" Hogarth said. "I would have thought you would have jumped at the chance. You're always advocating people do more. You know responsible authority and all?" 

I sighed. "Yes, I do believe in stepping up, but that's different.  I’ve got nothing to offer for CERT. I’m just a software project manager. I don’t have any medical training, I don’t know jack about construction and if you hadn’t noticed I’m far from what you'd call a Greek god of fitness. I'm anything but fire fighter material."

Hogarth settled back on his haunches. One long arm snaked out to my bedraggled fichus and came back with a branch. "Uh huh," he mumbled through a mouthful of leaves. "Let me ask you this, when you are brought in to help on a problem project, what do you do?"

I didn't have a clue where Hogarth was going with this. I did know that this was familiar ground for me. "Easy, start by gathering data, figure out what's gone wrong, create an "state of the project", create a plan of action to correct, execute and then keep going back through the cycle in a tight iteration loop until the project is on track or done."

Hogarth nodded. "Interesting. Sounds a lot like this." He handed me a printed PowerPoint slide that bore the title "CERT Sizeup."

More than a little annoyed at this delay, to my getting real work done, I skimmed my eyes over the slide. I blinked. I read the slide more closely, taking in each of the nine steps a CERT team goes through when assessing an emergency scene. "Oh… my… That's"

Hogarth nodded, "Just like project management?"

I really hate it when he's right.

Project Management is Leadership and Leadership is needed

In many ways this blog ties back to the Responsible Authority Gorilla.  No matter our authority, we have a responsibility to the project. Combine this with the ethics taught by professional certifications like the PMP and I argue this responsibility extends to helping those around us, with the skills we have developed.

That's all well and good, but project management isn't exactly a life saving skill?

Really? Take a look at the slide Hogarth showed me. It is from the national Community Emergency Response Team training for sizing up an emergency site.

Looks familiar, doesn't it? The process a CERT member goes through, to assess and deal with an emergency situation, is a lot like what we project managers go through when dealing with a project. I've seen lighter weight process frameworks than the CERT checklist. When you start learning about the Incident Command System, a national standard framework for how multi-agency and jurisdiction response to a disaster is handled, then you really see how our training, as project leaders, can be an asset to our community.

I'm currently taking CERT from my local city. This free training is offered by many communities to create a core of citizen volunteers that can help out in the event of disasters or major emergencies. When fire and medical is overwhelmed, CERT teams are become the "First Responders" and can often make a difference between life and death. Most of my fellow class mates are taking the class as a response to the "Glenview incident", what most of the world calls the San Bruno Gas Pipeline explosion. I, on the hand, am continuing a long tradition of community service.

I first learned CPR and First Aid in college as part of the Resident Assistant program for my dorm. I eventually ended up as the ERT Captain for one of my former companies, over seeing a team for a 1500 person campus. In the course of that time I've contributed to saving at least two lives and preventing several more people from having more serious injuries had I not been a first responder while the fully trained medical people were still in transit.

I'm no hero. I believe in helping others and I've learned that the skills I use to manage troubled projects are just as effective in managing the response to a disaster or medical emergency.

Good project management can change the world. Even if it is just one band aid at a time.

Joel Bancroft-Connors

The Gorilla Talker

Want me to talk to your gorilla? Send me an email, jbancroftconnors@gmail.com

You can follow me on twitter, @JBC_PMP

Who is Hogarth? Read Blog 001 to find out all about my personal gorilla.

A Gorilla Primer: What the heck is Agile?

"It's all rather simple." I said confidently. "It's a process to maximize our transparency so that we can deliver the maximum effectiveness of end purpose value to our constituents while ensuring the highest possible predictability in deliverable milestones ."  

Hogarth cocked his head to the side, "I'm not following. I thought this was supposed to be easy?" 

I tossed my hands in the air energetically. "It is! That's the beauty of it. Why the framework for one implementation can be summed up in ten minutes." 

"Really, so what's the value?" Hogarth asked. 

"Total optimization!" I beamed. "Using a collaborative team structure you generate value in an iterative cycle that completely optimizes your process and maximizes customer return."  

Hogarth looked at me for a long moment. Finally he reached up to scratch his chin. "Huh… I'm still not sure I'm following. How is this different from waterfall?"  

I jumped up "Totally different! It will change the world!" 

Hogarth shrugged, "How?" 

I let out an exasperated sigh, "Have you been listening to anything I've said? Haven't you read anything about this?"  

He nodded, "Yep and I'm still not understanding what's in it for me." He opened up his arms, "If you're going to sell me on a new way of doing things, you have to tell me what's in it for me and you need to use small words." 

"What's in it for you? Why that's…." 

Well damn, the gorilla was right again. 

What the Heck is Agile?

A blindingly simple question that is a lot harder to answer than one might think. Trust me readers, I will get to the answer, just bear with me a moment as I expound.

I'm an experienced agilist, I speak about agile often, and I write about agile regularly. And the other day I found myself trying to explain agile to a program manager who had zero knowledge of it.

Wow… It's not that easy.

First problem, where to start? I took part in the May 11th #PMChat twitter chat, which had a topic of "An Intro to Agile." It was a great Tweetchat, with a lot of valuable information. Only it would have been better called "An Intro to Scrum." That's great, it was a good topic and judging by feedback, very informative.  Only Scrum isn't all that is agile. When discussing agile, do you start at the nuts and bolts, or do you start at the overarching philosophy?  

Or maybe… You start with the user.  

User Stories: Skipping ahead to an advanced lessons, we find that User Stories are different from requirements in that they are focused on the benefit given to the user. So maybe we should be using the same concept to explain agile. Today is version 0.1 (zero dot one [zed dot one for British folks]) of my agile primer.  

Let's look at our users and what agile can do for them: 

Company President- Do you want predictability? Do you want happy customers? Do you want happy shareholders?

Agile is a company initiative that creates more predictability in releases and allows the company to quickly adapt to the customer's needs. Through happy customers your company has happy shareholders.  

Product Manager- Do you want to be able to change your mind? Did your customer change their mind? Do you want what really matters, when you need it?

Agile is a flexible product design process that allows you to adjust the product to meet changing customer priorities. What ships is what the customer really needs (and will buy).  

Manager- Do you  really want to be looking over your team's shoulder every day? Do you want to help your people grow, not just make the next code drop?

Agile gives your team the ability to what they do best, create. It gives you the ability to do what you are best at, helping your team grow.  

Project Manager- Are you tired of chasing down everyone with the age old "What's your status?"  Are you tired of living in the DMZ between product management and engineering? 

Agile is founded on transparent communication and puts deep focus on collaborative solutions that have the whole team working towards a common goal.  

Developer- Would you like development model that puts the power in your hands? Do you want to decide how to build something? Do you want management to listen to you when you say it will really take three weeks?

Agile lets you be directly involved in helping to define how something will get built and even what gets built. The company puts its trust in you to make decisions and listens to you when you say how long something will take. Schedules are based on what can be built not some artificial line in the sand.

Great, so what exactly is Agile?

Ah yes, once we get past the benefit we still have to figure out just what agile is.  

An early attempt I had at a one line summary is: "a customer focused, iterative process that is executed through a collaborative effort of the team and company."

Yeah, I know, with that kind of double speak I should be in politics.

Agile is:

• Listening to the customer throughout the entire development process, not just at the beginning.
• Focusing on the team. A better team makes a better product. Trust in the team.
• Building with GPS. You're constantly making sure you're on course.
• Learning from mistakes, not just writing them down at the end of the project.

-  and -

• Not new. The term is new, the ideas reach back decades. We owe the Agile Signatories for helping bundle the concepts into a single word.
• Not a methodology. It's a set of principles and values. Below these are frameworks like Lean, Kanban, Scrum and XP.  

At its barest essence, that is what agile is. It's not some secret, make it all perfect, sauce. It's hard work and incredibly rewarding. It's moving from shareholder value to customer value. Go read the Agile Manifesto. It's not about process, it's about results.

Okay, and?...

Right, that and four dollars will buy you a cup of coffee. What do we do with this? Good question. Agile itself isn't a solution. Agile is a mindset, a way of thinking, of interacting. You still need a framework to work within. The are four common agile frameworks, Scrum, Kanban, XP and Lean.

In a nutshell:

Scrum- Is characterized by its iteration cycle. At the start of a sprint (1-4 weeks), the team commits to working on a certain amount of the Product Backlog (Everything we want built). They meet each day to review progress and impediments. At the end of the sprint (iteration) they demonstrate working results (no PowerPoint). Then the team reflects on how the team did and what can be done to get better.

Scrum can be very good for new development, where uncertainty is high, change is constant and the customer is involved.

Kanban- Kanban has evolved from Just in Time manufacturing concepts. Its primary characterization is the WIP, or Work in Progress, that limits what can be pulled from the Queue (What needs to be done). It does not work in iterations, instead working in available workload. By limiting work in progress, you limit waste and generate greater focus by reducing multi-tasking. It's other driving factor is it starts with where you are now, and works to get you to a better process. Where most frameworks are replacements for existing methodology, Kanban focuses on continuous, incremental improvement from where you started.

Kanban can be very good in maintenance, where each item is often unique.

XP- Extreme Programing is probably best known for the concept of pair programming. XP is known for pushing the limits of traditional practices (hence "Extreme"). It also uses short iteration cycles, typically, one week max, as well as demos and retrospectives. It is also heavily leverages code reviews, unit testing and automation. Typically more so than Scrum. The average person will see little external difference between  XP and Scrum.

XP is very common with start ups and for projects that extremely dynamic or have few starting requirements. You are rapidly prototyping to a final product.

Lean- This practice is best characterized by the elimination of waste. Anything that does not create value for the end customer is considered wasteful and a target for elimination. It's a "do more with less" framework that at works primarily thanks to strong principles that oversee the structure. Toyota's Total Production System is the most common example of Lean.

Note: Some will argue that Lean isn't agile. Not being an adherent to any one framework I see Lean as sharing many of the same principles and thus put it under the loose umbrella of agile. It's easier than calling them all "customer focused, iterative development practices that focus on the team."

Lean is most common in manufacturing, where the product is relatively fixed and the improvements are focused on how to produce the product better.

Anything else?

Oh, Gorilla, yes. There are stacks of books and gigabytes of blogs on agile. I can't even begin to scratch the surface with all my blogs. Let me leave you with some additional resources and one last thought.  

Elements of Scrum- Great primer book on the Scrum methodology. I reviewed it last year. The authors also just released a 50 page super primer. Only $0.99 on Kindle.

Mountain Goat Software- Mike Cohn is one of the leading educators of agile. His web site is full of information.

Agile Leadership Network- Find a local chapter. Meet people who also believe in changing the world.

Wikipedia- Seriously, the articles on Agile are very extensive and a great way to get started.

One last thought: All the above is a fairly basic and fact based review. I'll want to leave you with why I use agile. We've spent several decades with companies focused on shareholder value. I think the time is coming to swing back to focusing on customer value. We've also spent the last several decades focused on getting more out of our teams. I think it is time to start giving more to our teams.

I think agile is the key to these changes. I think the values and principles of agile and lean will change the world for the better.

And I want to help.

Joel Bancroft-Connors

The Gorilla Talker

Want me to talk to your gorilla? Send me an email, jbancroftconnors@gmail.com

You can follow me on twitter, @JBC_PMP  

Who is Hogarth? Read Blog 001 to find out all about my personal gorilla.

The Abilene Gorilla: Going with the flow isn't always

I flung my door open only just catching it before it slammed into the wall and left a hole I wouldn't want to explain later. Resisting the urge to throw my notebook across the room I stomped towards my desk, registering the presence of Hogarth decimating my newest fichus tree.

For once I was almost happy to see Hogarth. Almost happy. At least I had someone I could complain to. "We are so doomed," I said as I tossed myself into my chair. It gave a whimpered protest, at the abuse,  though held together in the end.

Hogarth raised one eyebrow, which for a being with a monobrow that was no small achievement. "The Mayan's were right?"

I leaned back in my chair, throwing an arm over my eyes to blot out the light. "We should be so lucky. At least if the world ended I wouldn't have to watch our profits tank faster than skydiver who forgot his parachute." The deafening silence that greeted my answer  eventually caused me to peak out from under my arm and make sure Hogarth was still there. He was, just staring at me with those impassive brown eyes.

Sigh, here we go again. "The president just decided we should do a radical pivot of our business model. It's absolutely insane and it's going to kill our business. All you have to do is look at the recent customer feedback to know it was a bad idea."

Hogarth carefully set the denuded fichus branch down before speaking. "Well did he?"

"Did he what?"

"Did he look at the customer feedback?" Hogarth asked.

I tossed my hands up in the air, "I don't know. I didn't ask."

Hogarth cocked his head to the side, "Why not? Wasn't this a strategic brainstorming meeting? You all meet to throw out ideas and see what sticks."

I shook my head, "Hogarth, Hogarth, you don't understand. The president asked 'What about doing X?' No one is going to argue with his idea, he's the president." Pointing at my chest I said , "It's not my job to rock the boat ." 

"Isn't it?"

"Stop playing twenty questions with me!" I snapped. "He's the boss, we do what he says. He knows what he's doing."

"That doesn't mean he thinks it’s a good idea. He's the president, he has to look like he knows what he's doing."

I glared at Hogarth, "What's the difference?"

Hogarth looked at me. "Ever been to Abilene?"

"What?"

DON'T ROCK THE BOAT

"The Abilene paradox is a paradox in which a group of people collectively decide on a course of action that is counter to the preferences of any of the individuals in the group. It involves a common breakdown of group communication in which each member mistakenly believes that their own preferences are counter to the group's and, therefore, does not raise objections. A common phrase relating to the Abilene paradox is a desire to not "rock the boat"." - Wikipedia

The paradox reminds me of the lemming poster I used in "All the other Gorillas are Doing it" blog. The Abilene paradox is a solid reminder that no matter where the idea comes from, as a people or project manager, we can't blindly assume that it is a "good" idea. If you have concerns it is your duty and responsibility  to raise those concerns. You can't assume someone else will. Even in the most CEO dominated companies (can you say Apple?) it takes a team to design and build an idea.

But the nail that sticks out gets hammered down

Ah yes, the old Japanese proverb that espouses conformity and not making waves. Sure, no one wants to be the little kid who yells out that the Emperor has no clothes. Only ask yourself this, do you really want to be the Emperor's servant when he finds out he's been parading around in public without any clothes on? The problem with this approach, is what if there really is a squeaky wheel? If everyone chooses to ignore the squeak it doesn't go away. Eventually the wheel seizes up and flies off. Then where are you?

Let's instead look at another Japanese proverb, this one from Toyota. 

"Stop production so that production never has to stop."   or, as the Toyota Production System sums is up,

Jidoka

This is what empowers every worker on a Toyota production line to be able to stop production if they see a problem. Not only do they have the ability, they are empowered and encouraged to use that ability. Every step of the way, assumptions are challenged and reality is tested. While Toyota has had some recent setbacks in quality, no one can deny their decades of stellar quality nor is their little doubt they will be returning to those quality roots. It is what has made them the brand and success they are and Jidoka is no small part of that.

So the next time something seems so obvious that everyone knows it, open your mouth and make sure everyone does know. Don't end up going to Abilene when the restaurant down the street is what everyone really wanted.

Joel Bancroft-Connors

The Gorilla Talker

Want me to talk to your gorilla? Send me an email, jbancroftconnors@gmail.com

You can follow me on twitter, @JBC_PMP

Who is Hogarth? Read Blog 001 to find out all about my personal gorilla.

The Gorilla Product Owner: It takes a village

Note: For new Gorilla Blogs, head over to The Gorilla Coach

"Bob," Jake's tone was almost plaintive. "You're killing me here. I thought we had this all sorted out. Didn't we just spend three days doing ideation work?"

Bob looked pained, he wasn't happy and it showed. "We did and I thought we were sorted as well." He gave a shrug, "Sales got wind of the requirements and threw a royal fit that we weren't addressing performance on the OutDate hardware."

"They do realize it's a fifteen year old platform?"

Bob nodded, "And they insist it's a must have to support 'key' customers."

Jake grumbled, "fine, that explains that. What about this other stuff?"

Bob winced, "My boss isn't happy with the strategy, he wants to alter course."

I glanced over the new proposal. I made a note to talk to Bob about the concept of the word 'alter.' This plan was nearly a 180 from the previous one.

Jake threw his hands up in the air, "I give up. Every time I think we're settled and I can start planning, the entire model changes again. Who the hell is in charge of the business plan?"

I could see Bob stiffen at that one. He didn't respond, even though I could see he was rankled by the comment. I think he didn't respond because he knew he really wasn't in charge, even if his job description said that he was in charge. He had tried to put together a business plan and now, every time he turned around, someone was sticking a hand in and changing it.

"Sounds like you need to start the project before you start the project?"

"What is it this time, Hogarth," I asked with no small amount of dread. Turning to face him I continued, "I've got Bob fully engaged with development, they've been meeting regularly. I've got an honest to goodness PO led product backlog for the first time ever." I waved at the business plan on the screen, "and it's all been tossed out the window. What's the point? We are halfway through development and this is a huge shift in direction."

Hogarth nodded, "Which is why you need a project before the project."

I blinked, "Wait, what? That's Big Design Up Front! We're agile here!"

Hogarth gave me a huge, ivory filled yawn. "We covered this already, remember? Garbage in, Garbage out?"

I pointed a finger at Hogarth, "look here, I did that. Bob went through the whole process. We even brought in Jake and his team to look at some of the requirements. Our backlog was built on real requirements this time!"

Hogarth nodded, "And who else helped?"

"Huh?"

Hogarth gave a long stretched before fixing me with his dark gaze again. "You wouldn't design the features without the agile development team, why design the business plan without an agile business team."

Blink, blink. Well dang…

A Product Owner is Not an Island

Experienced agilists will of course be saying "duh" right about now. Product owners are supposed to work with the team and collaborate towards a final product. This is good and effective, and the PO can still be an island if they do this. He just has seven other cast-aways, from his three hour cruise, on the island with him.

Beyond even the question of "how do you prioritize the business value of the backlog," are questions like "what's the business model," "what's the product concept," and "where does the product owner get his requirements from in the first place?"

The product owner is not an island. He doesn't sit in some ivory tower and imagine great ideas, which he then transports to the development team in a puff of smoke smelling faintly of brimstone. Our product owner, still called a product manager by many companies, instead is sometimes reduced to nearly the level of a scribe collecting all the inputs from other parties and trying to justify how to have the product be "fast", "ultra-secure" and "cheep." The product owner must work and take inputs from a wide variety of sources in an often dizzying array of inputs and conflicting priorities. When every organization is clamoring for their little slice of the feature pie, you can end up with a product that looks more like Frankenstein's monster than Brad Pitt.

That's just the way it is, you can't expect that to change.

It can if you make a village.

In Garbage In, Gorilla Out I propose a new model for the early stage of a product. In what most lifecylces would call the Concept and Planning Phases I propose an iterative, agile driven, style that takes you from product ideation (vision) all the way to a well ordered backlog that the agile development teams can plan their iterations from. While I don't speak to this in the GiGo blog, in essence, what I am espousing is an agile project where the finished product is a product or release backlog. So if GiGo is an agile project, where is the team?

In GiGo I briefly touch on the idea of the GiGo project team. It is not just the product owner that moves through the GiGo project. With her on the journey are representatives from her key stakeholders. This is not a fixed team and will vary from company to company. Ideally it won't be more than seven, plus or minus two people which may require some team members to then go off and work with an SME team of their own. For example a representative from Technical Support might have their own Support GiGo team where they review and bring back final "product" to the primary GiGo team.

Who should be on the team? Other than the product owner, again it depends. Below is a list of common team members based on the most common roles to contribute to traditional requirements documents.

Product Sponsor	Customer  (or voice of the customer)
Related product managers	Technical Support
Technical Architect*	Marketing
Agile coach or Facilitator	Sales

While the product owner is the final decision maker, she is not the only person to have input into the creation process. When the PO works with a village, they prevent the customer, sponsor and team from getting PO'd at them.

Do you have your village?

Joel Bancroft-Connors

The Gorilla Talker

Want me to talk to your gorilla? Send me an email, jbancroftconnors@gmail.com

You can follow me on twitter, @JBC_PMP

Who is Hogarth? Read Blog 001 to find out all about my personal gorilla.

Gorilla Risk Impact- The "what" is more important than the "if"

OR: Probability just tells you how likely it is to hurt, not how bad it will hurt.

 "We have to fix it!" Carlos leaned forward in his seat, hands griping the table.

Decaf, man, decaf, I thought. "We're a week from launch. Making changes to the code now is absolutely impossible."

As Carlos turned beat red and began to splutter, I wondered if it was a common trait of Customer Service people or something they learned on the job. I'd lost track of the number of frothing support folks I'd dealt with in my time.

Carlos managed to keep his voice calm. "It's a severity one issue. Complete and irrecoverable data loss. They get taken to bare metal. Support can't approve this release."

"Carlos," I said, putting on my best "teacher" voice. "It would have to be a blue moon, in Australia for this bug to happen. It's such a fringe case it makes the guy on the street corner with 'The world will end tomorrow' sign seem like a sure thing." I closed the lid of my laptop and began to stand up. "I think we can put a pin in this one and move on, don't you?"

I left Carlos spluttering at the table. He was saying something about stopping the release. I didn't really pay attention. After all, he was in support, no one was going to stop the release over something customer support said.

I was opening the door to my office, when I heard a voice from within yell, "Duck!"

The paper airplane smacked me right in the eye, before I could even register what was happening.

"Ow! Hogarth!" I never realized how well those two words went together.

Through tear streaked eyes I saw my gorilla lumber towards me. "Hey, sorry about that. What are the odds of that happening, eh? I mean, here you are, back from your meeting ten minutes early. That never happens. Who would think you'd open the door just as I tried to hit it with a paper airplane."

I shouldered past Hogarth (okay I bounced off Hogarth, into the door jam and then into the room. He is an 800 pound gorilla after all) and strode to my desk. "Well you should have thought! You could have put my eye out. Anytime you're dealing with possible life and limb you should be planning for it."

Hogarth turned to follow me. I could feel his eyes on me and I just knew I'd been set up. It always happened this way. "Here's a question for you," he said. "What are the odds a rain storm will cause a mud slide on Devil's Slide this winter?"

"Close to 100%, there is always mud coming down off the hills."

Hogarth nodded, "Okay and what's the impact to your commute?"

I rubbed my chin, trying to see where he was going. "An hour, maybe and just one time. They have crews on standby just for that contingency."

Hogarth smiled, "And what's the probability of an 8.0 or greater earthquake hitting the region?"

I shrugged, "Who knows, once in every fifty years, maybe."

"I see," Hogarth picked something from his fur and popped it into his mouth. "And what would the impact be?"

"Ugh!  An 8.0 would be huge. It took years to recover from the Loma Prieta. It was only a six nine and look what it did." 

Hogarth's eyes twinkled, "So which one do you want to build a survival kit for? The one hour traffic delay, or the life changing earthquake?"

"Huh…"

Damn it! He'd done it again.

PROBABILITY versus IMPACT

Tell me if you've heard this before, "It's a fringe case," "There's a low probability of it occurring," "What are the odds of that happening?"

I was once poor Carlos. When I worked in global support organizations I faced risk all the time. I learned a lot about risk management, how to plan for it, how to communicate it, how to mitigate it and most of all, I learned that most of the time the focus wasn't on the "What" it was focused on the "If."

"If that happens, we'll have issues."

"If the user pushes that button, sure it will crash."

"If they are using Windows NT, who uses that anymore?"

Taking this approach is like lumping a $500 payout lottery scratcher ticket with winning the $500 Million Powerball lottery. The odds of both are slim indeed. Only if you win the $500 Million lottery, the impact of the win is going to be MUCH different.

To often we focus on "If" something will happen, when we really need to start with "What will happen." If the odds of a database crash are only 15%, that might seem like it is fairly minor. If the database crash will cause a cascading network failure that brings the entire eBay auction site to its knees, eBay isn't going to care if the risk only happens 15% of the time. It happened to them.

In my years I've come up with two tools to help with properly addressing Risk Impact.

LIKELIHOOD CHART: The first is more visual and is designed to get agreement and understanding from the team (see the image, below. Click to zoom in). The Likelihood Chart was something I came up with while still working in support. It mapped customer Severity to the Likelihood of the problem occurring. Then cells then had what the action item was for each combination of four severities and four Likelihoods.

This snapshot is an example of one use of the chart. The Likelihood meters can be adjusted up or down depending on the companies risk tolerance, Severity can be replaced by any impact scale the team agrees on and the action plan for each cell can be changed to suit the project and team agreement. What shouldn't be flexible, is when you set this up. This should be agreed to as part of the project charter/kick off. Get everyone to agree before you have show stopping bugs.

RISK REGISTER WEIGHTING: The second was a simple bit of math I applied to my risk tracking spreadsheet.

 On the surface, this looks like an ordinary risk register. Impact and Probability are both a ten point scale with 0 being the highest impact/probability (unknown being riskier than any known because you don't know) and 10 being no impact/mitigated. The magic is in the Total Risk Score. Here's the "math."

As you can see in this next image, Impact gets a higher weighting score than Probability. This means you can have a 100% risk even with a probability score of 4-Med. (For those doing the math, I have an excel formula that limits the maximum number in the Total Risk Score column to 100).

These are not silver bullets. I keep telling you, there are no silver bullets. Besides the one day you actually find the silver bullet will be the day you end up facing a vampire (you need wooden bullets for vampires). What they are, are two tools I've used in helping to make sure Impact (Severity) is the first thing the team focuses on.

Remember,  if their data center is an oozing puddle of goo, eBay doesn't care if it was only a 15% chance edge case

Joel Bancroft-Connors

The Gorilla Talker

Want me to talk to your gorilla? Send me an email, jbancroftconnors@gmail.com

You can follow me on twitter, @JBC_PMP

Who is Hogarth? Read Blog 001 to find out all about my personal gorilla.

The Agreeable Gorilla: the power of "And"

"But we can't do that."

Not my best opening line, but Jake had caught me unaware. I tried again. "Look, using the Saskatchewan office to do the testing is a great idea, but it won't work because we haven't set up any network infrastructure with them."

Jake gave a shrug. "Well we just need to get that set up then."

I nodded, "we could, but that means working with IT on prioritization. You know how much fun that is."

Jake asked, "Isn't this project the key corporate goal for the year? We just need to explain that to IT, right?"

"Yes it is. We absolutely can explain this to IT, but I don't think it will help much. They've already planned out their infrastructure work for the next four quarters." I don't think Jack was getting just how hard what he wanted to do was. The number of hoops we (I'd) have to jump through was staggering.

"Okay, I understand." Jake was staying remarkably relaxed through all this. "We can still make the request though, right?"

I gave a shrug, "Sure we can, but they won't say yes."  Jake nodded but kept silent. "Okay, Saskatchewan is off the table, any other ideas?" I looked around the table hopefully but no one said anything. Sigh it was going to be a long meeting.

"And  why do you think there are no more ideas?"

Sigh, the only thing worse than a long meeting, was a long meeting with Hogarth kibitzing at me. "I don't know  that. Ask the engineers, they're supposed to be the brilliant ones."

"And didn't you just ask them?"

"Yes, but they're sulking because their pet idea didn't fly."

"They are disappointed, I agree. And do you think your negative response might have contributed to that?"

Sigh, "Yes I suppose it could have, but you know how unlikely IT would be to agree."

"Certainly, IT has been a bit rigid of late, and if you don't ask, you will never know, right?"

Sigh, "Yeah, you're right."

Hogarth nodded, "Isn't it so much easier when your not being butted to death?"

Blink, blink… But, but, but… And, "Oh my."

The power of "But"

Have you ever stopped to wonder at the power of this simple little conjunction? With three simple letters you can entirely negate everything that came before it and utterly replace it with what ever you say next.

"Certainly it looks like a beautiful day, but it's nighttime right now with no moon so I can't see a thing."

See the power? If alchemists could harness the power of the mighty "but" then surely they would learn the secrets of turning lead into gold. After all, we all know that "but" really stands for "Behold the underlying truth!"

This one little word has the power to destroy communication.

And I believe that communication is one of the cornerstones to any team. Good communication will make the team better. Bad communication can completely ruin a project. "When you said blanco I thought you said you wanted the walls painted black. I didn't know blanco meant white."

Good communication also relies on collaboration. Nothing breaks a collaborative environment faster than a lack of trust. And how much are you going to trust the guy who keeps shooting down your ideas? "That's a great idea, but I don't think it will be practical to implement."

Are you a but-head? Grab a pen and a piece of paper. Go to your next meeting and listen to everything you say. Every time you say "but" make a hash mark. You may find yourself very surprised. Now have a friend do this exercise for you. Odds are, there will be even more hash marks. We are so ingrained in the use of the word that we don't even hear ourselves saying it. I've been aware of the dangers of this word for years, and I still catch myself going to this word at least three times a day. 

The power of "And"

Let us take in contrast the power of the lowly "and"

"We could go to the beach, and after that grab a bite to eat."

"I had a peanut butter and jelly sandwich."

"That sounds like a good way to boost DB performance, and if we use pair programing we can reduce bug count also."

It is simply amazing how much more open your communication becomes by substituting one three letter word for another. You take a conversation from a conflict, to a collaboration. From an either/or decision point to a "cake and eat it too" cooperation. 

Which do you think is more positive?:

"We were going to go to the movies, but we decided on going to dinner instead." - This makes it sound like a bad thing.

"We were going to go to the movies, and we decided on going to dinner instead." - Was there conflict?

Simple Team Exercise: Try this simple and fun exercise. It's called the "Yes, and" story game and actors use it a lot for practicing improvisational theatre. Seat the team in a circle. Tell everyone you are going to tell a story together. The rules are simple. The first person says one to four sentences of a story. Then they stop and hand it to the person to their right (or left, but pick one direction and keep going that way). The next person continues the story. Only they have to start their story by saying "Yes, and." They then continue the story from there for one to four sentences before handing it off to the next person who starts with "Yes, and."

We have the power to change communication. With a simple substitution we topple even the biggest gorilla in the room.

Joel Bancroft-Connors

The Gorilla Talker

Want me to talk to your gorilla? Send me an email, jbancroftconnors@gmail.com

You can follow me on twitter, @JBC_PMP

Who is Hogarth? Read Blog 001 to find out all about my personal gorilla.

A Month Passes Addendum: I've spent the last month paying attention to the use of "but" around me. I'm absolutely amazed at how common the word has become. In one recent coaching session, my client used "but" two times in a "sentence," creating a very conflict laden run-on sentence. I was editing some writing and found no less than three "buts" in one short paragraph. The writer had meant it to show how flexible something was, only the end result was to create a series of conflicts of what something could do. Reminded me of the old Ginsu steak knife commercials, "but wait there's more!" Are you a steak knife or a can opener? Make up your mind!

And I noticed another word, that is insidiously creeping up to supplant "but" while being no less controversial. When someone says "Actually, it's white, not black" do you have the urge to smile and agree or reach out and smack the offending words from the person's mouth?

There is enough conflict in the world without adding to it with the use of such ineffective words. So take the pledge with me. "I will actually make an effort not to say but."