Armchair gorilla

Note: For new Gorilla Blogs, head over to The Gorilla Coach

- Or walk a mile in the gorilla's shoes

This blog inspired by Tobias Meyer's recent blog "Scrum is not Project Management"

Normally I don't let Hogarth follow me home. There are limits and that's just one of them. The thought of an 800 pound gorilla on my couch is a terrifying one. And then there is what he does to the refrigerator. Did I mention gorilla hair on the white carpet? But it was the Superbowl and I had a moment of weakness.

"Come on! You call that a pass? My mother can throw better than that." I angrily waved at the TV while speaking through a mouthful of Dorritos. "Can you believe this guy, Hogarth? That play had blitz written all over it. I swear even a deaf bat could have seen it."

Hogarth looked at the dried banana chip poised to be popped into his mouth, then looked at me, then looked back to the chip. Sighing he lowered the chip and gave me a reproachful look.

"How much football have you played?" He asked.

I looked aghast, "Me? Last time I played footbal, it was with flags and I was still too young to vote."

Hogarth gave a sage nod. "I see. I bet you didn't even stay in a Holiday In Express last night."

It was my turn to sigh. "Okay, okay, I get the point. Not only am I not there, but I'm not a quarterback, have never been a quarterback and don't have the first clue how to be a real quarterback." I shook my head, "I'm sitting here trying to second guess the expert. Talk about stupid."

Hogarth nodded again. And then he spoke, his words breaking the 4th wall and my own train of thought. "So why are you trying so hard to prove Tobias wrong?"

I turned to stare at Hogarth my mouth agape. No sound came forth despite the repeated opening and closing of my bass like mouth.

Why indeed?

I make my living doing a job that typically has the job title of "Project Manager" or "Program Manager." Given that, it may be understandable to you that my emotional reaction to Tobias' blog was to disagree.  I certainly did this initially. The first few comments I thought about leaving to his blog were much less reasoned than what I ended up posting.

And then, much like my revelation in "A Project Manager's Poker Hand," I came to a realization that I was trying to impose my own value on someone else. Worse yet, my value was based purely on emotional reaction, where as the opinion espoused by Tobias was based on subject matter expertise.

Yes, I have Scrum training, I've studied Scrum and I've even incorporated some Scrum concepts into product development efforts I've been involved in. But I am most certainly not a Scrum expert. I've never worked on a classic Scrum team and I can't speak from first hand experience.

Tobias on the other hand has. He is a recognized expert on Scrum teams and Scrum development. Without my own "traditional" Scrum experiences, I have to put faith and trust on Tobias speaking from that expertise.  I don't know enough about a straight Scrum project to know if a "traditional" project manager would bring any value. I certainly hope to learn and understand more as I delve into the Agile philosophy, but for now I have to take Tobias at his word. Just as the Product Owner must trust the teams estimates, I should trust Tobias' expertise.

So as the saying goes, "Don't judge another, until you've walked a mile in their shoes."

All right, so Scrum is not Project Management.

What is project management then?

It was something of a wake up call to read some of the very acerbic comments posted both in Tobias' blog and Ken Schwaber's blog that inspired Tobias' blog (Yes I'm a response to a response). That people think project management is an evil tool of "corporate" or an "idea whose time has passed," was not something to cross my mind. Even Ken's own words had me blinking in confusion.

"We have found that the role of the project manager is counterproductive in complex, creative work. The project manager’s thinking, as represented by the project plan, constrains the creativity and intelligence of everyone else on the project to that of the plan, rather than engaging everyone’s intelligence to best solve the problems."

"Wow, that's not the project management I know" was my initial thought. I certainly have never felt I was stifling creativity or constraining anyone's intelligence. I was an art major in college and write science fiction as a hobby, not exactly what I would think of as an oppressive personality. Yet, the comments posted certainly had me wondering. I had to check myself in the mirror and make sure I wasn't wearing a black mask and breathing funny. <Darth Vader voice> You underestimate the power of project management.</voice>

So before I accepted my role in the dark side of corporate america, I decided to look for other definitions.

PMI's PMBoK defines project management as:

"Project management is the application of knowledge, skills, tools, and techniques to project activities to meet the project requirements."

And they define a project as:

"A project is a temporary endeavor undertaken to create a unique product, service or result. "

Okay, so not the most evocative words ever written. And I can already see issues with the definition of a project and the normal evolution of software. When version 1.0 ships, the team has usually already begun on version 1.1. Is the project the software as a whole or just v1.0. What is "done"?

Wikipedia, font of all knowledge, real, imagined and inaccurate, defines project management as:

"Project management is the discipline of planning, organizing, securing and managing resources to bring about the successful completion of specific project goals and objectives."

And Wiki defines a project as:

"A project in business and science is a collaborative enterprise, frequently involving research or design, that is carefully planned to achieve a particular aim."

Okay, so neither source's definition is going to make a kid say "Daddy, I want to be a project manager when I grow up." And honestly, neither source really describes what it is I do in my day to day job.

Certainly I spend time organizing and planning. I've both helped develop goals and objectives for a project and served as a gatekeeper to ask if we'd met them. Goodness knows I have built a lot of knowledge, practiced a lot of skills and developed a big old toolbox of techniques. But I don't think that defines what I do in my job or why my boss keeps paying me to do that job.

I know some folks think of project management as the "Owner" of a project. I've known project managers who "owned" the project. They were the almighty power and controlled the budget, the people, the project and final deliverables. This does still happen, but at least in the high tech firms I've worked for, this is less and less common. The guy in charge of building a bridge is a project manager and also the head engineer, this guy is the "owner." A guy managing a software team doing an IT integration project is not the "owner". The team all report to functional managers and the guy managing is more like the cat herder (We won't go into the myth today).

So what is being a PM mean to me?

Well not to sound like a broken record, but I would stat by reaching back to my "The gorilla with too many hats" and "Project Managers are SMES" blogs to start answering this question.

"If you have four engineers working on the project..., adding a fifth one is already starting to hit that wall of diminishing return. If you add a 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."

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

I've been doing dedicated project/program management for a decade now. In that time I've never had any illusions of being "in charge" of a project. Long before I heard the first utterance of "Agile" or "Scrum" I was practicing servant-leadership.

I am the broom:  Pam Stanton as well as a good friend and fellow project manager, Carl Jones have both used an example that I think speaks to what a 21st century project manager is. They compare our job to that of the game of curling. The curler and the stone are the product/project team and the product being built. The Curler's (team's) goal is to get the stone (product) to the center of target area (release date, objectives, value needed, etc.). The Curler is the main person. Without him you don't have a game. But he is not alone.  The sweepers use brooms to alter the state of the ice in front of the stone.

A good project manager is like a curling sweeper. He gets in front of the product and makes sure there are no impediments (Test equipment was ordered, team has a place to work, external vendor is managed to deliver its dependencies, etc.), but also makes sure those things that have to be done (certifications, compliance, sponsor updates, etc.) get done.

Over the years I've developed my own personal philosophy/methodology to being what I am as a professional:

1. People, not projects
2. It's all about communication
3. Process is a tool, not a roadblock
4. There is no one, right way

I don't know if I'm a traditional project manager or program manager. I know I'm not a traditional scrum master and there isn't even a standard definition of an agile project manager. But at the end of the day I don't think any of that matters. Because what I know I am is:

Effective

Joel Bancroft-Connors

The Gorilla Project Manager

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 Flight 030 now departing...

"Arrgh! I already told you, he's no longer with the company!"

Bob's blood pressure had to be rising. Yes, his door was open, but I was also six cubes down the hall and could hear every word he said easily. He was talking on the phone, so I had to imagine what the other side was saying, but I could imagine.

"Look, I was his manager, I just want his laptop for a couple of hours so we can get some files off it. What? Yeah, fine, send me the paperwork and I'll sign it, just get me the laptop."

Tully had been a junior product manager, working for Bob. He'd been with us for about a year and he'd done such an amazing job that he'd been given the entire GARGAMEL product. And then MacroServe had recruited him away to work on their new game system. It was a dream job, dream pay and he'd jumped.

Only problem was he'd jumped only a week after giving notice and just before Bob left on a week trip to Asia. Tully handed his laptop off to IT and turned his badge over to the department admin on his last day. Bob had been chasing IT for the last week, to try and get Tully's computer and all the files related to GARGAMEL.

Two hours later, Gus, the IT guy, walked by towards Bob's office a laptop under his arm. Lumbering in his wake, Hogarth sidled into my cube. Plopping into the spare chair he grinned around a mouthful of banana.  "This is going to be good."

I raised my eyebrows to my gorilla. "What do you mean?"

"Wait for it…"

Two minutes later Gus walked back, headed for the basement lair of all things IT. I turned and looked at Hogarth, raising my eyebrow again. Peaking over the cover of "How to win friends and influence people" he said "Wait for it…"

A minute later I heard a strangled cry from Bob's office. This was followed by the most forceful phone dialing I've ever heard.

"Yes, this is Bob. Yeah, I got the laptop. NOW WHAT'S THE BLOODY PASSWORD!"

Hogarth set Carnagie's book down. "Ah Tully, the grass was so green he didn't stop to smell the roses of departure."

I think the scariest thing about Hogarth's words were that I understood what he meant completely.

Transition Planning, are you ready?

With the economy on the recovery we are not just seeing the jobless rate slowly creep down. We are also seeing the jobful starting to stick their heads up from their cubes and wonder if there might be a better cube out there. So say you have done that and the company down the road has offered you this really great cube. They really like you, they really want you to join their team and they made it worth your while.

So the question is, what about your current job?

"What do you mean whatta about my current job? I haven't had a raise in four years! After surviving four layoffs I'm doing the work of six and there isn't any sign the bosses want to hire again. Even if we have made huge profits the last two quarters."

Ah, yes. There can be any number of reasons why you have no regrets on leaving your current employer. Or you could even not want to leave, but this new job is the perfect career move or will mean you can start paying down your debt. The question is, what will you do in the time between your resignation and the last day?

If you follow Hogarth's advice, you're going to be a very busy person. Manager-Tools did a three podcast series on "How to resign" (link is to the first cast). In this cast Mark and Mike outline twelve steps to resigning. Some of these only apply if you have direct reports, a large chunk have to do with you personally. As project managers (or any effective individual contributor) the key points are:

‐ Prepare a Key Project Report – Transition File*

What is the current status of any projects you are working on? Where are all the documents located? Who is responsible for what?

This isn't a one page document, this is the keys to all your projects. Any files related to these projects should be put on a repository that can be accessed by multiple people.  With storage technology so compact, I'd also recommend putting your projects on a flash drive (A 4GB USB Thumb Drive is less than $15). You can hand that over to your boss an ensure the files will passed on.

Include the plans for the next three months. You're the project manager so not just your plans but the project plans. People need to know not just where the project has been, but where is it supposed to go.

‐ Prepare instructions for your absence*

This is for everything else you do. Go look at your calendar and your to do list (for the next three months). What things are you doing? What department activities are you responsible for. Are you the only person who knows how to generate evaluation licenses for beta? Make sure you document them. Better yet, get someone identified and train them.

*- Credit where credit is due: These steps direct from the MT podcast. Descriptions are my own paraphrase of their advice, but is directly based on MT content.

You don't do all this because you are required to do it, I've never known a company that has requirements for an outgoing employee. You do this because it is the professional thing to do. It is the right thing to do. I won't trot out the ethics conversation in detail, but Project Mangers live and breath by our professionalism. The joke used to be "Silicon Valley is a small place". I updated that joke recently to say "Silicon Valley is a small place and it spans the whole globe." Don't burn your bridges, they can't easily be rebuilt.  And if you build a few bridges on your way out, all the better.

Two weeks is not enough:

So Hogarth's example is on the dramatic side. Tully gave only a weeks notice and his boss was out of town for most of that time. Everyone generally accepts that two weeks is the "professional" thing to do. Long before I ever listened to Manager Tools (who also recommend four weeks), I didn't agree with this. Sure, if you work at MacDonalds then two weeks is probably just fine. However, If you are in any kind of management job or major individual contributor role, then two weeks just isn't enough time. Four weeks gives you enough time to train a replacement, to update any documents that need updating, to ensure smooth transitions with time for questions. Four weeks is professional (there I go again).

"But my new company wants me to start right away."

Of course they want you to. But do they really need you to? If the answer is yes, then that's a whole other series of red flags. Any company that is so demanding that you start "right away" may be hiding some big issues under that job offer. The company that wants you to start "next week" probably is hoping you'll fix them right away. Go read the "90 day gorilla" for why that's just bad.

Tell your new company you want to be professional and give enough time to transition your duties. Nine times out of ten you'll have just been moved up a notch in their eyes. "This guy is a pro, we made the right decision."

Always one to practice what I preach, let me share with you my own experience. In one of my prior company's I did an almost five week transition. When I sat down with my boss, she was surprised but also very happy with my offer to stay that long and ensure a good transition. The interesting reaction came from people all over the company, as I informed them or the word of my departure spread. I got more than one question along the lines of "Why are you staying so long?" or statements like "I'd be out of here so fast, you'd see a cloud of dust." Three weeks later I got a different reaction. More than one manager/director level person pulled me aside and thanked me for one of the most professional transitions they'd ever seen. They appreciated the transitions I'd did with their teams, the time I'd taken to make myself available and my positive attitude.

And my new company was more than happy to let me have that time. I had more than one positive comment on how long my transition was. I very much had the impression that I'd created a good impression because of the time I dedicated to the company I was leaving. "If he puts that kind of effort into a place he's leaving, what will he do here?"

Be prepared: The Boy Scout motto is a very excellent tale of advisory caution to this advice. When you do resign, be prepared for that day to be your very last day. Though I believe it is much rarer now, some companies have been known to take the attitude that someone who resigns is a danger or threat. This can range from "He'll steal all our company secrets," to "If he sticks around, he'll encourage others to leave."

Because of this, ask yourself if you are prepared to walk from your bosses office straight to your car? Have you prepared your departure packet? Can they take your files and at least understand them and carry forward with them? Or is everything locked inside your PC, that IT will confiscate and your boss won't be able to get the files off of even after a month of asking?

Many years back, I worked in technical support. It was a great team and the manager was a great guy. I gave the normal two weeks notice and told him I'd work full tilt right up to the last day. He was very appreciative, but turns out the decision wasn't his. The "company" was worried about turn over in the group I was in and decided it was better to minimize my exposure to others. I'd resigned at 9:00 am. At 2:00 pm I was walking out the front door, a box of effects and a check for the next two weeks time. They would have rather paid me two weeks severance than have me around the other tech support reps.

In the end, you have to live with yourself. Did you give the job everything you could? Did you do what was right? Amazing how ethics and conscience are so inexorably tied together.

Joel Bancroft-Connors

The Gorilla Project Manager

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.

When do you add your project manager?

This is really about project management, trust me.

"The client is screaming bloody murder." Bob was sincerely agitated. Not his normal "we have a million dollar deal on the table" passion, but honest to goodness agitation, beads of sweat and all. "They rolled out the portal in their China office and all hell's broken loose. They ordered their long lead time parts to arrive on March 11th. When the parts didn't arrive, they called their supplier who happily informed them the parts would be delivered on November 3rd, just as ordered."

Across the table, Jake nodded sagely. "Well that makes perfect sense. "

I'm pretty sure normal human beings can't do what Bob did with his eyes right then. "Makes sense? They are going to be late delivering their Nonesense Tablet by six weeks and you're telling me it makes sense?"

Jake leaned back in his seat. I can't swear to it, but I think he was enjoying this. "Well yeah, the portal is a US only design. China uses Day, Month, Year date format. Here in the States we use Month, Day, Year. So when we write March 11th as 03-11, someone in China thinks you just wrote November 3rd." Jake then leaned forward  looking at Bob, "We raised this back during the planning phase of the project, remember?"

Well I didn't remember, but I hadn't been put on the project until a week after the plan of record. Bob's face showed no small amount of confusion as well. Jake, sensing the confusion explained.

"When the portal was defined, it was clearly stated as being a US only product. It isn't currently programmed to support other countries. That doesn't just mean the words are in English. The entire system is. Date formats, number formats, post code formats, UI sized for English only and so on."

Bob let his head fall forward, only barely catching them in his palms. "Okay, so its 'As Designed.' How long will it take to make a Chinese interface?"

"I'd say about six months."

"SIX MONTHS?" Bob nearly hit the roof, his eyes doing that very unnatural bugging out again. "I just want a Chinese interface, get the someone who speaks Chinese to sit down with the UI designer. It shouldn't take more than a week!"

Jake shook his head. "It's not that simple. We didn't code the product to be internationalized. Remember you had us remove that work from the project, so you could save time?"

"That was two weeks!"

Jake nodded, "It was. And if we'd done the work then. It would have only taken two weeks. Trying to fix it now means we have to rip everything apart. Think of it like a big truck trailer. The box you want is all the way at the front of the trailer. We have to pull out everything else to get to it."

Bob dropped his head into his hands again. He began to quietly sob "six months… six months… six…"

Hogarth dropped himself into the seat next to me, casting a sympathetic glance at Bob. "You know, internationalization is a lot like project management?"

I turned to look at my gorilla, "Come again?"

Hogarth grinned, "Yeah, think about it. If you wait until a project is in trouble, or even just in development, before you assign a project manager, you're already fighting an uphill battle. Look even bigger than that. How many start ups never make that jump from start up to sustained business because the structure they built as a start up isn't sustainable? By the time they realize they need to change, it's too late."

When is too late?

Making sure you can internationalize your software is a classic example of planning ahead to save yourself a lot of re-work down the road. If you don't make your code double byte compliant, you can end up having to re-architect from the ground on up. What could be a little extra work, during development, can require a complete disassembly of the car, just to put a missing screw into the middle of the engine.  Remember how big an issue it was to fix all those Y2K computers that had two digit years and needed four digit years? Same concept.

I18N also gives us a great example of "how hard can it be?" Making your software work in another country can be a very complicated and convoluted process (Check out the scope section of the Wikipedia entry on I18N). It is easy to just brush it off as changing the language on the screen, when in reality making your product work in another country can be an entire product of its own.

So as Hogarth has said, "internationalization is a lot like project management." And that begs the vital question of "when do you bring a project manager in?"

The PMBoK asserts it should be in the project initiation phase. Reality, however, can be a lot different. This is one of those times when I unequivocally side with the PMBoK.

Most of us are probably familiar with the statement "no, we're not ready for that yet," or "I think it's too early to worry about that."  Have you heard the line "This project's just started development, we're assigning you to be the project manager?" Or when you inquire about a new project did you hear "Oh it's way to early to get project management involved. We are just hashing out ideas?"

There is a measurable part of society that sees project management as little more than a schedule tracker and meeting holder. This perception places project managers in a non-essential role. If you have one, that's great. But if you don't, just have the development manager, civil engineer, etc. do it in his spare time. It's an add on, not a full time job.

Not everyone sees it that way, and the last ten years have seen this belief drop off considerably. However, that does not make it all a bed of roses. Even when project management is seen as a vital function of a project, the question of "when" remains a troubling little conundrum.

Most start ups don't have dedicated project managers. The general style of a start up calls for jack of all trade employees that can do many different jobs. Particularly in software  you hear things like "we're moving to fast," or "we need to be super flexible right now." At some point a successful start up has to cross the chasm from start up to predictable business. Smart start ups hire a project manager at this point. They recognize things are changing and they make an effort to take control of that change. I've seen far more start ups that don't. It is not until deliverables start dropping left and right, commitments are not made and half the company doesn't know what the other half is doing, that they bring in a project manager. By this point, things are so bad that PM is going to spend most of his time in fire fighting mode, fixing the problem of the hour and not making sure the company can execute the entire project.

Similar things happen in many big companies. A product has been fully mapped out, resources assigned, a schedule created (usually based on the desire for a ship date, not realistic estimates), before a project manager is assigned to "manage" the project. The poor PM isn't managing the project, he's one step ahead of the avalanche trying to steer it away from the sleepy alpine village.

Great organizations recognize that figuring our how to do things right, to start with, can save much more time in the long run. The "myth" that one hour of planning can save eight hours of work, has been proven true time and again. Great organizations recognize that you should get the experts on running a project involved from the get go. Project management reaches all the way back into even the wild idea stage. Whether you call it project management, program management or portfolio management, having someone who understands how to get a project from A to Z involved from the start can help to expose issues early and ensure everything that is needed is ready, when it is needed.

In a recent project I served as facilitator to the product management and product architects. The product wasn't even an official project yet, but they knew that in order to be approved as a official project, they needed to treat it like it was real. The output from that meeting went on to become the official specifications for the product. I've also worked in a company where I sat in the strategic roadmap meetings. These meetings would be planning out releases that were no more than ideas on PowerPoint slide.

What's the magic bullet to convince a manager, organization, company that they need project/program resources from the beginning? Unfortunately, like so much of project management, there is no silver bullet. I've used the internationalization example to good effect. Another that works well in, concert with Agile, is the GPS example, "Do you turn your GPS on when you start driving or when you think you should be there?" I've tackled this subject, from other angles, in my "Gorilla with too many hats" and "Project Managers are SMEs" blogs.

As always, relationships matter a lot. You can't force process or a project manager down someone's throat. But develop a good relationship, and like Archimedes and his lever, you can move the world. The biggest thing we can all do, is be successful in early project engagements. Industries learn, and if enough projects are improved through early project management involvement, then that it will become more common.

You might not always be able to get in on the ground floor of a project (or start up), but at the very least you can be aware of the additional pitfalls you're going to be facing.

Joel Bancroft-Connors

Veteran, the project management 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.

Book Review- 7 Habits

The mountain of books threatened to collapse the desk. Cubicle desks were just not designed to support the weight of so many books. Though I suppose the gorilla was the real issue.

"Hagarth?" I didn't really need to finish the question, he knew what I was about to say.

"I'm sharpening the saw," he said, not looking up from a book titled "The inter-dynamics of banana diplomacy when used in a corporate environment."

"You're what?"

He laid the book down and looked at me. "Oh forgive me. Here, let me move these books. How are you doing, you kind of look stressed?"

Hogarth was already bustling away to clean my cubicle as he asked the question. Without really any conscious thought I responded, telling him about the frustrating meeting I'd just gotten out of.

"You sound frustrated."

"Yes I am." I said reflexively. In my head I was thinking another thing all together. 'Wait a minute, I just said that…'

"I can imagine, I'd hate to do that kind of work and have it ignored."

Who was this and what had he done to my gorilla? "Hogarth what's going on, why are you being so nice?"

"What, we can't both get what we want. It's not okay for us to have a win/win situation?"

"Hogarth, have you been reading Covey again?"

The 7 Habits of highly effective people, by Stephen R. Covey.

I have owned 7 Habits for at least ten years. In all that time I don't think I ever made it past the introduction. It took Audible.com for me to finally take the time to listen to this book on being effective (No, the irony of my total ineffectiveness in reading a book I already owned is not lost on me. ).

I purchased the unabridged audio book, in all its twelve hours and fifty eight minutes of glory. As I listened to Mr. Covey read his own words, I repeatedly chastised myself for taking so long to do so. While the book and Mr. Covey's exact words were new to me, so much of the 7 Habits resonates with my own personal philosophies and project management styles.

Mr. Covey read the book personally and I think this added a lot more to the book. So many of the stories are directly personal that for someone else to read it, the book would lose a lot of credibility.  And Mr. Covey's personal anecdotes are a vital part of the success of this book. This isn't just some self-help theory being preached by a consultant. The 7 habits are something developed through Mr. Covey's personal life experiences. The sheer power of example on perspective is strong all by itself. Having the man who personally witnessed the events tell the story makes for an impact you just can't measure.

The seven habits themselves are not something profound or earth shattering. Instead, I would place them into the pantheon of common sense. And we all know how much we humans manage to use common sense. His concept of task management (Part of Habit 3: Put First Things First) makes complete sense and is so easily put into practice. I had a business colleague complain about how his team was constantly behind the eight ball and they just couldn't get far enough ahead of the fires to plan. He'd never read 7 Habits, but I described Mr. Covey's two by two Importance/Urgency matrix to him in a couple of paragraph email. A month later he told me they'd been using this for task prioritization and it had done wonders. By taking a little time, they'd discovered a lot of the fires were urgent, but not important.

The book is a dense read (or listen) to get through. It's not the kind of book you polish off on an airplane ride. There is so much data and thought provoking stories that you have to set the book aside to process it all (or turn off the recording in my case).  It is the kind of book that you should finish. There were a couple of times where I had the urge to push it to the side (Heck, I didn't read the print copy for ten years). The urge was driven completely by my own discomfort in facing my own decisions and how I'd approached problems in the past.

My largest regret with this book is I didn't read it ten years ago. This book may be twenty-two years old, but the words are still as relevant today as the day Mr. Covey first wrote them down.

Where does it go on my "Book Shelf Index"? The print copy is on an upper shelf in my home office. I won't be reaching for it every day, but that more has to do with my having copied the 7 habits down and putting them in my computer where I can reference them daily. Buy the book and the audio, this is a book worth hearing read by Covey and having for reference.

Joel Bancroft-Connors

Veteran, the project management 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.