Category Archives: Methodology

Deep Gorilla: To Succeed in Agile, Follow the Money

Posted on by
1

Deep_ThroatDarkness threatened to swallow me whole. The elevator doors had opened up on a scene right out of a classic horror film. The underground parking garage was plunged into the depths of darkness. Light was limited to a few lights pouring out pitifully small pools of illumination. The scattered light contributed to making the darkness even darker. Facilities was working on the “intermittent power issues with all diligence” but that didn’t change the fact that our parking garage currently resembled a set from some bad horror thriller.

Just like my mood.

Oh, sure, the Icarus team was doing awesome. They’d taken to scrum like a politician to a fundraiser and their performance was amazing. As a proof of concept it had been an earth shattering success. As a catalyst for change, it had run straight into a brick wall of resistance. “Oh it worked fine for a small project, but it will never work on a real product.”

It was time to throw in the towel. I’d given it the old college try and carried the water. Now it was time to take my marbles and go home….

The distinctive click of an iPhone unlocking and the sudden glow of the screen revealed the dark outlines of a figure. Cloaked in the inky blackness and wearing dark clothing, It was difficult to tell where the figure left off and the darkness began. He had an almost looming presence, as if he were greater in size than me. Greater in size than any man. Wait a minute, was that a black coat, or that was that fur?

“Hogarth!?!”

My gorilla lifted his iPhone to lips, the glow of the screen lighting up half his face and plunging the other side into deeper shadows. “Shhh, no names. We’re you followed? “

“Followed, what on earth are you talking about?”

Hogarth leaned back and turned his head from side to side scanning the darkness of the parking garage. Apparently satisfied there was nothing in the nothingness , he looked back at me. “If Percy knew I was here it would be bad for both of us.”

“Percy?” I wracked my brains trying to think of anyone in the company named Percy. “Wait a minute, you mean that Elephant you play poker with?”

Hogarth nodded, “Percy Liddy, he’s accounting’s Elephant in the room. His skin is so thick, nothing can get through to him. We were at a company once and the stock fell ninety-five percent in four hours. He just stood there, unmoved and perfectly calm. One of the monkeys from legal asked him what his trick for not panicking was. Percy responded that the trick was in not minding.”

“Hogarth, what are you going on about? I’ve had a long day and I just want to go home and drown my sorrows in reruns of Gunsmoke.” That’s all I really wanted to do. I was exhausted and tired of running head first into the brick walls of agile resistance. The company executives just didn’t see the value. It didn’t match their vision of the world and so it didn’t have a chance of succeeding. I was stuck, completely stalled, I had no idea who to talk to that would actually listen and could support an agile adoption.

“Follow the money,” Hogarth said .

I blinked at him. “What do you mean, follow the money?”

His bucket sized head gave a shake, “I can’t tell you that.”

I puzzled at what he had said. Follow the money. Besides being a way over used movie quote, what the hell did it have to do with anything. Then I understood. Okay I understood what he meant, I didn’t understand why. “You mean I should talk to Finance? Are you crazy, they pinch sawdust just to make more pencils.”

Just then Hogarth’s iPhone turned off, plunging our corner of the garage into total darkness. A few seconds later, from even deeper in the darkness I heard his voice whisper, “Just follow the money.”

Shaking my head I turned on my own iPhone, to light my way to my car. Accountants as the key to going agile, was he serious?

AGILE SUCCESS? FOLLOW THE MONEY….

Crack the shell on your average enterprise class company and you’ll find so many agile antibodies if could overwhelm even the most robust agile coach’s immune system. Once you move past the small company, you start running into all sorts of adoption anti-patterns. Enterprise companies have been doing things the way they have been doing them for so long that inertia will keep them going for the next century. Without some way to show a tangible benefit, that makes sense to the C-Suite executives, we are going to continue to run into challenges at the higher end of corporate mindsets.

Pat Reed and Walt Wyckoff may have just given us the tools to break down the walls around the C-Suite. I attended the July session of the Bay Area Agile Leadership Network. There, Pat and Walt presented an Agile Accounting Model: The key to Enterprise Agile. I knew of Pat and had attended a talk of hers early in my agile journey. So despite being a failed art major, I confronted my fears of finance and went to see what I could learn. I’ve spent the last decade working in Enterprise class companies and I’ve seen first hand the challenges of trying to take agile from a tolerated experiment to the accepted way.

I admit I was dubious. I also admit a lot of that doubt was tied up in my own lack of finance knowledge. In some industries, project management has its hands all over the budgets of their projects. In my entire Silicon Valley experience, I’ve never been in a company where budgets and project managers ever had more than a passing acquaintance. I wasn’t alone in the room either. Basic concepts like Expense versus Capitalization are things most of us understood, but only just.

It wasn’t until the break out exercises that my Aha lights started going off. Working with Walt on how to explain the benefits of agile to accountants, we made a break through that the same explanation used to the accountants could be change the minds of the C-Suite.

Again, I’m no accounting genius, so bear with me here.

First off: Expense vs. Capitalization for dummies, by a dummy- Expense means you have to subtract that money from your balance sheet right now. If the project expense is three million dollars, that’s three million less profit for this quarter. Capitalizing allows you to spread the cost over months or even years. IT does this with computer hardware all the time. You don’t drop $100K for a server on the Q3 bottom line. Instead you divide the cost over the life of the server. So a server expected to last four years costs the company $25K a year, for the next four years. (Go check with a real finance person on this before taking it to the bank.)

Now to the benefits:

You can capitalize your Product Management (And more of development and deployment):

In a standard Waterfall lifecycle, everything that happens before coding starts (officially starts with the project commit)and after it ends, is considered an expense. Only the direct development effort is considered a “material” part of the project and can be capitalized and then only after it ships.

In agile, design and development are often tightly inter twined. If you are making proof of concepts then you can capitalize. If you’ve read Lean Startup, remember the guys who started the smart concierge service. Now think about the fact that they could start capitalizing their product the minute they had that first paying customer. This was months before the first line of code was ever written.

Agile can let you release more often. This allows you to start your capitalization faster.

Instead of releasing once every eighteen months, a successful agile can be shipping customer releasable product as fast as every month. You can start capitalizing faster, so you spread out your costs faster.

But wait, Enterprise customers don’t like frequent releases. And what about proof? You have to convince the accountants you can really ship.

First off, there is almost always one customer who will take your release. And all you need is one. So long as one customer takes the release and puts it into production then you have a shipping product and you can start your capitalization.

As for trust, it’s not a quick road to make a major change. Go to accounting right now. Tell them, “In the next twelve months we’ll make a shippable release every quarter and we’ll find at least one customer to install it. A year from now, we will come back to you and ask that we be allowed to Capitalize our development process from the start of Sprint 0.” In other words. Show them the money first. Prove you can walk the walk.

It can allow you to Capitalize your services

I didn’t get this one as fully as the other two. Ron Lichty, an agile coach and author of “Managing the Unmanageable”a soon to be released book, raised this and by the nods from Walt I know it made sense. With so many companies offering professional services (consulting) along with their products, this could be a huge win.

A word of caution: Beware the dark side.

Okay, so let’s go back to that Lean Startup use case. They haven’t written a single line of code. The product doesn’t exist yet. Instead they are manually doing everything their automated concierge service will eventually do. The CEO and CTO meet every week with their one customer. And yet they could capitalize all of this, spreading out the cost of coming up with this product over several years.

If we give Wall Street new and creative ways to report profits, we will also have to be very certain we instill in the C-Suite the rest of the values of agile and Stoos. If we don’t, we could end up at the wrong end of a shell game that makes Enron and Bear Stearns look like table stakes at church bingo night.

Umm, I’m not following you.

Yeah, what he said, only I don’t trust your data.

Fair enough. I’m not sure I followed it all either. I’ve since started watching Khan Academy’s videos on Core Finance, to raise my own knowledge of basic business accounting. Don’t take my word for it.

Hear it from the Speakers: Pat and Walt will be presenting their findings at Agile2012. For those of you in the SF Bay Area, I know that Silicon Valley ALN is trying to get them to come and speak later this year.

Review the Slides: Bay ALNhas their slides posted to their Meetup page.

Google it: “Pat Reed Agile Accounting” will find you older examples of the presentation. I don’t know how much it has evolved over the years so this probably is your last option.

Imagine a world where the bean counters were asking the CEOs why the company wasn’t using agile development?

Imagine…

Methodology roulette, always bet on Gorilla

Posted on by
Reply

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

Wake up and smell the gorilla

Posted on by
3

Or: Finding my own business philosophy and what matters

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

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

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

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

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

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

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

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

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

Smack!

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

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

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

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

*This quote is paraphrased from Mark Horstman

 

MY AHA MOMENT- I’D BEEN CAREER COASTING 

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

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

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

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

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

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

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

The Gorilla Philosophy:

1- People, not projects

2- Communication is 100% your job

3- Process is a tool, not a roadblock

4- There  is no, one, right way

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

 

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

 

 

 

Pothole Project Management, a Gorilla PM philosophy

Posted on by
2
Or- How to solve a problem you lack the authority/resources to solve.
Ever have a day where you feel utterly powerless? Where your every act carries as much power as a waterlogged facial tissue holding back a runaway train? Okay, okay, I know, that that’s the normal state of being for a project manager. But I mean really and truly feeling like you have no more influence then a viagra spam email. Ever had one of those days?
I was.
Jake, the development manager,  had just declared his team had no plans to fix the fatal crash& corruption bug in the database load scripts. “It’s a fringe case, no one is ever going to hit it.”
Carlos was less than inclined to accept the answer. “Fringe case? A good twenty percent of our user base uses the Whippoorwill chip. What are my customer support reps supposed to say, ‘Oh sorry, sir, but that’s a fringe case. Can you please reinstall your system from a backup? You don’t have a backup, oh well.”
I sat in the middle, doing my best to stay the unbiased facilitator. Carlos could be a very reactionary customer service person and had a tendency to exaggeration, but I’d seen his data on this, and it was accurate. Over in the other corner, Jake’s team had been working for six months solid and had juggled a mountain of scope creep, introduced by the product manager. He was under a lot of pressure to deliver the product and just plain worn out by it.
So I looked to the product manager. “Bob, it’s your product, what do you want to do.”
Bob looked up from his Blackberry prayer. He glanced at the fiery tempered CS manager and then at the stoic development manager. “We’re a month late already, we can’t afford any more delays.”
Carlos nearly jumped across the table, “Delays? We wouldn’t be a month behind schedule if you hadn’t added a dozen features at the last minute and we wouldn’t have this bug if you hadn’t insisted on changing the DB schema!”
Two size-twenty, hairy feet levered themselves up onto the table next to me. Leaning back in his chair Hogarth folded his arms behind his head and turned to me. “You know this isn’t going to be any different from the last time customer support went toe to toe with the product manager?”
I glared at Hogarth, willing him to disappear in a puff of smoke. He didn’t and I was faced with the lopsided grin of my personal gorilla. I wanted to snap at him, that this would be different, but I couldn’t because I knew very well it wouldn’t be. Just like weather in LA, if yesterday was sunny, then odds were damn good tomorrow would be as well. The needs of the schedule would outweigh the needs of the product quality and customer support would be stuck supporting the bug. It would also impact our company. We were already starting to get a poor reputation for having great ideas, but horrible implementations.
Hogarth yawned, exposing a mouth full of pointed teeth, each gleaming like a reminder of things gone wrong. He said, “if you don’t do something, then it will be the same thing all over again.”
Now I was angry. It was one thing for Hogarth to state the blindingly obvious. But to imply I could change fate was quite the other. “Hogarth, I don’t have that kind of authority. My job is to move the project, not decide what it is!”
“We’re not going to have the responsibility argument again, are we?” he said. Before I could tell him this was different he waved towards the conference room’s big, picture window. “Remember that pot hole in the north parking lot, the one you used to hit every day?”
I nodded, “Yes, and I tried to get it fixed for six months. Facilities only finally got around to doing it last week. So?”
Hogarth shook his head, “Yeah facilities fixed it, but it wasn’t anything you did. The construction project on the south wing meant they had to drop a bunch of equipment at the head of the south lot, including in the CEO’s parking spot.” Flipping his feat down, Hogarth turned to point out at the north parking lot. “So they gave him a temp spot right next to the north entrance. See there’s his Mascarpone right there.”
“Maserati” I corrected.
He waved a massive paw-hand, “Whatever. The point is last Monday he drove into the north lot and took out his muffler on that pothole. Want to guess how fast it was fixed?”
I shook my head, “No, I want to know what your point is.”
“My point,” he said, “is sometimes the solution to the problem is to steer the right person into the pothole. Who do you think is really going to care is there is a crash bug on  the Whippoorwill chip?”
And the light dawned on me. “Massive Computing, probably our largest client. And Walter, their account rep is in town. I make sure Walter knows about the problem and he’ll get Bob to change Jake’s mind!”
My gorilla smiled. “You are learning, young Jedi.”
I call it “Pothole Project Management” and it’s one of the core tenants of Gorilla Project Management. It is something of the flip side to what I discussed in Blog 21, The Responsible Authority Gorilla. In Responsible I talked about how I, as the Project Manager, worked process and standardization into the team using Gorilla PM rule #1 “First thing is to get it done, then find out who should do it.” Pothole PM is the tool I bring out when my own authority (real or relationship) is insufficient to solve a problem. By steering someone with the authority into the issue, you can get the needed result.
Important point: This is not “I’m going to go tell dad!” This isn’t the school of tattle-tale project management. Relationships and subtlety are still very important. A project manager who gets a reputation for always going over people’s heads is a project manager who will soon have his team working to get rid of him.
Let’s take the example from above. I wouldn’t pick up the phone and tell Walter “Oh my god, do you know what they are doing?” My first approach would be to talk to Carlos, the Customer Service Manager. Carlos is the one who is most invested in the problem and he and Walter share a common interface point, that being the customer. Guiding Carl to go talk to Walter about “how we can ensure Massive Computer will be impacted minimally” will not only make Walter aware of the bug, but worst case will also start the risk mitigation planning if the bug does ship.
If I had to handle it directly, I’d do it in two ways, face-to-face and the power of status reports. Face-to-face is the trickiest, as it can all to easily come off as tattle-tale PM and that’s bad. You have to steer the conversation and get Walter to ask for the data. Power of the status report is the least risky, but you have to make sure people read your status reports (and that is a whole other blog, but there are tips for this). You make sure you have a history of factual reporting that includes issues and risks. If Walter is reading your reports, he’ll know about the issue gets involved that way.
Being an effective project manager is not about doing the work yourself, it is about making sure the right resource is applied to the right problem.
Joel BC
Veteran, the project management wars
Want me to talk to your gorilla? Send me an email
You can follow me on twitter, @JBC_PMP

Every project is a screwdriver – or the process inflexibility gorilla

Posted on by
1

[Thanks to Phillip Chen, for the inspiration for this blog. His discussion thread on “Do you tailor PMBOK or other PM methodologies for your projects?” in the PMP LinkedIn group, sparked a reply by myself that spawned this blog. ]

Things are really looking up. Just got transferred to the newly formed product incubation group. The company is finally putting innovation up as one of the top three business goals for the coming year and you’re on the bottom floor of the new team.


You were worried for a while there, market share was slipping and it just didn’t seem like anyone was willing to break the cycle. No one wanted to point out the Emperor had no clothes and winter was coming. But the board did. Now you’ve got a new CEO and he’s shaking things up. What could go wrong?


“That is not how we do it.”


“But this is totally new product line, it’s nothing like our existing products. If we follow the same process we won’t get to market for two years.”


“No exceptions, we have a process, it works and you will follow it.”

Welcome to the PIG:
And wham, you run right into the Process Inflexibility Gorilla. Hogarth and I have talked about his cousin, PIG, on many occasions. As Hogarth oft recalls “He makes the immoveable object look like a hockey puck in the Stanley Cup.”

PIG generally hangs out in larger, more established companies. He’s at home in long standing businesses that have managed to keep doing what they do, with the minimal amount of change. It seems that sometimes that success is in spite of themselves. As often happens, the process inflexibility gorilla is so firmly entrenched, that he is all but invisible to those around him. He is not just ignored but not even seen. It takes a business change, or a new set of eyes to see him. The challenge that then comes, is how to get those entrenched with him, to actually see him.

A company hired a Director of QA. They had previously practiced a developer QA model, with the philosophy that the best person to test code was the person who wrote it. This director, we’ll call him Saul (I just made it up on the spot folks), was given a broad charter, promises of support and let loose on the engineering organization. Now Saul was an effective executive. He knew he couldn’t just sweep in and “lay down the law” no matter how much air cover he might (or might not) have. Saul took his time, he asked lots of questions, observed, got to know people and laid out his plan. He made some minor wins and changes, but for the most part he spent the first few months collecting data. All in preparation for laying out a whole new QA methodology, just like the charter he’d been given said to do.

Only when it came time to roll it out he ran into a massive wall, one that made China’s Great Wall look like one of those Irish rock walls in a sheep pasture. So powerful was the institution, to the way things were ‘supposed’ to work, that even his powerful executive sponsors backed down. So entrenched was the “way its done”, that no one was willing to consider that the business had changed, or needed to change for it to continue to compete effectively. In the end Saul left the company, unwilling to spend the rest of his career trying to get people to see the invisible gorilla.

So, how do you deal with such a pervasive and hard to see gorilla? It’s not easy and it may not even be possible, but there are some things you can try.

Now one thing you may of noticed in my style, is I like analogies. I’ve found if you can break something out of the now and use something totally unrelated to explain it. When this topic came up in the PMP LinkedIn discussion forums I used the ‘screwdriver story’.

“Yeah sure, that screwdriver is absolutely perfect for that job. But not every job is identical.”

Of course many entrenched people will argue that everything is identical. Yeah that may be their point of view, but I just keep on with my analogy.

      “We both have a budget of $200. I’ll take the money and buy a nice , simple toolbox with all the normal tools in it, you know hammer, phillips, flat head, wrench, etc. You can use your $200 to buy a super whiz bang phillips head screw driver that is exactly perfect for the currently defined job.” “I’ll do this because when you get stuck in a room (project) that has nothing but lug bolts, your fancy screw driver is just a pointy stick.”

Something you have to go back to, in times like these, is the concept of innovation. If you have inflexible process you probably have one of two things. You have inflexible products, which will be unable to compete in the continuing market place. Or you have products that are not being managed efficiently because they are square pegs being shoved in round roles and shaving off parts to fit. If your company is not flexible, how long will it continue to survive?

All right, while a very satisfying conversation it won’t sway every listener. The people who are inflexible in process are often not going to want to consider there might be anything but phillips screws in their company. These kind of people are going to bristle when you imply the company might fail through lack of change. “That’s the way we’ve always done it.” So what do you do? Tough question and no easy answer.
One thing you can try, is to work around the road block. If you have good cross organization and seniority relationships, you might be able to push for change from another direction. You have to be careful though, as this steps into the touchy ‘going over/around someone’ politics.

When it comes down to addressing the Process Inflexibility Gorilla (PIG), we once again come back to relationship and influence. While Saul failed in his endeavor, more often than not a strong and broad set of relationships should allow you to get the value benefit of making process change across to people who can affect the change.

Don’t cry “The emperor has no clothes” or in this case “Look an invisible gorilla!” Instead steer people so they can’t help but run into the invisible gorilla. Once you run into an 800 pound gorilla it doesn’t really matter if you can’t see it, you know its there.

Talking with gorillas, I’m Joel BC