PM Mini Humor

How many PMs does it take to change a light bulb?....

I've always believed that a project manager who can't laugh at themselves is a project manger who's headed for serious heart burn. So with that...

…Two, one to change the light bulb and one to tell the other how much faster it would have gone using Agile.

Project Gorillas are Subject Matter Experts

Note: For new Gorilla Blogs, head over to The Gorilla Coach
[Non-legal mumbo jumbo: This piece was inspired by a conversation with fellow PMs at a Silicon Valley PMI job search networking breakfast. That conversation inspired me to write this little piece of fiction to bring my revelations to light. This blog goes the next step beyond the "Too many hat" blog that I did in February.]

  "Well it's rather complicated", the words were spoken by the pleasantly smiling engineering director. Having heard this lead in more than once, I instantly translated it to "I don't expect you to understand, you don't have a double masters in computer science and physics." Not that I said anything, I smiled back serenely and listened as he dove into a highly technical discussion that lost me in the first three sentences. But that was fine,


  I leaned back in my chair and watched as he grabbed a white board pen to start diagramming.
As he launched into a multi-level architectural diagram, in handwriting that would have confused a pharmacist, I glanced over at Hogarth. My gorilla was on the other side of the room, happily mapping out a Rube Goldberg machine. As near as I could tell it was a machine designed to give the Engineering director a wet willy through the use of canned air and plant sprinkler. Hogarth had also heard this speech before.


  A couple minutes later the director sat down, a look a satisfaction on his face. I looked up at the whiteboard, looked back at my notes. I then turned and looked at one of the software managers. She and I were old colleagues and I trusted her input completely. She'd already sent a status update that had given a high level status. Quoting it almost exactly I said "So you can't get the network layer to talk to the application layer and you think it will take four weeks to fix?"


 "Well if you want to boil it down to that…"


 "Yes, yes I do." I said, looking at Hogarth's satisfied banana grin.


  For want of a name, let's call this the "SME means you don't understand" gorilla. Spend a little time on any of the job search websites and you'll see a very common trend in Project Management job descriptions. It is couched in various ways, but essentially it boils down to PM jobs "requiring" expertise in whatever field the product being project managed belongs in. Working on an ERP deployment? Then they want you to be an ERP expert, preferably someone who's coded and deployed. Building the next best hand held device to use Android? Then they are probably asking for a degree in electrical engineering or at least mechanical engineering.

    In the end it typically boils down to a long list of very project management related skills, communication, organizations, facilitation, working with remote teams, etc., all topped off by a cherry of expertise in some highly specific job field (There is really a field called Human Ecology Engineering). The end result being jobs that become very tailor made to a specific job or industry. Best project manager there has ever been at your computer game company? That's great, but you've got no manufacturing experience so there is no way you could be a good project manager for a new line of toys. You do not have subject matter expertise, so you are not qualified. Even my beloved Manager Tools reinforces this concept to some degree. They describe three methods of management power, Role, Influence and Expertise. It is usually implied that expertise is SME knowledge in the industry or product you are working on.


My challenge to all this is simple. As a project manager I am a Subject Matter Expert, in Project Management.


     A Project Manager's SME knowledge is in getting a project from inception to launch with in the bounds of the project's constraints and while keeping the team from flying apart like wine glass shattering when it hits the floor.

     Let me explain a bit more- Project Management has officially been around since the first US Nuclear submarines. Such massive projects with very tight dependencies between teams, needed someone who could oversea the whole thing. These first PMs were usually taken from heads of a department or some senior engineer. He might not understand the full workings of the nuclear reactor, but he was a PhD. in naval structural engineering (or vis a versa).

    Moving through the close of the 20th century, project managers were typically pulled from a 'technical' field. The majority of PMs tended to be from engineering backgrounds of some kind. A large chunk of the rest rose up from the ranks of whatever they had been doing. A Logistics Planner had served on the front lines of shipping for years, before being tapped to coordinate a global logistics plan.

     It was not until the close of the 20th that this really began to shift. We started to see PMs who came out of business backgrounds. They still very much tended to be experts in a field. If you hadn't worked in insurance, being a PM at a risk management firm was pretty much a no go.

     It hasn't been until the 21st century that we have started to see Project Managers as a truly distinct discipline of its own. In the early 2000's the CEO of PMI met with a major university about Project Management (Thanks  to Cornelius Fitcher for his great podcast series where I learned this). The university was adamant that Project Management was a course, not a discipline. Today a Google search for Project Management Bachelor's Degree yields over 6.4 million hits.

     Today we are finally starting to see that Project Management is an area of expertise. The art/science of guiding something from start to finish is a critical and important as the art/science of laying out a PCBA board for the next great DVR product. The PM doesn't need to know the details of PCBA board layout. What he needs is the vocabulary to communicate with the guy who does know about PCBA and the mutual trust of a well communicating team.

     At the very fundamentals, I believe that a good Project Manager can manage any project. There are of course the typical caveats on "any" but I truly believe that PMs are far more industry portable than most industries seem to be ready to concede.
I've had this conversation with several people in the last couple of years. As you can imagine I've met with a fair amount of resistance to the concept. I had an IT PM adamantly insist that if you weren't an expert in IT infrastructure, or some major component of IT, then there was no way you could be a PM in IT.

     "Kind of like a software PM going to work for a Hard Disk manufacturer?"

     "Exactly!"

     Well I may not convince everyone, but I for one am confident in my Project Management skills. How can I not be? I started as a Customer Support rep giving game hints for the Nintendo game console. I've worked in handheld devices, mobile phones, consumer software, voice recognition, enterprise storage software, virtualization, and more. My most current job? I'm that former Software PM doing program management at a hard drive company. One of the best compliments I have ever gotten was from my current boss. "I hired you because you don't have twenty years of HDD baggage. I needed someone who would focus on the project."


On the front lines,
Joel BC
Veteran, the Project Manager wars
Want me to talk to your gorilla? Send me an email
You can follow me on twitter, @JBC_PMP


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

The Ninety Day Gorilla

[Non-legal mumbo jumbo: This piece is wholly made up based on multiple experiences I've seen and heard over the last 20 years. It does not reflect any actual single event. ]

They say walls have ears. Well they may not have ears, but the rice paper thin walls here means it's hard not to hear the conversation in the next office over.


"Thank you for coming, 'Bob'." shuffle, shuffle, "It's been an interesting four months, I have to say you've tackled this job with an impressive level of vigor."


"Uh oh…" I hear from behind me. I turn around to look at Hogarth. He's perched on the window sill soaking up what little sun makes it through the cloud cover. "That doesn't sound good…" I try to puzzle out what he means by that, in the process missing the next bit of the conversation next door. The raised voice pulls me back to my eavesdropping.


"I don't understand!" 'Bob' voices plaintively " When you hired me, you said you wanted me to shake things up, hit the ground running, get things done. Didn't I do that?"


Long pause, "Yes, you definitely hit the ground running and the Project Meddigo processes will definitely improve delivery time. The problem is, 'Bob', no one wants to work with you, everyone has complained about how you shoved the process through. one of the team went so far as to say if he heard you utter "in my last company" one more time, he was going to shove you out a window…"


I turned to look at Hogarth. He shook his big, black, hairy head, "Ouch."


I nodded in return. Poor 'Bob', he just ran head long into the 90 day Gorilla and it smacked him down, hard.



Ask yourself this, when was the last time you saw a new CEO come into a company and instantly start changing everything? Unless you're Donald Trump or Lee Iacocca, most CEOs won't last long doing that. Almost without fail a new C-Level exec doesn't change a thing in his first three to six months.

It is fundamentally no different for a Project Manager. It doesn't matter if you spent twenty years at HP, at Mid Size Company X, you just joined. Even if you've got friends in the team, you are still a new face, a new change, something to get used to. And in business, first impressions are king.

When you join a new company, or even a new department, those initial few weeks are when you either become part of the team, or forever place yourself on the outside. Some relationship experts say it takes over 600 positive events, to erase a single negative event. So how you first interact with your co-workers, your bosses, your reports, will be pretty much be how you are seen for the remainder of your time in that job.

In a job interview once, I told the interviewer "Virtually any project manager can get virtually any project from point A to point B essentially on time and in scope, once." That "once" is the key. A PM that burns out their team, will be hard pressed to motivate them again. It's the difference between building a team and driving a team. Unless you are a highly paid consultant than you can't really storm the gates to get the job done (and good consultants don't even try to do this). If you do storm the gates, when it is time to do it all over again, the team won't want anything to do with you. A good project manager can get most projects from point A to point B, but then he can do it all over again, with the same people.

I personally believe in the mantra of "Do no harm in your first ninety days." This is your time to listen, to watch, to ask questions, to learn and most importantly, to build trust. You need to build that trust with your new team and one of the best ways to build trust is the listen and ask, intelligent, questions. One way to ask intelligent questions is to "interview" the people you interact with. I've successfully used the ManagerTools PodCast entitled "Jump Starting Internal Customer Relationships." There is an incredible amount of value in sitting down with the people you work with to ask "what can I do to help you?"

I had someone challenge me on this rule recently. They said that if you hadn't made an impact in the first 90 days, then you'd be out. To this I say, there is a difference between "making and impact" and "doing no harm." If you spend your first three months learning, asking questions, finding out how things work, then you've made an impact and you've built trust. And that trust will allow you to have a much greater impact in the next nine months, that overshadows any amount of quick wins you might have gotten in those first 90 days.

You don't start a friendship by telling them how great and wonderful your last friend was, so don't start your job the same way.

On the front lines,
Joel BC
Veteran, the Project Manager wars
Want me to talk to your gorilla? Send me an email
You can follow me on twitter, @JBC_PMP


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

Gorilla Documentation- Why did we do this?

I sat back in my chair, trying to determine at what point I had lost all control of the meeting. I mean as a project manager it is pretty important to be in control, so it is doubly so to know at what point you absolutely and without a doubt lost control.


I think it was the moment the Exec asked "Why the hell is unicorn blue?!" (Okay it's not a unicorn and it wasn't blue, but for the sake of this blog it's a unicorn and it's now blue). This was promptly followed by a verbal scramble and near physical scramble. The QA guy looked at the engineering guy, who looked at the product manager, who did the fish out of water routine for a moment. He then launched into a halting rendition on how the unicorn priorities had changed based on competitive market differentiation (Our chief competitor already had a white unicorn and all), but when questioned on details (you know, cost of change, can we charge more, how this would change our market mix, etc) he fumbled with his computer trying to look up the data. At this point I vainly stepped into the fray to meekly say "We reviewed this a couple of months ago and you agreed." To which the Exec replied, "I don't remember that. I wanted it white, change it back."


No, I guess when I really lost control was when the engineering guy helpfully piped up that it would be a four week slip to change back to white. Yes, that's where I lost control.

"You know…" drawled Hogarth from the corner. I turned my head to look at the hulky form of my gorilla. He was sipping on a banana daiquiri without a care in the world. "If you had a Change Control process in place…" he left his sentence unfinished. Not that he really needed to finish it, I was all too aware of the unspoken end of this statement.


Yes, I'd run smack dab into the "We already decided this" gorilla. I tend to call him Deja, as in "Haven't we done this already?"



Change Control is an often forgotten process. Whether you call them Engineering Change Requests, Project Change Requests, replace Request with Order or something else, the process of documenting changes to the project, after the project has been kicked off is often left at the side of the curb of the project management super store.

It can start innocently and well meaning enough, "Oh, we just had the Plan of Record, we'll just update that", or "The schedule slip can't be changed, no point in going through a PCO review", and the best one "It's just a little change."

It's a slippery slope, do you let process paralyze you, slow you down, impede needed change? Or do you dive forward, intent on the end goal and not know exactly what you have when you get there.

How about neither? It's a fine line. Agile's Scrum demonstrates that change is a good thing, you don't want to have a product that isn't what you need when it is finally done. On the opposite side, if you have no clear idea of what the product is, how do you sell it? Even better, how are the poor souls in Customer Support supposed to support it?

I always approach this with a simple concept. I tell my team two key things. First, "Change isn't bad. This isn't about putting a roadblock up to stop change, it's about making sure everyone knows what is happening and what they need to do. The second thing is, "Six months from now, when the CEO asks why the hell it's pink, we can show her why and the reasoning why."

I even use the PCO form to document the undeniable. Our primary source of Widget Goo burned down and the product will be four weeks late as a result. It's not like anyone is going to reject the schedule change PCO for that, right? Right? So I go and fill out the PCO form, document it was a forced approval and file it with the rest.

PCOs are like a breadcrumb trail. They take you from the final product, all the way back to the project contract and show you how you got from a White Unicorn, to a Green Ogre.

And another big this about change control, change isn't a bad thin…

"Ah, ah…" Hogarth piped up. "That's a whole other gorilla."

He's right, change is good is a topic for another day. F
On the front lines,
Joel BC
Veteran, the Project Manager wars
Want me to talk to your gorilla? Send me an email
You can follow me on twitter, @JBC_PMP


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

[Non-legal mumbo jumbo: As a reminder, all these tales are either based on a wide amalgam of events over my career or completely made up tales to convey a certain point. None of these blogs represents a specific instance or specific people.]

Lost in Blackberry menus

Hogarth has the day off today. This is just a quick snap shot from the Project Manager wars.

 
 

I've worked in Silicon Valley for a very long time. In that time I have managed to completely avoid ever having to carry a BlackBerry. In fact until last year I avoided any kind of mobile email device. Last year I became an iPhone user at work and have kept using it as a personal device. Never having used a smart phone, I came up to speed on the iPhone in about two days. The interface was easy to understand, the menus were logical, and it was fast to make changes. Two weeks in, I was a pro. I could make my iPhone sit up and do tricks and I started not carrying my laptop around. I had all the data I needed right there on my phone.

 
 

I got a BlackBerry two weeks ago….

 
 

It took me about three days to understand why BlackBerry is still such a power house. It's spent the last fifteen years training its users. I'm two weeks in and the urge to hurl the device across the parking lot comes about twice a day. It does everything but wash the windows, but figuring out how to get it to not vibrate for anything but Calendar reminders is still baffling me. Heck, I even googled it and I'm still confused. If you have been using the BB for years, I'm sure it is all second nature to you. For someone new to the interface, I feel like I'm trying to understand how reverse derivative debt swaps work with a kindergarten level user manual.

 
 

Now if you'll excuse me, I'm six menus into the ring tone preferences and I need to call for a St Bernard rescue dog to lead me out.

 
 

Joel BC

Veteran, the Project Manager wars

Want me to talk to your gorilla? Send me an email

 
 

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