Showing posts with label Program Management Office. Show all posts
Showing posts with label Program Management Office. Show all posts

Sunday, May 11, 2008

May 12, 2008 – Stop Wasting My Time

My brother-in-law, Paul, tells a story about a boy, Theo, who wass afraid of clowns. The tale follows Theo’s life from childhood to teenager to young man through to his old age. At different stages in his life he attempts to survive a circus performance but always ends up fleeing, screaming hysterically, at the sight of the clown. He tries therapy, hypnosis and other extreme means to cure himself. Finally he joins a religious order of monks known for their fearlessness and sharp comebacks in the face of danger. In the final confrontation with the clown, Theo is being chased, stumbles and falls down. With the clown standing menacingly over him, Theo finally faces his fear and yells, “I don’t like you very much!”

Quite pointless, eh? Paul can drag this story out for at least 15 minutes, adding more details and deeper insights. When he finishes you feel cheated out of a large portion of your time.

As project managers, we need to make sure that what we are asked to do has purpose. The Systems Development Life Cycle is a great example of this. As part of the Project Management Office, I expect pushback from the people using the SDLC. The majority of the templates and processes come directly from the teams, but if they don’t make sense we need to get them changed. In order to be successful, everyone needs to get involved in the following ways.

Know What. Keep an eye out for PMO announcements telling you what has been added or changed. When you start a new project or phase, browse through the processes, templates, best practices and lessons learned to make sure you have the latest and greatest. The temptation is to modify what worked for the last project, but great improvements may have been made since then.

Understand Why. I’ve been guilty of playing the PMO blame card. Early in my PM career I would ask the team or client to complete something “because the PMO requires it.” A great example is the Risk Assessment. If you are just filling in risks because you have to, you are missing out on a project saving devise. Telling the client / business that you have to have one to pass an audit may get you off the hook immediately, but it shoots an arrow into your support team. Eventually the client / business will think all PMs blindly do whatever is dictated. They then loose faith in the whole organization.

Use Them. Put the process to the test. Processes and templates generally aren’t built to gaze longingly at. They make really lousy wall hangings and lawn ornaments. They are intended to be used. Besides, the best and most constructive complaints come from those that have tried to use them, not those that ignore them.

Provide Improvements. The goal is to use the group’s collective knowledge and learning to continuously refine and replace what exists today. The PMO will be among the first to admit that the best answers come from the line. Toyota’s manufacturing success has at its core the right and responsibility of assembly workers to suggest ways to make it work better.

The users of the processes are the real owners, not the PMO. If a piece is broken, get it fixed. If it doesn’t make sense, find out why it even exists. If no one knows why, get the PMO to drop it until someone screams for it back.

In the end, no one wants to waist your time with pointlessness. Well, except maybe my brother-in-law.

Sunday, April 27, 2008

April 28, 2008 – Them’s Fightin’ Words!

Choosing the wrong words can start a fight. I vividly remember conducting a PMO status meeting with upper management in which I nearly started a brawl without meaning to. While reporting the results of a recent project audit, I made the observation that very few resources were completing their weekly status reports. I surmised that management was setting a poor example by not producing their status reports. Unfortunately I said it out loud, immediately creating a hostile environment for myself.

Here are five lessons to learn from this:

  1. Watch what you say. Obviously the filter between my brain and mouth was not functioning during that meeting. Check your filter before you let something slip. Report the information concisely and clearly. You can present analysis and reasoning, but leave out the commentary.
  2. Consider how you say it. Only 7% of face to face communication is the words you say. Tone and visual cues (body language, gestures, eye contact, etc.) make up the other 93%.
  3. Recognize a challenge. Sometimes people deliberately try to draw you into a fight. They know the buttons to push and they start poking them. It may seem like an innocent question or a simple statement but it is intent is to challenge your authority and put you on the defensive: "Our projects have not been completing on time. Is it the role of the PMO to audit them and ensure they are successful?" It may even come across as a show of support or sympathy: "The PMO is obviously too understaffed to be effective in this environment." Be aware of who is saying what and think through why they may be saying it.
  4. Don’t take the bait. There are some things that are worth fighting over, but not everything. Just because someone is looking for a battle doesn’t mean you have to take it. This doesn’t mean to run from a direct challenge but don’t jump at every offense. Choose the time and place for your battles.
  5. Respond appropriately. The greatest life management book ever written says, "A gentle answer turns away wrath, but a harsh word stirs up anger." Think it through and determine what is being challenged and then choose a response like one of the following:
  • Call them on it. A direct challenge in a group setting requires a response. One tactic is to look them straight in the eye and ask, "Are you challenging my authority on this?" Generally people back down at this point. If not, you may have to pick another response.
  • Ignore it. You can ignore a question or comment that is intended as an attack. Don’t ever try to answer question like, "Are you still beating your wife?" It may be prudent to ignore a slight at the time and address it in private later. Sometimes the offense is unintentional and it won’t happen again, but if it continues you will need to deal with it.
  • Apologize. This is especially effective if they are reacting to a perceived threat by you. Believe me, during that status meeting I apologized quickly. True as it was, I needed them on my side to be effective.
  • Just the Facts. People can get defensive but they can’t really argue with facts. Make sure you have them right and then present them as evidence to support your case.
  • Humor. Making light of a comment acknowledges it and defuses it. Don’t mistake ridicule for humor, however. Making fun of the person will just tick them off and escalate the fight.
  • Delay. Retreat is not giving in, it is allowing both of you time to cool off and try again later.
  • Defend yourself. When push comes to shove, sometimes you have to push back.

It is easy to throw out fighting words. Dealing with them takes maturity and forethought.

Tuesday, February 19, 2008

February 19, 2008 – Welcome Aboard!

"Welcome aboard!" is, unfortunately, the only orientation some Newbies ever receive when starting a new job. If they are lucky someone shows them where the restrooms are...and how to find their way back. I can’t say how or why it happened, but I recently heard that a new project manager, on his first day, excused himself to use the facilities...and never came back. If you want to retain resources longer than a couple of cups of coffee, the PMO or department management should create a new hire initiation that covers the following areas.

People. Get them connected to others. An Org Chart helps. My biggest fear when starting in a new location is that the CEO will greet me in the hall and I’ll say something stupid. I can picture myself saying, "Must be great to be management and take all the prime parking spots!" Walk Newbies around with the Org Chart in hand and at least give them chance of not making fools of themselves. If possible, get a group to take him out to lunch and pay for it.

Access. A list of all required system, application and building accesses should be maintained. Prior to the Newbie showing up, make an effort to get the access set up. Add them to all of the distribution lists they need to be on. Extra Credit: Add to the list a paragraph or two describing what each system, application or building is and why it is important to them.

Tools. With great access must come great understanding. Too dramatic? Probably, but you need to know what tools are available and how to use them. Timesheets are a great example. Are employees required to complete one? How many different places is time recorded? When is it due? Oh, and how does it work? Make the documentation available and, when possible, step them through the first use.

Processes. For those of you who feel oppressed by process, be thankful you have one. Trying to run a project in a chaotic environment is worse. It is like hacking your way through a jungle with no paths. One client I was working had two IT departments: one had a well established process and the other took a more "whatever it takes" attitude. Several project managers moved from structure to chaos, thinking they were finally free. Within a couple of weeks they were calling back for templates and direction. They were drowning in their new found freedom.

Meetings. Every environment has a standard set of meetings that happen. In mature environments a Communication Plan exists that spells out each one along with its purpose, attendees, location, time and frequency. If the plan doesn’t exist, at least make sure they get sent the meeting invitation in time to attend the next one. Let them know what meetings they are expected to establish for their project. Is there an overall project status meeting? Does each area have their own? Are daily standing meetings the norm? Who handles the status with the Business? Is there a Steering Committee? Lacking direction some toes are likely to get stepped on.

Reports. From status to metrics, management doesn’t communicate without reports. This, too, is usually covered in a Communication Plan. Each company seems to have a different expectation for status reporting. Some obtain status information verbally at meetings with the team. Others expect everyone to produce a status report. I’ve seen several companies switch to a 4-Panel status approach (example: 1-page with 4 quadrants: Status, Financials, Schedule and Risks/Issues). Again, if the Newbie doesn’t know, someone isn’t going to get their expectations met.

Locations. The company I am currently working for has several buildings multiple miles apart on the same highway. When I first started out I would get meeting invitations for the "Large Conference Room" and end up in the wrong place. Let Newbies know where the different branches are, the best places to have lunch and how to decipher the meeting room locations. One place I worked used the names of different beaches for conference rooms. Cute idea, but where is Malibu in relationship to Laguna?

I would wait until last to mention the restrooms, though, just in case the Newbie gets the urge to check out and never return.