January 29, 2007 – Managing the Thing: Project Definition Part 3

Most of the topics that I cover could fill full books and several classes. I barely touch the surface and hopefully point you in the right direction. Even in the brief way in which we are discussing Project Definition it has taken 3 different entries to complete. Today will cover Roles and Responsibilities, Milestones and Budget, and the Management Approach.

Roles and Responsibilities. This section identifies the roles of specific resources involved in the project and outlines their responsibilities. Major miscommunications and unmet expectations can be resolved simply by clearly setting responsibilities here. Build a table with the columns Role, Name and Responsibilities. It is important to identify a specific individual with each role. Also, the Responsibilities column, as with Out of Scope section, offers you the opportunity to state what you expect others to do. The example below is for the Business Team Leads but you should also identify the Sponsor, Overall Project Manager, other Team Leads, external vendors and other key roles.

Role
Business Team Leads

Name
Heather Morgan (Demand Planning)
Jillian Enaile (Supply)

Responsibilities
· Represent their business unit on the project.
· Provide project status to Overall Project Manager and upper management.
· Identify and assign appropriate individuals to participate in JAD sessions.
· Review and approve the Design document, UAT, and Final Approval.
· Coordinate all aspects of UAT for their business unit, including test plan and test scripts creation, execution, and signoffs.
· Etc.

Notice the use of verbs to describe what is expected. Imbedded in the Responsibilities is another clarification on the UAT ownership.

Milestones and Budget. This section, as the name implies, identifies the major milestones and deliverables with planned start and end dates and estimated cost in dollars, hours, or both. This needs to align with the Project Schedule. By developing the schedule and PDD together you can perform checks against each of them to keep them synchronized. If you identify a deliverable in the Approach section, it should correspond with a group of specific tasks in the schedule. Similarly, if you have activities identified in the Project Schedule you need to account for them in the SOW.

Management Approach. Depending on the maturity of your organization the size of the Management Approach section may vary. It outlines how each of the following areas will be handled and sets the expectations up front.
· Communication Management – identifies reports produced and meetings held (ex. Weekly Status Report and Weekly Status Meeting).
· Issue Management – shows expected level of issue documentation and resolution plans, giving a specific path for escalation.
· Risk Management – documents how risk identification and mitigation and how when contingency plans are necessary.
· Change Management – describes what constitutes a change, how to document it and the approval process.
· Acceptance Management – gives direction on how to approve or reject deliverables and timeframes for doing either.

If your organization has any or all of these management approaches defined, do not recreate them here. Reference them and document any deviations that your project will follow.

These six sections (Background, Scope, Approach, Roles and Responsibilities, Milestones and Budget, and Management Approach) form a basic Project Definition Document. Depending on your environment and project needs, the level of detail and legal jargon that is required will differ. The concept remains the same: Define The Thing that is to be delivered. Set the project expectations in writing and then obtain formal approval of it. As we will see in the entries to come, this document forms the basis for both change and approval.

January 26, 2007 – Managing the Thing: Project Definition Part 2

Without defining the project, The Thing will likely fail to get accomplished. It will consume more time than anticipated and accomplish less than expected while costing more than it should have. When the wide variety of documents are boiled down to their simplest form that basics that need to be communicated are the Background, Scope, Approach, Roles and Responsibilities, Milestones and Budget, and Management Approach.

Project Background. The background is meant to describe who requested The Thing, what it is, why they requested it, and how the team arrived at the current point. A successful background is short and correctly spells the name of the person that requested it.

Scope. The scope section documents exactly what the team is responsible for (In Scope) and, just as importantly, what it is not (Out of Scope). Items should be identified clearly. As an example, “Support of User Acceptance Testing” does not clearly set expectations. You may be thinking, “make sure the system is up, answer a few questions, and fix anything that fails.” What the Sponsor may read between the lines is, “create the test scripts, train the testers, and supply coffee and donuts.” A better scope statement might read:
Support User Acceptance Testing by ensuring that the system is available, refreshing test data, recording defects and tracking corrections, and facilitating daily UAT meetings.

The Out of Scope portion further refines the expectations by addressing items that a newbie to the project might otherwise assume were the team’s responsibility. Examples would include:

• Training testers on the use of the system is the responsibility of the Training Department.
• The UAT Test Scripts will be developed by the Business as directed by the Business Project Manager.
• Bring your own stinking coffee and donuts.
  

Well, maybe the last one shouldn’t be in the final document.

Approach. The approach outlines the Technical Environment, Development Life Cycle and Deliverables.

Technical Environment. Is this web development or COBOL, JAVA or Infomatica? Clarifying this up front will set everyone’s expectations. This is not a Technical Specification so give a high-level overview and refrain from details of how the parts interact and perform.

Development Life Cycle. What phases or process will be followed as the project unfolds? Will you do prototyping, execute a pilot, or use JAD sessions to drive out requirements? Briefly define what the involved parties can expect.

Deliverables. This is the real substance of this section. In some cases it may make sense to have a separate section for it. Deliverables are the building blocks for the project and serve as checkpoints to verify progress. The sum of all of the deliverables should constitute the whole project so it will be helpful to develop a Work Breakdown Structure (WBS) to identify the all.

Each deliverable should be listed with its name, description, acceptance criteria, and approval authority. Below is a good example of a deliverable statement.

Name
Statement of Work

Description
This document defines the project by identifying the Scope, Deliverables, and Roles and Responsibilities. It is an agreement between the involved parties and forms the basis for project expectations.

Acceptance Criteria
The document contains the following sections:
1. Background identifying the request and brief history.
2. Scope of the project.
3. Approach with Technical Environment, Development Life Cycle, and all Deliverables identified.
….
Each section clearly articulates the expectations of each stakeholder.

Approval Authority
Project Sponsor
Business Project Manager
IT Project Manager
Manage of Sales

A good way to present this information is in a table. Notice how in the Acceptance Criteria lists the specific sections we have discussed. As we will see in the Acceptance Management section, those criteria are what the approver should be verifying when deciding whether or not the deliverable is done.

In the next entry we will cover the remaining sections of the PDD.

January 25, 2007 – Managing the Thing: Project Definition Part 1

The first key piece to successfully delivering The Thing is defining the project. PMI identifies three major documents that are used to do this:
1. The Project Charter grants formal authority for the project.
2. The Project Scope Statement documents what work is to be accomplished and the deliverables that need to be produced.
3. The Project Management Plan documents how the work will be performed.

If you think that the Project Management Plan is the same as the project schedule you would fail the PMP exam. A full Plan includes sections or even separate documents that lay out how you will manage the Scope, Schedule, Cost, Quality, Staffing, Communications, Risks and Procurement.

If you work for a company that doesn’t have this level of maturity yet, I would suggest creating a condensed version and calling it the Project Definition Document (PDD). Think of your project as a big sandbox where everyone is trying to build a castle. You need to know the rules of the sandbox and what you are building. That is the purpose of the PDD. By agreeing up front what you want to accomplish and how you are going to accomplish it, the complete team (Sponsor down to the coders and testers) can shovel sand in the same direction. Once completed the PDD should be reviewed and approved by the key project stakeholders (i.e. Sponsor, Project Manager(s), Business Manager, etc.).

I worked at a company where defining the project in writing and getting it approved was not encouraged. The reason became apparent as additional items were added to the scope. Project managers struggling to create detailed PowerPoint presentations for the overall project status. It had to cover aspects of the project they had no control over and little visibility to. The PM was stuck doing it because there was no documented understanding of the division of responsibilities and no authority to delegate it.

Tomorrow we will begin to look at the six areas that should be included in the Project Definition Document: Background, Scope, Approach, Roles and Responsibilities, Milestones and Budget, and Management Approach.

January 24, 2007 – Managing to the Thing: Introduction

Several years ago I volunteered to participate in a massive PC cleanup effort after a company wide virus attack. At the time my project deliverables were behind schedule and the virus was putting me further behind. As a Project Manager, that is not a good feeling. It was less than a month after returned to project management from the Software Quality Assurance group and I could feel the pressure from both sides. In my mind the SQA group was saying, “Finally, someone who knows the processes and can show those Delivery people how to do things right!” Meanwhile my new Delivery co-workers were rooting, “All right! Now one of them is going to find out just how difficult it is to follow their processes!”

While I was checking and installing virus protection in multiple buildings with several floors that night I had plenty of time to think about the things I wasn’t getting done. My new day job was proving to be very tiring as I attempted to stay on top of the wave of activities. I was trying to juggle everything, rushing from meeting to meeting, jumping from task to task and not completing anything. The strain of the urgent had choked out the basic principle that I knew: You have to define it before you can accomplish it.

Central to successful project management is delivery of the end product, or The Thing. In order to do this effectively, three key pieces need to work together: the Project Definition*, Change Management, and Acceptance Management. Over the next several days I want to outline the main aspects of each of these and show how they form the basis for project success.

Why these three? The Project Definition, Change and Acceptance at their core are simply communication vehicles. When used together, these three:
· Define The Thing that is to be delivered,
· Allow The Thing to change,
· Let everyone agree that The Thing is completed.

Without communicating these three, projects would go on forever without satisfaction for anyone.

*Project Definition – The defining document(s) for the project. Consulting companies use the Statement of Work. Internally it may be a Charter or the Scope Statement together with the Project Management Plan.

January 23, 2007 – Avoiding the Idiot List

I have a renewed dislike for stupid drivers. A buddy and I have been carpooling. Here in Southern California the freeways have carpool lanes with limited access at well-marked areas to enter and exit and a $300 fine for violators. On heavy traffic days you can sail along past the other three lanes, which are generally standing still. That is where the stupid drivers reside with their blatant disregard for the law, safety and my sanity. Obviously the regulation must not apply to them so they swerve into the lane in front of us.

Unfortunately there are idiots at work, too. Try to avoid these annoying actions and you won’t end up on anyone’s idiot list.

Not backing your team. Two of my co-workers were complaining to me one day about their manager. She was new to the group and had a completely different philosophy of management. The previous manager focused on enforcing the standards, even when it meant standing up against upper management. The newbie correctly identified the rift between the groups but assumed it was the fault of her new team. It took the team nearly six months before she came around and started supporting them.

Playing the dumb blond. During my auditing days there were certain females that thought if they batted their eyelashes and pretended to be helpless I wouldn’t be as hard on them. Granted, not all of them had blond hair. I treated them just the same as everyone else, but I might have spoken slower and use smaller words.

Ditching your own meeting. A friend of mine had a manager that scheduled a daily 7 AM phone conference for status meetings. That might be enough to get on my list but that wasn’t the worst of it. The manager didn’t show up for the first two meetings and left everyone sitting on the phone for 20 minutes until they gave up and left. The third day he called in late and was on the freeway heading for the airport. No one could hear him and there was little chance of him remembering anything. Worse, he never even apologized. My guess is he was swerving into the carpool lane.

January 22, 2007 – The Power of “I Told You So”

It is a wonderful feeling to be right, especially when you prove someone else wrong. Unfortunately, as project managers most of what we predict is bad news: our project schedules foretell that we won’t be able to get done on time; our budget analysis estimates we will be run out of money; we can’t add that change to the scope and still meet the deadlines. Somehow we are expected to be miracle workers and get it all done on time and within budget. When it doesn’t happen it is our fault. So when we are able to say, “I told you so” what they hear is “I failed.”

Although there is you can rarely use the actual words, there is power in letting people know it. The real power comes when everyone knows it and you didn’t have to say it. From a budget, cost and schedule stand point you can wager your reputation that you are right by placing your B.E.T.S. (Baseline, Estimate, Track, and Status).

Baseline. A baseline is a benchmark against which a measurement can be compared. Set the baselines for your project to the scope statement, established budget and promised end date even if they are unattainable. This is what you have been given to work with and they establish the project goals.

Estimate. Determining and documenting a realistic estimate is important. Go to the team and together work out an aggressive but achievable assessment. It should include enough detail to show if the baseline is achievable. This estimate becomes your “I’m telling you now so I can say I told you so later” statement. The trick is to present it so it doesn’t sound like you are saying, “I’m going to prove you wrong.” Call it the current estimate based on available information and let them know you are working to reduce the variance.

Track. People get away with asking for early dates and low budgets because the effort isn’t tracked and compared against the original request. By collecting actual effort and re-estimating the remaining work throughout the project you can show progress against the budget and schedule. Over time these statistics will show how the project is progressing toward its goals.

Status. On a weekly basis a status report should be issued that indicates where you are in the project compared to where you thought we should be. Analyze the data to show what effects your correctional steps are having on bring the project in on time and within budget. The object of the status report is to make sure there are no surprises if the deadline and / or budget are both blown.

In the end you probably won’t be able to stick your tongue out and say, “I told you so.” You might be able to word it like “This is what we were able to accomplish with the time, resources and budget that we had.” It may not feel as good as “I told you so” but they will get the picture and it won’t burn any bridges.

January 19, 2007 – Avoiding Unwanted Appraisal Comments

Annual reviews are a necessary evil. Everyone needs to get a clear picture of their performance and how it measures up against what is expected. Few people enjoy writing them and, unfortunately, not all employees are going to like what they find out. As managers we try to make positive comments but spin can only go so far. Hopefully you will never receive any of the following comments on your review.
· Consistently fails to meet his own low expectations.
· Encourages others to complete his assigned tasks.
· Redundantly fills out forms with useless information.
· Successfully manages personal business during office hours.
· Shows strong leadership skills in the area of bad decisions.
· Contributes non-helpful comments during meetings.
· Great example of what not to do.

So how do you keep from ending up on the lame end of a bad review?

Confirm expectations. A job description is a good place to start but usually isn’t the full picture. The last sentence for most jobs reads “and other duties as necessary.” Even if you have been employed at the same place for a while, ask your manager if there are additional responsibilities you should be taking on.

Set Goals. Look beyond the description of your current position and understand the requirements for the next two levels up. Pick specific behaviors or activities that meet or exceed the expectations for those levels and work toward them. If you are successfully performing beyond current expectations it will show up in your appraisal.

Record Accomplishments. Keep track of the projects and efforts you are a part of, especially the benefits achieved for the company. If you get an email from someone giving you kudos for a job well done, keep it. Use them when you fill out your self-appraisal to add specific examples to your statements.

Practice Safe Self-Promotion. I had a co-worker many years ago that continuously talked about how great he was and why he deserved to be promoted. Very annoying. I am not suggesting you do that, but a little plug for yourself at opportune times is sometimes necessary. If you are looking for an advance, express an interest and ask what the requirements are. When your team accomplishes something positive let management know about it.

Good appraisals and subsequent promotions don’t just happen because you do a bang up job at the same thing every day. Without setting goals based on a solid understanding of what is expected and working to exceed those expectations you may be settling for mediocre reviews.

January 18, 2007 – Mangled Meetings

Ouch. You just sat through another painful meeting. Your sitting-down-parts are numb. The right side of your brain fell asleep and the left side spent most of the time doodling. You counted five, no, make that six times the person across the table nodded off. The same person that monopolizes every meeting wouldn’t stop droning on. “Man,” you mutter to yourself as you leave, “I’m glad my meetings aren’t like that.”

The following ruts can mangle even the most anticipated meetings.

Lack of Agenda. Without an agenda a meeting will likely get hijacked. Just like going shopping and leaving your list at home, you may end up with a lot of interesting things but not what you needed. With an agenda you stand a chance of accomplishing what you set out to do. A secondary benefit of having one is being able to reign in Mr. Monopolizer by gently saying, “That’s nice but we need to get back on topic now.”

Late Start. In a number of places I have worked there was a decided lack of the attention to timeliness. People tend to show up late and meetings don’t get started on time. Announce to the team that you respect everyone’s busy schedule and so you intend to start and stop your meetings on time. Then follow through.

Out of Time. Some meetings are very productive. You are frantically collecting valuable information as time slips by faster than expected. About 5 to 10 minutes before time expires take a quick look at the agenda to determine if you are going to finish on time. If possible, adjust the agenda to hit a couple of final critical points. If you won’t be able to complete on schedule, thank the group for their time and ask how they wish to proceed. They may ask you to schedule a follow up meeting or they may wish to go into overtime.

Background Noise. Some people are clueless when on a conference call. There is always somebody that can’t find the mute button. I swear in one meeting I actually heard someone snoring. The sound of traffic from the person driving in is always a winner. Stop the meeting and remind everyone of the code to mute their line (ex. Press *6). If it persists specifically name the sound that you are hearing and ask whoever it is to put a stop to it. “HEY! WHOEVER IS SNORING, PLEASE MUTE THE LINE!!”

No Minutes. I must admit, I have two sets of meeting notes sitting on my desk waiting to be typed up. Remember, if it isn’t written it never happened. No one will remember what decisions were made or who volunteered to do what if there aren’t minutes. They don’t have to be word for word transcripts written on a triplicate forms. One effective alternative is an email to the attendees with bullet points for the major decisions and action items. Of course a standard form (i.e. the same one used for the agenda) stored in a common directory keeps them consistent and easy to locate.

Browsing through Barnes and Noble last weekend I found several books on leading effective meetings. Maybe these simple concepts will revitalize your meetings and keep you from shelling out $20.

January 17, 2007 – Integrity: At least try to fake it

Integrity is one of those old-fashioned words. It gets thrown in with words like horseless carriage, nifty and swell, house calls and milkman. It has been replaced by ideas like politics, expedience and sales calls. One sales guy I worked with summed up integrity in the work place by saying, “Pick us ‘cause we aren’t as slimy as the competition.”

Maintaining your integrity is a full time job. I even find myself slacking off once in a while. Here are a few reminders to help get us back on track.

Be on time. It seems that the cable guy syndrome has spread to other industries. They show up for meetings whenever they get around to it. One of the more annoying cases of this is dialing in to conference calls. The service we have prompts you for your name and then announces that you have arrived. If you are late the meeting is rudely interrupted mid-sentence with “Joe Smith…is now attending.” Part of the problem is that we stack meetings on top of each other. To alleviate this, one project manager I know schedules his meeting to start at 15 minutes after the hour. Unfortunately people still come in late.

Do what you said you would. Be a person of your word. If you say you will take care of something, do it. When you commit to a deadline, meet it. If you anticipate a problem accomplishing something, contact the individual and request an extension. Other people make commitments based on your promises. When you don’t follow meet your obligations it impacts more than your integrity.

Put in an honest day’s work. Some people leave early to make up for coming in late. When they are at work they may be playing solitaire, talking on the phone or go strangely absent for hours on end. Don’t just fill time. Be productive.
Seek work. I have been on engagements where there isn’t enough work to keep me busy. It drives me crazy because I always feel like there is something I am forgetting to do. If you don’t have enough to keep you busy make sure your aren’t dropping a responsibility and then ask for something more to do.

Report accurately. Your communications should be accurate and honest. This is true of your timesheet, status report, financial records and schedule. I’m not suggesting doom and gloom reporting. You can put the information in a positive light, but make sure everyone is kept informed and no one receives any unpleasant surprises.
A friend of mine recently fired an employee for failing to meet these simple standards. If you don’t think you have the moral fiber for it, try faking it for a while. Be cautious, though. Integrity may develop into a habit if you aren’t careful.

January 16, 2007 – Lessons from a Shotgun

I grew up in rural western New York State. By rural I mean there were more cows than people in most of the towns. The street my parents live on to this day intersects with Pondunque Road. The college I graduated from, Houghton College, boasts that it has at least two trees for every student. Because of this forest filled environment it seems that everyone owns guns. My brothers were out back one afternoon practicing their shooting skills. They hung a can from a tree by a string. One of them would swing the can, get out of the way and the other would try to hit it.

My dad was a chef at the college and would cook breakfast and lunch, come home to take a nap and then return to cook dinner. Needless to say, gunfire doesn’t allow for much napping, so out he comes. When he arrives he takes the gun and says, “Let me try.” The can swings, my dad fires, the rope snaps and the can flies to the ground. “That, boys, is how you do it.” He handed the gun back, turned and went back to work.

I learned three things from that unspoken lesson.

1. It is better to be lucky than good. A good shot would have hit the can, making it jump and bob. Hitting the string would require a marksman or a lot of luck.

2. Never admit it wasn’t planned. Planning well and working hard will set you up for success, but sometimes you accidentally hit a home run. Don’t stand around looking dumbfounded; act like you meant to do it. Let others try to determine if you are a marksman or just lucky.

3. Know when to walk away. My dad could have shot for the rest of the day and never hit that string again. He knew it and quite while he was ahead, leaving us standing around with our mouths open.

January 12, 2007 – How to Really Fix a Failing Project

You project is in trouble. You know it. Your team knows it. But somehow you have been able to keep it from your management. You need a quick fix. But there aren’t any. What can be done to get back on track? Since yesterday's ideas didn't help, here are some suggestions that might point you in the right direction.

Refocus the Scope. Begin by going back to the defining documents including your Charter, Statement of Work and approved Change Requests. Figure out what you have committed to accomplish. Conversely, document all of the things that were unofficially added to the project. What you are trying to obtain is a clear understanding of the commitments and the expectations of others. With these lists in hand, meet with the project sponsor (or similar key stakeholders) and agree on what should be part of the current effort.

Draw up the Schedule. Based on the remaining effort and current resources, recalculate the schedule. Forget the deadlines placed on the project at this point. Given the amount of work and people available, determine a realistic timeframe to complete the revised scope.

Determine the Cost. Find out what the budget is and how much has already been spent. After calculating the difference between the two amounts (hopefully it isn’t negative) compare it to what remains to be done. Based on your revised schedule run the numbers to determine a reasonable Estimate to Complete.

Review Lessons Learned. Meet with the team and other stakeholders to determine where the project went wrong. Develop a list of steps to take in order to avoid the same thing happening next time.

Develop Alternatives. Using the scope, schedule and cost information review the options available. Based on the Project Triangle* that pits scope, time and cost against each other, consider the impact of each of your options on those factors. Will your plan include adding more resources? Extending the date? Reducing the scope? Although “Phase 2” is always the answer most project jokes, it can be a solid alternative. In some extreme cases the right decision will be to cancel the project. Although an unpopular choice, some projects need to be dropped. Reduce the testing phase is usually the popular option, but I don’t suggest it.

Admit Reality. Once you have drawn up a couple of viable alternatives, present them to the management team. Begin with a healthy dose of reality. Management does not like going through the failed project dance. If they have to do it twice things get ugly. Lay out the situation, preferably without playing the blame game. Then present your plans for getting back on track. Let them help you talk through the options and make suggestions.
Start Fresh. Issue a revised scope statement, obtain the funding, reset the schedule and obtain appropriate approvals. You have been given a new lease on your project. Work the plan and make sure to incorporate the Lessons Learned from your first attempt.

* Project Triangle: Picture a triangle where each of the three sides represents Scope (or functionality), Time and Cost. If you change one side it impacts the other two. Reducing the size of the Scope side will allow you to reduce the Time and/or Cost side. It is the same for the other sides as well. This is a standard and effective way to communicate the struggle between the three.

January 11, 2007 – How to Fix a Failing Project (Not)

You project is in trouble. You know it. Your team knows it. But somehow you have been able to keep it from your management. You need a quick fix. What can be done get back on track? Here are some tried and true ideas that could do the trick.

Rename the project. The beauty of this is that people won’t recognize it. It is like a new lease on life. People will soon forget the problems with the old project and focus on the new and improved one. Just don’t use the name “The Project Formerly Known As….”

Declare victory. If your project had 10 objectives but you only accomplished 3, hide the Scope Statement and throw a big party. Convince the business that the 3 that were implemented were the only ones they really needed.

Restructure the team. Obviously fresh legs are needed to carry the project forward. It doesn’t even need to be new people. You could try just shuffling them around a bit, maybe elevating a new team lead. Easier still, just rename the resources.

Blame the requirements. Evidently the business didn’t know what they were asking for or they would have been clearer. If the requirements were better written the project would be done by now. Better go back to square one and rewrite the requirements.

Begin Phase 2. This is the ultimate fix. Phase 1 was obviously a learning experience and created a foundation to build on. Phase 2 is where it will all come together. Used with the declaring victory tactic this can be extremely successful.

If you use these tools you will baffle and amaze your critics.

January 10, 2007 – Evil Alter Ego #5: Ms. Meetings

We’ve beaten Mr. Genius, Ms. Bellows, Mr. Promise and Mrs. Process. But what chance do we have against Ms. Meetings? She is very sweet. As a matter of fact, she brings donuts to all of her meetings. And she certainly has a lot of them. Any time there is a question she calls a meeting. She has regularly scheduled Status Meetings, Team Meetings, Progress Meetings and Recap meetings. During testing there is a meeting at 7:00 AM to determine the daily schedule, a meeting at noon to check on status and one at 6:00 PM to review results. Then every hour on the hour she meets with the individual areas to make sure progress is being made. She even had a couple of meeting to determine why productivity was so low.

Meetings are like vegetables and exercise: good in moderation but overdosing becomes boring and painful. If you find you are attending or calling too many meetings consider the following advice.

Make a list of all meetings. Go through your calendar for the past month and write down all of the meetings you lead or attended. You may be surprised by the total number.
Document each meeting’s purpose. Every meeting originated to fulfill a need. That sole objective of calling a meeting should not be to discuss, review or consider. You will certainly do those things but meetings need to have a point. Add focus by setting a goal like “to determine,” “to finalize [task list, assignments, report, etc.]” and “to approve” [change request, deliverable, document, etc.].

Eliminate redundant meetings. Review your list and narrow it down to the unique purposes. If you have three different meetings scheduled to address testing, you may only need one.

Combine similar meetings. If you have two status meetings with the same individuals but for different projects, combine them. Perhaps it makes sense to have the Issues meeting combined with the Risks meetings. An effective status meeting technique for mid-level managers is to hold one meeting with multiple project managers discussing their projects as a group. This eliminates scheduling half hour meetings with each and the wasted time between sessions. It also makes other PMs aware of the efforts, issues and risks others are facing.

Use other communication methods. If your meeting is simply to relay information you might be able to accomplish it better by sending well written emails or documents. To eliminate the need for one of your testing meetings use a tool like SharePoint, a document on a share drive or even a project web site that can be updated by the team as they complete each step.

Thus ends our first round of evil alter egos to combat. I’m sure our super-hero gene will spawn others to plague us in the future, but until then remember: “with great power comes great responsibility” (quote from Spiderman’s Uncle Ben).

January 9, 2007 – Evil Alter Ego #4: Mrs. Process

Fighting alter egos can be tough work. Like Dr. Jekyll striving against Mr. Hyde it can seem like a loosing battle. Especially when a particular alter ego seem so helpful in the beginning. Take the case of Mrs. Process. She starts by figuring out how things are done and documents the procedures. Working with others she identifies faster and better ways of getting things done and incorporates them. By performing audits and making sure that the procedures are followed she can spot problems before they become issues. The problem starts when she becomes inflexible and intolerant. As she turns over to the dark side her focus become the letter of the law. Forms become static and any alterations are denounced vociferously.

Don’t misunderstand me. As a former Software Quality Assurance Analyst and Project Officer I am a big fan of process. It is when we become slaves of process that this alter ego wins. It isn’t limited to QA people, either. Project managers can become mired in process. How do we stop this insanity?

Question the process. Processes are meant to speed up development by being consistent in the way tasks are performed. Over time they should evolve and improve. That doesn’t always happen. If a process you or your team is being asked to perform doesn’t make sense, question it. Find out the purpose behind it and determine if it is going to help or hinder you from achieving that goal.

Focus on purpose. Once you understand the spirit of the law make that the focus. If the process needs to be bent, bend away. Very few processes were intended to be rigid. Granted, if you are working with nuclear materials there are some specific process you need to follow. But when you are managing a project the letter of the law is not always required. Do what makes sense using the processes as guidelines.

Allow for exemptions. Sometimes it just makes sense to bypass a process. If you have a strict Quality Assurance group or are subject to Sarbanes-Oxley requirements it is important that you get permission, usually in writing, to do so. Corners can be cut, but you need to ensure that the project and company are not placed at risk by slicing too much.

January 8, 2007 – Evil Alter Ego #3: Mr. Promise

So far we dealt with Mr. Genius by clueing him in to what everyone else already knows: he doesn’t have all the answers. Then we overcame Ms. Bellows by dealing with the root causes and calming down. But Mr. Promise seems like he would be a great guy to have around. How could he possibly be evil?

Unfortunately, Mr. Promise is extremely dangerous, both to his own career and to his projects. The only thing worse than not keeping all of the promises he makes is when he actually attempts to. If he breaks a promise people get mad and he will eventually get fired. In an attempt to keeps every promise his project is likely to either go way over budget or far beyond schedule. To curb this alter ego you need to pick, protect, track and close.

Pick your promises appropriately. Just because something sounds like a good idea doesn’t mean it should be tackled. Even if a task needs to be done it doesn’t mean it should become your responsibility or be dded to your project. Granted, if you are the expert and have the time, go ahead and volunteer. If not, allow someone else to step up. One trick is to simply wait quietly. The silence may encourage someone else to take it on.

Protect the project. Check the request against the scope of the project. If it passes that test then check the budget and schedule to see if it can be included. Depending on the size of the request use the Change Management process to authorize and fund it.

Track your promises. The big items that are handled through Change Management are easy to track. It is those annoying little ones that are made during meetings and in casual conversations that tend to trip us up. Make sure you document and track them as action items. For meetings, use minutes with a section for recording action items for the group. Assign both a resource and a due date for each action item and check the progress at the next meeting.

Close them out. When a promise is met, make sure to loop back and let the person know it is completed. In some cases they may not even remember asking for it. The follow up will give them a chance to verify it is what they expected and will bring closure to the request.

Mr. Promise’s desire to help is honorable and with these simple steps we can keep him from destroying himself.

January 5, 2007 – Evil Alter Ego #2: Ms. Bellows

The superhero gene inherent in project managers can mutate and become something ugly. Such is the case with Ms. Bellows. Instead of discussing, she yells. People leave her office in tears. Behind her back people call her Yelly Kelly.

The problem is that she is successful. People jump when she says to and projects get done on time. This makes upper management happy and she is rewarded, reinforcing the original problem. Eventually no one willingly works with her and some of the best resources leave the department, company or even country.

If you see this trait in you, how can it be stopped?

This is a tough problem because there are so many factors tied in to it. Family origins, bullied as a child and inferiority complex are prime examples. I’m sure through psychoanalysis Freud would determine that she was deprived of Starbucks in junior high. Some of the blame obviously falls on the environment that allows or even fosters her behavior. Because everyone expects this attitude the cards are stacked against change. But if you see some of Ms. Bellows in your actions and want to break out of it, there is hope. Here are a few things you can implement to reduce the volume.

1. Acknowledge that it is a problem. Look at the negative impact it is having on your team and your ability to lead. Your feelings are legitimate. There are things that make us all mad. The problem is the action.

2. Address the causes. Sit down and make a list of the things that really tick you off, like dropped commitments, missed dates and unforeseen issues. You know what your hot buttons are. Now train yourself and your team to deal with the root causes of these problems before they happen. Record action items in meeting minutes so commitments are clear and expectations are set. Refine estimation techniques to set realistic dates and track to them. Use risk mitigation to identify potential issues and address them before they happen.

3. Take a deep breath. When you are ready to let fly with a verbal barrage take a hearty breath in through your mouth. This does 2 things for you. First, it is very hard to make your vocal cords yell when you are breathing in. Second, it gives you a brief chance to relax and change what you are going to say.

4. Replace yelling with a catch phrase. Instead of yelling, imagine if you said something like “I would normally be yelling by now, but….” Most people hear better when they are not being yelled at. The natural tendency is to become defensive or tune out. Catching them off guard like that may help them listen this time and do things differently next.

NOTE: Screaming is abusive and doesn’t belong in the work place. If you are a victim of a yeller and feel like you are in a hostile environment, speak to your HR department. If you recognize it in yourself, seek help.

January 4, 2007 – Evil Alter Ego #1: Mr. Genius

There is a certain gene in the DNA of a project manager that results in a superhero complex. We are the ones that find leadership voids and itch to fill them. If there is chaos, we long to tame it. When things are wrong we strive to right them. Where there is no org chart…well, you get the idea.

Unfortunately there is also a dark side to this gene. The side that urges us to become bosses instead of leaders, engrossed in schedules instead of managing and concerned with process over people. These next entries are dedicated to fighting those tendencies and overcoming our Alter Egos.

The first Alter Ego that needs to be dealt with is the Mr. Genius. He is prevalent among new or weak project managers that have moved up the ladder from a technical background. He thinks that since he is in charge he must be the brightest and have the best ideas. Their ideas are presented as facts and the team had better fall in line behind them or else.

There are several downfalls to this concept. First, as you transition from the technical realm to project management you can’t stay current on the latest and greatest. Naturally your ideas start to become old school technically. Second, it stifles any ability of your team to bounce ideas around and make them better. Third, you begin to realize that there are brighter bulbs on your team than you. Finally, your team will eventually find people to work for that value their abilities to think.

The only way to overcome this is through my 4-step program.

1. Repeat the following: “My idea is not the only idea and sometimes it isn’t even the best one.” If you struggle saying that then keep repeating it until it sticks. Eventually you may realize that you want people on your team that are smarter than you. It increases your odds of success and allows you to concentrate on managing.

2. When you present an idea make it the starting point and not the final decision. Be the first ones to point out a flaw that needs to be addressed. This encourages others to either replace your idea or make it better.

3. Don’t stubbornly hold on to an idea that has been bested. You will only build animosity with your team.

4. Appreciate the final product. Acknowledge the team’s success and refrain from muttering “my idea still rocks” under your breath.

Following these steps will result in a more productive team and keep you from burning out trying to be the brightest one in the bunch and the evil Mr. Genius can be sent packing.

January 3, 2007 - NMJ (Not My Job)

A project manager once came to me with an interesting dilemma. It seems the manager for one of her projects was asking her for status reports on projects she wasn’t even involved with. As she explained the situation it became clear that this manager had not assigned PMs to 3 or 4 projects that he was responsible for. She felt trapped. She couldn’t easily say, “Hey! That’s NMJ (Not My Job)!”

My suggested solution was to handle it like a change request. First, determine the amount of time spent on a weekly basis to gather, document and present the status for each project. Depending on the level of reporting this could be significant (i.e. progress reporting, financial reporting, issue and risk reporting, defect reports, etc.). For this PM the effort was compounded by the fact that she wasn’t remotely part of any of the projects.

Second, meet with the manager and explain the impact this is having on other projects. Show him the estimates and point out that these projects need their own PMs assigned that are able to do more than just report status. In essence, verbally issue a change request and ask if this should be made part of your project. This ought to be enough to make him see the problem and find a different solution.

However, if he insists the reporting continue you may have a decision to make: live with it or say, “No.” For the “just say no” side, I was once asked to add a fourth project to my workload. In that case I explained that I could not successfully manage another and declined. I know the manager was disappointed and I probably lost some of his respect, but I knew it wasn’t possible.

If your decision is to continue doing the reporting, at least make sure you are placed on the projects for time reporting or billing purposes so the effort is taken from the right budget. This will help hammer home the impact without killing the budget of your original project.

January 2, 2007 – Ransomed Projects

It’s the week before go-live on a major initiative. Tests indicate that all requirements have been met, input feeds are working properly and output is as expected. Unfortunately there is a problem that is keeping you from going live. The business has determined that “just one more thing” is necessary before they sign off on the implementation, effectively holding the project ransom. What can be done?

First, remember who the project owner is. Although your department is responsible for making it happen, there must be a business purpose for it to be of value. Since it is their project, they have the right to put it in jeopardy.

Second, determine and communicate the impact of the change to the project. This includes the cost in money and schedule. With a week to go to implementation it is unlikely that any amount of money is going to have an impact. The real issue will be the schedule. Give a realistic assessment of the timeframe including adequate testing to ensure a success. It may not be the right decision in your eyes, but it is theirs to make. If this is a feud between different business groups, stay out of the middle of it. Give your advice and step aside.

Third, whatever is agreed to, make sure it is documented and approved. Include any decision to forego proper testing. This ensures that it is a conscious choice to move forward and that everyone is clear on the implications. Being the professional that you are I’m sure you will never use it to say, “I told you so.”

Ideally there is another level of management (i.e. Project or Program Management Office) that could help you present the case for moving the implementation date or negating the new requirement.

In extreme cases where the well being of the company is at stake, you may need to escalate the issue to upper management for arbitration. If this becomes necessary don’t do it anonymously or behind anyone’s back. Be honest with the team and explain why you are doing it. When possible request a meeting and include the key stakeholders in the discussion. Then keep it a discussion. Don’t let it become a shouting match where the loudest one gets their way and you loose your job.

In the end you will probably be required to do the impossible yet again and cram in the new requirement. The difference will be that it was an informed and supported decision not done through hostage negotiations.