Sometimes a Gorilla is just a Gorilla


“You’ll thank me for this. It’s going to make you so much more productive.”

Jake eyed the spreadsheet dubiously. I suppose I could understand his reticence. At first glance the Systematic Total Universal Program Iteration Document was a bit of an eye chart. I hadn’t understood it really until I’d taken the five day intensive training. But hey, now that I was trained I knew this was the absolute best thing I’ve ever seen. Ever!

“And I have to update this every week?” he asked.

I shodded my head. (You know, when you start to nod your head and then shake it no?) “Well that tab yes, click this other tab for the daily report.”

Jake complied, his eyebrow crawling into his hairline when he did. “This… This is a daily report.”

I nodded enthusiastically. “Uh huh, we’ll always know where the project is now.”

Jake closed his laptop and gathered up his stuff. I could see he was in a daze. Probably thinking about just how productive this was going to make him, once he finished the training. As he walked past me I heard him whisper ,”Yeah, this is definitely stupid.”

I held up a finger, “It’s pronounced ESS-tup-Id .”

Jake stopped for a moment. Then shaking his head, he kept going.

I tugged at my beard. “Well that was weird.”

“Weird in that he didn’t feed you his computer, or weird in that you thought that actually went well?”

Why did he always have to come and ruin my mood? “Hogarth, I don’t need your help. Things are going just fine. The new process is going to be a wonder.”

Hogarth’s looming form pushed off the wall and made its way over to the conference table. “I was more thinking blunder, but hey they do rhyme. “

“Blunder? Have you been smoking banana peals again. What are you going on about?”

Hogarth settled into a chair, easing back slowly as it desperately protested. “I’ll have you know I was drying those peals for a science experiment.” He waggled a leathery hand at me. “You’re playing with your shiny new toys again.”


Hogarth leveled his deep brown eyes at me. “If it works, don’t fix it.”



Way back in 2009 I introduced folks to PIG, the Process Inflexibility Gorilla. In that blog I gave folks the screwdriver argument , which is a useful analogy for why you want to be able to support more than one process, tool or way of thinking.

In a nutshell, the screwdriver argument is:

“If you have the world’s best screwdriver and you’re locked in a room with lug bolts, all you have is a pointy stick.”

And flexibility is a good thing. It’s a key tenet of agile and many leading management techniques. I’m all for flexibility. I’m all for trying something new and innovative. And I’m also aware that I suffer from the all to common failing of…

Red Ferrari Sports Car

“Oooooh, shiny…”

Sorry, where were we? Oh, right, shiny. Back in the 90’s there was a US SitCom called “Home Improvement.” In the show, the lead character (Tim Allen) was a bumbling suburban dad with a TV Show where he was a tools “expert.” Without fail, if he got a hold of a new tool, he had to use it and he had to use it right then. Even if it meant he ended up dropping a crane load on his wife’s classic car.

New toy syndrome can be the death knell of many a good project. The latest fad comes along (we talk about fads in “Agile- A Gorilla Four letter word?”) and off the company goes. Who moved my cheese, Trust Courses, Yell Thereby, African Expeditions, Survivor Board Room, you name it, we’ll try it. All in the blind attempt to find a better way. Only do we need a better way?

If the orders are shipping on time, order placement productivity is high, the customer is happy and the company is doing well, do you really need to shake everything up and put an entirely new ERP system in? Probably not. And yet I’ve seen it done. A complete replacement of a tools system because the new tool would be cheaper, so what if it doesn’t have all the features we need right now, their professional services said they can build us what we need.

New toy syndrome can strike our projects as well, though sometimes it can be old toy. I worked at one company in a division that had been acquired from the outside. The division was acquired because they understood a specific target market and knew how to build and sell to that market. The buying company then proceeded to try and impose its monolith process on the new division. A process designed to build technology that took from 2-3 years to develop was laid on top of an organization that regularly went from concept to ship in less than six months. And then the big company was confused by why the new division was doing so poorly.

You know, I could go on. But in the end, I think Hogarth summed it up perfectly.

“If it works, don’t fix it.”

Talking to gorillas, I’m Joel BC

One thought on “Sometimes a Gorilla is just a Gorilla

  1. Pingback: New PM Articles for the Week of August 6 – 12 | The Practicing IT Project Manager

Leave a Reply