Garbage In, Gorilla Out- Know "What" before "Do"

“What do you mean he said it’s crap?!?” Jake’s voice thundered. I’m pretty sure there was steam coming out of his ears. I could feel my own kettle on a rapid boil myself so Jack must have been at nuclear meltdown stage.  I turned and cast a sympathetic eye down the table. Poor, Bob, our hapless product manager looked like he’d just been served up as the main course at a great white shark feeding frenzy.

I’ll give him credit though; Bob didn’t cower in the face of our rampaging development manager. I mean after all, it wasn’t his fault, he was just the messenger. Bob nodded his head gravely, “he did. He went on to say it was lifeless, had no vision, was poorly put together and had no business being on the store shelf.”  Ouch… Fiat Armburger was the man. If he gave your product a pass, you could name your price with the channel. But if he panned you, might as well start selling the office furniture now.

Jake shook his head, a look of complete disbelief washing over him. I don’t think I’d ever seen him look so defeated. “We executed perfectly. We even shipped three months early. Hell! We delivered everything you asked for in.” His eyes turned back to Bob at the last words.

“I know, I know,” said Bob. “What can I say, we missed the mark. We’ll just have to try harder the next time.”

I jumped to my feet. “Well now,” I interjected, because if I didn’t Jake was going to levitate across the room and kill Bob with his eyeballs alone. “We have a stack of bug reports here. Bad review or not, we’ve got to fix these issues before GA. After all, we still have to ship, the schedule is committed.”

It worked, everyone calmed down and we got back to making the product ready to ship. I don’t know about anyone else, but all I could really do is wonder whether anyone would even buy it.

“Nope, it’ll be the worst launch since Ishtar.”

Great, just what I needed. A failing product and now a gorilla who thinks he’s a movie buff. Why me?

“Well cause it’s your fault.” Hogarth offered up.

I spun my chair to face my personal gorilla. He was lounging on the wall contemplating his naval (yes gorillas have belly buttons, Hogarth’s was large enough to misplace loose change in). “How on earth is it my fault?”

Hogarth looked up, producing a quarter from his naval. “Well technically it’s Bob’s fault, but come on doesn’t it get boring always blaming  the product manager?”

“Hogarth, explain to me how this is my Bob’s fault much less mine?” Though the idea of it being Bob’s fault was certainly more appealing to me.

Hogarth smiled, “G.I.G.O.” 

“I… what… ” I stammered. Then my mind realized what he meant. “Oh… my george…”


Garbage In, Garbage Out:

GIGO is a term that reaches back to the dawn of the commercial computer age. It’s a fundamentally simple fact that states  “computers  will unquestioningly process the most nonsensical of input data (“garbage in”) and produce nonsensical output (“garbage out”).” The overall concept goes back even father to early “computer” inventor Charles Babbage (now seeing a resurgence in fame thanks to the Steam Punk phenomenon) .

It’s hard to argue with the concept, in fact the software programmers I know wouldn’t even try. To them it’s like trying to say “Brick+Music=42”. It just doesn’t work. You have to use good inputs if you ever want to have good outputs.

So then, why the heck do we think the magic solution is in the development soup?

For the sake of this discussion, we’re going to take a scrum team. This problem applies to any kind of development process, from BDUF to XP. I’m using scrum because let’s face it, some of us have held it up as the golden ticket to solve all ills. So let’s see what happens when the golden ticket uses lead to develop.

The official Scrum Guide is seventeen pages long. Of those seventeen pages, about one page is devoted to the concept of a Product Backlog. This page covers that the product backlog is the Product Owner’s responsibility, that it is important, that higher stories have more details, that it should be rank ordered and that it should be regularly groomed.

You can groom a Canadian Hairless cat all you want, he’s still not going to win any beauty contests. A scrum team needs a good product backlog (requirements) to work from. If they don’t have a good backlog, then  they can ship the project on time, on budget and it will still fail because it was a bad idea to start with. New Coke failed because there wasn’t a need for it, everyone was happy with the old coke.

GIGO– If you don’t take the time to figure out what you want, then you won’t get it.

But, but that’s not agile! You’re saying I have to do big planning up front! See I knew agile was a crock.

Yeah, no…

You don’t have to document the Library of Congress, before you start a project, but you need to make sure you at least understand what the customer wants and have an end vision in mind. You then have to make sure that when the developers are getting ready to start coding, they understand EXACTLY what is wanted for that functionality. You can absolutely be agile in your product planning process. In fact, you can just be agile in planning and I think you’ll get a better project, even if development still builds in “waterfall.”

The Gorilla Planning Outline:

I found much of my inspiration in Jim Highsmith’s Agile Project Management: Creating Innovative Products. I heartily recommend the book for anyone involved in project planning or project management. Another good bit of inspiration came from Agile Learning Labs, a really great agile coaching and training shop in the San Francisco Bay Area. If I have stood farther, it is because I have stood on the shoulders of giants (Isaac Newton).

Note: This is an outline only. Within each stage I promote agile based exercises to get to the end goal.

The Cast:

Product Manager/Owner

Product Sponsor

Customer Voice/Representative

Architect*- Optional

Agile Coach/ Facilitator

*- An architect level technical person can provide valuable insight to this stage of the project. It is vital though to ensure this person(s) can separate business from technical constraints. An architect who is constantly focused on the how and how long will not add value to the process during this stage. The exception is in Stage 6, Estimate the Cost.

Stage 1: Defining the Product

Purpose: Create the “product box.”

Time Needed: Half Day

Description: Ensuring everyone thinks that blue is really blue is a fundamental starting point. If the product owner things you are building a Ford Pickup and the Sponsor is envisioning a Land Rover, you have a disconnect. This stage of product planning focuses on the overall corporate goals and customer “box” experience. The “box” experience is the level of experience you get when you pick a product up off the shelf and look it over. What compels the customer to buy? The core of these concepts comes from Jim Highsmiths’ chapter on Envisioning from Agile Project Management.

Stage 2: Layout the Product Story Outline

Goal: Create a timeline of the product’s use and identify missing gaps.

Time Needed: Half day to full day.

Description: “How did we forget that feature?” has been a long asked question, typically so far into the development process as to require derailing the project to get the feature in. Story Mapping is a process that discovers the users, the end to end experience and then allows you to drive into the highest level of user stories but doing vertical break downs.

Stage 3: Create the Chapters (User Stories)

Goal: To create clear and concise descriptions of user experience with the product.

Time Needed: Oneweek offline work, after Stage 2 and then half day.

Description: A poorly written user story can lead to the implementation of something that is technically perfect and a complete failure as it doesn’t meet the needs of the user, as envisioned by the product owner. A critical component of this stage is that even the highest level stories need a basic acceptance test to validate against.

Stage 4: Decompose the User Stories

Goal: Break large user stories down into iteration obtainable goals.

Time Needed: Half day (can be done with Stage 3 to save some time overall)

Description: One of the largest challenges in the creation of a backlog is to go just far enough with the details of a user’s experience and not to far that you’re creating a functional feature spec. Product Managers often struggle to not provide so much data that they are directing the engineers to a specific implementation – which can both stifle a creative new idea and can upset the engineers who feel they are being dictated to. Engineers who get too vague a story are faced with many challenges, not the least being “what exactly are we building,” “If I’d know that originally, I would have estimated this as a much bigger story,” and “This will take at least six weeks, I can’t do it in a four week sprint.”

By breaking user stories down to iteration manageable levels the team is able to better estimate value and cost (time to complete), removes confusions that can result in a feature that doesn’t match the vision of the product owner, allows for shorter iterations – which itself improves the overall development process by allowing more chances to apply the “inspect and adapt” philosophy of agile.

Stage 5: Value the User Stories

Goal: To create a relative ranking of all user stories on a project.

Time Needed: One to two hours

Description: P0, P1, P2 ultimately breaks down. Fifteen years ago I never even heard of P0 and you might actually see a P3 in a product. Today you see projects where everything is a P0 and engineering says it will take two years.

Doing force ranking, feature weighting and other traditional techniques rarely leads to the level of consensus required to create a final ranked list. The realistic question to ask teams, at this stage, is how often estimating against real world artifacts has worked. When was the last time a product forecast was accurate? Using agile values opens up the process to creating a system that creates agreement not conflict.

NOTE: This is one of the secret sauces of this process. In my next blog I document an excellent exercise for how to define business value for an entire release in just a couple of hours.

Stage 6: Estimate the Effort (Cost)

Goal: Rank the user stories in relative order of effort (cost to produce).

Time Needed: One to two hours

Description: Classic estimating of user stories. It needs to be done on even the grossest level stories for the product owner to be able to properly rank order the backlog. Otherwise a backlog can be skewed towards value, costs or even worse, gut judgment. Poker Planning and Delphi models have an inherent flaw of focusing on the story itself which leads to exact effort and not rank ordering estimates.

The Cast: This stage does not involve the product owner/stakeholder cast. Effort estimating is done by the engineers doing the actual work. It is important to not just have management at this stage but engineers doing the functional work.

Note: The developers should not have knowledge of the business value rating at this stage. They are just assessing the complexity of the future. If they know a particular feature is the absolute silver bullet, they may over or under estimate it.

Stage 7: Order the Requirements List

Goal: One backlog to rule them all.

Description: At this point the Product Owner has both a business value and a cost. These are both placed on the user stories. From here the product owner then uses their judgment and skill to create the product backlog. They weigh the value and cost of a story (feature) to create the backlog.

Note: In agile development, best practice is to groom the backlog once iteration with the product team. This is where cost can be reevaluated, better definitions of stories can be done and the product backlog reordered as a result.

Power to the Gorilla! – Or, I passed the PMI-ACP now what?


Oh life was good, oh so good. I read the email one more time before leaning back in my seat with a self-satisfied grin. I even went so far as to kick off my shoes and toss my feet up on the desk. In a bygone decade I would have pulled a cigar from my pocket and lit it in a self-congratulatory act of hedonism. Instead I satisfied myself with lacing my hands behind my head and staring at the ceiling with a happy grin. Absolutely nothing could ruin my good mood, nothing!
My door opened, allowing a deep voice to fill the room. “Ding… Third floor, housewares, bedding, inflated egos…”
Okay, almost nothing. “Go away, Hogarth, I’m not letting you spoil my mood.”
I could feel Hogarth lumbering into the room but I didn’t turn my starry eyed gaze from the ceiling. I herd the snap of Hogarth breaking another branch off my poor fichus and didn’t fret over it one bit. I’d just get another plant, it wasn’t a big deal. Nothing could ruin my mood.
“Why would I want to spoil your mood?” Hogarth said. “I mean its not every day you earn a coveted inaugural slot in what’s likely to become one of the industries influential certifications.”
I kicked my feet off the desk and brought my gaze down to my fichus nibbling gorilla. “Really? You’re not here to tell me about some monumentally stupid thing I’ve done? I haven’t overlooked some gaping field of land mines, stepped on the toes of someone important?”
Hogarth shook his head, “nope, nothing like that.”
I leaned back in my chair with a cheerful grin. “Yeah, it is pretty special to be on of the first hundred GOPHRs. I mean just getting into the Global Operation Project Handler Registered pilot program was an achievement. Passing the test was pure gold and now I have arrived!” I pumped my fists in the air to punctuate my last words.
Hogarth didn’t say anything at first. He carefully finished pulling a long strip of bark free from the branch and sucked it in like a piece of spaghetti. Finally he looked up from his branch to look at me, my arms still raised ridiculously in the air. “Okay, you’ve arrived. Now what?”
“Huh? I’ve arrived. I did it. This is my ticket.”
Hogarth nodded, “I see. But what are you going to do?”
“Do?” I stared at him perplexed.
He nodded again. “The price of greatness, is responsibility.”
I threw up my hands again, this time in annoyance. “Hogarth! Don’t spout Spider Man at me.”
“Not Spider Man, Winston Churchill.”
Having isn’t Being
On January 10th I was informed that I had passed the PMI-ACP  certification exam and am now a certified PMI-ACP retroactively as of October 10, 2011, the day I took the test. Yes, I’ve been a PMI-ACP for three months and didn’t know it. By the numbers I’ve heard reversed engineered, there are currently a little more than 500 PMI Agile Certified Practitioners (as of January, 2012). In comparison there were between 300,000 and 400,000 certified PMPs worldwide in 2011.
So what’s it like to be one of the first? Well there was no balloon drop. Ed McMahon didn’t show up on my doorstep with the Publisher’s Clearing House check. In fact it doesn’t really feel all that different. Now perhaps having three months pass from test to result lessens the anxiety, but I had none of the elation of seeing “You passed” on the screen when I received my PMP.
One thing did change though. Responsibility…
Now this is not a word I am unfamiliar with. Hogarth and I discussed the responsibility of project managers in a past blog. Still being one of the first to hold the PMI-ACP has caused me nearly as much reflection in a week as I have done in the many months on it since it was first announced.
I first blogged on the PMI-ACP with the “Potato, Pahtato Gorilla” in March 2010, where I talked about why I saw a value in the certification. While not directly discussing the PMI-ACP, when Hogarth played poker I stressed that a certification isn’t the silver bullet it is just what shows people you should know what you are talking about. In my Lemming Blog I bemoaned how bad training could be a death knell for the certification. And finally, my last blog was a retrospective on my experience with the certification process. In addition, a good chunk of my blog this last year covered agile topics in large part because of my involvement with the certification process.
And through all these blogs there are some common themes that come back to responsibility.
And now that I have the certification, I know it’s my responsibility to live up to both the certification and to Hogarth’s maxims of speaking to the unspeakable. As one of the first 500 I have a certain responsibility to project management, agile and of course myself.
So with that, some specific thoughts being a PMI certified agile practitioner:
How do I fit in the overall agile community?
So how will we ACPs fit into the overall agile community?
Great question. Even more so than the PMP, it is no magic bullet. There are agilists that won’t have anything to do with me just because I have an ACP. Agilists that think certifications are just proof you are part of all that is wrong with product development.
Then of course there are companies that know very little about agile and my having the ACP isn’t going to be some spear and magic helmet. The reputation of PMI will lend it some credence, but at the end of the day what matters is my own work product.
For a large swath of the agile community I think what the ACP is going to do is to raise peoples expectations. If I’m a certified agilist then I better damn well know what I’m doing, right?
In the long run, it will be what certified ACPs do that will determine where we fit in. Which brings us to…
Representing the certification.
Going back to the Winston Churchill quote, there is a lot of responsibility that comes with being a trailblazer. If I’m the guy walking through the minefield, to find the safe path, then I darn well better not miss any mines. If I make it to the other side, but the team gets blown up, then I’ve failed. Because being and agile project manager isn’t about me, it’s about the team.
Being one of the first ACPs means I’ve have to be a lot. I’ve got to be an agile coach, agile mentor, agile evangelist and most importantly, I’ve got to be agile.
I guess it’s a good thing I already felt I had to anyway. If I had to change to live up to the certification, then I shouldn’t have been given it in the first place.
Wow, so all sweetness and light? Sounds like you drank the PMI Kool-Aid.
I don’t think I have. If I did, someone slipped it into my coffee. No, I’m won’t change who I am for this certification. I think the ACP fits who I am. It’s not to say I don’t have issues with it and that I won’t raise my concerns.
The Name: PMI-ACP
I’ve not received my super dooper, official certification packet yet, and searching PMI’s website is like trying to get a straight answer in a political debate, but as near as I can tell the official way to represent my certification is “PMI-ACP.”
Really? Look, guys I’ve already got enough three letter acronyms behind my name to cause enough issues (PMP, CSM, CSPO, CSP). Giving me a seven letter one? Even the most storied professor of Oxford is going to just have three letters behind his name (PHD). Now I have to use a seven letter TLA? Heck, my TLAs are now longer than my entire name and that’s no mean feet with my name.
There’s only one other body out there giving out agile related certifications and those all start with CS, so I don’t think anyone’s going to be confused with plain old ACP. If you’re worried that folks won’t know where the certification came from, then do more marketing.
Seriously, I’ll be referring to it as the ACP. I doubt anyone is going to mistake me as the “American College of Physicians”
Beware Prep Courses :
I’ve already referred to my Lemming Gorilla blog, but this bears talking (okay maybe it’s a rant now) about. So let me climb up on my soap box for a minute.
Virtual doesn’t cut it: I know, I know. It’s a brand new certification and finding training isn’t easy right now. The thing is, one of the key principles of agile is about the value of co-location. Yes, in a lot of real life use cases you’ll be dealing with virtual teams, but when you are first learning agile you want to experience it first hand. You want to get into hands on exercises with fellow students. You need to focus when you’re learning (We’ve all read email while watching WebEx training, admit it). Let me ask you this? Do you want your airline pilot to have learned by mail order? You need to learn agile hands on.
PMP Prep Course Shops:  You can’t swing a dead tuna without hitting a PMI approved trainer for PMP prep courses. Some of them are very good, some of them are little more than test mills. And with all of them you need to look very closely before taking a ACP prep course from them. The PMP is a long standing certification with a unified body of knowledge. The PMP is also a certification for a multi decade profession. Most of us who study for the PMP already know project management really well. We spend more time learning the “PMIisms” than we do learning new. For the PMP, prep courses that are designed to help you pass the test make some amount of sense. I’ve still got a lot of issues with the ones that care only about getting you to pass the test, but that’s a soap box for another day.
The ACP is new. The ACP is based on a very diverse body of knowledge (Ten years of structured agile, over sixty years of lean, something in between for many concepts we now call agile, and over ten books in the official PMI study guide. ) The concept of “Agile Project Management” is still relatively new, despite agile concepts being really old.
If you haven’t been using agile, if you don’t understand it and see the value, dare I say if you don’t believe in it, then taking a three day prep course that gets you to pass the test is going to be the greatest disservice to you, to PMI and to agile as a whole. With the PMP, you need to learn the PMI way of thinking. With agile, you need to be agile.
So check out the credentials of any training shop you look into. Check their agile credentials. The one I talked about in my past blog had found a CSM willing to help them, but the company itself didn’t have any agile background. If their sales pitch has anything to do with “It’s the next big thing,” or “Get on the bandwagon now,” walk, don’t run from the place.
You can do it yourself: If you’re an agile veteran, like the Agile Scout you probably don’t need to even study. Compared to Peter I’m a rank amateur in agile with barely enough agile project hours to qualify for the exam. Yet I didn’t take a prep course. I had a stack of books, Wikipedia, Google and sample questions (Edit: Jan 20, 2012: At this time I cannont recommend the use of the Agileexams service) . I knew agile, I just needed to spend some time getting familiar with the common language that exists out there.
PMI is paying attention: One thing I really give PMI credit for, is being responsive to this. Rory McCorkle is the product owner for the PMI-ACP certification and product manager for the PMP certification. He’s been very approachable since the beginning. So I took the issue of Test Mills to him. He told me that PMI is very focused on this and wants to ensure that the ACP doesn’t turn into an test mill. He even encouraged me to report a test mill if I thought they were not being ethical about their practices. There’s those ethics again.
Full Disclosure: I have talked with someone about building a prep course. If I did, I would build it on the principles of agile and it would be designed to codify agile, not get you to pass the test.
So at the end of the day, does it mean to be a PMI certified agilist?
I don’t have super hero cape, I didn’t find the secret to untold wealth, It didn’t change me into something else.
At the end of the day it’s a validation of who I am and what I’ve been doing since I added agile to my personal toolbox.
Joel Bancroft-Connors, ACP
The Gorilla Talker
Want me to talk to your gorilla?
You can follow me on twitter, @JBC_PMP

The Gorilla changing room- Making decisions out of choices

“WAIT, WAIT, What?”
Bob hasn’t been handling stress to well lately. His last word broke into a near falsetto and the tick above his eye was threatening to register on the Richter scale.
Monica didn’t seem the least phased by the outburst. I think it would have taken a good 9.0 to shake the plastic smile from her face. “Marketing thinks Pantone Snorkel Blue 19-4049 is not the right shade for the logo on the case. We want to look at Dark Blue 19-4035 instead.”
Okay, so I have to admit Bob was probably justifiably upset. Me, I was having an odd sense of déjà vu.
“Excuse me, Monica, but didn’t we go over the logo color about three weeks ago and all agree on Snorkel Blue?” I asked, trying to give poor Bob time for his blood pressure to get back down under 200.
Monica gave a casual wave with her absolutely pristine fingernails. “Well, yes, but marketing wasn’t sure then so we didn’t say anything.”
If Monica kept talking in the third person I might just snap myself. “Okay, we are starting mass production in a day. I’m not even sure we can change the color. Wally?” I turned to look at the head of our hardware team.

Wally looked at me with a pained expression that didn’t need words. If they had words, they’d probably been something like “I’ve had our manufacturer change the blasted logo color seven times, how many more do you want to change it?”
Monica gave a dismissive wave to Wally. “Marketing feels certain that the color has to change, can’t you just speed up the shipping process to cover?”
Bob leaned forward, smoke veritably curling from his ears. “We already chose the color, five times. If you can’t be bothered to attend the meetings because you are to busy getting your forehead botoxed…”
Hogarth sidled up to me, his hot breath on my neck the first clue I had to his nearness. Thing is I wasn’t surprised. The meeting was going just so many different ways of wrong that I knew he was bound to show up sooner or later. I guess you could say I was starting to learn and understand his presence. His appearances were no longer absolute surprises of non-sequiturs.  I could almost hear the lesson he was about to give.
“So does this make you Bill Murray?” he asked.
Blink… Huh? Blink… Blink… That was not the lesson I was expecting.
I turned away from Bob’s latest fusillade at Monica and stared at Hogarth. His brilliant white smile was in counterpoint to his bushy black eyebrow raised at me in question. Sometimes I think he truly takes pleasure in confounding me to speechlessness. “Hogarth, what on earth are you talking about?”
Groundhog day of course. You know, the film with Bill Murray reliving the same day over and over until he gets things right?”
“Hogarth, it’s not February, I’m not Bill Murray and what the hell does this have to do with the meeting.”
“Well didn’t you already decide on the color of the logo five times?”
“No, it’s been seven…” Hogarth just looked at me.  “Oh, hell.”
There is a malaise sweeping business, from San Francisco to Sydney and Johannesburg to Edinburgh the same problem is rearing up to prevent companies from succeeding, from moving forward, from getting anything done, from not killing each other in meetings of death, from doing the right things, the right way. What is this frightening cancer? What is this thing that is able to crush your projects and leave the teams wondering what was the license plate of the bus they were just thrown under?
We can’t make decisions… To be clear, we are very good at picking choices. We are wonderful at nodding heads and saying “yes” but we are absolutely abysmal at making and committing to decisions. When it comes to putting the rubber to the road, we are found to be lacking even the tires needed to hit the road.
Wait a minute. You just said we are very good at making choices, what’s the problem?
A choice is not a decision: A choice is picking someone to ask to prom night. A decision is saying “I do” to marry your spouse. When you go to Baskin and Robbins (A US based Ice Cream store) there are thirty-one choices of ice cream, but there is only one decision as to what you’ll get on that single scoop. A decision is a stake in the ground with clear accountability tied to it.
Accountability… There’s that scary word again. Don’t run away, it won’t bite. Accountability is easy. It can be fulfilled with Mark Horstman’s single law of project management., “Who, Does What, By When.”
You see, what so often happens is that everyone is sitting in the room and a plan is developed. People nod their heads, and maybe the guy who was really opposed decides now is not the time to object. But then there is no follow up. Sure it might have gotten documented in the meeting minutes, but no one was assigned ownership. No date was set. No specific plan was set. How do we know if it is done? How do we know if what was agreed is what is being done? How do you measure the “acceptance criteria?”
If a choice was made, you don’t. If a decision was documented then you have.
Hey now! Don’t run scared just because I used the “D” word. Documentation does not need to mean a twenty page requirements document. Documentation just needs to be “Who,” “What,” “When.” The only hard part is the what and if you define what by the acceptance criteria it can be pretty darn easy.
You have the power! Stop the déjà vu cycle! Don’t go through another Groundhog day again. Don’t let a meeting end without “Who,” What,” and “When” being written down and agreed to.
Change isn’t a bad thing. But changing because you didn’t agree the first time is a waste.
Joel Bancroft-Connors
The Gorilla Talker
Want me to talk to your gorilla?
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

Methodology roulette, always bet on Gorilla

This blog originally appeared on 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.

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 Failed Gorilla: Just because you failed doesn’t mean you didn’t succeed.

Photo Courtesy of:
It was like rearranging deck chairs on the Titanic. No matter how many times I moved the boxes around, the data still showed the damning truth. Failure. The project was a failure and there was no amount of lipstick I could slap on it to make it anything else. The executive review was going to be painful.
“FORE!” A golf ball whizzed past my head and shot out the open window. All but picking myself up off the floor I shot a look out my open door. Cheerfully striding down the hallway was Hogarth, wearing the most ridiculous golfing outfit I’d ever seen in my life. All right, the outfit wasn’t so bad, but on Hogarth it was awful.
“Hogarth!” I snapped.
Ignoring me, he cheerfully swept into my office and over to the open window. Casting a critical eye out the window he gave a dissatisfied grunt. “Dang, I was hoping for an eagle on that hole. Be lucky if I make par.”
“HOGARTH! What on earth are you doing?”
He turned and offered me his ivory smile. “Practicing for the launch party golf trip, of course. This is going to be so fun!”
I buried my head in my hands. “Hogarth,” I muttered from the depths of my palms. “There isn’t going to be a launch party.
The project is a failure.”
“The project the customer is using right now?”
I nodded, “Yes, that project.”
“Maybe I’m dense, I mean I’m just a gorilla, but isn’t shipping to the customer a definition of success.
I threw myself back in my chair and cast my arms in the air. “The Project was a failure! We shipped a full quarter late and went over budget by fifteen percent!”
“The customer is so happy they are doubling their order and you’ve failed?”
“Yes! We failed to ship on time and on budget. That’s two of the triple constraints. We failed!”
“Huh,” he grunted. He took a seat on the corner of my desk, eliciting a groan of protest from it. “I’m not sure I’m following you. The product shipped, the customer is happier than ever and they are planning to order more and that’s a failure?”
I nodded. 
“Hmm, okay. Let’s take a new approach. You remember Apollo 13. Was it a success or a failure?”
“It was a success; they all made it home alive. You can’t argue with breathing.”
“Yeah, but they were supposed to land on the moon…”
“Who, cares about landing on the moon! They lived.”
There are dozens of stories about the stunning percentage of projects that fail. And yet we still do projects. You’d think with ratios upwards of 80% project failure that whole departments would be getting shot on a daily basis and a lot more companies would be going under every week than actually do. So why doesn’t this failure have a greater impact.
Just because you failed, doesn’t mean you didn’t succeed. Just because a feature is broken, doesn’t mean it doesn’t work. So tied are we to the infamous Iron Triangle of Cost, Schedule, and Scope, that we often lose sight of two of the most important things.
Are we delivering value to the customer?
Are we delivering value to the business?
Whether you use Agile in your development process or not the value of communicating with your customers just can’t be overlooked. When you communicate and communicate often, you will find the needs of customer shifting. This can drive many folks mad, as they try and keep features locked down and fixed. But at the end of the day we are selling the product to the customer. If we build it exactly to the original specifications and that doesn’t meet the customer’s needs, then you’ve got a real failure.
What’s a bigger failure? Being three months late, but the customer is happy. Or being on time and the customer doesn’t want the product?
Make sure you are in touch with your customers, internal and external and don’t let the Iron Triangle sink you to the pits of despair.
Joel Bancroft-Connors
The Gorilla Project Manager
Want me to talk to your gorilla? Send me an email
You can follow me on twitter, @JBC_PMP

How is a Gorilla Project Manager like R2-D2?

“So what do you do?” 

See, this is why I hate dinner parties. Now if I was a doctor, a pilot, heck even a mechanic, it would be easy. I’d just say it and we’d move on to the meaningless small talk portion of the evening. But no… I had to decide to become a project manager, even worse an agile project manager. With a deep internal sigh I sized up the person who had just asked me the question. 

Neil was nice enough, but I could already tell it was going to be an uphill battle. He was the neighbor of the host who was a friend of my wife’s. I already knew Neil was in Real Estate (he’d left a stack of his business cards in the bathroom), I didn’t relish the next few moments.  

“I’m a project manager.”  

Neil cocked his head to the side. The look of confusion on his face was all too familiar. Taking a breath I tried to explain. I don’t know why I did. It’s not like I’d ever had any success before. And yes, I’ve tried the “I heard cats for a living.” I really didn’t want to be asked what circus I worked for again.  

“I’m responsible for managing the scoping, planning and execution of project deliverables with a cross functional team in order to get a product shipping.”  

“Oh, so you’re a manager?” Neil asked. Of course what he was really asking was if I was in charge of people. Why is it that a measure of your worth is how many people call you boss?  

I shake my head, “No, I don’t have direct reports. My job is to facilitate the project and help the core team deliver.”  

“Like a hostage negotiator?”  

I sighed. Smiling, I nodded my head. “Yeah, just like that.”  


I wasn’t even going to try and explain how agile project managers were more like coaches. Not being a sports fan myself I didn’t want the conversation to go down the rat hole of how I thought the local pro sports teams would do this season. 

Just then I spotted a dark shape duck around the side of the house. Hiding a groan I excused myself from Neil and left the smell of BBQ cooking on the patio behind me. Coming around the corner of the building I found what I feared most.  

“Hogarth, let go of that branch.”  

Hogarth turned towards me still holding onto a large branch sticking out from the tree in the side yard.. “This is an Arkansas Black apple tree, do you know how rare those are?”  

“Hogarth, you can’t eat that tree, it’s not yours.”  

He gave a sigh and let go of the tree. “Fine…” He flopped to the ground and picked at the overgrown lawn. “You won’t begrudge me a little grass, will you? I’ll give you the secret of explaining your job.”  

“Hogarth, I’ve been a project manager for years. There are even people in my company that don’t have a clue what a PM is.”  

Nibbling some of the green grass he looked up at me a smiled a toothy white grin. “That’s ‘cause you never told anyone that you’re R2-D2.”  



R2-D2 – Robot side kick to the Skywalker’s of Star Wars and Agile Project Manager: He’s not the hero of the show and he’s never been a leader, but it would be hard to imagine the Star Wars universe without this plucky little trashcan on wheels. But what does R2 have to do with being project manager? 

Everything! R2 is the ultimate Agile Project Manager. Or perhaps we project managers are the ultimate R2 Astromech droids.

R2-D2 knew all about responsibility without authority: Princess Leia, his project sponsor, assigned him the project but gave him no resources to do it with. He even had to track down the product owner for more information. He enlisted C3PO on the force of their relationship alone. As the project progressed he collected more resources on influence or by working with his project team.  

R2-D2 understood that project requirements change: When his sponsor first gave him the project it was very simple, get this message to Obi Wan Kenobi (his product owner) so that Kenobi could stop the Death Star. But he knew the requirements would change. He didn’t demand a full list of requirements before he headed for the escape pod. He was confident that future backlog grooming would reveal more requirements. He also knew that iteration planning would break the epic scale user stories down into smaller stories and tasks. So he started the first sprint with just a couple of user stories. Engage existing resources. Get off the Ship. Don’t get shot.  

R2-D2 knew how to motivate his teams: When R2 met Luke Skywalker, he knew who the boy was. He leveraged past project retrospectives for that (Okay, he was in the first three movies). So with that in mind do we really think he accidentally showed Luke the holo of the princess? Heck no! He remembered that Obi Wan told Senator Bail Organa he would watch over the boy. So by revealing the holo, not only would he possibly find a clue to where his product owner (Kenobi) was, but also could motivate the young man to help the project.  

R2-D2 knew his job was to guide the use of proper process, but also knew that sometimes you trust your team: Process said you used a targeting computer when firing a proton torpedo. But he chose to trust his team member, Luke, when he turned off the computer. Good thing he didn’t stick to rigid process enforcement, right?  

R2-D2 knew all about removing impediments: Shut down the trash compactor. Fix the hyper-drive. Stop the elevator from falling. Shift power to the rear deflector shields. Open this door. Put C3PO’s head back on. Put C3PO’s head back on, again. When his project team encountered an impediment he jumped right in and owned clearing that impediment.  

R2-D2 was the ultimate servant leader: R2 knew exactly what needed to happen. After all, he’d been working on related projects since the Phantom Menace. By the time it came time to destroy the Death Star, good old R2 knew all the players. He could have told Luke that Vader was his dad on the first day they met. But he didn’t. He knew he had to let his team member discover some things himself. Instead he carefully guided his team member on the path. 

He was never the hero, but he always saved the day. He worked quietly and tirelessly in the background to ensure all went well. Emperor Palpatine may not have known who he was, but his team did and they appreciated him for his efforts. 

So you see, the next time someone asks you what you do for a living. Stand up proud and declare. 

“I’m R2-D2.”


The Angry Gorilla: Emotion is your choice.

Photo from Wikipedia

“I CAN’T BELIEVE THE NERVE!” I stormed into my office, barely catching the door before I slammed it for all it was worth. I compensated for the averted door slam by tossing my notebook across the room. Stalking after it, I noticed Hogarth reclining in the corner of the room. I didn’t even look at him, I was in no mood to have my head shrunk by a pseudo- imaginary gorilla who’d watched one too many Dr. Phil episodes. “Don’t even start, I am NOT in the mood.”
I threw myself into my chair, threatening to topple it over in the process. I glared sightlessly at my computer monitor. I was too agitated to even scan my recent emails. It was all I could do to not grab the monitor and throttle it like I wanted to throttle Bob’s snake-like next. Finally I calmed down enough to scoop my battered notebook up off the floor.

Photo by astrogrl –

Sitting back up I noticed Hogarth again. He was sitting in the corner of the room, not speaking or moving. He just sat there calmly looking in my direction. I snorted and tossed my book on the desk. “Not gonna work, hairball. You can’t fix this with a few pithy sayings and making me twist my mind around to look at itself from behind.”
Hogarth just sat there, unblinking. His placid face betrayed no hint of emotion.
I grunted and turned to my computer. I might as well get some work done.
Five minutes later I threw up my hands in surrender. Turing to the still silent Hogarth I said, “Fine, you win!”
Hogarth didn’t respond. He just laid his hands in thighs and cocked his head to the side.
“The team just demoed the product to the CEO. He was really impressed with how the workflow was improved. He said ‘Best damn idea I’ve seen in a long time.”
Hogarth just blinked. Still I could hear the question. “So? So Bob took credit for it. Complete and total credit for it. The lily livered slime bag had the nerve to take credit for the work!”
Hogarth just looked at me.
I sighed. “Bob’s idea for the workflow was a miserable failure. The team tossed it out and came up with something from complete scratch. Sure it fit Bob’s stated user requirements, but it had nothing to do with Bob’s actual ideas.” I smacked the table in frustration. “And there wasn’t anything I could do about it. If I’d told the real truth, it would have looked like I was tossing Bob under the bus. He may be a spineless product manager, but I’m not going to lower myself to that level.”
I clenched my fists, fighting back the desire to pound on the desk. “Oh he makes me so MAD!”
And then Hogarth finally spoke. “No, he did not make you mad.”
“What?” I stared at my gorilla with blatant incredulity. “I’m furious. I damn near took the door off its hinges and I think I dented my desk. How the hell can you say that Bob didn’t make me angry?”
Hogarth spoke, his voice calm and Yoda-like. “Anger you, Bob did not. Chose to be angry yourself, did you.”
I shook my head, not sure I’d heard Hogarth clearly. “Hogarth, he just took credit for the entire project and you want to tell me he didn’t make me mad?”
My gorilla nodded his head. “Yes.”
“Have you been sniffing the white out? That’s the most ludicrous thing I’ve heard you say all month. How on earth is it he didn’t make me mad?”
Hogarth folded his hands in his lap and leaned back against the wall. Speaking from under half-lidded eyes he said, “between stimulus and response, lies the ability to choose.”
“Really, Hogarth, you need to stop buying self-help books at Kmart. What quack shrink said that?”
Hogarth opened one eye and looked my way. “Stephen Covey.”
Anyone who’s ever said Project Management isn’t a stressful job probably defines fun as “poking hot needles in their eyes.” Project Management can be high stress, high conflict and highly political. Mark Horstman,, points out “What junior employees call politics, executives call doing business.”
So the stress and conflict are part and parcel to the job we do. What we do about it though, is completely in our control.
Stephen Covey says in 7 habits of a Highly Effective Person “Between stimulus and response, lies the ability to choose.” It is the kind of phrase you might expect from a Zen master or Yoda and in his own ways, Covey is the Jedi teacher of business. It’s an incredibly simple concept and as powerful as it is simple.
We project managers are bombarded from a hundred different angles every single day. We face reluctant teams, self centered sales reps, political managers, oblivious executives and more. At least that’s what we tend to describe them as when in reality we are dealing with teams that are unsure of next steps or feeling insecure with their positions, sales reps that are paid to make sales and if they don’t they don’t get paid, managers who recognize business is a series of give and takes and executives that must make a hundred decisions a day to keep the company moving and you probably are only aware of three of those.
Human nature is pretty quick to assign emotional content to everything. Being an effective project manager means focusing not on the emotions but on the behaviors. Behaviors are the words one says, how one says them (tone and inflection), facial expressions, body language, and work product (timeliness, quality, documents, delivery, etc.).
  • Bob’s slouching in the meeting, that must mean he doesn’t care about the project. No, what it means is Bob got two hours of sleep last night because his son fell off the porch and broke his arm. Bob was in the ER until two in the morning.
  • Mary just wrinkled her nose. She thinks your idea is horrible. No, Bob smells like a sweat sock and Mary has a really sensitive nose.
  • Alexi just called the project “bad and bloated,” he’s being insulting and condescending. No, Alexi is a native Russian speaker and he watched an urban comedy last night. He meant to say “phat” not “bloated” and was trying to say he thought the project was “cool.”
Once we recognize that we should be looking at people’s behaviors, without assigning emotional bias, then we have to start working on our own response. Maybe Bob did intend to completely undercut you and hog all the glory. Is slamming your door and breaking your desk going to make things better? Will your boss blame Bob for having to shell out money for a new computer monitor? More importantly, will anyone want to work with you? Bob may have been underhanded and greedy, but you are the one and only person responsible for your response to his actions.
Being a great project manager means taking the high road, a lot.
Just remember “The man poking you in the chest does not make you angry. You make yourself angry.”
Joel Bancroft-Connors
The Gorilla Project Manager
Want me to talk to your gorilla? Send me an email
You can follow me on twitter, @JBC_PMP

The patient Gorilla: When Risk Management means you wait

“Listen, Jake, I need something here.” I leaned in over his desk, doing my best convincing look..

The development manager shook his head. “We’re in the middle of a sprint. When the sprint is over I can pull Eric from the team for the next sprint and have him focus on this.”
I sighed. He was right. No matter how important this was, we were in the middle of a development sprint. We couldn’t pull someone from the team like that. I nodded, “Thanks, Jake. I’ll touch base with you next week, after the Sprint Demo.”
I sulked back to my office, chewing my lip. In a week things could change completely. In a week it might not matter or worse it might be a total disaster. I turned around twice, intent on demanding Jake do something right now. Each time I only made it two steps before turning back. There wasn’t anything that could be done right now, not without tossing the entire project into chaos. But… But…But… There was no way I’d be able to concentrate on anything else for the rest of the week.
With an ulcer slowly building I walked into my office. Hogarth was sitting in the corner, a branch from my nearly dead fichus held limply in one hand and a parchment gripped in the other. Making a mental note to buy a new fichus I dropped into my chair. “What’s with the royal decree? ” I waved towards the parchment in Hogarth’s hand.
He looked up. Pointing with the hand holding the branch, he nearly impaled the parchment. “It’s a notice of my reality review. It’s tomorrow.”
“Reality review?”
Hogarth nodded. “Every year. It determines if I continue to exist. Or, if like Descatres when he was asked if he wanted another drink and said “I think not,” I disappear in a puff of unreality.”
I blinked trying to wrap my head around the absolute ludicrous idea that Hogarth could just vanish in a puff of smoke. It was as absolutely incomprehensible as… I looked at my personal gorilla again and shook my head. Right, as unreal as a manifestation of my own conscience as a physical gorilla.  With my brief bout with reality past I returned my attention to Hogarth.
“But, that means you might not be?”
Hogarth nodded. “Ayup.”
“What can you do?”
Hogarth shook his head. “Nothing, the review is based on my past years existence. This is just the findings, they’ve already made their decision.”
Neatly avoiding the whole “who are they?” issue, I said. “Nothing?” Oh, that was brilliant! Way to state the obvious.
Hogarth nodded. “Yep.” And then he calmly rolled up the paper, put it away (don’t ask, I know he doesn’t have pockets and I try not to think about that) and began pealing the bark from the fichus branch. “Oh well, I’ll find out tomorrow.”
I blinked again. ‘Oh well?..’ “How can you not be stressed about this? What are you going to do?”
Hogarth shrugged, “Right now? Nothing.”
“Nothing?” I yelled. “How can you sit there and do nothing? Your very existence is on the line.”
Hogarth nodded. “Yep.”
“And you’re going to do nothing?”
Hogarth rubbed his chin with a leathery hand. “You know, you’re right. There’s this new vegetarian Vietnamese  place down on 5th. Maybe I’ll give that a try.”
My first response was almost over powered by the desire to ask how a gorilla intended to be served in a public restaurant, but the first response won out. “Dinner? How can you be thinking about eating right now? We need a plan, we need to do something!”
Hogarth gazed at me with his deep-brown eyes. “Do what?”
“Well, umm… Ahh.” 
Hogarth said, “Can I do anything about it right now?”
I struggled to find a different answer, but in the end I shook my head. “No. The review is tomorrow and they already made their decision.”
Hogarth nodded, “Yep. So I’m going to go have a nice dinner. Tomorrow will come, when it comes and I’ll find out then.”
Just like the sprint would end at the end of the week…
Managing risk can be a study in Pepto-Bismol. So many factors can impact a project that one can go quite literally risk blind with all the potential impacts to your project. Even if you avoid the “acts of nature” like earth quakes, terrorist attacks, total global meltdown, you can quickly spiral a risk register into the dozens of entries, all of them a major potential impact.
This post isn’t about risk management. While I have a lot to say on the subject, this post deals with risk management gone wrong. Once you’ve done your risk management, you have to have a certain amount of trust in your work. Okay, you’ve identified a major potential risk. If it happens, it will happen in three months. You’ve put in place a mitigation plan, you’ve put in avoidance plans. Now what?
It’s three months away, stop worrying about it. Review it during normal risk reviews, but don’t let it consume you.
This extends beyond just traditional risk management. It goes to every aspect of a project that you have no control over.
If we had four new headcount, that would solve our schedule issue. But you know that there is no way on earth the company will hire four new heads right now. So stop lamenting and move on.
You won’t know if the build works until the compile is done. It’s going to take six hours and finish at 2:00 AM. Go home, have dinner, go to bed and find out if it compiled when you get to the office at 8:00 AM.
You put an offer down on a house. The bank is considering the offer, but it’s Friday and Monday is a holiday so it will be Tuesday before you have an answer. Don’t sit by the phone all weekend and worry. Go out and have a normal weekend.
It’s by no means a new concept. Reinhold Niebuhr came up with the Serenity Prayer in 1937 and it has become an oft quoted and parodied prayer. No matter your religion (or lack of) the core concept remains the same.
Grant me the serenity to accept the things I cannot change,
Courage to change the things I can, And wisdom to know the difference.
If you can’t change it, don’t sweat it. Go have dinner and focus on something you can change.
Joel Bancroft-Connors
The Gorilla Project Manager
Want me to talk to your gorilla? Send me an email
You can follow me on twitter, @JBC_PMP

Gorilla Development Units

The sweat on my brow was threatening to swamp my eyes in their salty haze. Frantically wiping my face, I returned my hands to the keyboard. “Come on, there has to be something… Anything?” The screen updated and the information it offered up gave me no relief. “Ah hell! Come on, it can’t be that hard! There has to be something.”

By now I was getting well and truly desperate. If I didn’t find something soon, my house of cards was going to collapse. And then, like a shining beacon in the night, there was my salvation. I read the details and shuddered. A six hour webinar, starting at 1:00 AM my time. Cringing I signed up. I didn’t really have a choice, did I?
“Eight hours of planning can save eight weeks of work.”
My shoulders sagged and my head fell forward to knock my LCD screen over. (Sometimes I miss the old days of the glass CRT. At least when your head hit one of those, you felt it.) I let the monitor fall. There was no point in recovering it, I knew I wasn’t going to be using it for a while. Instead I let the impending feeling of doom over come me. That voice could only mean my own private gorilla had come to “enlighten” me on the errors of my ways.
“Oh come on,” said Hogarth. “It can’t be as bad as…” A leathery hand reached past me to right the monitor. “The use of fractal equation theory in the application of grid based project mapping scatter status charts.” Hogarth paused, “Presented by Hans Gibberish from his classroom in Belgium.”
Settling down on the floor, Hogarth pulled a branch off my fichus tree. With immaculate, white teeth he began to peal the branch free of its leaves and bark. “So why on earth are you registered for perhaps the most boring webinar in the world, that starts at o-dark thirty in the morning?”
I turned in my seat. Holding my hands defensively in front of me I said, “I don’t have a choice. I’m five and a half PDUs short of sixty and I have to file them by end of business tomorrow or I lose my certification. Last weekend I took a two day course on the history of project management, as interpreted in mime. And I even went to the consultants PM networking event yesterday.”
“You’re not a consultant.” Hogarth observed.
“I know that, but it was worth one and a half PDUs!”
Hogarth nodded. He was silent for a long minute, intent on rendering the last of the fichus branch to wood pulp. Finally he gazed at me with his deep brown eyes. “How long have you had to earn your PDUs?”
“Three years.”
“And how many PDUs did you need?”
Hogarth held a massive hand up, fingers working through the math. “So twenty PDUs a year. Just over 1.5 PDUs a month?”
I sighed. “Yes…”
“And in the first two years of your certification, how many PDUs did you earn?”
“None!” I shouted. “That’s why I’m scrambling now. I was to busy to earn them.”
Hogarth sighed, shaking his head. “Well first off, you did earn PDUs. And second off, eight hours of planning saves eight weeks of work.”
“Huh?” I said.
“Google it.” He replied, reaching for another branch.
If you are not a certified project manager, you might be a little lost. Most professional certifications require a certain number of “units” of relevant activity to maintain your certification. For PMI’s PMP certification, that is 60 Professional Development Units every three years. Failure to acquire the required PDUs will result in you being ineligible to renew your certification. If your certification lapses, you have to take the test all over again to recertify. 
About every three months I meet a project manager at some networking function. His eyes are glassy and its clear he’d rather be somewhere else. Only he’s there and eagerly looking for any other networking events. Why? Because he’s about to hit his three year limit and is short of PDUs. So begins the mad dash to get those desperately needed PDUs.
I’ve now been a PMP long enough to have seen this cycle repeat with the same people. When I first became a PMP I met people in the mad dash for their PDUs. Then they disappeared, sunk into the mires of their professional job. Only to resurface three years later, to once again make the mad PDU dash. Not unlike salmon swimming upstream, trying to dodge the bears of “too little time,” “not enough money,” “have to work my day job.”
And every time I meet someone on the mad dash for PDUs, I silently shake my head. It doesn’t have to be that hard.
I’ve got a good friend who absolutely tracks every single PDU he ever earns, even after he hit the sixty PDU limit. I believe he’s currently a full year from needing to recertify and he’s well over 130 PDUs. Me personally I’ve got at least ninety PDUs and a year until I recertify. I know for a fact I’ll make at least another thirty in the next year.
Earning PDUs is easy. And with only a little planning and a little “getting out of the office” you can easily earn 60 PDUs in two years. 
Some tips and advice:
Know the rules: PMI has several useful documents to aid you in understanding PDUs. Start with their “Maintain Your Credential” site for general overview. PMI offers its own suggestions for earning ways to earn PDUs and has printable PDU Reporting Form for offline documentation.
The real gem is easy to miss as it’s billed as comparison of the old and new PDUs (In March of 2011, PMI went from 18 categories to 6). The type of PDUs explained PDF breaks down the six PDU categories (A – F), including maximum PDUs you can earn for certain categories.
Do your job: You can earn 5 PDUs for holding a project management job. One quarter of your PDUs can be earned just by showing up to work each day. PMI is not explicit, but I’m pretty certain a volunteer job will apply as well.  This is Category F in the PDU chart.
Read a book – or listen to a podcast: Another 10 PDUs a year can be garnered in self directed learning. Two of the most popular are books and podcasts. I personally recommend Pam Stanton’s PDU for Lunch and the Cornelius Fichtner PDU podcast. I’m pretty sure Ficthner’s also qualifies in the continuing education category, so you can earn more than 10 a year. This is Category C in the PDU chart (Continuing education is Category B). [EDIT- I’ve since learned that Pam’s webinars are good for Category A (PMI Acredited training) if listened to live and Category B if you catch the recordings and Conelius’ are good for Category B. So read books or talk to PMs for your Catagory C and save Pam and Cornelius for A and B]
Talk to other PMs: Another way to earn Category C is to go to formal PM gatherings. But that costs money, right? No, not always. Many PMI chapters offer free networking events. Usually for the price of a cup of coffee or a cheap breakfast, you can spend an hour a month talking with other PMPs. That will get you your 10 PDU a year easy.
That’s forty-five easy PDUs right there. Register for two one-day PM workshops in your three years and you’ve just locked up your next recertification.
So like the gorilla said, “eight hours of planning can save eight weeks of work.” We project managers know this mantra, we preach it to engineers all the time. For us let’s change it just a little.
“Regular planning will prevent a mad dash at the finish line.”
So, do you PDU?
Joel Bancroft-Connors
The Gorilla Project Manager
Want me to talk to your gorilla? Send me an email
You can follow me on twitter, @JBC_PMP