April 30, 2007 – So What?

Anyone who has teenagers or has had to deal with them will inevitably run into one with a bad attitude. Even their body language says “SO WHAT?” As project managers we deal with a lot of issues, risks, problems and people. Some times it makes you want to throw your hands up and say, “So what?!?!” Actually, that might not be a bad idea. How would that look for issues, risks, budget or schedule problems and politics?

Issues. My natural inclination when someone raises an issue is to try and solve it. The next time you are confronted with one make sure to ask “so what?” So what is the impact to the project? Is it severe? Does it need to be address immediately? Is it something we can live with? Can it be addressed in future releases? Some times the impact is small enough that it isn’t worth the effort to address the issue.

Risks. Applying the “so what?” question to risks is easier since you aren’t feeling the immediate pain you do with an issue. Not all identified risks are dealt with the same way. In addition to Avoidance (sidestepping it), Mitigation (reducing the probability or impact) and Transference (making it someone else’s problem) there is the ultimate “so what” attitude: Acceptance. In Risk Acceptance you look at the probability of it becoming an issue and the impact to the project and decide it isn’t worth the effort to take action against it.

Budget or Schedule Problems. Budgets and schedules usually are scrutinized highly on projects, but sometime even they get trumped. There are times when a project has to get done. People may be willing to pay whatever it takes and wait longer to get it. I was managing on project where new requirements were requested toward the end of the testing phase. When we said it couldn’t be done the response was, “Would more money help?” Unfortunately money wasn’t the issue, time was.

Politics. I can’t stand politics. It is probably because my straight forward approach to life and management causes me to inadvertently step on toes I don’t see. The question can work here, too. I would suggest you let the voices inside your head ask the “so what?” question rather than blurting it out. So what if that person or group isn’t happy with the product? Does it meet the specs? Are they the ones paying for it? So what if they aren’t going to like the status I need to give? Is it better they hear it now before the project fails? So what…do I have to do now that I offended the boss?!

The answer to this question will help you gauge what your response should be. Sometimes you will luck out and be able to ignore the problem. Other times the answer will be to take action. Either way, you will be working from an informed position, not reacting blindly.

April 16, 2007 – A Question of Ethics

Ethics has been the topic of several separate conversations I have had recently. One friend expressed near outrage about a discussion she overheard between two of her managers. It ended with one saying, “Well, your ethics aren’t necessarily mine!” Another friend found it amusing that he was able to avoid the company ethics meeting by lying about already attending.

It is odd to think that we need training in ethics. No one seems to require training to be unethical. A coworker of mine once summed up the difference between humans and animals by claiming that we are able to devise a justification for our animal-like behavior. Is it possible that ethics really is in the mind of the doer?

Most companies have a code of ethics for their employees to read and sign. Do they think signing a piece of paper will make those of us with questionable morals magically ethical? Or is it more like the police telling someone “anything you say can and will be used against you in the court of law”?

There are four general categories of ethics: Equality, Truth, Honesty and Integrity. How should I act tomorrow based on these four simple words?

Equality. Individuals should be treated on their own merit. We’ve come a long way, but unfortunately we can still find many examples where people aren’t treated equally. My responsibility is to act professionally regardless of differences (race, sex, politics, religion, etc.). I don’t have to agree, condone, validate or celebrate the differences, but I had better not use it to separate people out for different treatment.

Truth. Watch what you say. There is that sticky place between the “truth” and the “whole truth” that allows for a lot of wiggle room. The closer you can bring these two together, the more ethical you are. If I had a truth meter on my communications how close to a 10 would it read? Do my status reports cover things up? Are defects reported accurately in my test results? How big is the fudge factor in my financial statement?

Honesty. My conduct toward others should be fair and not deceptive. I suppose this concept rules out brown-nosing…unless of course that tie really does make my boss look thinner. If I have to finagle a situation to make me look good, I am probably stretching my honesty credibility. What is the motivation behind my action? Is it to make me look better than my rival? Do the right thing for the right reason.

Integrity. Uninformed or gullible people are easy targets. Integrity is not taking advantage of them. It is doing what I said I would do. It means refraining from calling in sick with an “eye” problem because I “can’t see” bothering to go to work today.

Ethics can all be boiled down to the Golden Rule: “Do unto others as you would have them do unto you.” It doesn’t matter if you can do it without getting caught. Ethics are a personal thing. I am personally responsible for my ethics and am expected to treat others and my company properly regardless of how I am treated in return.

April 19, 2007 – From Education to PM without Experience?

Tomas from the Czech Republic sent an email in regard to the “How can I become a PM?” podcast. He asked how to break in to the project management role coming from the academic world. He finished studies in Economics and Management and had a Software Engineering degree. He now has a lot of theoretical knowledge in IT and Economics but doesn’t want to be a programmer and lacks the experience to move into the PM role. Where can he go from here?

When you have great educational credentials but lack the "real world" experience to back it up you can feel trapped. As with any profession, people interviewing candidates are looking for someone with proven abilities over those that "head knowledge." Makes sense. If I were visiting the Czech Republic and needed a cab in Ostrava I would want someone who had been driving there for a while.

Here are 3 alternative approaches.

1. In the PM Podcast episode I discussed taking an assignment as a project coordinator. This role is usually under the direction of a project manager and does more of the grunt work (timekeeping, project schedules, meetings, minutes, etc.). As a coordinator you get to see the theory in practice and learn the tactics, what works and what fails without being no the front line. IT also introduces you to the key players and positions you for the next step up into management.
2. Bypass the coding and try to break in at the analysis or design level. One area that coders typically avoid is business analysis and writing specifications. Most are more content sitting in front of the computer than interacting with end users and business personnel. Starting at this level would bring you up to speed faster on how the business works. Again, you will be meeting the stakeholders and developing the relationships to move to the next step.
3. Go directly to the business side. If your education includes economics or other business related field this may be a good fit. While you gain the business knowledge you can apply your understanding of IT to fill the role of liaison between the business and IT.

More and more universities with management courses here in the states offer internships or mentoring programs. If you are still obtaining your education I would encourage you them to look for those opportunities. You can gain real world experience to add to your resume while still learning about it.

April 16, 2007 – Audit Failures

I have a friend who used to work for the Internal Revenue Service (IRS) as a tax collector for the United States. When this agent performed an audit he expected you to be honest and work with him to determine what was owed. He had the authority to make your life miserable if you chose to mess around. After trying unsuccessfully on one case to work through issues with an individual the agent showed up at the company before 6:00 AM with padlocks and chains to impound all of the vehicles. In concert with this move he froze all financial assets as soon as the banks opened.

On the flip side, he was working with a woman whose husband had run up bills, lied on his income tax and then left her. She met with him to work out some payment arrangement. After reviewing the case he determined that there was no way she would be able to repay what was owed so he wrote the whole thing off. She walked away free and clear.

When I was a project auditor I didn’t have that level of authority. The audits I performed were focused on making sure the projects and teams were following the procedures and that the company was not at risk. It was great to audit the managers who honestly worked with me to understand the project even when there were problems.

To keep from having and causing problems, review the following audit failures that should be avoided.

Lacking Definition. The most important part of a project is the definition. Without clearly defined objectives, deliverables and ground rules you won’t know where you are going, when you are done or how you will get there.

Make sure your defining documents clearly identify the project scope. Problems are usually found in this area just by speaking with the project manager. I review the Statement of Work and then start asking innocent questions like “what is your team currently working on?” When he starts talking about things that aren’t in the SOW I know there’s a problem.

Review your project’s defining documents and make sure you are doing what you said you would and nothing more.

Missed Milestones. Milestones are checkpoints. There isn’t anything magical about them. But if an audit discovers several of them have been missed then the project is at risk of failure to deliver. Don’t try to hide the fact that you are behind. Be the one to point it out. Then outline what you are doing to pull the project back on schedule. This may include bringing in additional resources, issuing change requests to adjust the dates or lowering the scope to meet the deadlines.

The audit reads a lot better if it shows you understand the issues and have a plan to correct the course. It sounds a lot better than “he hasn’t got a clue that the project is in jeopardy.”

Unacceptable Approvals. A good auditor looks deeper than file names to determine if an artifact is acceptable. There were multiple times that I looked at approval emails to discover they were worthless. There are 4 areas that approvals fail:
1. The person approving isn’t authorized. Check the names against the approval matrix or other guiding documents (i.e. SOX) for the right signoff levels.
2. The document doesn’t say what it approves. When issuing an email requesting deliverable approval make sure it spells out exactly what is being approved. Just saying “I approve the document we looked at yesterday” isn’t going to cut it.
3. Using voting buttons. At first it looks like a good idea: send an email and let them pick either Approve or Reject. The problem is the email content is lost on the return and all you get is the word “approve” or “reject.” It doesn’t say what they approved and it relies completely on the file name.
4. Doesn’t actually say “Approved.” I have seen questionable approvals that say “looks good” or “ok.” Not the best, but at least it indicates an affirmative response. The tough ones are the conditional approvals. If they say, “I approve this if Joe approves it” you better have Joe’s approval evidence, too. Or if it says, “I approve if you change these 3 things.” You will need to have it re-approved by everyone after those 3 things are modified.

Take a look at what you are presenting for your audit and don’t try to hide anything. The real reason for performing them is to identify areas that need improvement and then focus the necessary help on solving the problems. Besides, it can’t be as painful as a tax audit.

April 9 – Avoiding Hindsight Management

This article was originally published at http://projectmanagementlearningcenter.com/.

Growing up in rural western New York we had cold, long winters. Natural gas wasn’t cheap even then. With 4 sons and a chain saw, my dad would cut enough firewood to heat a big, four-bedroom, 2-story home from October to April.

Cutting firewood has its dangers, though. Those large oak and beech trees don’t fall quietly to the ground and stack themselves into neat, tidy rows. This manly job sparks famous last words like:

“I wonder how close I can drop this to the truck.”
“The ground looks solid enough to drive on today, doesn’t it?”
“Why is that tree hung up like that? Maybe if I pull on this…”
“What does poison ivy look like again?”

In hindsight these are all great questions but they should have been answered before taking another step. Risk Management begins with asking questions about what could possibly go wrong and then determining what to do with the answers.

Once you have identified your risks, there are 4 ways to deal with them: avoid, transfer, mitigate or accept. We will take a brief look at each of these and weigh them against their cost.

Avoid. The best way to keep from dying from a shark bite is to never go near the ocean. To the best of my knowledge, no one vacationing in Bolivia has ever been killed by a shark. On your project there are simple things that will help avoid risks. Developing detailed specifications will help reduce the risk of creating the wrong product. Choosing a known, stable development platform will lower the time expended on the learning curve and potential technical hang ups.

The down side to avoiding risks is that you limit your options. Detailed specifications limit flexibility during development. Using existing platforms will take you off the cutting edge.

Transfer. By finding someone else to take the responsibility of the risk you can transfer it to them. This is usually done for financial purposes. One way is to contract with a 3rd party vendor to fix bid a portion or the entire project. This transfers the risk of going over budget to them. Insurance is another form of risk transfer that we are familiar with. We buy insurance against the risk that our house might burn or our new gadget might break.

The problem is that this doesn’t really reduce the risk. It simply passes ownership of it to someone else. Because they won’t take it on without some reward it will probably cost you more to transfer your risks.

Mitigate. Mitigation is a proactive approach to reduce the probability of a risk occurring or the impact to the project should it happen. Documenting, assigning and tracking specific actions that will reduce the risk’s probability or impact allows you to manage risks effectively. If there is a risk that IT Architect Committee may not approve your approach, you should work with members of the committee from the beginning of the design to incorporate their ideas early.

For more information on Risk Mitigation refer to the Risky Business series at http://www.cuttingsedgepm.blogspot.com/.

Accept. Sometimes the best way to handle a risk is to not take action. It may be that the cost of avoiding, transferring or mitigating the risk is too high. The probability or impact of some risks is not worth the effort to deal with them. You may want to develop steps to take if the risk turns into an issue (i.e. contingency plan), but action other than keeping an eye on it isn’t necessary.

You will never completely eliminate risks, but by taking one of the options above you can lower the impact of it to your project. With better foresight you won’t need as much hindsight.

April 5, 2007 – It’s in the Game – Information Overload Part 2

An overload of information is like adding Olympic Games traffic to major city rush hour. No one ends up going anywhere. Yesterday we looked at how to reasonably limit the Project Schedule. Today we will look at meeting minutes and messages.

Meeting Minutes. Minutes are extremely important. I recall one project that I transitioned to another project manager where the client immediately started changing things previously agreed to. When asked about it I was able to pull out the meeting minutes and set the record straight. Unfortunately, minutes are usually the first thing dropped when project managers get busy. Sometimes the problem is that too much information is crammed into the minutes. It ends up taking longer to issue them than the meeting took. Here are some tips on handling them better.

1. Just the facts. Minutes are not intended to capture every word everyone says. Skip the discussion points and just record the decisions and action items. Too much detail takes too long and is counter productive. No one is going to read multiple pages of minutes for every meeting they attend.

2. Use a consistent template. Find a format that helps you organize the minutes and encourages you to keep them concise. Blank documents lead to writing paragraphs of information instead of bullet points.

3. Fragments are ok. Unless it is a formal environment it is ok to skimp on full sentences for your bullet points. Use good grammar, but keep it short.

4. Off load. You don’t need to do everything. For team meetings especially, have a different team member take the minutes each week. Train them on what you expect and let them handle it. If you have a team member that is aspiring to be a PM, give more of that responsibility to him/her.

Messages. Nothing puts me to sleep faster than a long voice mail. Pointless emails come in a close second. I’m sure you have received your share of both. You have probably had someone leave you a long voice mail and then follow it up with a mega-email on the same topic. So what is the best way to avoid overload for messages?

1. Pick your platform. Some things are better said than read. Phone should be used to get someone’s attention and get them to call back. If you are leaving someone numbers or other details, email may be the better choice. On voice messages longer than 30 seconds my mind starts to loose focus.

2. Delete and rerecord. If you find that you are starting to ramble or are trying to cram too much information into a voice mail, stop. Delete what you have and start over again. You may even want to rethink your choice of platform.

3. Leaving your number…twice. It seems like the more information someone leaves in a voice mail, the faster they blurt out their phone number. I end up having to listen to the whole message twice just to make sure I captured it correctly. Give your phone number at the beginning of the message, tell them why you called and then leave your number again.

4. Reread your email. Take the time to read what you type. Look for redundancies and excess wording. Re-organize your thoughts if necessary. Shorter emails get read and acted on sooner.

Information is great but too much information can get in the way. Learn the balance and you can increase your odds of winning the game.

April 4, 2007 – It’s in the Game – Information Overload Part

One of the advertising campaigns for EA Sports is “It’s in the Game,” referring to the fact that the games are technically accurate as well as fun to play. Actual statistics are included to make their games as realistic as possible.

While I was managing a project for Electronic Arts I began playing more of their games. Depending on your perspective the level of detail included can either be great or a real pain. If your favorite football team was on the top of the heap when the stats were taken it is great. But what if, like me, you are a Buffalo Bills fan? Not so good, eh? If you are from the United States, FIFA World Cup can be extremely frustrating. No matter how you play the game you are unlikely to pull off a major victory based on statistics. Hard core players can change the stats and build a better team but maintaining that much detail can be overwhelming.

Managing a project can cause much the same information overload. The key is to identify the right balance between enough and too much. Let’s take a look at that balance for 3 areas: Project Schedules, Meeting Minutes and Messages.

Project Schedules. Project Schedules are notorious for either a complete lack of information or radical overload. When planning and tracking your projects there are a couple of things that can help make it manageable.

1. 4 – 80 rule. Ideally task effort should be between 4 and 80 hours per resource. Instead of having 1 hour to review a document, 1 hour to make changes, 1 hour to review it again, and 1 more to approve, combine the effort and create one task to “Review and Approve.”
   
   Task over 80 hours per person are difficult to truly estimate. If I’m asked to do something that it is more than 2 weeks of effort I need to break it down further to fully understand what is expected. An exception to this rule is fixed duration tasks like support where you know it is a certain amount of effort and no more. If 80 becomes too granular for tracking purposes, make sure to include a separate checklist of items that make up that task. This allows progress to be tracked and keeps the team from burning the entire budget without accomplishing anything.
   
2. Avoid recurring tasks. Don’t set up a task for each meeting. MS Project allows you to create a “Recurring Task” for things like status meetings. This actually creates multiple tasks that you will need to track against. Too much detail. Instead, create a single task for each meeting that spans the entire project. You may even be able to combine all meetings into one if it is clear who should be charging for which meetings.
   
3. Off load. When you manage multiple vendors or departments push some of the effort to the PM or Team Lead for those groups. Set expectations for the timelines, deliverables and level of reporting you are expecting but let them handle the details.

Next time we will continue with ideas on how to avoid information overload with Meeting Minutes and Messages.

April 2 – 7 Steps to Overcome Misperceptions

People living in the LA area are big on perception. Billy Crystal used to say, “It is better to look marvelous than to feel marvelous.” Sometimes this works to your advantage. When I was in my early 20s my hair started turning grey around the temples. This gave me the appearance of being older and wiser and others took my ideas seriously as a result.

Other times, however, it can work against you. If someone has the perception that you are just a programmer, they are unlikely to let you run a project. When someone thinks you are always confrontational you can’t very easily argue them out of it. Perceptions are hard to overcome because they subconsciously taint the way people view you. They will overlook the 10 times you volunteer but remember the 1 time you were unable to pitch in.

How can you break these misperceptions? Here are 7 steps to help alter them.

1. Listen to the Accusation. Do not immediately go on the defensive. There is no way you can change a perception in a meeting so don’t try. Try to narrow it down to a specific problem. Sometimes people make it easy for you by saying, “you always….” Ask questions and make notes, mental or on paper, about their concerns.
   
   If you think you are experiencing the impact of misconceptions but no one has mentioned anything start investigating. Identify specific examples of how the perception seems to be playing out against you and analyze the situations. Talk it through with someone and ask, “Am I just being paranoid?” Keep in mind, just because you are paranoid doesn’t mean everyone isn’t out to get you.
   
2. Confirm the Perception. Verify that your perception of their misperception is real. Check with a close colleague to see if they see the issue. It may be that the person has the same reaction to everyone. Even if it is only one person’s perspective you will need to deal with it. You may be able to catch it before it spreads.
   
3. Find the Root Cause. Try to determine what the basis for their view point is. It may have been a rough first impression or misinformation from someone. Don’t start the Spanish Inquisition, but if you can identify the source it will help stop the problem.
   
4. Search for Truth. Check to see if there is any truth to the perception. Be honest with yourself and dig deep. In most misperceptions there is at least a small amount of reality.
   
5. Alter Your Approach. You won’t change minds by brut force. One group I worked with had a reputation of being defensive. Had they gone around yelling “we aren’t defensive!” they would have confirmed the perception. What they did instead was change their reaction when an issue was raised. Instead of immediately saying “It wasn’t us!” they switched to “I see your point, let me review the situation and set up a meeting to see how we can best handle it.” The end result may still be a change request, but the perception changed. You might be seen as willing to try instead of defensive.
   
   If people think you are lazy and unproductive, it may be because they don’t know what it is you do. Find a subtle method to inform people of what you accomplish. If you are not issuing a status report, start one or perhaps change what you report. Try volunteering for more visible assignments. Get noticed doing things.
   
6. Give it Time. Although first impressions are formed instantly, undoing them takes time. Continue in the new direction and start looking for changes in attitudes.
   
7. Talk it out. Sometimes perceptions are too deep to change subtly and a more direct approach is necessary. If the job or relationship is important enough it may warrant a meeting to calmly discuss the situation. Explain your perception and the steps you have taken to change. Many times the individual will not even have a clue that there was a problem. Other times you may be able to talk through your differences and move on.
   
   There may be times when real animosity exists. In those situations it is better that it is out on the table and addressed than festering in the background.

Misperceptions can be painful and may even ruin opportunities for you. Address them early and save the hassle later.