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, butAnd, “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
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.”

Gorilla Ethics: Is that your banana or mine?

Have I ever mentioned how much I loathe team building exercises? Not the real one, no.  The ones that take cut-throat competition and slap a happy veneer over it to call it team building?
I squinted through the sunlight, trying to see where Sue was in the obstacle course. It was one of those big inflatable things that look like some swim float on steroids. She was struggling through inflatable tire rings about halfway through the maze. Meanwhile our opponents, from accounting, were just clearing the exit with their second to last man. And I was standing helplessly at the starting line, waiting for Sue to reach me so I could take my turn in the inflatable torture chamber.
The referee (okay the high school kid overseeing our event) came up to us and asked Monica how many were left to go on our team. She turned to look at Mr. Huggle . He looked over at me and then back at the ref, “Just him.” I looked at Mr. Huggle in confusion. He was the anchor, he’d called it at the start of the event and as the boss, he got it. He looked at me and gave a short shake of his head, the meaning unmistakable.
And then I didn’t have anymore time to react. Sue was running towards me. No matter what, I needed to do my personal best…
I walked into the  air conditioning of the sports center’s cafeteria. I made a beeline for the coolers full of beverages and yanked a bright blue sports drink from the ice. Putting the bottle to my neck I let its cold wash through me as I closed my eyes and tried to let go. Mr. Huggle had never run the obstacle course and because I’d run my heart out, we’d “beaten” accounting and “won” the obstacle course.
Yet, in the end it hadn’t mattered. They had already trounced us in the soccer shoot-out and then went on to annihilate us in ultimate Frisbee. So in the end, accounting won the overall competition and all I had for my experience was a lingering unease and a sweaty t-shirt.
Finally I gave a shrug and took a long pull from the sports drink. I had to let it go. It’s not like it was a big deal and we didn’t win anyway. So what if Huggle cheated?
<Clunk… Slide…. Clunk… Slide…>
Fearful of what the sound could be, but knowing full well what it was, I turned towards the door. He was silhouetted in the sunlight, his black form even more indistinguishable than normal. He was moving strangely, a waddling shuffle, almost like he was wearing…
“Hogarth! Why are wearing skis?”
Hogarth shuffled across the room his skis knocking over a couple of chairs the process. Plucking a banana from a fruit bowl and taking a bite from the unpeeled banana he chewed on it thoughtfully for several seconds. Finally, just as my patience was about to boil over, he turned to me and said. “To go down the slippery slope of course.”
“What slippery slope? It hasn’t rained in weeks!”
My gorilla gave a shrug. “The slippery slope that starts with fudging a team building game and ends with a Bernie Madoff sized Ponzie scheme.”
I threw my hands in the air in disgust. Stomping to a chair, I flung myself down and took a long pull on my sports drink. “Hogarth, it’s not the same. It’s light years difference between the two.”
Hogarth nodded, “You’re right, the difference is vast. And you’re wrong, it is the same. That’s your problem.”
“Huh?”
My gorilla looked me right in the eyes and spoke. “There is no such thing as black and white only shades of grey. The secret is knowing that and always questioning what you do. If you’re always checking to see if you’re off course, you’ll get back on course a lot faster.”
Ethics- In this post Lehmans, Enron, Madoff era you can’t go a week without some kind of news article about ethics. Whether it is decrying a lack of it, tips for being better, passionate arguments for the use of it or even unethical advice on how to fake it, ethics has become a major component of our professional lives. This isn’t the three martini Mad Men era of business (if that ever really existed) where anything goes to close a deal. This is the era of the always online internet where what you said ten years ago is still floating around on some Alexa server. PMI has made ethics an integral part of its certification process, as had many professional organizations.
We all know it is right to be ethical, we all know what it means. Google summed it up in their corporate motto “Don’t be evil.”
Hey, Google! How’s that working out for you?
The world has become a lot murkier in the 21st century. The clean and crisp lines that had Superman as good and Lex Luthor as evil have given way to hero’s like the Dark Knight and villains  the Libyans throwing off their “legal” government.
Where is the line now? If there is not black and white, then how do we know if we’re on ethical ground or a quicksand pit of corporate malfeasance?
Unfortunately, I don’t think there are any magic bullet on this. In the example above, you risk the wrath of your employer if you point out he’s cheating in a simple game. Is it unethical to stay quiet? At the other end of the spectrum, if your boss is embezzling seven figure amounts from the company, it’s pretty clear cut that you should do something.
But those examples are like night and day!
Yes they are. The question is, what’s the difference between night and day? The answer is about one minute.
There isn’t a magic formula to tell you when you’ve gone from skating the edge to full on breach of ethics.
The secret is to always be asking yourself if you’ve crossed that line. Just as the courageous man is a man that knows fear but does it anyway, an ethical person is one who is constantly examining their own actions.
At the end of the day, there is only one person who can tell you if you’re being ethical or not.
Look in the mirror.
Joel Bancroft-Connors
The Gorilla Talker
Want me to talk to your gorilla? mailto:jbancroftconnors@gmail.com
You can follow me on twitter, @JBC_PMP

How to be a Gorilla Manager: In five easy steps

 

Dear Hogarth,

I want to become project manager. Can you give me some advice on what to do?
Thanks,
– Aspiring cat herder
Dear Aspiring,
Run, run as far as you can.
Barring that, I recommend you have your head examined. I mean, seriously, if you do your job well no one will notice you. If the project fails, you’ll be standing right next to the product manager when they roll out the firing squad. Why would you want to put yourself through that?…
“Hogarth!”
My gorilla looked up from the keyboard, banana sized finger poised over the Return key. “What? Oh right, let me guess.” He sat back in my chair. Amid the creaking protests of my chair he did a disturbingly accurate imitation of me. “Hogarth! What on earth are you doing?” He grinned at me, “that about cover it?”
I pinched the bridge of my nose. The pounding ache behind my eyes was threatening to burst out like some bad horror flick monster. “Yes, that covers it.”
Hogarth said, “good, then we have that covered. That was easy.”
“Hogarth…” I said menacingly.
He held up his hands. “Oh, right, what am I doing? I was just checking my email. Someone wanted some advice on becoming a project manager.”
I blinked, “you have email?”
“Well duh. It’s the 21st century, of course I have email.” He shook his head like I’d asked the craziest question ever.  Okay, maybe I did. Did I?
Shaking my head I tried a different tack. “You were giving advice on becoming a project manager?”
He nodded, “Yep, don’t.”
“Don’t?” I asked. “You do realize what I do for a living?”
Hogarth nodded, “Yep and that’s why I’m advising him not to.  You’re losing your hair, you’ve got an ulcer, and heaven knows that no one appreciates your work. Why on earth would anyone want to be a project manager?”
“Because I like helping people!”
Hogarth pointed a paw at the screen, “Okay, help him…”
And once again I had been Hogarthed.
Advice for the aspiring Project Manager (Scrum Master or Coach)
What advice would I give to a young project manager? While the urge to advise him or her to “run, run very fast,” is fairly strong, it is also entirely unhelpful. And I really do like to help people, something I think makes me a good project manager, scrum master, coach, leader, etc.
So if I were to be giving advice to Josh Nankivel‘s students, what would I say? There are so many pithy, trite, over used things I could say. I could call on the masters of PM and just quote them. I could call on the masters of business, military or the circus and quote them.
And doing that would do two things. 1- Put the students to sleep, 2- Absolutely be nothing about me and the passion that makes me successful.
So my advice would be what works for me. Be a leader.
“Oh, right, that’s real helpful.”
You’re right, that falls into the “pithy but true” category. The question is, how to be a leader? How to move from managing to being the visionary, the inspirer, the front of the charge or the wind beneath their wings.
For myself, it is following five personal principles. These are principles I’ve come to hold over my life and drive how I live my life and do my job.  It may not work for  everyone, but if I’m going to give advice, I should damn well have some passion for what I’m advising.
“So what are those five principles?”
Right, good question. Below are my five guiding principles and a short explanation. After presenting them at the PMI Silicon Valley annual symposium, in October of 2011, I began referring to them as the “Gorilla Equation,” the five “x” factors that make a good managers. 
The Gorilla Equation
  1. People, Not projects.
  1. Communication is 100% of your job.
  2. Process is a tool, not a roadblock.
  3. There is no, one, right way.
  4. All roads lead back to the customer

People, not projects: This is the foundation principle in the Gorilla Equation. Without this foundation the rest lack a structure to sit on. If I focus on helping the team become a high performing one, the team will do better. A better team leads to a better product and I firmly believe this combination will lead to a better world. 

I spend every day of my job trying to make myself obsolete by enabling the team and helping them grow.

Communication is 100% of your job: PMI says communication makes up about 80% of a PMs job. I say it’s 100%. Think about what a project manager does. You’d be hard pressed to find anything that doesn’t involve some manner of communication.  Not only is it 100% of your job, but you need to be adding value to every communication you are involved in. You are not an operator, you are more like the chief operation officer for your team. It’s your job to facilitate all the communication and enhance it along the way.

Process is a Tool, not a roadblock: Don’t ever let process take control of your project. If a process does not contribute value to the end user/ end goal, then look at dropping it,  streamline it, or focus it. Make sure your process is not subverting principle 1 or 5.

There is no, one right way: If I want to go from San Francisco to New York there are dozens of options (Different airlines, driving, train, cruise ship, even biking) and any one of them could be the right way for me, depending on my goals and constraints. Anytime you here “That’s the way we have to do it” ask “Why?” If something has to be done, be open to if there is an easier way to do it. Inspect and Adapt.

All roads lead back to the customer: Where “People, not projects” is the foundation principle. “All roads” is the guiding mantra. Rooted in my original high tech job in customer support its been like that beacon in the night that lost ships yearn for. If you can’t map what you are doing to some impact to the customer, then you should be asking why you are doing it.

Five principles, one result. Better me, better teams, better product, better world.
Joel Bancroft-Connors
The Gorilla Talker
Want me to talk to your gorilla? mailto:jbancroftconnors@gmail.com
You can follow me on twitter, @JBC_PMP

The contemplative gorilla: The value of retrospectives

Bang… Bang… Bang…
You know the nice thing about banging your head on the desk? It feels so great when you stop.
Bang… Bang… Bang…
The smell of banana proceeded the lumbering form that entered my office. “You’re gonna break the desk like that,” Hogarth said.
Just great, honestly I hadn’t done anything wrong this time. Why was he here? “Go away, Hogarth. Let me be miserable in peace.”
Hogarth slid a ripe banana onto the desk, preventing me from hitting my head further. Unless I wanted to make banana puree. “Come on,” he said, “you should take it as a compliment. The team blew away all previous performance records for delivery. The pointy haired bosses are breaking up the team to try and spread the love. You did an awesome job, be happy about it.” He pointed at my computer screen, “besides, you’ve got the project retrospective to go to. You don’t want to be morose in that.”
“Retrospective!” I snapped. “What’s the point of a retrospective? The teams’ being broken up. I’ll have all new engineers for version 2.”
“Huh…” Hogarth grunted. “Are we reviewing the product that was just built, or are we reviewing the project?”
“The project” I snapped. “We don’t need to review the product, we had 100% pass on acceptance tests and validated with management and the customer that they got exactly what they wanted.”
“That’s what I thought.” Hogarth said. “Let me ask you this. If your Kendo teacher only taught you lessons that wouldn’t damage the blade, would that effect your learning?”
“Wha? Of course it would. He teaches me things so I’ll be a better swordsman, the sword is the tool to learn with.”
“And so is the product…”
Agile Retrospectives: The keys to them are they are by the team, for the team and take action from them right away. No filing it away in a dusty file cabinet.
I had an interesting conversation on #PMChat . While discussing bringing projects back from red, we got into learning from mistakes.  The question was:
“Q4. In his post @backfromred discusses the concepts of a ‘learning culture’ for project success. What does that mean to you? #PMChat
Rob Kelly (@rkelly976) tweeted:
 ” Actually conducting a lessons learned session, archiving them, AND using them later .”
Sidebar: So if you only just tuned into the Hogarth channel, let me just remind folks of my position. I think that agile values and principles can be applied in any company and at any layer to make better teams, better products and better companies. 
So it is untestable that I responded to Rob with:
“Don’t archive them. Pick at least two things and start doing them right away. “
Ron Rosenhead (@ronrosenhead) also replied to Rob with
“BUT: research suggests that people do not read lessons learned …#pmchat relying ons something that does not work”
And I jumped back with:
“Which is why you action them right out of the meeting. That’s the #agile model for retrospectives. Don’t file.
Whew, enough tennis,  let’s get to a point!
Agile retrospectives have a major component to them that so many other Lesson’s Learned models lack. That is immediate accountability and action. When you come out of a retrospective, you should have a clear decision on changes to make changes and have the “Who, Does What, By When” documented. If you don’t make a decision and don’t turn it into action items, then you get what Ron laments, a filed document that no one reads.
Now Rob came back with a great question.  I had a glib answer for at the time, but one that really got me thinking. He asked: “What about heavy contractor/turnstyle orgs?”
He raised a great point. There are many industries that roll most of the team every release. If the company is failing, some of the team might be let go. If the project was a success, some of the team is promoted. So what happens to the team? What happens to the collective knowledge?
What’s the point in doing an immediate results retrospective if there is no one left to enjoy it?
As fate would have it, I have just been reading Agile Retrospectives, by Esther Derby and Diana Larsen. I read the last chapter today, after the PMChat, and found these words of wisdom.
“Even when the team doesn’t stay together, people take that learning with them to benefit other teams and other projects.”
Agile spends a lot of time looking at the team and sometimes we can easily forget that teams are made up of individual people. These people have their own career paths and arcs that will take them on varying courses over time. And that’s okay. Remember, this is the 21st century. This is the century I think will see project managers becoming the new “people manager.” In an era when few companies look after their employees careers, it falls to individuals like the project manager to help coach and guide the people on their teams. This goes to one of my core principles, that if you focus on the team, the product will follow.
If our focus is on the team, then we should exult when they are tapped for new projects, new promotions, new jobs. Manager Tools maintains that one of the best measure of a manager’s success is that they get their people promoted.
Instead of focusing on how the project will be impacted, recognize the value the team will get from that final retrospective. What lessons will they learn and take with them? How will this benefit the company, the industry, the world? Better teams are made up of better people. And a better world is made up of better people.
You do the math…
And if that wasn’t a compelling enough reason, think about the benefit to the company as a whole. From the same paragraph of Agile Retrospectives.
“Release and project retrospectives uncover organizational factors, policies and procedures that get in the way of the team – and these require coordination across areas to solve.”
Taking it back to being all about “Me.” If you have to go off and two version 2.0 of the project, the best team in the world isn’t going to matter if the supply chain looks more like a supply thread.
No matter what happens after the project, a retrospective will help all those involved to be better on the next team and the next project they are on. Better teams, make better projects.
You do the math…
Joel Bancroft-Connors
The Gorilla Talker
Want me to talk to your gorilla? Send me an email
You can follow me on twitter, @JBC_PMP

The Winning Gorilla: A Book Review of "The Lazy Winner"

“Yeah, sure no problem. I can get that done.”
I hung up the phone, a cheerful smile on my face, and turned back to my computer. Only to be faced with a staggering to do list awash in the red of late deliverables. Why the heck did I just say yes to another deliverable? I was already behind on a half dozen and the list of commitments just for this week was enough to keep me busy through to the new year. What was I thinking?
“You weren’t”
Sigh… And here comes the gorilla to tell me the error of my ways.
Hogarth perched on my desk, causing it to groan in protest at this 800 pound bulk. “There’s a wonderful word in your English language. You might be familiar with it. It’s the word ‘No.”
“Yeah, yeah I know about no.”
Hogarth pointed his banana at me, “But do you know how to use no?”
“Of course I know!”
“Really? Can you tell me the status of the Glitteratti regression testing?”
“At this time QA has not published their report so I don’t have an up to date status.”
Hogarth shook his head, “That didn’t sound like a no. Way to many syllables. What’s the status of the Glitteratti regression?”
I gritted my teeth, “I don’t have that status right now, I should have it…”
Hogarth waved his cantaloupe sized hand in front of me, “You know, never mind. I actually came in here to ask if I could borrow your car. I saw this great move on an old Dukes of Hazard that I want to try. So can I borrow your car?”
“NO!” I replied without thinking.
Hogarth smiled broadly. Leaning over he patted me on the shoulder, “see there, I knew you could say no!”
BOOK REVIEW: The Lazy Winner, By Peter Taylor
It’s not often I’m on the leading edge of a book. It took me close to twenty years to read 7 Habits and my last review was on the ten year old Good to Great. So the ability to read a book when it first comes out is something I take as a great joy.
Now I do need to give the disclaimer that I didn’t pay for The Lazy Winner. I received a complementary copy with the agreement that after reading it, I would write a review for it on Amazon. That said, being the gorilla talker means I’m not about to pull punches just because I didn’t pay the cover price.
Summary:
The Lazy Winner steps beyond Peter’s first book, The Lazy Project Manager and seeks to provide helpful guidance for anyone trying to survive the daily grind of professional life. The Lazy PM was chock full of useful tips and techniques for the project manager and still sits in a prominent spot on my desk bookshelf. The Lazy Winner is both targeted at a wider audience and more narrow in its approach.
The book is strictly focused on you and how you can succeed in the work environment without killing yourself. And it is not a book that tries to promise the world. In fact Peter spends the first couple of pages trying to convince you not to read the book. You have to want to change to change.
The key to the book is five questions and then how you answer and define them:
Do I want to do this piece of work, job or task? Even if I do want to do it, do I need to do it?
Is the potential result or outcome worth my effort?
Do I have to do it myself?
If I have to do it then what is the shortest path to the point of success?
What exactly is the point of success and at what stage will I just be wasting time?
Revisiting the Pareto rule, which he first references in The Lazy PM, Peter then uses these five questions to help the reader learn how to channel what he actually does to the most important and value added items. And unlike many self help books, in this vein, he doesn’t try whitewash away the stuff you don’t do. There is a large factor to ensuring things don’t get dropped, even as you do less, but more productive work.
Peter even talks about the inertia against change. “But it’s so easy to just keep doing it this way…” Using some of his signature simple graphics he walks the reader through how to examine the value of change versus not change.
The Good:
This makes sense: Peter has a conversational reading style. Having listened to his podcasts, I could easily imagine him reading the words to me. He mixes a simple writing style, humor and just the right amount of formatting to make The Lazy Winner the kind of book you say “I’ll just read one more page and then I’ll put it down.”
Questions of power: I’ve understood the Pareto rule and I learned the hard way I don’t have to do everything myself. And even with that under my belt, the five questions make a wonderful level of sense and will be something I refer back to time and again.
Footnotes of laughter: Read the footnotes. I usually am one to skip footnotes as way to much detail but you’d be the poorer if you do that with this book. Read the footnotes for the information but more importantly for the humor.
The Bad:
Just a snack: The PDF copy comes in at just 162 pages with the Appendix (a very useful appendix) starting at page 121. Peter packs a fair amount into the book, but I can’t help but feel I’m reading the cliffs notes of summary copy of the book. Everything section left me looking for more. Then again, perhaps this was on purpose. If you give to much help in a self help book, people might not think for themselves. In the end, like the Chinese food Peter loves so well, this book left me hungry for more thirty minutes after finishing.
I’m ready for my close up: I love the cover to The Lazy Project Manager. It is simple and compelling. The kind of cover that catches your eye on a bookshelf or in an e-catalog. While the photo of Peter is a good one, I think it would be a lot better as the “About the author” picture. A laughing man, not looking at the camera doesn’t sell me “Winner.” If I didn’t know who Peter was, I might be inclined to say “Wow, what an ego, he used his own face.” I’d rather see art in the same style as The Lazy PM. A stylized checkered flag over a man racing a desk or something.
Ow, ow, my wallet: $23 US for the print edition of the book feels a little steep. It’s a smaller book than his first and still going for a similar price. Perhaps I’m just out of touch with prices but if I were to heft the print version, in a Barnes and Noble, I’d think it didn’t weigh what a $23 book should weigh. The Kindle version though is $9.99 and that’s in the reasonable (for Amazon) e-book range.
The Bookshelf Index:
The Lazy Winner won’t be joining The Lazy Project Manager on my desk bookshelf. It has some valuable insights, but the core meat are those magic questions and a couple of other points. I’ll be creating a one page of those to pin on my wall and the book will be filed away in my reference stack.
Well worth the read, but not something you won’t be reaching for again and again.  This book is perfect for electronic reading. Short, easy to read and you won’t be wanting to flip through the pages to refer to it like you might with The Lazy Project Manager.
NOTE: Passing on a shameless plug from Peter Taylor. The Lazy Winner is currently (Dec 14, 2011) free on the Kindle in the US Amazon shop. Take advantage of his largess while it lasts.
Joel Bancroft-Connors
The Gorilla Talker Project Manager
Want me to talk to your gorilla? Send me an email
You can follow me on twitter, @JBC_PMP

Methodology roulette, always bet on Gorilla

This blog originally appeared on PMChat.net. I heartily recommend this site and more importantly the weekly Twitter chat that Rob Kelly and Rob Prinzo host with the hashtag #pmchat. Thanks again to Rob and Rob for inviting me to speak in the PMChat pre-game call and to share this blog on their site.

“Hogarth?”
My mind was still trying to comprehend the scene before me, but my mouth already knew who was undoubtedly responsible. The conference table was gone; in its place was a roulette table. Gathered around the betting section of the table were some of the usual suspects, Percy – the pink elephant, Wanda – the black swan, the apes Stanley and Winston, and even James – the intern.  And overseeing the table was none other than Hogarth. Wearing a poker visor and sweeping up chips with one of those crooked neck poles you see in gambling movies, he was cheerfully laying on the “dealer” patter.
“Winner pays to six phase lifecyle on black. Oh, tough luck for Wanda betting it all on Scrum red. Lay your bets for the next spin…”
Hogarth, was the gorilla in the room. He’s one part elephant in the room – that problem everyone is trying so hard to ignore, and one part 800 pound gorilla – something so powerful that it can act without regard to the desires of others. The gorilla in the room can crush your project into dust and leave your team wondering what the license plate number was of the bus they were just thrown under.
Like Harvey, Jimmy Stewart’s imaginary rabbit, Hogarth is my personal management Pooka. Thing about management Pooka’s is they are a blessing, a curse and totally unpredictable.
“Betting is closed,” Hogarth said. “Round and round she goes, where she stops nobody…”
“HOGARTH!” I snapped, this time much louder and with a healthy dose of annoyance. “What on earth are you doing?”
My 800 pound gorilla looked up from the spinning wheel. “Oh hey there, Boss. We’re just playing a little methodology roulette.”
I shook my head, trying to comprehend what he was saying. The roulette wheel was slowing down now and as I stepped closer I could see words, not numbers on the red and black pockets that made up the wheel. I caught words and acronyms like “6 Phase SLDC, 9 Phase PLC, Scrum, Lean, PDD, PUD, and BDUP”
“Methodology what?”
The table broke into groans of disgust as the ball finally fell into a pocket labeled “SotP.”
Hogarth turned to the table, brandishing his chip collecting stick. “Oh too bad, no one put anything down on the “seat of your pants” methodology.”
Hogarth pulled out the banana tucked under his sleeve garter. While he peeled it he addressed my question. “If you haven’t noticed, there is a hell of a lot of methodologies running around. Just here in the company you’ve got at least a dozen variations. Your using a Scrumish model in the consumer group, IT is using a Lean Kanban model, Finance has a customized accounting focused process for all projects it takes part in, and let’s not even get into what it takes for the hardware team to change a single resister from 10 to 15 ohm in that monolith, twelve gate process they have.” Tossing his banana peel in the trash, he continued around a mouthful of the fruit, “With all those different processes it plays complete havoc on anyone who wants to run a project. What the heck should they learn, PMP, Prince, Six Sig, Agile, IBM’s custom process, Accenture’s?” He shook his head, “Man could go crazy trying to figure out which process to become an expert on.”
He was right, absolutely dead right. I could feel my heart start to quicken with impending panic. What should I do?
“Oh come now, you don’t think I’d leave you hanging, now do you?” He gave me a sparkling white grin and pointed at the table. “When you can’t beat the house, don’t play the game. Remember it’s not about the process, it’s about the people.”.”
It’s good to have a Hogarth… (just don’t tell him that)
Methodology Roulette- Or how the heck can you work in any project?
We are hearing more and more about the portability of the project management skill set. I’ve blogged about this in previous blogs, “Project Gorillas are SMEs” and “The gorilla with too many hats.” The nutshell concept is that the project management career has become its own expertise that can transcend specific industries. I’m a walking, talking example of this, having worked in such diverse industries as hard drive manufacturing, consumer electronics, computer games and virtualization.
“Okay, so I believe I can work anywhere. The question is, how do we keep up with all the ways to run a project?”
Even within a single “big bucket” methodology (which is really the wrong term at this level, but that’s another blog) there are dozens if not scores of variations. I’ve worked in traditional “waterfall” (Plan Driven Development or Big Design Up Front) projects that range from a bare three phases/gates to a staggering nine phases/gates and I’ve heard of programs with even more gates. The blog Leading Answers has a great blog on Agile Adoption that shows a periodic table of agile adoption. If there are that many ways to adopt agile, just think of the number of ways to do agile.
PMBoK, Prince2, BDUF, PDD, XP, SCRUM, LEAN, AGILE, SIX SIGMA, PMP, CSM, ACP, AAPM, CSP, CPM, ABC, 123, PDQ, the list of methods and certifications is staggering. PMI alone has six different certifications, five of which are focused on their own specific methods and practices.
“Oh my head, there’s no way to keep up.”
That’s right, so don’t even try. Instead focus on what’s most important.
There is one thing every project I’ve ever worked on possessed. One constant factor across a half dozen industries and even more job titles. It’s on every project and it’s what you should focus on.
“You mean people?”
Right! You see for me I’ve come to the realization that it’s not about the methodology at all. To paraphrase presidential candidate, Bill Clinton, “It’s about the people, stupid.”
Projects are done by groups of people. And when a group of individuals works together, instead of in parallel, they become teams. And through teamwork the end result can be greater than the sum of the parts.
And that’s why today I call myself an “Agile Project Manager”.  Using the principles and values of agile to guide how I work with any team, any project, any methodology.
(Remember, agile isn’t a methodology. Just like the PMBoK isn’t a methodology, but a set of best practices, agility as it is practiced is nothing more than a set of guiding principles set forth in the Agile Manifesto. Scrum, XP, lean, those are methodologies).
The very first value of agility is “Individuals and Interactions over Process Tools.” It has nothing to do with the tangible. It has to do with how the team should function. Principles four, five, six, eight, and twelve are directly focused on people or team interactions and principle eleven can’t happen without a motivated team. Agile isn’t about shipping software, but instead is a set of values and principles. Values that have an extreme focus on the who, not the what.
“But Agile is just a passing fad, it won’t last.”
Agile the word is new, the concepts behind agile are not. Agile is new vocabulary for good business practices that go back to post World War II with Edward Demmings, the Toyota Production System, and the people philosophy that became the Toyota Way. It really goes back even further; to the Hawthorne Study in the post depression and the roots of Industrial Psychology  in WW I troop assignments. The point here is solid team building practices have existed for a long time. In the 1980’s and 90’s it seems we lost the way. In the drive for more efficient companies we forgot that the people in them are what make the products, not the balance sheet.
Using Agile as a management technique makes sense and is something that’s been done for decades. I’m not doing anything new, I’m just coming full circle.
“Umm, okay. So how do you do Agile without using Scrum (or Lean, or Kanban, or..)?”
There are many ways to do this.  Author and agile coach Lyssa Adkins focuses on coaching the players. Agile fundamentalist, Tobias Mayer, ascribes to total self-empowerment of the team. The Manager Tools  podcast series focuses on making you a better manager with the concept that making a better you makes a better team. You can follow one of the existing concepts or, like me, you can develop your own principles and guides. For me I focus on how I can help teams. By being the best team helper I can be, I support the team in being better.
At the end of the day the core concept here is to focus on the team. A better team, makes for a better product.
Joel Bancroft-Connors
The Gorilla Talker
Want me to talk to your gorilla? Send me an email
You can follow me on twitter, @JBC_PMP

The Responsible Authority Gorilla

The project meeting was moving forward very well. We were tracking on everything and it looked like we’d actually have the release out on time, and with everything we wanted in it. We had just gotten to the issues with the flux capacitor redesign work and I asked Paul, the engineer, when he would be able to give an updated report on completion.
Paul shifted in his seat, stealing a glance at Jake but said nothing. Jake, the development manager,  leaned forward and spoke, “I’m taking Paul off this project, I need him to rebuild the prototype simulator. It’s running 10% slow and I don’t like that.”
I did my best to keep my mouth from gaping open. Without the flux capacitor redesigns, this maintenance release would be all but pointless. Nodding my head I said, “all right, then let’s look at the next item on the agenda…”
After the meeting I slipped back to my cube, looking forward to ensconcing myself behind the safety of my monitor. The fury black form reclined on my desk told me I wasn’t going to get that opportunity.
“May as well cancel that maintenance release, huh?” Hogarth said, casually peeling a banana.
I shrugged, “Not my call, I just track the projects. I don’t have the authority to change resources.” I shoved aside Hogarth’s feet and flopped into my chair. “Jake thinks work on the simulator is more important, Paul works for him.”
“I didn’t think the simulator was even gonna be used until next year.”
Resisting the urge to complain about Hogarth’s banana breath I gave another shrug. “It’s not, but I have no authority to change things.”
“So what? That doesn’t mean you don’t have a responsibility!”
The Authority vs. Responsibility Gorilla. I think we are all familiar with the lack of authority gorilla . I’ve yet to meet a project manager who never had to run a project in which he had little or no real authority.  But how many of us think about, the responsibility gorilla?
Authority- Dictionary.com defines authority as
The power to determine, adjudicate, or otherwise settle issues or disputes; jurisdiction; the right to control, command, or determine.
“The Power”
I get all tingly when I read that. Reminds me of the 1980’s cartoon, He-Man, and his magical transformation (work safe video) from medieval geek to super hero. There is a small problem with this. At least in Silicon Valley high tech power is practically a fundamental myth. Mark Horstman, of Manager Tools, maintains there are three kinds of workplace power. Role Power, Expertise Power and Relationship Power. Role power is the power a boss has, the power to hire and fire, to make decisions that will affect everything in his organization.
Role power in the 21st century is a myth. Anyone who tries to operate exclusively on role power will ultimately fail. Without a healthy measure of expertise and, especially, relationship power that manager is headed for a short career.
Still the concept of authority does exist and all to often a project manager has limited or no authority on their projects. So what do we do? Do we throw up our hands in despair and give up?
Like bloody hell we don’t.
We are project management professionals.
What does this mean? Great question! A web search for the definition of “project manger” returns back thousands of answers. Some of these answers are contradictory to one another, but there is one theme that pops up over and over.
“The person responsible for the project”
Responsible. The word makes me feel all grown up and mature, but it is the key to this concept. In fact, let’s take the grown up analogy a little further. When Tommy gets suspended from school, for throwing spit wads, his reaction is “But the other guys were doing it!” And if you grew up in the United States you are probably familiar with the stereotypical parental answer, “And if all the other boys jumped off a cliff, would you?”
PMI members reading this should be familiar with the PMI Code of Ethics and Professional Conduct. This code is mandatory for all PMPs and I personally think is part of what can set apart a PMP from other structured project management certifications. If you look with in the code you will see two key points.
1.1 Vision and Purpose
As practitioners of project management, we are committed to doing what is right and honorable. We set high standards for ourselves and we aspire to meet these standards in all aspects of our lives
2.1 Description of Responsibility
Responsibility is our duty to take ownership for the decisions we make or fail to make, the actions we take or fail to take, and the consequences that result.
There it is again, responsibility. And the big kicker in all that “and the consequences that result.” If we don’t take responsibility then we have to be prepared for the consequences.
This is where the professional part comes in. As professionals we are under an obligation to be responsible.
Quick and Dirty Example:
In the United States, citizens have the right to vote. It is not a requirement but a civic right. And with this has become an often repeated concept. “If you don’t like how the country is being run, then vote. If you don’t vote, then be quit complaining.”
A real world example:
One of my project management jobs was in a global support organization. The job had two key components; ensure the support organization was ready for each software release, and feedback into future projects support’s experiences from supporting previous releases. This later responsibility was a constant challenge. We ran into roadblocks, barriers and just plain confusion. Some projects didn’t have a way to roll in lessons learned, others didn’t want any outside input, and so on. It made for many a long and stressful day.
So what did the support planning group do? We decided to be the most professional and helpful group humanly possible. We made sure our house was in order. We made our processes transparent, we published our templates, we communicated constantly in all directions and we adopted one of the most powerful tools in communication.
We stopped saying “no” and we started “yes, and”. It’s a trick I first learned in improvisational theater and one that made perfect sense when my boss suggested it. We no longer said “No, you can’t ship this it’s not stable” and instead said “Yes, you can ship and here is what we expect the call volume will be and how much those calls will cost.”
These two changes, openness and “Yes, and” made a dramatic change. In a few short months we had addressed more critical support issues than we had in years of prior work. And the more fascinating thing we saw, was how other groups started to change their own processes and procedures. It’s a bit thrilling when you see another department using a document that is clearly based on a template you designed.
We didn’t have real authority. We couldn’t change the products being built, we didn’t have the power of the purse that sales can wield so well. But we did know we were responsible for support being able to do its job and we took that responsibility to heart, being the best and most professional we could.
Conclusion:
No matter what our authority level, project managers can never surrender their responsibility. It is our job to help a project from point A to point B. We may be the CEO anointed leader, fully empowered to hire and fire at will, or we may have little more authority than updating the Gantt chart. In either case though, we have the power of influence, the power of experience and the responsibility to, at the very least, be the most professional and helpful person we can be.
We are the glue.
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
Like what you read? Then please tell a friend, tweet it, put it up on your wall, or send out smoke signals.

Effectiveness is the new Gorilla

– Or, saving time does not save work.
[Before we dive into another, great Gorilla, I’d like to ask a favor. If you find these blogs informative, please post a comment. If you find them really valuable, please tell your friends, tweet the link, mention me on your Facebook. The only way I know if my advice is helpful, is if I hear from you. – Thank you – ]
My head hurt. The stack of work before me could have doubled as a small skyscraper. No matter how hard I worked, I’d easily be pulling twelve hour days for the next two weeks. I had to find a way to be more efficient. I needed a way to speed things up, wipe a bunch of this work off my plate as fast as possible.
My eyes fell on the project training and adoption plan. It was the largest component of the communication plan for the project. It was a two hour, interactive training program that would ensure every single person involved in the project would be on the exact same page. I’d finally finished the slide deck. I’d just gotten the last sign off from the project stakeholders, that the training accurately covered all their needs and issues. I was now staring at the global calendar system in utter dismay. With people spread all across the globe (we have a coder in Antarctica, seriously?), it was going to take at least three weeks to roll out all the training. Then I’d have to compile all the questions into an FAQ, send that out and circle back with all the key stakeholders again. It was a nightmare, I’d be spending so much time on this, when would I manage the actual project?
Suddenly I had a triumphant idea. It was brilliant, it was easy and it was efficient! I’d cut three weeks off the planning phase in ten minutes! With glee I opened my email client. I found the email list I needed,  Division_Head_Honcho_All_Employees, I’d send the deck out to everyone with instructions to review it and send any questions they had to me. And to save time on hunting approvals down, I’d write the email so that if they didn’t respond, approval was automatically assumed.
Pure GENIUS!
<SMACK!> The banana careened off my skull and into my monitor, knocking my poor flat screen over like a high tech cow tipping.
Spinning around I shouted, “HOGARTH! What the hell was that for!”
Hogarth sauntered across the room, stopping to pick up the banana, and began peeling it. He took a large bite from the end, before waving the banana in front of my nose. “Let me ask you this. Suppose you’ve got one of those cute little Smart cars. You know the ones just a bit bigger than a carry on suitcase, get 43 miles to the gallon.”
I nod knowing anything else would potentially result in another banana to the head.
Hogarth continued, “That is one efficient car, no question about that. But if I leave the parking brake on, or let all the air out of my tires, then no amount of gas efficiency will make that car effective.”
Ah yes, the Efficiency is not Effectiveness Gorilla.
Frying eggs for my next four breakfasts, all at once, might be efficient but it surely isn’t effective. And I really won’t be looking forward to cold, fried eggs for the next three days.
Dictionary.com defines Efficient as:
Performing or functioning in the best possible manner with the least waste of time and effort; having and using requisite knowledge, skill, and industry; competent; capable: a reliable, efficient secretary.
It defines Effective as:
Adequate to accomplish a purpose; producing the intended or expected result: effective teaching methods; effective steps toward peace.
On the surface, they seem very similar. However efficiency focuses on the “least waste of time”, while effectiveness is about “producing the intended or expected result”. It doesn’t matter if you complete the three hour test in 30 minutes, if you only get ten percent of the questions right. You have been time efficient, but you did not get the desired result, to pass the test.
A Practical Example:
In a previous job I was responsible for managing the program to ensure a multi-hundred person team was ready for the release of a new product suite. The team had no control over what the product suite would be, but did have to make major changes to how it did business, what tools it created/used and how its people were trained, in order to be ready for this product suite release.
The program team for this project was over thirty people spread out over more than a half dozen global locations. Team members ranged from individual technical or process contributors to heads of entire teams that would have to support the new product suite. Of these team members, none was  above a senior manager role and the project sponsor was only a director. It was a challenge just to communicate with the team and the act of bringing them all into alignment and working to the same cause was daunting. At a fundamental level, the entire organization was going to have to change better than 40% of how they conducted their daily work.
Early in the project work I identified that the team was going to need proper decision making empowerment and end to end support. This required communication and buy in with well over a hundred individuals, ranging from the senior exec, of the division, down to individual subject matter experts. In an era of multi-thousand person ‘corporate initiative’ emails, it would have been very easy to blast out an email outlining the whole process, with a fancy hundred slide power point presentation to cover every contingency. I could have done this in less than a week and have not just those key one hundred people, but the entire division fully briefed on the project and what they had to do.
Very time efficient, and very ineffectual. Instead I spent a month focused on project initiation communication. I wrote individual emails, met one on one with people and created ‘commitment contracts’ from the VP on down to the SMEs. Everyone knew what their role in the project was, who they were accountable to, who was accountable to them and how communication would flow.
When the product suite finally shipped, the division was more prepared then they had been for any other release in company history. The war room set up to handle post release issues lasted only a week and was almost entirely focused on issues that cropped up from other divisions not being prepared. Quality metrics for the division, which had always gone done right after a major release , didn’t just hold steady but actually improved. The division knew more about this release than any previous release. Instead of spending the first three months learning, they were ramped up from day one.
At the end of the project, four weeks of work saved countless hours, dollars and people stress. At the project start, it didn’t seem to be a very efficient use of time but it was very Effective.
Being Effective:
Anoop Grover, a Silicon Valley IT project management expert, spoke at a recent PMI event on comparing Waterfall vs. Agile methodologies. At the event he said to the effect “I don’t care what method you use, what I care about is the outcome. Did I get what was intended.” He went on to balance this by stressing that any project must communicate clearly and often up and down the chain. At the same event, Jeff McKenna, Scrum luminary, shared a story that essentially boiled down to “Under this new model, you promise me ten features and always deliver at least nine. I also know that if you don’t deliver a feature it will be feature 10. I can plan to this and know what to expect.” If your senior management knows what to expect, then they have more trust, more trust makes for a much more effective organization.
When tackling an issue, ask your self what the desired outcome is. Ask yourself if the way you’ve been doing things is efficient or effective. Take the time to understand what your stakeholders and team want, expect and need.
You’ll save time, and bottles and bottles of antacid.
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 gorilla with too many hats


“So that said, can you code?”


I look across the interview table. Well okay I look at the telephone, cause I’m in the companies office but the person I’m interviewing with is sitting in his house 20 miles away. But that’s another gorilla.


So I look at the phone.


I look down at my resume.


I look at the job description for this job.


Apparently, my interviewer takes my stunned silence for a request for more information. “Cause you see, we’re running lean and we need people to do more than one thing. We might have to send you out to do a customer implementation by yourself. So how’s your coding?”


Now Hogarth doesn’t mind that the guy is on the phone. He’s taking advantage of that by taking up the other two chairs in the room. “Welcome to the Teens, dude. If you can’t do it all, then you’re not good enough. Everyone has to work harder these days. If you can’t code, do a balance sheet, fly to Malaysia for the weekend to close a sale and then get back on Monday to make sure the 300 person software roll out is on schedule, then you’re no good to them.”

Sigh… The “multi-hat gorilla”

Now Hogarth is right, to an extent. 2010 will probably go down as the year of ‘do more’. With the global recession we are all being asked to work harder and do more in our jobs. It’s part of the downside of the recession and the trend of higher productivity.

I’m all for productivity, but there’s a difference between productivity and continuous partial attention. As you might guess, I’m not a fan of the CPA concept. Studies have proven (UCSD Study, MSFT Findings, just to name the first two I Googled) interruptions seriously affect performance. A single 30 second interruption can result in a 15 minute work loss.

I look back at the phone, “I don’t code, that’s what the engineer is for. My value is in making it so the engineer can focus on his job and not on the surrounding project issues. If you have four engineers working on the project of this size, adding a fifth one is already starting to hit that wall of diminishing return. If you add a dedicated program manager, you can get more productivity from those four engineers, than you would from adding a fifth engineer and expecting one or more of those engineers to also manage the customer relationships, deadlines, certifications, interface with marketing, etc.”

“Uh huh….” came the reply from the phone. “So you don’t code?”

Some gorillas are just better to let be.

There is value in improved productivity and we’re doing more with less is the new norm. But all that said, a good, solid, project manager can make a team run more efficiently than just tossing another engineer on the pile. At least that’s what Hogarth and I think.

Joel BC
Veteran, the Project Manager wars
Want me to talk to your gorilla? Send me an email