But I like cake Gorilla

I look up from my computer screen, grinning. "So, Hogarth, how can you tell the project manager in the room?"

My Gorilla turns from the mini Christmas tree on my bookshelf. Holding the tiny glass ornament in his big hand he cocks a hairy eyebrow, "How?"

"By the knives in his back!" I grin merrily at the self deprecating joke.

Hogarth cocks his head to the side, peering at me quizzically, "But I like cake."

"What?" I return Hogarth's quizzical gaze. "Hogarth, what are you talking about?"

"I like cake, I'd rather use those knives to cut up the project end celebration cake."

And my retelling of a classic project management joke runs smack dab into the practicality of my Gorilla. In his own cake loving way he reminds me that there is more to a project than earning initial trust and delivering the project. In the 21st century, nine times out of ten, you have to get that team turned around and do it all over again.

Suddenly the joke loses its appeal. Not because we project managers can't make fun of ourselves, but because of the grains of truth in the joke. I touch on this in my 90 Day Gorilla post, but it goes beyond that first 90 days. If you are not constantly working on your relationship with your team, you will soon find that team wants nothing more than to see you go away. Sure you've helped their efficiency, you've helped their profitability, you've helped their exposure, but if they don't want to work with you, you've not helped yourself and the team won't work as well the next time.

Mark Horstman talks about MBWA, Management By Walking Around. This is just the tip of the iceberg, but is a great example in a nutshell. The key point on this is if you do not constantly work to make sure you have a good relationship, then at the end of the project you will be the one with the knife in your back, instead of using that knife to cut the cake.


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 Holiday Job Hunt Gorilla

[This blog is dedicated to Skip La Fetra, facilitator of the Silicon valley PMI job search breakfast. He led a great meeting that tackled this gorilla in a wonderful way and inspired this blog.]

The jingle of bells battered my skull like a thousand tiny anvils being dropped from orbit. Grabbing my skull I turned from my desk to take in a sight I immediately wished I could erase from my memory.

"Hogarth! What in the Sam Hill are you doing?"

My gorilla looked down at the red velveteen jacket he wore, shaking his head as he did so. With the jingling of his bell bestrewed hat nearly overpowering his words, he said "Well I admit old St. Nick shares the red theme with Bealzabub, but isn't it taking things a bit far to accuse him of being devil and not elf?"

I rolled my eyes, trying not to let Hogarth's verbal judo distract me from exactly why he was dressed up like a Christmas in the jungle reject. "Why the heck are dressed like that?"

"For the holiday party" he replied, his tone so bubbly it could make Champagne feel impotent.

"Party?" I sighed. "Hogarth, I'm not going to any party."

"You're not?" he replied crestfallen. "So back to pinging your network contacts and checking job boards?"


I threw up my hands, "What's the point? It's the middle of December, I'm not going to get a job now. I just want to wash my hands of all this, try and enjoy Christmas and I'll get back to looking in January."

Now imaginary gorillas should be fairly benign, after all you've thought them up, right? So when he walked over and smacked me upside the head I was understandably surprised. "Ow! What was that for?"

"To snap you out of your Dickensian moroseness " he said. "Cause I'm the 800 pound gorilla in the room and I'm not leaving until you deal with your attitude."


And there I was, having literally been hit over the head by the "Holiday Job Hunt Gorilla"

I have had the experience of being unemployed over the US holiday season (Oct 31st to Jan 1st), twice in my professional career. The two experiences were stark opposites of each other and show a clear example of why the holidays is the time to Speed Up, not Slow Down your job hunt.

In my first experience , I all but hid from my unemployment, trying to deny it was there and giving all sorts of justifications to not make even a token effort to look for work. I also completely ignored every bit of advice I give in my own career insurance blog. Not only did I end up hiding from my lack of a job through Christmas, when the new year came along I had lost all my momentum, all my drive. I eventually landed a new job, but it was more luck than my own actions. I was out of work for the better part of a year that time, an experience I never wanted to repeat again in my life.

In my second experience I was laid off from my company on Sept 30th. I started my new job on Feb 2nd, nearly four months exactly. More importantly, between Dec 20th and Jan 1st I was speaking with three different companies and even interviewed in the week between Christmas and New Years. I not only followed my own advice (learned almost word for word from manager-tools.com) but I sped up my efforts over the holidays. I took advantage of the hidden benefits of the season to accelerate myself into a great job.

No, I think the holidays can be argued as being the best time to search for a job, or to at the least close in on that next job prospect. There is a natural spirit of giving and kindness in the season, that is not limited to department store Santas and It's a Wonderful Life reruns.

During a Silicon Valley PMI Job Search Breakfast the attendees came up with the following, excellent, list of things to do in the holiday season.

- Don't slow down. This is not the time to slow your pace, but to increase it.

- Most companies operate their Fiscal Calendar from Jan to Dec, so their year is ending. This means their new budget year starts in January. They already know their budget and likely have started their job reqs.

- Holiday parties are not a time to bemoan, but a time to network with friends and colleagues. Make sure your business cards are up to date and plentiful.

- It is the season of giving, take advantage of people's natural tendency to be more open and giving to approach them.

- Be prepared for rapid response "can you come in tomorrow?" This is very common in the holidays.

- Do NOT underestimate the power of the thank you note! If you were good about sending "Thank You" notes during your first interviews then you can follow up with a Christmas cards to reopen your communication with the hiring firm.

- The holidays give you a readymade excuse to reach out to an old colleague who you fell out of touch with. Haven't talked to Bob in a year? Send him a holiday card and reconnect, then stay connected.

- If you get a job sent to you and it is not for you, think of who you know that might fit. Keep up your spirit of giving and helping and it will come back to you.

In the end, it boils down to a very simple mantra "Don't Slow Down, Do Speed Up and remember all your job hunt and networking basics."

Wishing you all the happiest and most successful of holiday seasons!

Joel BC
The Gorilla Talker
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.

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.

 
 

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.