October 21, 2010 – Communicating what Matters

Several of the brain dump entries from February center around “Communicating what Matters.” This shouldn’t be a surprise. Some have estimated that 80% of project management is communication. Others claim that 63% of all statistics are made up on the spur of the moment.

The mark of an excellent project manager is communicating the right amount to the right people in the right format at the right time: making it matter.

The Right Amount

We’ve all sat through long winded, slide enhanced meetings that completely fill the4-hour morning time slot and spill over into lunch. If you are like me, you grasped the concept, impact and expectations of the topic within the first 20 minutes, but have to endure the remaining torture. In truth, I probably delivered some of those presentations.

The purpose of any communication is to allow the audience to make informed decisions (#2 on February’s list). This is true whether you are sending an email or presenting at an executive meeting. Give them all the information they need; leave nothing important out. Summarize the content and focus on the pertinent information. You will want to have any supporting evidence or content available, but wait until they ask before inundating them with it.

Additional suggestions:

• If asked to produce a report, verify the content and detail needed before starting.
• At the start of a meeting, lay out your direction and ask if where you are headed is where they expected to end up.
• Reread your emails from the perspective of the receiver. Is it organized logically? Is your main point summarized within the first two sentences? Are you being too wordy?

The Right People

Have you ever been to a meeting and thought, “Why in the world did they invite me to another one of these?”

Or what about speaking with someone for an hour only to have them say, “I’m not the person you need to talk with. You need to speak to Joe Smith in Accounting.” Why couldn’t they have informed me of that in the first 5 minutes?!?

One critical communication point is the “To:” list on your email. Check it twice before hitting send. Make sure you have only the intended audience copied. Avoid hitting “reply to all” unless you mean it or remove unnecessary names.

Make sure you have the right individual. In the Orange County chapter of PMI there is an individual named Tom Cumming. Because we are both active in the chapter, we are constantly receiving emails intended for the other individual. Making that mistake wouldn’t be too bad, but if one “Joe Smith” is the CEO and the other is the guy in accounting you wanted to contact, be careful.

Additional suggestions:

• Mailing lists are essential. Setting one up for each project will save time when sending out communications. Then make sure to maintain it as people join and leave the team.
• If you are not getting feedback on emails or people are not showing for your meetings, verify that they are receiving your communications.
• When in doubt, ask. A simple phone call saying, “I’m trying to reach the individual in charge of…” can save a lot of explaining later.

The Right Format

This became strikingly clear to me on one particular project. I failed to deliver the project’s schedule and status in a format consumable by my client. The direction of the project was on track to meet our schedule. We were well within budget. The scope was being honed appropriately.

However, because it wasn’t delivered in the format that was expected, I missed the mark. Once it was sorted out, things progressed much smoother.

If you are new to the department or company, ask others to point you in the right direction. If there is a PMO, there is usually a template. Don’t reinvent what already exists.

Additional suggestions:

• If there are several versions of a regular communication (ex. Status Report, Resource Request, Charter, etc.) in use, look to standardize it. Consistency will save time for you in creating it and for the recipient in reviewing it.
• Templates need to be reviewed and revised regularly to make sure they are meeting the needs of the intended audience.
• If there is a meeting, report, or template that is no longer needed get rid of it.

Presenting the right amount of information to the right people in the right format will at least you stand a chance of “Communicating What Matters.”

February 5, 2010 - PM Value Brain Dump

I am sitting here writing down all the words and phrases that come to my mind in relationship to real Project Management. Here is what I have so far.

Communicating what Matters
Informed Decisions
Change with Purpose
Monitoring Direction
Leading, not just Reporting
Analysis of Activity
Controlling the Outcome
Removing Random Factors
Risk Management
Involved Stakeholders
Enabling Management
Planning Success
Integrity in Action
Confronting Conflict
Lessons Learned
Tension Breaking
Instilling Confidence
Team Defender
Resource Motivator
Promoting Purpose
Follow Through
Critical Thinking
Ownership
Improving... Self, Situation, Team, Understanding...
Challenging... Self, Situation, Team, Understanding...
Results Driven
Business Focused
Influential
Self Controlled

Pieces of this brain dump will be examined more in the next several blogs. We'll ask "What is the result of a project manager being ____?" We will also touch on ways to instill more of these in your thoughts, actions and reactions.

Until then, if you have additional ideas, pitch in by leaving a comment.

January 24, 2010 – Driving me Crazy!

Having a GPS in the car drives me crazy. I do not operate well with directions that come one step at a time. It may be the Project Manager in me, but I want to see the big picture and know where I’m heading. Besides, at 65 miles an hour, I can’t judge “300 yards before taking the next left.” I’m not even sure if “Miss Voice” means her left or mine.

I realized this last week as I was traveling to a client site with our main sales person. She was driving and I was trying to navigate. We were attempting to go from Orange County, CA near Disney to the Pasadena area, home of the Rose Bowl Parade. The final destination was between the 60 and Interstate 10. I know how I would go and assumed the GPS would use the same route, straight up the 605.

Imagine my confusion when Miss Voice said, “In ½ mile, take exit to Interstate 5 North.” Before I could wrestle the screen to show the projected route, we had swerved onto the exit ramp to follow the directions. It was either that or face the dreaded “Recalculating…Recalculating” reprimand….or worse, the “Make a legal U-Turn” snide remark.

Through a comedy of errors, we managed to get back on track. We missed the 60, but found Interstate 10. Following Miss Voice’s advice, we passed the exit bearing the name of the street the client was on and took the next exit. I had a general sense of where we were heading by then and expected to head south and then east. Miss Voice, however, took us north and then west until we realized the ending address had changed.

I personally think Miss Voice was so disgusted with us that she was thinking, “Fine! If you don’t appreciate me, I’ll drive you to a back alley where you’ll get car jacked. They’ll strip this vehicle down and sell me to someone that can follow directions!”

Some project managers run their projects using a GPS. They punch a predefined address into their Charter and start driving. They fail to look far enough ahead to get into the right lane before missing the turn. Ultimately they allow the project direction to be altered without their knowledge, ending up somewhere else entirely. Even if they avoid a devastating collision, the sponsor usually ends up with car sickness.

Here are the top 10 ways to reach your destination without throwing your GPS out the window.

10. Lay out the full map. Understand where you are headed. You don’t need to know the turn by turn details, but you want to be able to sense when you are going in the wrong direction.

9. Verify your destination. Review the scope and requirements with your stakeholders and obtain their approval.

8. Keep an eye on the gas gauge. Budget, time and resources have to be planned and used appropriately.

7. Listen to Miss Voice. If you have laid out your plan and schedule accurately, follow them.

6. Track your progress. A GPS uses your current speed and position to calculate arrival time. Analyze your progress and spend rate to make sure you are on schedule and budget.

5. Look for landmarks. Set milestones in your schedule. Use them to validate your direction with stakeholders and gauge your timing.

4. Check the map frequently. Verify progress against the scope and requirements in order to stay on course.

3. Recalculate. As the project progresses, more information is available. It may be refined requirements, new technology, resource changes or other factors that impact the end product. Use formal change processes to re-evaluate and alter the direction and cost.

2. Check the traffic. Analyze the risks in your project. If it appears there is traffic ahead, take action to avoid it.

1. You have arrived at your destination. Recognize when you have completed the project’s scope. Don’t allow random course changes to be slammed in at the end of the project. These tend to be less structured, lack adequate testing and overrun the budget.

We arrived in one piece, but it is a good thing we left early.

January 13, 2010 – An “OH [INSERT EXPLETIVE HERE]!” Moment

I bolted awake at 5:11 this morning…heart pounding, mind racing…to the sound of rain. Living in Southern California, it isn’t a sound I hear all that often, but it is one that strikes fear into my heart. Lest one think that I suffer from Ombrophobia, I actually enjoy a good rain storm. I miss the huge thunderstorms we had growing up south of Buffalo, NY. My true fear of rain rises from the list of my belongings sitting outside that are not intended to get wet.

Today it was the seat from our van, removed a month ago to make traveling easier for my daughter and her sprained ankle. Originally placed in the garage, it was sitting, exposed, on the patio where she had dragged it to sit in the sun.

It was indeed an “Oh [INSERT EXPLETIVE HERE]!” moment. Your mind, body and soul leave their peaceful ignorance and arrive, adrenaline pumping, heart stopping, in total awareness. I’ve had a few of those moments:
• Calculating the cost of sending my daughter to college next year
• Reading the scale the last time I weighed myself
• Opening the email telling me my team lied to me
• Checking the deadline on the project
• Realizing that my last blog was on April 6 of last year
• Getting called in to your manager’s office on the day they announce layoffs

I was reminded again that these moments are the result of choices we make every day. It usually isn’t the big decisions that trip us up. We tend to put a lot of thought into those. It is the little ones that nail us.

How many times did I walk by that seat and think, “That needs to be put back in the van” and did nothing about it? How many pieces of chocolate did I eat between Thanksgiving and New Years? Why didn’t I put either the dog or the garbage out before leaving the house?

Those haunting questions have driven me to take the Choice Challenge. By following these 5 steps, I predict you can drastically reduce your number of “those” moments.

1. Establish Priorities. Without priorities, nothing is important. You may think it is the opposite (i.e. everything becomes important), but life doesn’t work that way. Note to Tiger Woods: A moment (or moments) of excitement with a mistress is not at the same level as your family or your career.

2. Define Achievements. Set bench marks for yourself and head toward something. All great non-goal examples begin “perhaps this is the year I will…” or “wouldn’t it be amazing if….” Drop the “perhaps” and dreaming pieces and establish some real goals.

Having a happy, involved, and loving family would be a great achievement. Is it something you are going to leave to chance or are you willing to work at it?

3. Recognize Your Choices. When your phone rings, you have a choice: interrupt what I am doing or allow the caller to leave a message. Your reaction to a situation or individual is a choice: do I immediately yell and throw a fit or take time to plan my revenge… I mean response? Should I watch reruns on TV or work on my book?

Waiting until after you have eaten a candy bar to think about your diet doesn’t work. Believe me, I’ve been there.

4. Evaluate each Choice against your Priorities and Achievements. Many things are not bad, they just don’t get you where you need to go. Doing your timesheet is a good thing, unless you have a Director waiting for a report. Staying late at work to get ahead is great, unless it is your anniversary and your wife is waiting for you.

5. Make the right choice. Nine times out of ten you know what the right thing to do is. Have the courage and strength to pull the trigger on the right choice. You could avoid having another “Oh…” moment.

One of my achievements this year is to begin writing again… that and to get that chair dried off and back in the van.

April 6, 2009 – Going Covert, Part 6

NOTE: On January 12, Computerworld published an article I wrote entitled Covert PMO. This series of entries is a fictional account based on the Project Manager in that article. Any resemblance to anyone from my past, present or future is purely coincidental. To start at the beginning, jump to January 1, 2009 – Going Covert, Part 1.

Day 27, Tuesday – Management meetings have been switched to Tuesday. That actually works out well. On Monday’s I approve last week’s time, update the schedule and fill out the status report on line. In Tuesday morning’s standing meeting I confirm the status in time to make any last minute updates before the firing squad.

Speaking of firing squads, I think I’ve found a way to turn the tide on the management meetings: shoot yourself first. It sounds drastic but it seems to work.

Today I came in with my usual reports. This time, instead of waiting for the barrage of questions and going on the defense, I attacked…myself. I had already asked myself all of the questions I knew they wanted to so I walked through them all before they could start.

“We are currently 2 weeks behind schedule. In order to make the deadline I have asked the team to fast track some of the testing. We’ve completed the extract and started the data conversion and transfer pieces. While that is happening we’ve used Excel to generate a test file for the vendor, Counseling Phone Support (CPS), to use.

“There are 2 major risks to the project: 1) any additional changes to the format or content of the data. 2) The inability to make web services work as the interface.

“Because the probability of either of these remains high, I have an individual finalizing a manual means to produce the file and FTP it to CPS for processing. It may be labor intensive but we could extend the project indefinitely by supplying the data by hand.”

I answered most of their questions before they even asked them. I even threw in some they should have asked. For those I didn’t have answers to I brought the acknowledged the issue and told them when I thought there would be an answer.

Some of them looked bored. Quite a switch from the last meeting I had with them.

Day 28, Wednesday – Wednesdays always offer a little breathing space. The rush for the end of the week hasn’t started quite yet and all the reports are done. It gives me a chance to “walk around” and check with the team. It’s a bit easier when they are all co-located but I try to touch base with most of them somehow during the week. Still trying to work out the video thing with the offshore team.

Back to the PM problems. If I remember correctly we had just solved world hunger and started on world peace. No, that wasn’t it, but it sometimes helps to put this into perspective. There are a lot bigger problems in the world than the Business getting the requirements right the first time.

Estimated End Date: Deadline was set before anyone really estimated the effort.

We identified 3 types of estimates: Ballpark Estimate, Budget Estimate, and Detailed Estimate.

Ballpark Estimate is used the first time an idea is tossed out. It could be as much as 75% low because we only know the bare minimum.

Budget Estimate is given after a set of high level requirements is reviewed and an impact assessment team has reviewed it. This estimate can be up to 25% low and have a realistic duration. The end date should be announced until the project actually starts.

The Detailed Estimate is done while the design is finalized and should be within 10% of the final cost. End date should be set.

As a group we’ve decided to start using the terms. Without management support we can’t enforce it, but consistency may breed familiarity and that can lead to acceptance.

March 2, 2009: Leadership requires Involvement

"Every soldier deserves competent command. Air conditioned officer's quarters are no place for a leader whose troops are under fire. General Fred Franks once said, "You gotta get onto the fight. Commanders must be visible. They must be present in order to ignite the soldier's resolve. They must provide a bottomless supply of courage for soldiers to feed on when their own supply begins to dry up."

...from Axiom by Bill Hybels.

I've been putting together a presentation based on the Covert PMO topic and this quote struck me. Imagine being in the midst of a battle and receiving an email telling you to advance on the enemy. Maybe it is just a text message from your commander who is sitting half way around the world in an air conditioned office. Would that instill the courage you need to rush forward and attack?

Wouldn't you rather have someone in the trenches with you, guarding your back?

Are you visible to your team or do you sit at your desk and lob email at them like hand grenades?

With dispersed teams it is more difficult yet just as important to make that connection. Pick up the phone or get a webcam set up. Use a proxy (i.e. a team lead or manager on the other end communicating directly). Get connected.

Be involved enough that your team can't claim you just showed up at the end of the battle to take the credit.

February 16, 2009 – Going Covert, Part 5

NOTE: On January 12, Computerworld published an article I wrote entitled Covert PMO. This series of entries is a fictional account based on the Project Manager in that article. Any resemblance to anyone from my past, present or future is purely coincidental. To start at the beginning, jump to January 1, 2009 – Going Covert, Part 1.

Day 21, Wednesday – Finally, a piece of good news: the designer said they knew about the requirement and had set the blasted thing up for Web Services from the beginning. Problem solved.

Day 22, Thursday – The Business Project Manager called me back on the Change Request… to my surprise. She was in the Business Sponsor’s office and they were asking what the next steps were. We discussed the implications of the change and they expressed their concerns about the timeframe slipping. I assured them that the resources had been pulled from other efforts to ensure that this project met their deadline.

One of the things IT tends to forget is that the Business has their own deadlines, too. Based on our commitments to them, they work through the legal and government aspects of the new offering. Couple that with marketing it and training sales to pitch it and you have a lot of moving parts to pull together at the last minute. A slip by IT can cause them to miss a window of opportunity.

By the time we finished their approval of the Change Request was sitting in my inbox. At the end of the conversation they said something I hadn’t heard from anyone since moving over to the PM role: “Thank you.” It actually sounded like they meant it, too.

Day 23, Friday – Got a chance to get back to the list of issues the PMs had brought up. Here’s what I sent them for review.

Project Charter: responsibility of the Project Manager. It is vital to nailing down what the project is going to do, but no one is going to push for one to be created any more. Eventually the SOX Audit team would nail us for it, but the PMO was pretty much defunct.

Project Schedule: Responsibility of the Project Manager and the team. Start with Work Breakdown Structure and have the team add tasks with estimated hours to complete.

Estimated End Date: Deadline was set before anyone really estimated the effort…

Oh, shoot. It’s already 5:30 and I have a date with my wife tonight. Have to pick this up next time.

Jump to Part 6.

February 1, 2009 – Going Covert, Part 4

NOTE: On January 12, Computerworld published an article I wrote entitled Covert PMO. This series of entries is a fictional account based on the Project Manager in that article. Any resemblance to anyone from my past, present or future is purely coincidental. To start at the beginning, jump to January 1, 2009 – Going Covert, Part 1.

Day 16, Friday – Wow! It’s Friday already. Payday is always nice. Technically it is already spent, but it is nice to have it pass through my bank account. It makes me feel like I’m doing my part to stimulate the economy.

The follow up schedule review meeting with the team went well. I wouldn’t have guessed thinking in terms of hours would be such a culture shock to them. Given the hours they estimated and their availability on my project I was able to project a realistic timeframe for delivery: 112 days. That’s a bit longer than the 83 days originally planned and certainly not happy news for Management on Monday.

I ran a couple of different scenarios, checking the critical path, and came up with some options to present to Management. It isn’t rocket science. We can (1) extend the date; (2) decrease the amount of work; (3) increase the number of resources or some combination of the three.

We’ve already been told the data is fixed. When the CEO sets a date, it stays set.

Since we haven’t finalized the requirements we may be able to adjust the scope of the project.

Adding new resources would slow us down on an already crunched schedule. Our best bet is to get more time from the resources assigned to the project.

Day 19, Monday – Meeting with Management went almost as expected. Why is it that something that seems obvious to me is a mystery to Management? Calculating the length of a project is simple mathematics. If the number hours your resources have doesn’t equal the number of hours left to complete the project, the date is going to slip.

Fortunately, after the “I’m so disappointed in you and your PMP certification” speech and then getting grilled with questions, management opted to pull my resources off their other projects. If, in fact, they are allowed to, it will effectively cut our duration by a third and place us in range to meet the deadline.

The surprise additional action they took was to add a Finance report for invoicing purposes. They need to know the total number of records sent to the Clear Mind Counseling Center. Not a big report, but I’ll put a Change Request in within the next couple of days after we estimate the effort.

The other PMs picked Tuesdays to informally get together and talk through our projects and problems. Our first meeting is tomorrow

Day 20, Tuesday – Finished off the estimate on the finance report and sent it out for approval. I wrote it up and attached it to an email, asking them to respond with an “Approved” or send it back with the reasons why not. I receive two phone calls asking what I meant: one from the Business Project Manager and one from the sponsor. Evidently the business doesn’t normally get involved at this level.

It was a great conversation starter, though. I suspect I’ve opened Pandora’s Box. After I explained that a Change Request outlines what is requested and how it impacts the cost and schedule, her interest level was raised. The business is likely to start asking for more involvement going forward.

The phone call from Management started with, “What are you thinking?!?!? We don’t send Change Requests to the Business!” I guess that was another one of those written procedures they got rid of without telling anyone in the PMO.

The PM meeting over lunch went better. Since they still think of me as belonging to the PMO, I was expected to head up the meeting. I started by recapping my first 20 days. My whining consisted of:

• No documentation on management of project including the Project Schedule and Charter.
• The fact that the deadline was set before anyone really estimated the effort.
• Requirements were incomplete.
• Lack of resources and those that I had were over allocated.
• Management status meetings more like firing squad.
• Unrealistic expectations set and held by management.
• No opportunity to re-estimate based on more knowledge of the project.

They agreed with my list and added:

• Project managers running too many projects (one guy had 7!).
• Developers adding “little” items to the project that are found in Testing as defects because they don’t match the requirements or design.
• Business not offering any input until User Acceptance and then they want to change everything.
• No agreement on requirements.
• Failing Sarbanes Oxley (SOX) related Internal Audit checks and having to rework things.
• Information Security (InfoSec) reviewing the product and demanding changes at the end of the project.

In a way it felt good to collectively get it off our chests but it left us feeling empty. Not quite hopeless, but certainly depressed. We decided to think through what we did on our own projects to address these issue and get together next week to start sharing them.

When I got back to my desk I received another curve ball. The Business Project Manager sent me an email saying there was another company they were starting to work with that offered different services. She wanted to know if we could send the same feed to another company.

Our schedule is so dead.

Jump to Part 5.

January 19, 2009 – Going Covert, Part 3

NOTE: On January 12, Computerworld published an article I wrote entitled Covert PMO. This series of entries is a fictional account based on the Project Manager in that article. Any resemblance to anyone from my past, present or future is purely coincidental. To start at the beginning, jump to January 1, 2009 – Going Covert, Part 1.

Day 14, Wednesday – Had lunch today with a couple of other Project Managers, Bill and Darryl. I told them what I was struggling with: Management expectations, resource over allocations and a project without definition. If it was sympathy I was looking for, I was going to have to look elsewhere. No surprise there. They were guys and both had complained about the same things during project reviews I had conducted.

They stopped short of laughing in my face but their little smirks were infuriating.

While washing down our $1.50 hotdog from Costco with Diet Cokes, we came to the conclusion that the processes themselves were not the issue. The biggest roadblocks were:

• Too many projects for a PM to manage
• Resources spread too thin
• Projects held to preliminary budget and dates
• Processes not communicated to the teams
• No management buy in to the process resulting in directives at odds with standards and processes

Bill mentioned that some of the other PMs had voiced similar frustrations. We decided to pick up the conversation with them.

I stole an hour in the afternoon to do a little research. My access to the PMO data hadn’t been cut yet. For the most part, PMs each had 2 or 3 projects, but some of them were running more than 5. My rule of thumb says the project management pieces alone take a minimum of 6 to 8 hours a week:
1.5 hr status meetings (15 minute / day or 1 per week) plus minutes
1.0 hr reviewing and updating schedule
1.5 hr updating the project repository and/or creating the project status report
1.0 hr risk / issue management
1.5 hr business status meetings and minutes

With 3 projects half the week is spent you’ve only covered the basics. Any requirements management, technical reviews, conflict resolution, additional reporting or stakeholder management is in addition.

In a prior life I had 3 concurrent projects. Management wanted to give me a fourth. When I presented the math to them they gave it to someone else. I like to think their respect for me went up, but I suspect their tolerance of me dropped instead.

Day 15, Thursday – Met with the team to review the schedule. I kept it somewhat high level, mostly activities and asked them to think in terms of hours, not days. It appears to be a bit of a shift in their normal thinking. I want to calculate the duration based on their availability given the number of projects they are working. They offered minor change, mostly in dependencies and half hearted commitments.
I scheduled a follow up for tomorrow and will nail it down. The rest of the day was spent estimating availability from the status gleaned in our Stand Up meetings.

Jump to Part 4.

January 8, 2009 – Going Covert, Part 2

NOTE: On January 12, Computerworld published an article I wrote entitled Covert PMO. This series of entries is a fictional account based on the Project Manager in that article. Any resemblance to anyone from my past, present or future is purely coincidental. To start at the beginning, jump to January 1, 2009 – Going Covert, Part 1.

Day 12 – Monday. Take a deep breath….hold it…let it out slowly. Great. Just 5 days until Friday.

Actually the weekend gave me a chance to do just that: take a deep breath. It helps to switch gears for a bit. I mowed the lawn. I’m probably one of the few homeowners in southern California still mowing my own lawn, but it allows my mind to relax and put things into perspective. Call in Monday Madness, but I have a bit more optimism today.

I did two things this weekend. First, I took stock of what currently exists. Second, I made a list of what was missing with notes on getting them. Here’s what I came up with.

Have:

• Project description: New insurance offering – interface with external vendor supplying them with member information, they offer call in counseling. Supposed to be a big money maker.
• Deadline: 3 months from last Wednesday. Firm.
• Commitment: Promised by CEO to shareholders’ meeting 4 months ago.
• Documentation: Some. Charter was drafted but not presented. Requirements are stored as Use Cases in RequisitePro. Design is being developed mainly on whiteboards for now.
  Status: Officially in Design, but Requirements are not completed/approved and I heard that Developer 1 is coding. Not sure who Developer 1 is, yet.
• Need:
  Scope definition. Ideally it would be the Charter, but there may be something political going on there.
  Finalized and approved Requirements. Need to get them out of RequisitePro and in front of the Business.
  Introduction to external vendor project manager…if he/she exists.
  Find out who Developer 1 is and stop the coding.

What I didn’t do this weekend was put together a Schedule. Don’t have enough information yet.

Initiated a Stand Up Meeting. Actually, most of the team called in to the conference number and the Team referred to the meeting as a Scrum. Semantics. I asked 3 questions of each member:

1. What did you do yesterday?
2. What are you doing today?
3. What other projects are you working on?

Turns out most of them are working on multiple projects and are not getting much time for this one.

Day 13 – Got nailed last night for not having the Schedule ready. My fault for not resetting the expectation. By not saying when it would be completed I allowed Management to create an unspoken expectation in his head. His wishful thinking date didn’t correspond to my “you’ll-get-it-when-it-is-done” attitude.

After talking Management down off the ceiling I calmly explained the current state of the project, walked through the Have and Need list and said I would have a schedule by the following Monday. I think what he heard was “blah, blah, blah, blah…Monday.” At least now we share the same target date.

Note to self: Never promise anything on a Friday. They invented weekends to catch up on everything you don’t get done during the week.

The Business Sponsor is excited about the project. She sees it as an easy $100K profit each month. While we were chatting, I pulled out the Cost Benefit Analysis template and started filling it in. Technically it is an Initiation Phase document, but I had a plan.

Asked about the delivery date. Said she suspects that it was arbitrarily picked by the CEO, but the sooner the system is up, the sooner they can make money. Companies were already interested in signing up.

Set up a weekly meeting with her to give a verbal update, but assured her that she could pick up the phone at any time and ask. Along that line, I think I’ll send out one paragraph email blurbs throughout the week to update Management, the Business Sponsor, et al. When appropriate I plan on mentioning team members by name to give them credit for their actions.

Jump to part 3.

January 1, 2009 – Going Covert, Part 1

Day 1 – It should have been an easy operation: go in, implement the update and get out. But it was anything but easy. It led to the Incident. Years from now I’m sure the Resource remaining with the Company may laugh about it, but this week the PMO was hit hard. The Head was chopped…gone. They pulled rank, brought her a box to go with the termination speech and brought in a Yes Man.

It may have been better if the whole unit had been pulled out. At least then we could land somewhere else and possibly do some good.

And this was supposed to be the year everything went right.

Day 2 – Made it to Friday without suffering the fate of the Head. I’ll regroup over the weekend and start fresh on Monday.

Day 5 – Overheard joking in the Development quadrant this morning. Someone said the Head had it coming. Overstepped her bounds and tried to call the Management to task for not following the Processes. IT’S A LIE! They were waiting for her to fail. Then they were all over her like flies on road kill. Stupid thing is we tried to warn her, but she didn’t see it coming.

Now the shuffle starts. I’ve been demoted from the PMO and reassigned to the Project Management squad. I knew too much to stay in the PMO but not enough to get rid of me completely. The patsies they are putting into the PMO certainly won’t push too hard or ask the wrong questions.

I’m ok for now. Gotta keep my head down, do the Job. It’s been a while since I had a full time PM roll, but I’m sure it will come back quickly.

Day 6 – Looks like I’m heading to the front lines: high profile, troubled project in the heat of battle. I suspect when he handed me the Binder, Management wanted me to think the smirk on his face was congratulatory. It wasn’t. This is a win-win for him. If by chance I survive and win the battle, the Company profits. If I fail, Management has a ready made reason to push me out. It would probably make him happy if I pulled the trigger on my own.

Day 8 – Been looking through the Binder. The previous PM didn’t do much. We’re supposed to be in Design, but there isn’t any evidence that the Requirements are complete. The Schedule looks like someone took the template and blew a big hole in it before throwing names against it like rotten vegetables at that house down on 3rd street. Not pretty.

Based on the Charter…which was never approved…we have a deadline. No real objective or clear direction. Just a deadline.

I’m assuming the previous Project Manager won the lottery…or got another job. Haven’t even heard what his name was.

Did meet the Team, though. Some of them seem pretty sharp.

Day 9 – It’s Friday again. With a long weekend of Planning ahead of me I suspect I won’t get much sleep. Entering the sleep-depravation phase. I wonder how long before the water-boarding starts.

I made the connection today. This is the project the PMO wasn’t allowed to review. It was stamped “Critical” and encouraged to “not let the Processes get in the way of progress.” Looks like it lived up to its calling because it did go critical…nearly nuclear.

And now it’s all mine.

Jump to Going Covert Part 2.

NOTE: On January 12, Computerworld published an article I wrote entitled Covert PMO. This blog entry is a fictional account based on the Project Manager in that article. Any resemblance to anyone from my past, present or future is purely coincidental.

December 15, 2008 - Killing False Confidence

You leave for your flight well ahead of schedule. Traffic is light and you arrive, unhurried, at the airport. Strolling up to the counter you secretly laugh at the frantic people running toward the crowded ticket line or scanning the flickering departure screens in panic. Being the saint that you are, you even let a mother with a screaming child ahead of you in line, silently praying they are not on your flight.

The kiosk attendant signals you forward and you confidently hand him your ticket. Reading his tag you smile and say, “Good morning, William.” He glances at the ticket and looks quizzically at you then rechecks the document before calling over a manager. As she scans the paper you catch William staring at you with a smirk on his face but he quickly turns away.

“Sir,” the manager says, “were you aware that this ticket was for yesterday?” Your sense of confidence is proven false…and your day was going so well. Fortunately, William is to busy helping the next customer to notice the dumb look on your face.

Call it paranoia, but every time I get a strong surge of confidence I get nervous. It seems that no matter how many times I verify project progress something ugly always rears its head to ruin my day, like when:

• The vendor promised a strong replacement project manager for a very client intensive project. During the turnover meeting the clueless look on his face caused a bit of doubt. Upon questioning, he admitted to never having managed a project before; never receiving project management training; and wasn’t told that his new role would include project management.
• The team developing the backend interface has been “on schedule” for testing for weeks. At every status meeting they re-state that they will be ready by 6/28. On 6/28 they proudly announce that they have completed the interface…design.
• The support team has confirmed that backups are being performed nightly. They have even told the project manager to stop repeatedly asking such a stupid question. After all, they are professionals and know what they are doing. A month after going live the system fails. No problem. The tapes are recalled to perform a restore only to discover that the backups never completed successfully.

How do you keep from being lulled into a false sense of confidence? I suggest you K.I.L.L. it.

Keep changing the questions. The project manager dealing with the “professional” support team asked to the point of irritation if the backups were being performed. She needed other questions that may have produced a different answer. “Who is performing the backups?” “When do they complete?” “How many tapes are involved?” “How long is it taking?”

For the interface problem, a simple “What will be ready by 6/28?” may have uncovered a serious problem.

Even though it was a fixed bid project, asking for the replacement project manager’s resume would have saved time and effort.

Insist on evidence. To ensure the project stays on schedule you need facts, not promises. One of those facts is actual time spent and estimates to complete from the people performing the work. Minimally this can be collected at the activity level but preferably by task. This exposes trends before they become trouble.

Have the support team show run times and completion codes of successful executions. Check with end users to ensure successful processing. Go check the online system yourself to verify that the changes were implemented.

Listen to what is not said. As you begin changing your questions and insisting on evidence there may be long pauses or blurted out excuses. Usually what is left out is as important as what is said. Begin by saying “So, what I am hearing is…” and restate what they said. Then follow up with “Can you confirm then that you…” to clarify what you didn’t hear them say.

“We will replace the current PM with another one” should have solicited “Can you confirm that the PM will have equal or more experience?”

For the errant development manager, reiterate that he said, “The code will be unit tested and turned over to the development environment by 6/28.”

Learn from previous mistakes. The saying “once bitten, twice shy” applies to both your mistakes and other project managers’ lessons learned. Review the results from similar projects and ask other project managers about the team members you inherit.

Informed optimism is far more reliable than false confidence. Keep checking the details and you won’t miss your flight.

NOTE: This article was originally offered to all PMI chapters for their newsletters. If you would like original content for your publication, please contact me.

November 26, 2008 – Watery Lessons

I'm in the middle of a "working vacation." Those are the ones you use to catch up on all the pieces that have been dropped over the last several weeks...or months. This blog was supposed to be one of those things. I had one topic started, but ran the concept by the Computerworld Project Management Editor. She likes it, so I will be developing an article on it...which means I needed another topic for the blog.

I was considering this while swimming with my daughters here in Palm Springs. We were having contests to see who could make it across the pool underwater without surfacing. That hit pretty close to some of the projects I have been on. What I observed was:

Disorientation. Once under water your senses diminish. Your eyesight becomes limited and your ears are muffled. You think you are heading in the right direction but end up arcing away from the target. In the middle of a project your focus can wander from your objectives, flooded by the Olympic sized pool full of meetings, tasks, resources, activities and all the other objects floating around you.

Go back and revisit your project charter. Look at what you promised the business. Are you still on track? Are you delivering what you said you would? Is your critical path backing up? Check your meetings to see if they are killing time or being productive. Swimming faster won’t help until you get your project pointed in the right direction.

Urge to Quit. While trying to cover the widest length of the pool, I found myself despairing over the distance and wanting to give up. I took two more strokes and realized I could finally see the end. I kicked through and made it all the way.

I’ve bumped into a couple of project managers lately that are wondering if it is time to find another job. Frankly, if the economy was better, they probably would have been gone by now.

If you haven’t already, create your own personal list of tasks and see how far you have to swim. Then, set closer goals. Fight the urge to quit and take it one stroke at a time.

Catch your Breath. At the end of the day, it is only a job. I spent over two hours in the pool horsing around with my daughters. In the greater scheme of life, that was by far more important than the two hours I spent answering work related emails. Go ahead. Take time to catch your breath before diving back in.

October 27, 2008 – Back to the Basic: Communication – How

Once, in the midst of a long distance relationship I had the grand idea of sending a Western Union Telegram to my girlfriend. From my vast knowledge of telegrams, based solely on movies and TV, I knew that every time you put a period they say "STOP" to indicate the end of the sentence. I envisioned a hand delivered envelop with the words “Don’t STOP loving me and I won’t STOP loving you” on Western Union paper. I think they took my $20 and placed a phone call instead that incoherently said "Don't loving me and I won't loving you."

Telegrams were a great way to express you feelings in the 1800’s but by the 1980’s it was out dated. Sometimes you know what to say and when to say it but fail to be heard because of how you choose to say it.

How to be Heard. When deciding how to get your message out, you need to consider both the method and content.

The method does matter. There are the normal methods:

• Phone. Great for quick answers and to give initial direction. Not so good for detailed instructions or approvals.
• Voice Mail. Excellent for letting people know you called and for playing phone tag. Don’t rely on it to guarantee the message was conveyed or that action will be taken.
• Instant Messaging. Good tool to exchange ideas and verify progress.
• Email. Reliable for giving more detailed instructions and receiving approval. Not very personal and can lead to chaos when everyone replies to everyone else.
• Teleconference. When your team is half way around the world, email doesn’t cut it. It can take 2 days to convey a message. Scheduling a teleconference can clarify the conversation quickly.
• Webex / GoToMeeting. Web meeting tools that allow you to share your desktop information make it possible for you to run your business from practically anywhere.
• Get out of your seat. The personal touch allows you to observe the non-verbal aspects of communication like body language, eye contact, gestures and facial expressions. When other methods fail, it may be worth the trip down the hall or across the world.
• Video Conference. The next best thing to being there. Setting up a web cam on both ends of the world can be relatively cheap and net big benefits.

Sometimes you have to think beyond the normal to get your message across.

• Go Big. The company I work for owns a plotter for printing poster size images. Some statements need to be loud. Skywriting might be a little much.
• Websites / SharePoint. A central location for communicating project updates is a great means to keep the team, management, end users and other key stakeholder informed.
• Hand Written. In an age of electronic everything, sometimes the best communication is a hand written note. It can be a card of encouragement, a sticky note of thanks or a message on the whiteboard.

Content clarifies. Here are some simple things that will help get you heard clearer.

• Check the Spelling. I recently received a high glossy postcard from my insurance company. They spelled the word “their” wrong…twice. It doesn’t instill a large amount of confidence in the company.
• Reread it for clarity. Some sentences make their own nonsense…like this one. Often I review what I think is brilliant writing and find it muddled.
• Shorten it. As you reread, look for simpler, more concise ways to communicate your thoughts.

In the end, you need to merge the What, When and How to get your message across.

By the way, that long distance relationship? We just passed our 19th wedding anniversary.

October 13, 2008 – Back to the Basic: Communication – When

Rarely do you hear a project sponsor say, “There is way too much communication going on here.” Unfortunately a common complaint is the lack of communication. True, the loudest complainers are often those that opted out of the weekly status meetings and never responded to your emails. You are left wondering when it is appropriate to connect with them.

When to Speak Up. This weekend I was listening to The Tech Guy on a local radio show. Google is piloting a new gmail feature that checks your sobriety before letting you hit the send button. You have a minute to answer math questions correctly to proceed. Evidently too many drunks were waking up in the morning with a hangover AND some explaining to do. For the record, late night may not be the best time to send an email. Sleep impaired judgment can make the worst email look like Shakespeare.

Status. Many factors go into how often you need to get the word out on your project’s progress. The list includes:

• Project length – Quick hit projects may be over within a week so weekly meetings are useless. For projects in excess of a year, weekly status meetings are too frequent during slower development phases.
• Development type – Agile project development requires daily, fifteen minute, standing meetings. More traditional projects don’t.
• Location of resources – Co-located teams communicate hourly. World-wide teams require more structure behind their interaction.
  

End Users. It has been my experience that the biggest potential failure in communication is with end users. We engage them to get requirements, flash some screens by them for User Acceptance Testing, and finish by dumping the product on them unannounced. Instead of being the central focus they are nearly an afterthought.

Use touch points throughout the project to build to the product release finale. Electronic Arts and other entertainment related industries go all out. When EA Sports released “Tiger Woods PGA Tour” the world knew months in advance and they gave it a media show kicked off. Major motion pictures splash billboards, previews and internet sites long before opening night.

Instead of the implementation date being just the point you are pushing your team toward, start a count down for the intended recipients. “NEWS BULLETIN: Only 47 Days until Dallas goes Digital!” Tease them with the features they will get.

Road construction has the main route to our house torn up. A typical construction sign reads, “Reduced lanes from September 15 to November 10. Use alternate routes.” That says “Your life will be painful for then next 2 months.” Instead they should say, “On November 10 your pothole problems will be gone.” Or “Coming soon: An extra turning lane to get you home faster.”

No Surprises. Ever the optimists, project managers tend to hold out on reporting bad news in the hopes they can right the boat before it sinks. If you foresee problems, raise them as risks as soon as possible. Be proactive in avoiding and mitigating them before they become issues.

Rarely does an issue spring out of nowhere to crush a project. By not warning management ahead of time you eliminate any leadership they may be able to give (additional funds, better people or different priorities) and make them look bad at the same time. Not a good combination. Managers tend to remember such things. With advanced warning the Titanic might be retired to the docks in Long Beach, CA instead of the Queen Mary.

September 29, 2008 – Back to the Basic: Communication - What

While waiting in line at Costco to buy my $1.50 hot dog and soda, I watched the manager collect money from the tills and seal it in plastic, oblong containers. He walked over to the wall and stuck them in a pneumatic tube. With a muted *phoomp* they shot up and out of sight.

Long before email, the quickest form of interoffice communication was the dial switch message tube. Plastic cylinders were sucked from one end of the building to a central switch board. From there they were placed in another tube and pushed to their destination. Instead of having a megabyte size limit for attachments there was a weight limit.

Given the length of time that people have been communicating, the topic of communication is obviously huge. Methods have evolved from papyrus to paper and are headed to paperless…which just seems to create more paper. Communication is concerned with the entire package: what to communicate, when to say it and how to deliver it.

What to Communicate. Simply put, as a project manager you need to communicate answers, accolades, applause, bad news, budgets, briefs, causes, critiques, costs, delays, dangers, decisions, earned value…and I’m only up to the Es!!! An estimated 80% of a manager’s job is communication.

So how do you know what to communicate? That depends on who needs to know.

Delivery Team. To the team you need to articulate the vision and direction of the project. Begin with the defining documents (Charter, Scoping Document, SOW, etc.) to lay out the vision of the project. Use the Work Breakdown Structure (WBS) to drive discussion of what needs to be accomplished and how to get there. Set delivery expectations by laying out a schedule with assigned resources, specified effort, and agreed upon dates.

Since communication is a bi-directional exchange, require feedback. Collect status, effort, re-estimates, criticism and suggestions. Don’t accept excuses, complaints and whining without moving them beyond to solutions.

Sponsor / Management. Contrary to popular belief, management does not always want a rosy picture painted for them. They need the truth told succinctly so they can make informed decisions. They also need bad news delivered as soon as possible so they can take action.

On the other hand, management, if left to their own devices, will make assumptions that may not be true. Understand their expectations and work to align them with reality. Based on the scope definition of one project I was on, we successfully upgraded a software package. The directive for Phase 1 was “out of the box” and we and held the modifications to a minimum. At the end, the sponsor was disappointed she didn’t get the new reports she wanted. I had failed to keep her expectations focused on the scope.

Governance / Auditors. The job of the Governance (Program or Project Management Office) and Auditor groups is to ensure that the safeguards are in place to make the project a success. They want to know that you understand the processes are following them. If your project doesn’t fit the mold, meet with them up front and carve out a new mold that everyone can live with. Communicate lessons learned and process improvements to make projects work more effectively.

End Users. Usually End Users are ignored until the product is virtually complete and then they are brought in to ooh and ah over what we created for them. Your job is to understand their expectations from the inception of the product, align those expectations with the development, confirm them in the User Acceptance Testing and deliver successfully. Communication is the key through each of these steps.

Others. There are always others. Some of them can kill even the most successful project. While speaking with my PMO counterpart on a mass transit project, I asked who was handling the communications to the ultimate end users: the people taking the trains and buses. The project was to implement smartcard technology into the public transportation system. If they were unprepared to use the system, it would be a failure. Who will be impacted by your project and how should you be communicating the changes to them?

The ultimate purpose of communication is to eliminate surprises. Do that and you will be communicating the “what.”

September 15, 2008 – Back to the Basic: Competing Project Constraints

Following last week’s edition, one of my project management co-conspirators dropped me a note informing me that the triple constraint (see The Troubling Triangle) is officially dead. The upcoming release of the PMBOK Guide 4th edition has killed it.

In lieu of the binding, restricting, tri-legged barer of logic, PMI has opted for “Competing Project Constraints.” The new PMBOK includes Scope, Quality, Schedule, Budget, Resources and Risk as a representative list of the numerous constraints that a Project Manager faces.

Without reading the text directly I can not make a fully informed decision about the wisdom of creating a multisided polygon constraint. For one thing it doesn’t have quite the same ring as a triangle (I’m sure there’s a bad musical percussion joke in there somewhere). However, here are my initial thoughts.

1. I whole heartedly agree that Project Managers have more to worry about than Scope, Schedule and Budget. I don’t think there was ever any real misunderstanding of that fact.
2. By removing the Triple Constraint and accompanying triangular image, we loose the visual used to explain the impact of changing one of the legs.
3. Of the examples given as other constraints, Quality is easily represented by the size of the area encompassed by the leg segments of the triangle. Although not originally part of the image, it fits.
4. Another, Resources is generally a factor of the cost (or budget) of the project. If money is no object you can get better and more resources. The New York Yankees and Real Madrid sports franchises, with their ability to buy talent, come to mind. Generally speaking, projects run out of time or money before they experience a lack in available resources.
5. For the other, Risks, I need more explanation for the use of the term “constraint.” If the term means “factors that may adversely impact your project” then I would agree.

Perhaps that is the basis of the change in the terms used. PMI may believe that it is doing us a favor by widening the term to show the myriad of chainsaws and knives we need to keep juggling. My fear is that it opens the door for management to defy the simple logic that if they increase scope, schedule or budget, one or both of the other legs have to adjust.

If we are expanding the number of constraints, maybe we just need a different image:
Picket Fence – Each of the slats represents a constraint holding the project level.
Suspension Bridge – All of the cables adjusted to keep the path safe for passage.
Multi-legged Table – Legs adjusting together to support the project.

Whatever the symbol, I will miss the triangle.

September 8, 2008 – Back to the Basic: The Troubling Triangle

In our quest to return to the basic of project management we have already tackled the stakeholders. Next we take on the triple constraint in the form of a triangle. The concept of a triangle to represent the Scope, Schedule and Cost of a project is actually quite ingenious. Adding more scope dictates an increase in the schedule, cost or both. Reducing the cost or timeline for the project requires less scope. Each part is dependent on the other two.

The trouble is that management thinks of these three items as completely independent of each other; like 3 line segments lying as distinctly separated as the bones in my daughter’s x-ray from last week’s edition.

Scope. The scope of your project includes the full extent of what is agreed to, both verbally and in writing. In reality scope is never fully defined until all of the requirements are vetted, but from the minute you take ownership it is our responsibility is to ferret out promises and commitments made. This is especially evident in the consulting world. Account Representatives (aka Salesmen) are notorious for making promises and not letting the project manager in on the secret. Take your list of Stakeholders and find out their expectations.

The resulting wish list is not your scope. Like pruning a Bonsai tree you need to cut that back to something you can realistically deliver in the timeframe and cost provided. Remember, you can’t set one line segment of your triangle without impacting the other two.

Cost. Auto salesmen get a bad rep, justifiably so in many cases. But you can take a page out of their play book. When asked how much it will cost to deliver the scope, ask how much they are looking to spend. If they only have enough for a used, beat up Yugo, don’t try to sell them a Lamborghini.

When giving an estimate, put it in terms of what will be delivered. Never give a quote without documenting your assumptions; the “here’s what I was thinking…” piece. Placing the cost into context forces the discussion of scope.

Schedule. Timing is always an issue. On one project our directive was to go live in August. Backing up from that date gave us July for Testing and Implementation, June for Development, May for Design and April for Requirements. It would be tight, but do-able. At the end of May “in production” was clarified to mean the day after 4 weeks of parallel testing in the production environment. Changing the move to production, even if we weren’t “live” would have been impossible without changing the scope and adding more resources (increasing the cost).

Find out what the date is and the significance of it. If it is a hard date you have already set one of the legs in the triangle.

As you establish the three legs of your triangle, it is management’s job to stretch the scope side while reducing the length of the cost and schedule sides. How can you effectively push back without a career shortening screaming match?

Go gourmet on them. Most CIOs, VPs and Senior Managers enjoy their share of fine food. The higher end restaurants produce amazing dinners that take longer to serve and cost quite a bit more than your local fast food joint. Even our cafeteria at work has a sign that says, “Good food takes time. Thank you for your patience.”

Build a reputation on speaking straight and not padding estimates. It is your responsibility to present the facts, back them up with evidence and state your case clearly. It is their job to make decisions.

September 1, 2008 – Back to the Basic: Stakeholders

On July 17, 1999 I was sitting in an emergency room waiting for x-rays to confirm something obvious. My six year old daughter had broken her left arm just above the elbow.

On the television a worse parental nightmare was unfolding for the Kennedy family. The night before, John F. Kennedy Jr.’s plane had crashed off Martha’s Vineyard, MA (USA) and the news was covering the ongoing search. It was determined that the likely cause of the accident was spatial disorientation, a confusion of the brain that completely destroys your perceptions. The sky that night was dark, and a haze hid the horizon. Without visual references the brain can misinterpret signals from your inner ear.

Pilots with this condition have been known to fly upside down while believing they are right side up. Instead of climbing steeply they may in fact be heading straight for the ground. Only by relying on their instrument panel can they pull through it.

In the midst of a project, when changes are dogging you and deadlines are due, it is easy to loose sight of reference points, forget the basics and start running on adrenaline and pure luck. If your instincts are solid you may be able to fly by the seat of your pants for some distance. However, even the best project mangers can succumb to project disorientation. Fortunately it is neither fatal nor as tragic as JFK Jr’s death.

This series is entitled “Back to the Basics” and is intended to remind us that projects fail day by day, usually when we loose sight of simple things.

Stakeholders.
Project success begins by identifying and understanding who your key stakeholders are. If you can’t identify the players and which side they are on, you stand little chance of satisfying their needs and landing the project without incident.

Identification. Several stakeholders jump out immediately: the sponsor, end users and your team. But a stakeholder is an individual or group that is either impacted by the development process or the end product of your project

In 1988, New York State attempted to put a low level radioactive waste dump in Allegany County. Although not involved in the construction or ultimate use of the facility, the people of the county were key stakeholders. Their “Bump The Dump” campaign successfully blocked the project and in 1992 the US Supreme Court amended the federal law that required states to store radioactive waste within their own borders.

Create a list of the people and groups impacted by your project. Include hidden ones like:
Current users of what you are getting rid of or replacing (system, building, facility, software, highway, forest)
External suppliers, users or supports. Whole communities are impacted by factory shutdowns, megastore constructions or radioactive dumps. On a much smaller scale, the company supplying data or using your information will have impacts, too.
Support Teams. Call center reps, operational support and disaster recovery are impacted by system changes.

Motivation. Once you have identified them, you need to understand their position. Some will be strong supporters of the project. Others my loose their jobs or need to be retrained as a result of it. For each stakeholder determine and document how the project will impact them.

What pressures are they under? Your director’s bonus may be based on you spending the entire budget. Regulatory or legal requirements may impose strict timeframes. CEO commitments to shareholders may have been made.

Recognition. Return to your list throughout the project. In addition to documenting new stakeholders, begin to put specific names beside each one. This will help you think through whom you are dealing with and begin to plan your approach to dealing with them.

Communication. From the beginning of the project you need to keep the stakeholders informed. You don’t need to have all the answers and in some cases you won’t be able to divulge all of the information, but an open line of communication will alleviate fear and uncertainty.

Unspoken and unaddressed concerns will exist for something as big as potential layoffs or as seemingly small as a new time entry logon screen. Create a forum and an atmosphere conducive to asking question and providing feedback.

The ultimate success of you project depends on you identifying the right stakeholders and satisfying their requirements while sustaining minimal damage from the opposing viewpoints. It is easy to become disoriented by the loudest stakeholder or the one holding the cash, but by identifying them and their agendas you can pull out of a dive before you crash.

NOTE: For an interesting twist on Stakeholder Management, visit the article “The End of Fairy Tale Beginnings” at www.computerworld.com

August 18, 2008 - Stand up and act like a... PM?

For the past few weekends I have been pulling together training material to cover Project Initiation, Tracking and Reporting for HP’s Project and Program Management tool (PPM). Not the most inventive of names but it seems to be a fairly robust system that integrates Financial and Project Management at the corporate level with add-ins for QA and other project pieces.

For that reason all of my creativity has been sapped and I have been unable to blog. However, during last week’s PMI Orange County dinner meeting we had an interesting speaker. Listening to Lee R. Lambert, PMP (http://www.lambertconsultinggroup.com) was like getting a slap in the face to wake you up.

He began by asking how many people had the job title “Project Manager” and then gave us the stunning news that we weren’t. By PMI’s definition a project manager has the right and responsibility to make decisions. Very few of us actually make decisions. We supply timely information, analysis and recommendations for people that do. By PMI’s definition that makes us Project Coordinators or Project Expeditors.

Our responsibility then is to present clear truth, backed by evidence with solid analysis and delivered in a timely manner. Over the next couple of weeks I plan to revisit the basics of how to obtain that information. Far too often we fall under the hypnosis of management’s instructions to add scope, reduce costs and get it done sooner with fewer resources.

We say “oh, well” and back down with half hearted pleas for sanity to reign…but it doesn’t. Then we complain the entire life of the project, pushing the team beyond their limits and try to deliver something...anything…that resembles what was required impossibly soon.

As professional project managers we need the ability to say “Yes, we can do that and here is what it will take.” Then present a solid estimate, realistic timeline and honest cost for what they asked. State the case and let them make the decision.

So, tune in next time and we will get started.