Every project is a screwdriver - or the process inflexibility gorilla

[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 money and buy a nice , simple toolbox with all the normal tools in, you know hammer, phillips, flat head, wrench, etc. and you can use your 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 flat head screws, 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. I 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

The Conflict Gorilla

"Absolutely not! That would be a complete waste of resources and I won't sanction it."

Around the table feet shuffle, eyes find fascinating patterns in carpets and ceiling tiles and not a person responds to the declarative outburst. Deeply intent on your nearly empty page of notes, you try and ignore the looming form of Hogarth the gorilla.

"I thought the product manager owned the product?" he asks, munching noisily on a banana.

I direct a jail house whisper at Hogarth "She's the VP of release engineering, she out ranks everyone in the room."

"Mmh.., , but she's not on the project team, is she?"

"She doesn't have to be, she can make any of our lives miserable."

Hogarth picks a flea from his fur and flicks it into the garbage can. "So she can use her role power to cow you all into place, cause no one wants to disagree with her?"

"Shut up Hogarth."

The Conflict gorilla: A more frightening and unapproachable gorilla you will likely never find. Most people inherently shun conflict. Those that do not, often tackle it head on and get swatted down for their temerity, with the same end result. The above example is a radical one. The fear of a high-ranking person's power has cowed many a bright manager to inaction. But it is not the only time we avoid conflict. How many times has someone complained about quality of another peers work, unmet deliverables or more direct negative behaviors (She's always interrupting me, I can never finish a sentence).

Yet when you ask that person (or yourself, let's be honest here) what they(you) did about it, invariably the answer is in the range of 'nothing', 'I sent an email', 'You're my boss, what can you do?'?

It's amazing in a world, so filled with global conflict, that we tend to avoid any semblance of it in our professional and personal lives. Someone, somewhere, is probably earning their PhD, studying how conflict-avoiding seeking people can have spent so many centuries in global scale wars. Well let me be the first to step up and say "Hi, my name is Joel and I'm an anti-conflicter."

As I look back on my years in Silicon Valley I cannot count the number of times I ran headlong into a conflict situation and let fear, desire to not rock the boat, not become a target, rule my actions. And to what cost? Would I have gotten that promotion, would that million dollar bug have been fixed, would the team been more productive, and so on?

This gorilla has long been the bane of my existence. I knew it was an issue, I knew it was a roadblock, but I could never get past it. Then I heard a wonderful quote. Mark Hortsman, management consultant and podcaster said "My uncle always used to say, conflict is any two people in the same county". Wow… so I can't avoid conflict. In fact conflict isn't necessarily a bad thing. Are you saying, that just as Risk Management says a risk can be a good or bad event, so is it with conflict?

There you have it folks, like it or not we are stuck with conflict. The question is, will we have good conflict or bad conflict?

Now before I give some of my own personal tips, let me advise you against what NOT to do:

Some people like to confront conflict head on. In the above example, let's say the Product Manager had gone head on with the VP, saying some thing like "That's my decision and between myself and the developers."

Now the Product Manager is technically correct, but even as nicely worded as that was, it is a slam right in the face of the VP. The entire rest of the meeting just became ringside seats to the conflict. Just because you have the will to face the conflict, doesn't mean you should charge in guns blazing. Look what it did for the Charge of the Light Brigade.

So how would I approach the situation?:

Well in the above situation, imagine if you as the Project or Product Manager has just said, "Okay", or "Okay, thanks for your input" ?

One of the first things to diffusing conflict is to not rise to it. Think of good forum posting etiquette. If you are in a hot thread, the rule is thirty minutes. After you write your post, wait thirty minutes, read it again and ask if you really need to send it.

At the highest level, dealing with conflict has to do with making a safe environment for both sides to talk freely.

Which brings us back to a theme I sense developing in this blog, relationships. If you have a good working relationship with not only your team, but your stakeholders and the extended team, then you will have less negative conflict. Get out of your cube and talk to that VP, get to know more about them than the color of their Blackberry.

Here are some resources I've found that are helpful to dealing with conflict:

• Dialogue Smarts: Skills for Mastering Crucial Conversations : Find someplace that conducts the training. One of my old companies offered it and I still have the Dialogue flip cards on my desk.
• Crucial Conversations: This is the book by the creators of the course. If you can't take the course, buy the book (or both).
• 
  
  Management-Tools.com: No I don't get paid to endorse them. I just have found they really work. I recommend the podcasts on Feedback (Especially the Feedback for Project Managers and Peer Feedback), the "Feel, Felt, Found" podcast, the Resolving Conflict podcast and their series on communicating to the DISC profile system.
  
  
  
  In the end, we can't avoid conflict. As long as we are not monks on a mountain top we will encounter conflict. The question is how we will deal with it. As a reminder hint, hiding in the turtle shell is not the solution.
  
  
  I'm Joel BC, Gorilla Talker
  

There is no such thing as Career Insurance

"Hogarth, what are you doing?!"


Hogarth looks up from where he's causally perched on the corner of my desk. Holding up a piece of paper he asks, "Did you know your resume is three years out of date?"


"Not now, Hogarth, I have a report to write, then I have a beta planning meeting and tonight I've got to fix the garage door." I shoulder past him, to drop into my chair. "Besides," I say, "this job is nice and stable and I don't have any plans to go anywhere else.


My gorilla blinks at me, "I'm sure the Titanic didn't have any plans to run into an iceberg either."


I pointedly ignore Hogarth and started typing up my meeting minutes.


Hogarth lets out a deep sigh. Sliding off his desk he gives a shrug, "Yeah sure don't mind me, I'm just the 800 pound gorilla in the room." Shuffling off to the far side of the office, he mutters "man my cousin has such an easy gig."


Unable to quell my curiosity I look over, "Cousin?"


Hogarth thumps down in the corner, "Oh yeah, he's got a great gig with AXA Equitable. Getting paid the big bucks to be the 'are you ready for retirement gorilla.' TV Commercials, print, web, you name it. You can watch his videos on the web."




"I'm already saving for retirement, Hogarth. Besides, I'm not getting paid to update my resume or network, I'm getting paid to manage this project. I just don't have time to worry about my resume."


Holding up his watermelon sized hands he says "Oh I'm not gonna talk to you about retirement, I'll send my cousin over to do that, but let me ask you something, do you have life insurance and pay money for it?"


I sigh, "Yes, but…"


"Do you have car insurance and pay money for it?"


"Yes, but…"


"Isn't it true that time is money?"


I let out a deep, resigned sigh, "Yes."

*****************************************

Yes folks, welcome to the 'career management plan' gorilla. It has got to be one of the most prevalent and avoided gorillas of all times. I know I've done it, I've watched friends do it, and enough people are making scads of money to help people with it, that there is no denying that this is one big gorilla.

Now folks, let me just start with saying, I'm not saying anything new. The very nature of gorillas, is that they are not new or ground breaking concepts. They are those things we don't want to face, and are often old and well known.

Michael Auzenne and Mark Horstman have made a business of advising executives and managers on the art of career management. Their Manager Tools podcasts are a must listen for any aspiring executive and a should listen for the rest of us. The November 2009 edition of PMI Network quoted John Challenger, of Challenger, Gray & Christmas when he said, "You should spend 5 percent to 10 percent of your time engaged with organizations and meeting people in your field or industry outside of work." There isn't a job board out there that doesn't advise you to keep your resume current. And if you talk to any successful executives, maintaining their network will be one of the top priorities they list.

Yet, especially in the high tech industry, we task focused professionals all too often bury ourselves in our work, wrapping it around us like a thick blanket of denial. It takes a market upset, a lay off you just escaped or that all frightening appearance of the HR person outside your office who says, "Can I speak with you?", for most of us to even think about anything but our job, the next release, the next project. Time was, at least so I'm told, that your company and your manager were as focused on your success as they were on the success of the company. Now I don't want to cast a blanket aspersion on managers, or even companies, but the hard truth is most companies worry about the company as a whole, or the bottom line and managers are often taking care of their own career insurance.

So as I had Tweeted - "Gorilla Talker Tip #2- There is no life insurance for careers, if you don't manage your career, no one else will."

So here are some tips I've personally found useful, vital and effective. (Again, nothing new, almost everything is something I learned from somewhere else, I'm just the guy talking to the gorilla.)

Listen to the Manager Tools podcasts: I discovered these not long ago and the light that went on, when I started listening, was incredible. I highly recommend "Your resume stinks!", "Building a Network", "How to handle headhunters", and "Contacting Recruiters", but I am personally in the process of listening to everything in their catalog.

• Maintain your network: 500 people in LinkedIn is not a network, it's just a tool. You need to keep in regular contact with your direct network. Set yourself a reminder to contact them at least once a quarter (Horstman calls it the "CTL-SHIFT-K rule", for the keyboard command to create a task in Outlook). On the LinkedIn front, if someone sends you a INMail or request for an introduction, respond! See the next rule.
• Give more than you take: Part of keeping up that network is being ready to give of yourself. Whether it's acting as a reference, sending a job lead someone's way or even more, don't keep score and you'll find it will come back to you.
• Own your own computer!: I've known friends who showed up for work and found the building locked, never to re-open again. I've seen people ushered from their cubes, only to return after IT has removed every piece of technology from the cube. You need your own computer and not just to find that next job. You need a secure place for your contacts, your personal career documents, your private email.
• Maintain a private email address: Don't just have it lying around for a rainy day. Keep it active, check it often, make it a way for people to get in touch with you. It should be professional! No "I_rock@izzy.com", get yourself a nice professional address at a mainstream provider or with your own private, but professional domain. For example jbancroftconnors@yahoo.com or Tom@Masterson.com.
• Point your LinkedIn to an email address you use: How many times have you heard "Oh sorry, I didn't see your invite, I don't check this email very often?" Point your LinkedIn to an active email account. Oh, and while we are on LinkedIn, treat this like a resume. Keep it up to date, keep it active and for heavens sake, keep it in sync with your actual resume (more on resumes below).
• Save your contacts: I've committed, this sin, keeping all my contact data in my work Outlook and then losing it all. In today's internet society, we have no excuse. Once a quarter sync your contacts with your Yahoo, GMAIL, Plaxo, whatever. But to add to that, print it out! Technology is great, but tech fails. Woe betide if you don't follow the 'own your own computer' and you can't even call people. Oh and cell phones don't count, not only do a lot of us use company phones, but they are one of the least reliable places for long term information storage. Sure I have an iPhone, but the contacts are from my Outlook and I've had to reset my phone more than once.
• Keep your resume up to date: Better yet create a "Career management document" (CMD). Depending on who you talk to a resume should be no more than one or two pages. A strong career will have a lot more than two pages of information. You could have half a dozen accomplishment that don't apply to your current work, but if you don't capture them somewhere, you might lose them. Used to be a crack shot at budgets? Guess what, budget skills are in style again. Still remember your accomplishments from 1998? I personally use a Mind Map. Each box is a job I've held and I then have bullets for all the accomplishments I have for that job. When I need a resume, I can pick and pull from each job, to tailor my resume to the position. The other part of this is to maintain it. Once a quarter, 30 minutes a quarter, go through your resume. Not just updating your last job, but the whole thing. Maybe you were working on an integration project and you remembered how you were given a commendation for integration work, ten years ago. Add that to your CMD for that old job. You never know when it will come in handy.

In the end remember the most important rule- Your current job could end at any time, a new once in a lifetime opportunity could come out of the blue, your spouse has to move to Australia, the list goes on. Only one thing is certain…

Change happens.

Now if you'll excuse me, I have to talk to a gorilla about a horse.


I'm Joel BC, Gorilla Talker
Want me to talk about your gorilla? Send me an email


*-Special thanks to Mark Nottage, my excellent proofreader and all around skilled tech geek.

Too many cooks in the program team

I can feel my eyes slowly glazing over. I'm not trying to, really. I am doing my absolute best to stay focused and present. After all, technically I am facilitating the meeting, right? Want me to talk to your gorilla? Send me an email




Tuning back into the conversation… discussion… okay let's call it what it is, the knock-down, drag-out argument. I determine that, yes they are still on the exact same topic and neither side is relenting. I can almost hear the announcer's voice:


      "And in this corner, weighing in with an MBA from Wharton and a BS in Computer Engineering 
      from UC Santa Cruz...The Product Manager!"


     "In the other corner, with a Masters in Computer Engineering from CalPoly, an electrical engineering
     minor, a minor in physics, and founder of two start ups...The Engineering Manager!"


I try to remember, how exactly the functional spec review devolved into 'passionate' discussion on whether one feature should be implemented with Java or .Net. The Product Manager is currently white boarding exactly how the feature would be coded in .Net. Meanwhile, the Engineering Manager is not only disagreeing with him, profusely, but is adamantly stating the feature isn't what the customer wants and trying to push his own user scenario.


At this point Hogarth leans over and quietly confides in me, "So...just so I'm clear. The Product Manager is trying to engineer the product, the Engineering Manager is writing new user scenarios oh and executive staff isn't even bought in to the whole product, because our competitor isn't doing it yet? I got that about right?"


"Shut up Hogarth…" I mutter.


"What? Okay, fine just ignore me. I'm only the gorilla in the room."


Welcome to the "too many cooks" gorilla. When everyone in the program team is part engineer, part product manager, an expert in QA, and of course a natural salesman (I mean how hard can it be to sell our awesome product, right?).

When exactly did it happen? Take the Product Manager role, for example. Today, if you want to be hired as one in Silicon Valley, you have to be an expert in business and engineering. If you don't have a double major, you can practically say good bye to the job. Okay so I exaggerate a bit, but it just underlines a trend I've watched for the last ten years.

I guess I blame the Dot.Com era. Now maybe that's using a convenient scapegoat, but it is true that the late 90's start ups required everyone to wear multiple hats. When I was a product manager, during that time, I had to be not only a product manager, but a business development manager, a salesman, a trade show AV expert, a project manager, a QA tech, a user interface expert and even desktop IT to my coworkers. We all got so used to wearing so many hats, that we started thinking we were good at everything we did. I guess we all forgot the second half of the famous saying. "I'm a jack of all trades, but a master of none."

Flash forward ten years and I'm watching the Engineering Managers trying to shape the product, while Product Managers are trying to code the product, and absolutely nothing is getting done. It's almost like we've lost the ability to trust that the other guy can do his job and we can focus on doing our jobs.

"Isn't that what I just said?" Hogarth asks in a deadpan voice.


What advice can I offer?

This is one of the biggest and most difficult gorillas that I've ever had to deal with. As a project manager, you can easily identify he's there, but talking about him is not as easy. You certainly can't tell the Product Manager to "mind your own business and let the engineer code." Sure it would feel very satisfying, but not all together productive. There are two things I've found to be helpful, in facing this gorilla.

1- Support the expert: Of course you can't come out and say "The engineer makes that decision", but you can provide support to the expert for a given task. Not only can you facilitate meetings to focus on the 'expert' for a given discussion, but make sure you have clear process documentation, with task owners (Engineering owns the functional spec, PM owns the user scenario), clear definitions of documents (what exactly should a Market Requirement Document (MRD) do, as opposed to what an Functionality Requirements Documents (FRD) should do.) It may seem subtle, but it can go a long way to clarifying roles.

2- Ask the right questions: "How does using Java change the user scenario?", "Don't you have market data on why this feature is critical?" You're not really asking questions of course. In true Socrates fashion, most of the questions you ask, you already know the answer to. You are just bringing the answer into the light. Remember though, the questions should support the expert.

And there is one more way to avoid this gorilla. That is to know what you are good at, know what your job is and put faith in your team mates to know the same. But then we are all doing that already, right?

Have any tips for dealing with the "too many cooks, not enough experts" gorilla? Share them here and bring out your inner gorilla talker.

Until next time I'm,
Joel BC
Professional Gorilla Talker
 

WHO IS HOGARTH?

 

WHO IS HOGARTH?

Welcome to the weekly team meeting! 

It's six months to go until the product ships. We just finished a gripping argument on what constitutes a pass in the QA test benchmarks. I'm not sure but I think we settled on 95% pass rate, it might be 90% I'd have to check my notes. We are now doing a review of outstanding product change orders. Engineering wants to remove a major feature? Their argument is the project is behind schedule and this feature will take to much work. As arguments start to dive into yet another rat hole, you realize that no one is even mentioning that your chief competitor is stealing market share hand over fist with their new release. A new release that is already better then your next planned release.

Not even with Hogarth sitting there the business paper open to an article all about our competition.

Oh, right! Meet  Hogarth. He's sitting down the table, wedged between the QA director and the product manager, quietly reading his newspaper and ignoring everyone else. It's a bit of tight fit, but what do you expect from an 800 pound gorilla?

Say hello to the "gorilla in the room".

The phrase itself is a modification of the English idiom, "the elephant in the room", Wikipedia defines this as - "An obvious truth that is being ignored or goes unaddressed. The idiomatic expression also applies to an obvious problem no one wants to discuss.  It is based on the idea that an elephant in a room would be impossible to overlook; thus, people in the room who pretend the elephant is not there might be concerning themselves with relatively small and even irrelevant matters, compared to the looming big one.'  (From Wikipedia )

Like many people in the 'Valley', a good friend of mine and fellow Project Manager Wendy WorthingtonBarnes*, likes to call it the "gorilla in the room"; as so often that gorilla takes on the power of the 800 pound gorilla,  "an overbearing entity in a specific industry or sphere of activity" (From UrbanDictionary.com). Just as Microsoft is the 800 gorilla of consumer operating systems, the teams abject denial of the competitors new release is the 800 pound gorilla in the meeting.

As project managers, we find ourselves facing the gorilla all the time.  Often we are the only ones even willing to address the gorilla, and we run into fascinating challenges in how to get everyone else to face the gorilla. Sometimes it isn't possible and/or worth trying to talk to people about the gorilla.  When that happens you just find yourself staring at him, doing your best to manage around him and sometimes, since no one else will listen,  talking to him.

That's what this blog is all about. Observations and stories about the various and sundry gorillas I've encountered within my years as a high tech professional. So welcome to my observations, ideas, challenges and triumphs in dealing with the "gorilla in the room". 

Wendy calls her gorilla Stanley.

I call my gorilla Hogarth.

What do you call your gorilla?

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

*- The title of this blog was inspired by Wendy WorthingtonBarnes and I would be remiss without giving her the proper credit. When I wanted to start this blog, my thoughts for a title were very disconnected with what I wanted to do with the blog. She reminded me about the gorilla in the room and how often we face it and the rest, as they say, is history.