Sometimes the biggest issues facing a project manager, are the ones no one wants to talk about. These tales talk about that gorilla in the room and how to tackle him.
Tuesday, November 9, 2010
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,
Veteran, the Project Manager wars
Want me to talk to your gorilla? Send me an email
You can follow me on twitter, @JBC_PMP
[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.]
Take a little bit of the Lazy Project Manager, sprinkle in a healthy dose of Manager-Tools.com, a shake of Covey's 7 Habits and mix it with a “been there, done that, got the polo shirt” project management professional and you have Joel Bancroft-Connors, the Gorilla Project Manager.
In my time as a project manager I’ve made my own share of mis-steps and seen some outright disasters. My goal is to help others not make the same pitfalls so many of us have made already. If, in the process, I can bring a smile to a face then all the better. A happy project manager is a successful project manager.
In my spare time, between family and job, I love to write. Whether it's the Gorilla blog or fun fiction, putting pen to paper gives me a great amount of satisfaction.