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.

 
 

The Career Management Gorilla

There I sat, skimming through Monster job listings. "Out of state, not enough pay, under qualified, over qualified.. Ah ha!" Like it was outlined in glowing neon letters, it jumped out at me. Perfect location, good benefits, looked like it would pay just right.

I clicked on the 'apply now' button with eager glee. I browsed to my job hunting folder and found my resume, jbancroftconnors_resume. Smiling ear to ear I moved my mouse over the submit button. And that's when the smell of ripe banana hit me.

"Yur not gonna send that are you?"

Turning in my seat I looked up at Hogarth. "Of course I am. I'm perfect for this job. Heck it even ties into my old art school background."

Waving his half eaten banana at the screen my resident gorilla grunted, "Yeah but your resume doesn't mention that. And look here, the job is asking for someone who's worked with call centers in Ireland."

I grin cheerfully, "Right! And I've worked with Ireland in my last two jobs!"

"And your resume doesn't say that. Aren't you gonna customize it for this job?"

Sigh… The dreaded resume tailoring gorilla. We all know we should do it. Some of us do it, some of us never do it and others agonize for days to make each and every resume just perfectly right. Two things are a given with resume tailoring. 1- It's a good idea. 2- It's time consuming.

Regular exercise is a good idea too, want to know the last time I hit the gym?

Still, Hogarth had a point. I had fallen into the online application rut. I was using a 'good enough' resume and no cover letter. It's a wonder I got any phone calls (okay so to be fair, I was doing the networking thing and writing cover letters, but I was not customizing my resume).

Knowing I was doing it wrong but also being an efficiency minded project manager I sought a better way of doing things.

Enter the "Career Management Document". Full credit goes to Mike and Mark of Manager Tools. Their "Your Resume Stinks!" and "Accomplishments- Connecting your Resume and Interviews" pod casts gave me the idea for this. In these casts Mark Horstman describes how your resume should never be more than a single page, but your list of job accomplishments are not tied to the actual resume. Create a "Career Management" document (CMD) in which you have all the jobs you've worked. Under each job you list all your notable accomplishments, not just the ones that are current. Every three months you go through your CMD and look at all the jobs. Maybe you just got done with an ugly budget process and you remember that ten years ago you had to fix a budget on short notice. So you go back and update that old job with the accomplishment.

Then for every job you apply for, you go through and pick 3-5 accomplishments that make the most sense. Instead of manually crafting every resume, for every job, you take your 'Chinese menu' and pick what works.

Personally I use Mindmanager, from Mindjet to manage my CMD. I've got a Mind Map with bubbles for each of my jobs, career over view and my professional qualifications. I can export it to a word document, cut out what I don't need and bam! I have a tailored resume.

Here's a sample of what it looks like:

http://i18.photobucket.com/albums/b128/Welshman_BC/CMDTemplate.jpg

So with my career management gorilla appeased, I hit submit on my next great career. And a few months later, I'm very happy with that new job.

If you are interested in a copy of my MindMap template or want a PDF of the template, just send an email.

So until next time, don't forget to talk to your gorilla.

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.

The gorilla with too many hats

"So that said, can you code?"


I look across the interview table. Well okay I look at the telephone, cause I'm in the companies office but the person I'm interviewing with is sitting in his house 20 miles away. But that's another gorilla.


So I look at the phone.


I look down at my resume.


I look at the job description for this job.


Apparently, my interviewer takes my stunned silence for a request for more information. "Cause you see, we're running lean and we need people to do more than one thing. We might have to send you out to do a customer implementation by yourself. So how's your coding?"


Now Hogarth doesn't mind that the guy is on the phone. He's taking advantage of that by taking up the other two chairs in the room. "Welcome to the Teens, dude. If you can't do it all, then you're not good enough. Everyone has to work harder these days. If you can't code, do a balance sheet, fly to Malaysia for the weekend to close a sale and then get back on Monday to make sure the 300 person software roll out is on schedule, then you're no good to them."



Sigh… The "multi-hat gorilla"

Now Hogarth is right, to an extent. 2010 will probably go down as the year of 'do more'. With the global recession we are all being asked to work harder and do more in our jobs. It's part of the downside of the recession and the trend of higher productivity.

I'm all for productivity, but there's a difference between productivity and continuous partial attention. As you might guess, I'm not a fan of the CPA concept. Studies have proven (UCSD Study, MSFT Findings, just to name the first two I Googled) interruptions seriously affect performance. A single 30 second interruption can result in a 15 minute work loss.

I look back at the phone, "I don't code, that's what the engineer is for. My value is in making it so the engineer can focus on his job and not on the surrounding project issues. If you have four engineers working on the project of this size, adding a fifth one is already starting to hit that wall of diminishing return. If you add a dedicated program manager, you can get more productivity from those four engineers, than you would from adding a fifth engineer and expecting one or more of those engineers to also manage the customer relationships, deadlines, certifications, interface with marketing, etc."

"Uh huh…." came the reply from the phone. "So you don't code?"

Some gorillas are just better to let be.

There is value in improved productivity and we're doing more with less is the new norm. But all that said, a good, solid, project manager can make a team run more efficiently than just tossing another engineer on the pile. At least that's what Hogarth and I think.

Joel BC
Veteran, the Project Manager wars
Want me to talk to your gorilla? Send me an email

Book Review- Evaluating Project Decisions

Greetings all!

 

After a long holiday break Hogarth and I are finally back. Hogarth is still getting over a banana hang over so today we'll take a break from our normal format to offer up a book review.

 

I am a member of the Bay Area Agile Planning Leadership Network. Recently BayAPLN was asked to review a selection of books. I volunteered, hoping to learn about some new tools and pass on my review for others at the same time. Now, Hogarth and I do not take our commitments lightly. So when we agreed to review "Evaluating Project Decisions - Case Studies In Software Engineering" by Carol L Hoover, Mel Rosso-Llopart and Gil Taran, we were bound and determined to read the book and provide the best possible review.

Well you know what they say about good intentions? Over the course of a month, I attempted to complete the book. I actually ended up scheduling time on my calendar and even using self rewards for every section I finished reading. In the end I was only able to plow halfway through the book before I finally gave up.

So to start with the bottom line up front, I give this book a failing grade. The only place I would recommend someone read this book, is if they are taking a course that it is required reading and they do not know anything about project management what so ever. There were several things that culminated in my rating of this book. A number of these so grievous, to be enough to prevent me from ever recommending the book on their own. Together they compile up that I can't in good conscience recommend this book at all.

The highly academic bent of the book is not in and of itself a bad thing. There are many well written text books out there. The thing is, they are supposed to be Text books and are tied to a course that will fill in the missing information. "Evaluating" did not actually give you answers or final solutions to the case studies. Instead the case studies all ended with a Case Analysis section that asked a bunch of questions. This is fine for a text book that leads to a class lecture, but as a business book on project management it failed to deliver. I was left wanting to know the analysis, but instead was faced with a homework assignment.

The explanation portions of each chapter were likewise difficult for me to absorb. The authors provided what I found to be simplistic overviews of what I consider basic foundational project management. For a computer sciences bachelor student the overview is probably helpful, likely having minimal exposure to project management principles. For anyone with even a few years in the software industry, the text would have been a very dry review.

After the third chapter of project management for dummies, capped by case studies that didn't actually give suggested solutions I finally set the book aside. The flavor of the book and the errors I had run head long into had finally built up to make it impossible to complete the book.

Speaking of those errors, those are perhaps the single largest contributor to why I finally gave up. Faced with text that was dry and offered little new concepts was difficult enough. But when I was questioning every fact in the book, it just made it impossible to continue.

Errors ranged from obvious grammar errors, ones I could spot and I'm known for my own poor grammar to basic fact issues like you don't take a few days to "Jaunt on the San Francisco Bay". SF Bay is the kind of bay you go out for a few hours and then go home. It was however the Earthquake fiasco that so irreparably shook my faith in the authors ability to fact check that I began to question if they were not just making things up to fit their findings and premise.

For those who really want to know I've included my rant (I can't justifiably call it anything else) about the Earthquake fiasco below.

For the rest, I must again advise against the reading of this book unless assigned by your professor. And even then, I'd reconsider that class if the professor is using this as their source material.

For Hogarth and myself I bid you happy project management dreams,

Joel BC

Veteran, the Project Manager wars

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

The Earthquake fiasco:

I made it only as far as page ten before I found myself deeply questioning the book. The authors created a case study called the "California Bridge Problem". So wrought with errors was this case study, that I immediately found myself questioning everything else I read. This wasn't some minor little error, this case study was so rife with errors the facts presented almost seemed to be 'adjusted' to fit the needs of the story. Anyone who spent even a twenty minutes with Google will note the massive errors. Having lived in California all my life I didn't even need twenty minutes to question everything this book had to say.

"It can't be that bad you say?"

Well let's see:

• 
  
  The Authors merged the 1989 Loma Prieta and 1994 Northridge earthquakes into a single event.
  
  
  They said it occurred in 1991 (This is the date of yet a third somehwhat famous quake called the Sierra Madre quake).
  
  
• The ascribed the quake as an 8.49. The Loma Prieta quake was a 7.0 and the Northridge a 6.7. The Richter scale is a logrithmic scale, so an 8.5 quake would be equal 5.5 gigtons of TNT a 7.0 only 32 gigtons. Just a little off in the power. There are only 7 recorded quakes of 8.1 or greater in known history. One of them is the one caused by the asteroid that killed the dinosaurs!
• The stated the quake lasted two minutes. Both quakes were around 20 seconds. Quakes of two minutes in length are incredibly rare and usually much stronger.
• They claimed the Bay Bridge collapsed because of inadequate concrete columns. No the bay Bridge is a metal structure. It was freeway overpasses that collapsed in both the 89 and 94 quake.
• Even the proposed new way of building bridges missed the mark. Encasing in steel sleeves was a suggested retrofit for existing highway bridges that could not be built to the new recommended spiral reinforcements. 

Yeah it was bad... And you know how I feel about not addressing the Gorilla in the Room.