Pothole Project Management, a Gorilla PM philosophy

Or- How to solve a problem you lack the authority/resources to solve.

Ever have a day where you feel utterly powerless? Where your every act carries as much power as a waterlogged facial tissue holding back a runaway train? Okay, okay, I know, that that's the normal state of being for a project manager. But I mean really and truly feeling like you have no more influence then a viagra spam email. Ever had one of those days?

I was.

Jake, the development manager,  had just declared his team had no plans to fix the fatal crash& corruption bug in the database load scripts. "It's a fringe case, no one is ever going to hit it."

Carlos was less than inclined to accept the answer. "Fringe case? A good twenty percent of our user base uses the Whippoorwill chip. What are my customer support reps supposed to say, 'Oh sorry, sir, but that's a fringe case. Can you please reinstall your system from a backup? You don't have a backup, oh well."

I sat in the middle, doing my best to stay the unbiased facilitator. Carlos could be a very reactionary customer service person and had a tendency to exaggeration, but I'd seen his data on this, and it was accurate. Over in the other corner, Jake's team had been working for six months solid and had juggled a mountain of scope creep, introduced by the product manager. He was under a lot of pressure to deliver the product and just plain worn out by it.

So I looked to the product manager. "Bob, it's your product, what do you want to do."

Bob looked up from his Blackberry prayer. He glanced at the fiery tempered CS manager and then at the stoic development manager. "We're a month late already, we can't afford any more delays."

Carlos nearly jumped across the table, "Delays? We wouldn't be a month behind schedule if you hadn't added a dozen features at the last minute and we wouldn't have this bug if you hadn't insisted on changing the DB schema!"

Two size-twenty, hairy feet levered themselves up onto the table next to me. Leaning back in his chair Hogarth folded his arms behind his head and turned to me. "You know this isn't going to be any different from the last time customer support went toe to toe with the product manager?"

I glared at Hogarth, willing him to disappear in a puff of smoke. He didn't and I was faced with the lopsided grin of my personal gorilla. I wanted to snap at him, that this would be different, but I couldn't because I knew very well it wouldn't be. Just like weather in LA, if yesterday was sunny, then odds were damn good tomorrow would be as well. The needs of the schedule would outweigh the needs of the product quality and customer support would be stuck supporting the bug. It would also impact our company. We were already starting to get a poor reputation for having great ideas, but horrible implementations.

Hogarth yawned, exposing a mouth full of pointed teeth, each gleaming like a reminder of things gone wrong. He said, "if you don't do something, then it will be the same thing all over again."

Now I was angry. It was one thing for Hogarth to state the blindingly obvious. But to imply I could change fate was quite the other. "Hogarth, I don't have that kind of authority. My job is to move the project, not decide what it is!"

"We're not going to have the responsibility argument again, are we?" he said. Before I could tell him this was different he waved towards the conference room's big, picture window. "Remember that pot hole in the north parking lot, the one you used to hit every day?"

I nodded, "Yes, and I tried to get it fixed for six months. Facilities only finally got around to doing it last week. So?"

Hogarth shook his head, "Yeah facilities fixed it, but it wasn't anything you did. The construction project on the south wing meant they had to drop a bunch of equipment at the head of the south lot, including in the CEO's parking spot." Flipping his feat down, Hogarth turned to point out at the north parking lot. "So they gave him a temp spot right next to the north entrance. See there's his Mascarpone right there."

"Maserati" I corrected.

He waved a massive paw-hand, "Whatever. The point is last Monday he drove into the north lot and took out his muffler on that pothole. Want to guess how fast it was fixed?"

I shook my head, "No, I want to know what your point is."

"My point," he said, "is sometimes the solution to the problem is to steer the right person into the pothole. Who do you think is really going to care is there is a crash bug on  the Whippoorwill chip?"

And the light dawned on me. "Massive Computing, probably our largest client. And Walter, their account rep is in town. I make sure Walter knows about the problem and he'll get Bob to change Jake's mind!"

My gorilla smiled. "You are learning, young Jedi."

I call it "Pothole Project Management" and it's one of the core tenants of Gorilla Project Management. It is something of the flip side to what I discussed in Blog 21, The Responsible Authority Gorilla. In Responsible I talked about how I, as the Project Manager, worked process and standardization into the team using Gorilla PM rule #1 "First thing is to get it done, then find out who should do it." Pothole PM is the tool I bring out when my own authority (real or relationship) is insufficient to solve a problem. By steering someone with the authority into the issue, you can get the needed result.

Important point: This is not "I'm going to go tell dad!" This isn't the school of tattle-tale project management. Relationships and subtlety are still very important. A project manager who gets a reputation for always going over people's heads is a project manager who will soon have his team working to get rid of him.

Let's take the example from above. I wouldn't pick up the phone and tell Walter "Oh my god, do you know what they are doing?" My first approach would be to talk to Carlos, the Customer Service Manager. Carlos is the one who is most invested in the problem and he and Walter share a common interface point, that being the customer. Guiding Carl to go talk to Walter about "how we can ensure Massive Computer will be impacted minimally" will not only make Walter aware of the bug, but worst case will also start the risk mitigation planning if the bug does ship.

If I had to handle it directly, I'd do it in two ways, face-to-face and the power of status reports. Face-to-face is the trickiest, as it can all to easily come off as tattle-tale PM and that's bad. You have to steer the conversation and get Walter to ask for the data. Power of the status report is the least risky, but you have to make sure people read your status reports (and that is a whole other blog, but there are tips for this). You make sure you have a history of factual reporting that includes issues and risks. If Walter is reading your reports, he'll know about the issue gets involved that way.

Being an effective project manager is not about doing the work yourself, it is about making sure the right resource is applied to the right problem.

Joel BC

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.

All the worlds a stage, and we are merely gorillas

Or- Welcome to the 21st century, you are always "in public"

Bob sat down in the chair across from me, a conspiratorial smile on his face. Unseen by Bob, Hogarth silently lumbered past to perch on the desk section behind me.

Bob was part of my program team, Hogarth was just a 'bit of undigested beef', so I focused my attention on Bob. "What can I do for you Bob?"

"Man can you believe they promoted Mary? I mean come on, Jake can code circles around her with one arm chewed off by a bear." Bob's voice was hushed in the way a five year old "whispers" across the school yard. I was momentarily taken aback by Bob's statement, which he seemed to take a tacit approval to continue. "And we all know she got the job because she practically knifed poor Steve in the back on project Pacheco. Seriously, is there a single ounce of good in that woman?"  Bob went on to express his personal feelings on Mary with great amounts of vitriol, his rant eventually petering out like an out of gas car. 

"Well what do you think?"

I leaned back in my chair, contemplating what Bob had just said. Mary was most certainly not on my most favorite people list. More than once she had caused one of my projects to fly off the rails, with near impossible "customer" demands. Personality wise she was about as warm and fuzzy as a petrified, flash frozen hedge hog. And still…

"You know," drawled Hogarth. "Interesting thing about Bob. Overheard him in the break room not twenty minutes ago. He was ranting on and on to a guy from legal. Couldn't stop moaning about how his project manager was an over bearing control freak who didn't even know the difference between a half bit flange rod and a radiated tie off bar."

Bob only worked on one project, the one I was the project manager for. I gave Bob my best smile and simply said, "Bob, when you question a corporate decision and then proceed to demean someone, no matter who they are  it makes me wonder how you'll represent our project and team. If you'll excuse me, I need to get this report done."

Behind me, Hogarth smiled proudly.

So before the tragedy of Japan's Tsunami blotted it from the headlines, the news was abuzz with the latest scandals to rock NPR. It seems VP Ron Schiller let loose with how he really felt about the Tea Party, in what was supposedly a private conversation with potential donors to NPR.  The fall out from that was the grist for many a news story mill, but what I found most interesting was something that had nothing to do with the actual words said or the resulting fall out. Though it is of important note that Schiller went on to say "I made statements during the course of the meeting that are counter to NPR's values and also not reflective of my own."

Remember those last five words- "Not reflective of my own."

I was listening to my local news radio and they interviewed some talking head (are they still called talking heads on radio?). After what I thought was a well thought out set of answers, the talking head answered the final question, which had to do with how he felt about how the reporters had obtained the secret video (If you skipped the link to the story, they were fake donors meeting Schiller for lunch and had a secret camera). The talking heads said something like "If I'm in public, I'm going to speak differently than I am in private."

Hello, Houston? We have a problem.

There are so many things wrong with this, I don't know where to start…

First off, if you're willing to bad mouth the Bad hair party so you can get donation money from the Parted Hair Brotherhood. Whose to say you won't trash the Parted Hairs next month to get money from the Mohawk's are sexy society? It's a question of integrity. When I hear people gossip, trash talk or tear into their company, I immediately wonder what they say about me when I'm not around or how they talk about decisions made on my projects. This kind of talk is destructive, tearing down other people is destructive. You don't have to be flower-power, hippie-love to everyone, but there is a fine line between not liking someone's beliefs and tearing them down.

This is by far the most important part of this blog. It doesn't matter if you are in private or public, if you treat people poorly, it will reflect back on you three fold. But at least if you are going to take a controversial stance, be prepared to defend it in public. Just look at Ron Schiller, I think he only compounded his mistake when he spoke publically.  Not only was what  he did monumentally stupid, but then he tried to say that what he said wasn't what he really felt.

So let me get this straight, you were lying to get donor money? Oh, and that makes it all better.

Which brings me to my second/last point (okay lousy segway, but stay with me here). Going back to the talking head and his comments about being in private.

Welcome to the 21st century. Welcome to 24 hour Facebook, to a world where anything and everything can be posted to the internet in a heartbeat.  From secret diplomatic cables released by Wikileaks, to that ten year old picture of you puking into a bathtub that your old college room mate just posted on Facebook, anything and everything can and does become public. Like it or not, we are on stage and broadcasting live 24 hours a day.

As project managers, we need to be especially sensitive to this. We may not have the line item budget, or the direct reports, but as PMs we represent the project and the company.  If your Facebook page is a drunken tribute to the Rocky Horror Picture show, mixed with rants about how Uncle Sam is impinging your rights to own surface to air missiles, do you really think Mr. Fortune 500 is going to hire you? You'd better be the next Bill Gates, with the patents to back you up to stand a chance in heck.

In the end, it all comes down to personal integrity. It shouldn't matter if you're in public or private or if someone might post your words or show off a picture. Integrity is a value that goes back to the dawn of time.  All that's changed is now it is so much harder to fake it. As Manager Tools guru, Mark Horstman says "You're not that smart; They're not that dumb."

Stay true, stay honest, stay real.

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 Potato, Pahtato Gorilla

Or- My personal Aha Moment, on the value of an Agile Certification.

I should have known communication was going to be an issue from the start. When the Director of IT clarified that he was in charge of Interactive Telemarketing and the guy in charge of the actual infrastructure was called the Director of Data Management, it should have been a clue to the coming communication issues.

"So the overall framework will use a standard five phase PLC.."

"A what?", the Dir. of DM asked.

I smiled, chiding myself for not spelling out PLC, there I go again using alphabet soup, "Sorry, a five phase product lifecycle, concept, planning, development, verification, and sustaining." The Dir. of IT looked confused, so I elaborated. "A structured process from strategic vision through developing and then release."

"Oh," the DM replied. "We call that a phased release tree and we call them Ideation, contract, coding, test and shipped."

I nod, "Right, so the overall framework will be follow the PRT." Drucker says, "Communication is what the listener does," so I changed my language to fit my listeners. " Because requirements are still fluid, we will shorten the.. contract phase and use a modified Agile, Scrum process as we move into the…"

Another question, and another explanation led to my changing my terminology to call this a "Wagile job."

I began to have an inkling of a communication gap.

"Due to the short release schedule I propose we use one week sprints…"

"Iterations."

"The schedule currently has the backlog grooming on…"

"Story time…"

Two hours later I left the conference room, completely exhausted. Dropping into the temp cube I was parked in, I rubbed my face. The meeting had gone well over schedule, almost completely a result of the constant running translations that had to happen for any information to pass back and forth.

And in lumbers my personal gorilla, whistling a merry little tune. He held out a banana to me, "Want a Musa Fruit?" he asked.

"Hogarth, that's a banana!" I snapped.

He nodded, "Yep, it is. Good thing you guys weren't trying to put out a fire in there. The building would have burnt down before you agreed on what to call that cylinder object to deal with fires."

"Fire extinguisher," I snapped.

"Nah, I was thinking about the phone handset so you could call the fire department. You really want business directors fighting a fire?"

If you've hiding under a rock for the last week or so, you might have missed that the Project Management Institute has announced a new Agile Project Management Certification. For some this announcement is akin to hearing that "Big Brother" has decided he wants to install cameras in your car. To others it's something too long in coming, after all isn't PMI the one and true wisdom in projects? For a large, middle of the road, group the announcement has been followed by a "wait and see" attitude.  Announcing something and how it will actually work are very different beasts.  Announcing you've found life on Mars and then revealing that it is only a millennium dead microbe are two, very, different things.

With feet firmly planted in both the PMI and Agile communities, I was prepared to take a wait and see approach. To start, I wasn’t convinced that there should have been a PMI agile certification in the first place. The Program Management cert (PgMP) has been less than a stellar success. Does PMI have the credentials and ability to make such a certification have value?

But then I don't make those decisions and another part of my brain came to the realization that much of the value of a PMI Agile cert would be in the hands of the people who pursue that certification. Like any trail blazers, they could give this new certification real purpose or they could turn it into another white albatross on the road to certification alphabet soup (professional web site developer, really?).

So until yesterday I was still trying to decide if there was an actual value to even creating a body of Agile knowledge and a certification around that. With the power of the internet at my fingers, I can easily read up on any Agile methodology, from Extreme to OpenAgile and back again. Why did we need a certification?

And then I had my Aha Moment and I realized that yes, this certification could be a very good thing.

My Aha moment came talking with Ainsley Nies about one of the "use case" studies she brought into her Agile Management class at UC Berkeley Extension. Captain "Dave", a police officer, came to class and described how he coordinated the police response to the San Bruno Pipeline explosion last year. What he described is something nationally called the Incident Command System (or SEMS in California) and when Ainsley recounted the tale I recalled my own experience with ICS and it all snapped into place.

ICS started as California's Standardized Emergency Management System, in the 1970's to respond to series of catastrophic urban effecting wildfires. When the retrospectives were done, it was found that it was not a lack of resources but a breakdown in communication and management, a failure in common language, that resulted in poor ability to respond to the fires. This is not surprising for a state almost 800 miles long, paramedics from Eureka may have never even been to San Diego, much less worked with their ocean search and rescue. After 9/11, Homeland Security took California's system and turned it into a national system that all emergency service organizations were required to learn. Today, any US emergency responder can arrive at any US disaster and plug into the existing "project."

Why? Some weaknesses in incident management were a result of:

• Lack of knowledge with common terminology during an incident.
• Lack of an orderly, systematic planning process.
• No predefined methods to integrate inter-agency requirements into the management structure and planning process effectively

Lack of common language. ..

Lack of a common planning structure…

Lack of cross organization integration…

When I studied for the PMP, I didn't learn great swaths of new knowledge. I'd been doing project management for years, even before I wore the official title of project manager. What I did learn was a common language and a set of common frameworks, in short a tool box and the instruction manual to go with it. How I ended up using those tools was up to me, the PMBOK itself clearly states it is a set of guidelines or common practices. Getting my PMP gave me the ability to converse with other project managers on a common basis. It also gave me a community.

And an Agile Project Management certification can be of the same value. Like an Incident Command System for using Agile methodology, it could offer a common language, common frameworks and make sure that when we all grab hold of the elephants tail, we all know its an elephant we're holding onto and not python. It can shorten the time new teams take to come up to speed. It can mean that an Agile PM can join a firm with other Agile PMs and already know they are talking the same language.

Does my Aha Moment magically make things all rosy and bright. No, but it does tell me that this certification can be a good thing. When we can all agree that the red cylinder is called a fire extinguisher, it will make it a lot easier to put out the project fires.

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 Book Review- The Elements of Scrum

 

There is something eternally satisfying in closing the back cover of a hard copy book. Especially when the book was such an enjoyable read.

In this age of reading books on Kindle, iPad, printer paper or listening via serial podcast or audio book format, reading a good old fashioned book still has so much emotional content tied up in it. Perhaps the millennial generation will/does feel different, but for we of the Pong generation I think the physical book will always remain a comfortable thing. I love reading on my mobile device and there are some books I truly prefer that way. But not Elements of Scrum.

I had just laid the book down, flipping through the final index pages with an all too satisfied grin of completion. Staring at the blank screen of OneNote I was trying to mentally compose just what I would say about my experiences reading the book.

And like any unasked for distraction, Hogarth wandered by just as I was preparing to type.

"Whuz thad?" he said. At least I assume he did, the spray of partially eaten donuts made it hard to tell.

I looked down at the book, "Elements of Scrum, I just finished reading it."

Smiling brightly, Hogarth grabbed the book up. "Ooh, the periodic table, I love the periodic table!"

I sighed, "No, Hogarth, not chemistry elements. It's a book on the fundamentals of the Scrum Methodology."

"Oh, so elements like Scrumium, Standupum, TDDine, and Taskon?"

"Go away, Hogarth…"

The Elements of Scrum, by Chris Sims and Hilary Louise Johnson

I've had the pleasure of seeing Chris Sims in action. Chris is the founder/head coach for Agile Learning Labs. A self professed former, aspiring rock star and software coder, Chris' real talent lie in his ability to engage a room. His coaching style is very dynamic and engaging. Anyone looking to sit at the back of the room and soak up some knowledge, should not attend one of Chris' trainings. If you want to roll up your sleeves and walk away with hands on practical knowledge, Chris is your man.

My biggest question, when I picked up EoS, was if Chris could take that in person coaching style and translate it to the printed word. I had my doubts. Chris is a hands on trainer, I don't think I've seen him use more than a half dozen PowerPoint slides, ever.He's a phone first, email days later, kind of guy and I wondered if he'd be able to distill down his thoughts to a cohesive print product. Chris, however, is a smart coach and in collaborating with Hilary I think he found the person who could focus his in person stories and translate them to the printed medium.

EoS is a great mix of approachable writing, great anecdotes and simple pictures, both the ones drawn into the book and the pictures the words easily formed in my head. The nearly 200 pages flew by quickly while giving me some excellent new perspectives on the use of Scrum. For readability I found it outstanding.

Elements is not a complete "how to" book of Scrum, that's not the goal of the book. It's laid out a lot like one of Chris' trainings, and will give any reader a strong foundation in the basics of Scrum. Even though I've taken scrum master certification and have been an active agilest for some time now, I still came away from this book with a deeper knowledge of Scrum's core fundamentals. That says a lot for a $30 book, that it can still teach you some new ideas after taking a two day training class.

The final positive point I can give it is where it will live, now that I've read it. EoS will find a place on my ready reference shelf in my office cube. When I need to check something on Scrum, it's only an arms length away and finding information in it is google easy.

Well worth the cover price.

Thank you and talk to you next time when I'll share with you my "Pot Hole Project Management" philosophy.

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 Responsible Authority Gorilla

The project meeting was moving forward very well. We were tracking on everything and it looked like we'd actually have the release out on time, and with everything we wanted in it. We had just gotten to the issues with the flux capacitor redesign work and I asked Paul, the engineer, when he would be able to give an updated report on completion.

Paul shifted in his seat, stealing a glance at Jake but said nothing. Jake, the development manager,  leaned forward and spoke, "I'm taking Paul off this project, I need him to rebuild the prototype simulator. It's running 10% slow and I don't like that."

I did my best to keep my mouth from gaping open. Without the flux capacitor redesigns, this maintenance release would be all but pointless. Nodding my head I said, "all right, then let's look at the next item on the agenda…"

After the meeting I slipped back to my cube, looking forward to ensconcing myself behind the safety of my monitor. The fury black form reclined on my desk told me I wasn't going to get that opportunity.

"May as well cancel that maintenance release, huh?" Hogarth said, casually peeling a banana.

I shrugged, "Not my call, I just track the projects. I don't have the authority to change resources." I shoved aside Hogarth's feet and flopped into my chair. "Jake thinks work on the simulator is more important, Paul works for him."

"I didn't think the simulator was even gonna be used until next year."

Resisting the urge to complain about Hogarth's banana breath I gave another shrug. "It's not, but I have no authority to change things."

"So what? That doesn't mean you don't have a responsibility!"

The Authority vs. Responsibility Gorilla. I think we are all familiar with the lack of authority gorilla . I've yet to meet a project manager who never had to run a project in which he had little or no real authority.  But how many of us think about, the responsibility gorilla?

Authority- Dictionary.com defines authority as

The power to determine, adjudicate, or otherwise settle issues or disputes; jurisdiction; the right to control, command, or determine.

"The Power"

I get all tingly when I read that. Reminds me of the 1980's cartoon, He-Man, and his magical transformation (work safe video) from medieval geek to super hero. There is a small problem with this. At least in Silicon Valley high tech power is practically a fundamental myth. Mark Horstman, of Manager Tools, maintains there are three kinds of workplace power. Role Power, Expertise Power and Relationship Power. Role power is the power a boss has, the power to hire and fire, to make decisions that will affect everything in his organization.

Role power in the 21st century is a myth. Anyone who tries to operate exclusively on role power will ultimately fail. Without a healthy measure of expertise and, especially, relationship power that manager is headed for a short career.

Still the concept of authority does exist and all to often a project manager has limited or no authority on their projects. So what do we do? Do we throw up our hands in despair and give up?

Like bloody hell we don't.

We are project management professionals.

What does this mean? Great question! A web search for the definition of "project manger" returns back thousands of answers. Some of these answers are contradictory to one another, but there is one theme that pops up over and over.

"The person responsible for the project"

Responsible. The word makes me feel all grown up and mature, but it is the key to this concept. In fact, let's take the grown up analogy a little further. When Tommy gets suspended from school, for throwing spit wads, his reaction is "But the other guys were doing it!" And if you grew up in the United States you are probably familiar with the stereotypical parental answer, "And if all the other boys jumped off a cliff, would you?"

PMI members reading this should be familiar with the PMI Code of Ethics and Professional Conduct. This code is mandatory for all PMPs and I personally think is part of what can set apart a PMP from other structured project management certifications. If you look with in the code you will see two key points.

1.1 Vision and Purpose

As practitioners of project management, we are committed to doing what is right and honorable. We set high standards for ourselves and we aspire to meet these standards in all aspects of our lives

2.1 Description of Responsibility

Responsibility is our duty to take ownership for the decisions we make or fail to make, the actions we take or fail to take, and the consequences that result.

There it is again, responsibility. And the big kicker in all that "and the consequences that result." If we don't take responsibility then we have to be prepared for the consequences.

This is where the professional part comes in. As professionals we are under an obligation to be responsible.

Quick and Dirty Example:

In the United States, citizens have the right to vote. It is not a requirement but a civic right. And with this has become an often repeated concept. "If you don't like how the country is being run, then vote. If you don't vote, then be quit complaining."

A real world example:

One of my project management jobs was in a global support organization. The job had two key components; ensure the support organization was ready for each software release, and feedback into future projects support's experiences from supporting previous releases. This later responsibility was a constant challenge. We ran into roadblocks, barriers and just plain confusion. Some projects didn't have a way to roll in lessons learned, others didn't want any outside input, and so on. It made for many a long and stressful day.

So what did the support planning group do? We decided to be the most professional and helpful group humanly possible. We made sure our house was in order. We made our processes transparent, we published our templates, we communicated constantly in all directions and we adopted one of the most powerful tools in communication.

We stopped saying "no" and we started "yes, and". It's a trick I first learned in improvisational theater and one that made perfect sense when my boss suggested it. We no longer said "No, you can't ship this it's not stable" and instead said "Yes, you can ship and here is what we expect the call volume will be and how much those calls will cost."

These two changes, openness and "Yes, and" made a dramatic change. In a few short months we had addressed more critical support issues than we had in years of prior work. And the more fascinating thing we saw, was how other groups started to change their own processes and procedures. It's a bit thrilling when you see another department using a document that is clearly based on a template you designed.

We didn't have real authority. We couldn't change the products being built, we didn't have the power of the purse that sales can wield so well. But we did know we were responsible for support being able to do its job and we took that responsibility to heart, being the best and most professional we could.

Conclusion:

No matter what our authority level, project managers can never surrender their responsibility. It is our job to help a project from point A to point B. We may be the CEO anointed leader, fully empowered to hire and fire at will, or we may have little more authority than updating the Gantt chart. In either case though, we have the power of influence, the power of experience and the responsibility to, at the very least, be the most professional and helpful person we can be.

We are the glue.

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.

Like what you read? Then please tell a friend, tweet it, put it up on your wall, or send out smoke signals.