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.]