Monday, December 24, 2007

December 24, 2007 - Twas the Night before Christmas

Technically it is the extremely early hours at the beginning of the day before Christmas. I've just spent the last several hours wrapping presents with my wife and listening to music. Rather than making a half hearted attempt at writing something intelligent I will simply wish you a Merry Christmas.

"And there were shepherds living out in the fields nearby, keeping watch over their flocks at night. An angel of the Lord appeared to them, and the glory of the Lord shone around them, and they were terrified. But the angel said to them, 'Do not be afraid. I bring you good news of great joy that will be for all the people. Today in the town of David a Savior has been born to you; he is Christ the Lord. This will be a sign to you: You will find a baby wrapped in cloths and lying in a manger.'

Suddenly a great company of the heavenly hosts appeared with the angel, praising God and saying,

'Glory to God in the highest, and on earth peace to men on whom his favor rests.'"

Luke 2:8-14

May you seek that great joy and know true peace.

Merry Christmas from the Cutting's Edge.

Sunday, December 16, 2007

December 17, 2007 - Use Case Diagrams: A PM's View

Last week I attended a class on managing requirements with Use Cases. It was aimed at training business analysts and programmers to use Unified Modeling Language (UML) to understand and communicate business requirements . As a project manager I found it both enlightening and encouraging.
Enlightenment. Bottom line, modeling requirements is the quickest way to work with the end users and agree upon of what the system should be designed and developed to do. Because our focus was requirements, the class used Use Case diagrams as the basis for the training.

The three main components of a Use Case diagrams are the Actors, Use Cases and Scenarios. Actors are represented by stick figures, Use Cases by ovals and Scenarios by text boxes. An Actor is a role played by either humans or other systems that interact with the system being built. A Use Cases is a complete series of events handled by the system to help the actor achieve a goal. Scenarios detail how the Use Case will achieve those goals.

In one of my training sessions I use the eXtreme Insurance company as the basis for the exercises. The company is creating a new system to support the sale of life insurance policies to extreme sports nuts. These policies will be sold by cashiers of D&L Sporting Goods stores. The diagram above details the Purchase Policy use case. Other use cases that would be added to this diagram include Process Claim and Reconcile Transactions.

These quick, graphical representations are developed from information gathered through interviewing the users, observing system usage, researching similar systems and other means. The diagrams are then reviewed with the business to verify understanding, accuracy and completeness of the system. Gaining this clarity early in the process is cheap. Waiting for feedback until a prototype or, even worse, User Acceptance Testing may result in costly rework.
Encouraging. The encouraging part of this class was the way the instructor used Use Cases as a means to establish a requirements baseline and discuss change management. Remember, this was a class designed for analysts and programmers. By moving the discussion to their level, the Project Manager wins powerful allies for managing scope. Analysts can better identify the required functionality and processes, lower future surprises and rework. Programmers start to recognize gold plating as anything that isn’t specified in the use cases. When the business begins to ask for additions or changes, clarification begins with revisiting the diagrams and understanding what is different. Those differences become change requests to be processed by the Project Manager.

Sunday, December 9, 2007

December 10, 2007 - Burnt by Hiring a Newbie

As an account manager for various clients, I have had to hire project managers to fill open slots. The hard part is separating the bad from the good. One agency I worked with promised me a solid project manager as a replacement for one that left. When he arrived I sat him down and started laying out my expectations for scheduling, status reporting and other normal activities. It was met with a blank stare. From there the conversation went something like:

Me: "So, have you managed a project before?"
Newbie: "No, but I have been the lead on several initiatives."
Me: "Have you had any project management training?"
Newbie: "No, but I’ve worked on a similar system before."
Me: "Did you know you were supposed to be the project manager for this project?"
Newbie: "They mentioned I might be doing something like that."
Me: "Why is it you are here?"
Newbie: Blank stare.

When I called the agency I was assured they had a lot of confidence in him because he was, and I quote, a "high performing technical lead." With service like that it comes as no surprise to me when clients complain about receiving the bait and switch – promised a solid Project Manager and getting a rookie. How can you prevent it? Ask the right questions up front.

Here are three basic questions to ask before accepting a PM for your project:

1. What and when was your last project management assignment?
Your first clue of a potential rookie would be if they talk about their great technical lead rolls. See if they can articulate the business purpose for the project and why it was a challenge for them. Get a flavor for the overall size, duration, number of resources they managed.

2. How did you manage the cost, schedule and scope of that effort?
This questions will test their ability to speak in project management terms. The phrases you are looking for are:

  • Established the budget (cost)
  • Used the Work Breakdown Structure to develop the deliverables and lay out the schedule (schedule)
  • Created a baseline and established milestones (cost / schedule)
  • Tracked actual work and estimates to complete by resource at the task level (schedule)
  • Compared the progress and costs back to the baseline (cost) with bonus points if they mention critical path or earned value
  • Defined the scope in the Charter, Statement of Work or other defining document
  • Used Change Requests to identify and approve deviations from the scope

3. When did you schedule status meetings and who attended them?
Status meetings fall into two categories. The first is with the team to gather the status. The second is with the sponsor and other management to convey that status. From my experience at the end of the week you have the team status meeting, collect timesheets and status reports. On Monday the project schedule is updated and the weekly status report is create and sent out. Tuesday is then the day for the sponsor status meeting. The information is fresh and you have a current view of the forecasted project.

Solid answers to these 3 questions will give you a good comfort level of your candidate’s ability. Keep them honest by asking for some of the struggles they dealt with in implementing their tactics.

If you have additional questions that would help weed out rookies before they are hired, share it in a comment.

Sunday, December 2, 2007

December 3, 2007 – Lacking Commitment

They stripped a month off my project. Okay, technically I misunderstood them when they said go-live was September. What they meant was there would be a month long parallel run in production before they turned off the old system in September. Either way there were four less weeks of development time.

After sketching out the timeline, System Testing was scheduled for July 18. The four weeks to that date didn’t look long enough to me for the interface team. I wanted desperately to return to the steering committee with evidence to support my suspicions, but when asked, the team assured me it would be ready. Every status meeting I checked. Between meetings I followed up. Always the same answer: “We are on schedule.”

On July 17 we had the pre-System Testing meeting to tie up loose ends, the interfaces being one of them. The technical lead smiled and said with confidence, “We finally did it. The design is complete.” Yes, he said DESIGN! During the somewhat heated discussion that followed it became clear that they were no where near ready to test. The code didn’t even exist. They had said the words but had never committed.

Obtaining Commitment. Before anyone can (or should) commit to anything they need to know what they are in for. Walk through the expectations with the team that will do the work. Ask them for their estimates, timelines and constraints. Deadlines I impose can be dismissed as unrealistic but if the team develops the dates they own the estimate and associated commitments.

Scheduling Commitments. Before finalizing and announcing any dates, put a schedule together to lay out the commitments. Ideally you would use Primavera, MS Project or other tool to detail phases, deliverables, activities and tasks with planned hours and baseline dates. Even without those you can still put a meaningful schedule together. At a minimum, break the effort into pieces (ex. Interfaces A, B and C) and sketch out the tasks to complete them. Lay out the timeline based on the commitment and assign resources to the tasks.

Tracking Commitments. If your team has matured to the point of using actual hours and estimates to complete to rework the plan on a weekly basis, consider yourself fortunately. Many companies aren’t there yet. For everyone else, you can work it using the due dates and percent complete. Each week have the team report on which tasks are completed and the percent complete of started ones. Also have them review the task end dates and confirm they are still realistic. If a task slips, check the ripple effect and have them determine how to get back on track. Projects usually fail at the task level. Keep them in line and you stand a chance of completing on time.

Breaking Commitments. Sometimes commitments can’t be kept. Your team has to know they can tell you when they can’t meet a date. For whatever reason, my interface team waited until it was too late. By communicating the progress along the way adjustments can be made. Scope can be altered. Resources can be added. Alternatives can be discussed. When communicating the disappointing news to your management, have your facts in place. Instead of just saying, “We can’t make it,” spell out:
· Cause of the problem.
· Plans to get back on schedule.
· Proposed new dates.
· Steps to keep the problem from happening again.
· Help needed from management.

To solve our problem we ended up bypassing the interface engines by generating test material until they were completed. With significant sweat and long weekends we were able to meet the aggressive September timeline with a shortened parallel run.

Sunday, November 25, 2007

November 26, 2007 – How to survive an Audit

Truth in reporting is vital to building trust and successfully managing people and projects, but sometimes it is better to keep your mouth shut. Too much information can lead to problems. One of my former co-worker never had the filter between his thoughts and his lips installed. Case in point: Needing to take Friday off, he asked his manager for the time off. That part was great. However, when asked what he had planned, he should have just said he needed to run some errands. Unfortunately he proceeded to tell of his DUI conviction and that he was going to an alcohol awareness weekend as part of his sentencing.

Having survived many project audits and then being both a Project Officer and Quality Assurance Auditor for several years I can assure you that a project audit is not the place to offer more information than requested. Here are 6 tips on how to survive an audit.

  1. Determine the audit type. There is a big difference between an project health check and a regulatory audit. The purpose of a health check is to understand the state of the project to help increase the probability of success. A regulatory audit is to verify compliance with regulations or standards. You can use a health check audit to bring visibility to issues and risks facing the project so management can supply the necessary resources to address them. Regulatory audits, on the other hand, are there to find problems. Unless there are serious or illegal problems with your project, you may want to down play the issues for a regulatory audit.
  2. Understand your Auditor. The audit groups I have worked with all had the interest of you, your project and the company in mind, not their own agendas. Some auditors feel they have to find something wrong in order to justify their existence. Understanding the type of auditor you are dealing with will help shape the way you answer questions.
  3. Get the list. Understand the standard you are being held to. Since audits rely heavily on question lists, get the list ahead of time. Make adjustments to your management and documentation styles to be able to answer "yes" to any of the questions. If one of the questions is "Are regular meetings held that review status, financials and issues?" then make sure your minutes have those points listed.
  4. Avoid the search. Based on the list of questions, have evidence that shows compliance readily available. If they want meeting minutes, have a folder full of them. When they are looking for approvals, have copies, emails or other artifacts compiled to present. If they have to dig, you may spend even more time answering misdirected questions.
  5. Only answer the question. You have the right to remain silent. You many want to use that right, especially for regulatory audits. Just like my buddy the drinker, giving too much information can cause problems. Even if what you say isn’t a problem, additional data can cloud things or look as if there are issues. Again, if there are serious or legal items at stake, don’t hide them but don’t air your dirty laundry, either.
  6. Less than 100% is good. Odds are you will miss something on you audit and that’s okay. The key is to develop an action plan based on the short comings and get any audit issues resolved before the next one.

As long as you know the expectations, audits results shouldn’t be a surprise to you. By following these steps you may, however, surprise you auditor.

Sunday, November 18, 2007

November 19, 2007 – Automotive Sponsor Problems

It is never good when your mechanic calls and asks, "How attached are you to this vehicle?" Friday was not one of my better days from that perspective. I drive a ten-year old Plymouth Neon and normally it gets me where I need to be. Sure it leaks oil and steering fluid but the AM radio still works and three of the four door locks are still automatic. But Friday it decided to die on the way to work.

The mechanic said it would take about $900 to get it back up and running. Then there was the list of things that "need" to be done totaling another $1000. I just checked and my car is only worth about $2500. I felt like the sponsor of a project that has gone bad. Actually there were three things that drove that feeling home.

Return on Investment. The mechanic was the first to bring it up with his opening question about my love for the Neon. He could tell the cost of fixing it wasn’t going to be cheap. Prior to undertaking a project, a company needs to understand the ROI, both the costs and the returns. The projected costs are more than the expenses to complete the project. Don’t forget to include training, maintenance, licensing and other life cycle pieces.

These costs should be balanced by the expected returns from the endeavor. Savings are usual the first thing considered. How many people will I replace? How much time and money will it save. Add to these benefits forecasted increases in projected sales because staff can spend less time fiddling with the system and more time with customers. Consider that the new online experience may lead to more purchases. Customer satisfaction may net more repeat business. Think through the project purpose and project the positive results of success.

Lack of Information. Friday morning I certainly didn’t have enough information to decide whether or not to give up on my car. I needed a multiple choice question and was handed only a true / false option. How much was my car actually worth? What would it cost to get an comparable vehicle? Was it worth more as scrap metal? What could I really afford? Would there be additional expenses I didn’t anticipate? If I bought a different car, would it have more problems than this one?

When deviating from or adding to the project scope, a Change Request documents the final decision, but the discussion starts by answering questions. Sponsors expect project manager to supply them with the information to answer those questions. Why wasn’t it in scope to begin with? What are the consequences of not doing it? How much is it going to cost? What other options are there? If the answers aren’t readily available, you may need to request funding to research and find them.

Risk Management. Among the "other" items my car needs are new front brakes, brake fluid flushed and replaced, and my back breaks aligned. Total cost an additional $450. The risk of not fixing them is obvious. If you can’t stop your car, something else will have to. Whatever you use to stop it (another car, a brick wall, etc.) will probably cost more than $450. As with any risk I could Avoid, Transfer, Mitigate or Accept it. Buying a new car would avoid the problem. Making sure my collision insurance is up to date would transfer the risk. Getting the brakes fixed would mitigate the issue. I opted to accept the risk and postpone the brake fix to a future phase of the project. You may want to stay off Beach Boulevard for the next week or so.

It could have been worse, though. Had the car continued to run it would have completely overheated and destroyed the engine. I wouldn’t have had any choices at that point and my next blog would have been about purchasing a new car. Don’t hide project problems from your sponsor until things overheat and there are not choice left.

Sunday, November 11, 2007

November 11, 2007 – Humility Helps

One of the ugliest things to hear about yourself is, "he thinks more highly of himself than he ought to." I heard someone once ask, "Aren’t you as impressed with him as he is with himself?" Brutal. I once worked with a guy that really thought he was something. When he finally left he let everyone know how lucky the new company was going to be to get him. We felt luckier ourselves.

I’ve been fortunate with my career and have done some interesting things, but people I know are constantly surprising me with what they have done. This happened twice yesterday. At breakfast one of my buddies told me about the success he has had with his writing. One of his recent submissions topped the charts at over 1000 hits. For the past four years I’ve known him as the "go to" man with tax questions who leads the discussion in our Bible class.

Then at lunch I was bowled over by another friend of mine. He usually speaks softly and carries a hammer. He volunteers his general contractor expertise working at our church to build the big backdrops for the stage. I found out that thirty-plus years ago he was a rock star with a seven year Capitol Records contract.

Whenever my pride starts to get the best of me, I need to remember these four concepts.

Pride goes before destruction. This is often true in sports. The team that is supposed to dominate ends up limping off the field in defeat. At work it happens when you think you have everything under control because of your great team building abilities, interpersonal skills and general greatness. It blinds you to how your attitude is impacting the team until they start leaving to get away from your ego. No team? No success.

Respect is earned. If you have to tell people how great you are, you probably aren’t. One of the hard parts of starting in a new place is building back your reputation. Until people see for themselves that you know your stuff, they aren’t going to listen.

Past glory doesn’t guaranty current success. Every situation is different. Every team is unique. Every environment has its own challenges. Because I have managed a multi million dollar project for one client doesn’t mean the $100,000 one is going to be flawless. You need to make it happen, not stand around telling people how great you were.

Picture a real hero. November 11, 1918 brought an end to World War I. People around the word and throughout history have fought and died to keep others safe and free. They continue to do so today. Locally, police and fire fighters put their lives in danger to protect us and our property. Place your accomplishments into that perspective. I spent over a year creating inventory applications for a greeting card company.

When you humbly consider others greater than yourself, you have a chance to truly lead your team successfully.

Sunday, November 4, 2007

November 5, 2007 – Dealing with a Newbie, Part 2

Last week we looked at how to deal with a pretty standard newbie just trying to fit in, establish himself and be productive. But what happens when you get a problem newbie? Some are just killing time while collecting a pay check but others may actually be gunning for you and your job. Either one is a pain to deal with. Here are some suggestions for training your newbie to get his act together and recognize you as the manager.

Formally assign work. Come right out and say it. Don’t suggest or hint that you want something done, assign it to him. Show him where it is in the schedule with his name on it. Give him a task list. Find something that works, but make sure you set the expectation that he is responsible for accomplishing certain items. Formally assigning and receiving of tasks is an acknowledgement that you are the manager.

Agree on target dates. Work with him to identify completion dates for the tasks assigned that he can agree to and the project can live with. Giving him a say in the due dates transfers ownership to him. At least subconsciously he will know a measurement has been established and he will be held to it.

Hold status meetings.
If you are not already have weekly status meetings with the team, start them. Have everyone give a synopsis of their accomplishments for the week. The peer pressure of hearing his teammates’ achievements may inspire him. Also, meet informally one on one with him to check on progress.

Give him praise. When he does a good job, recognize it. The act of receiving the recognition builds on the manager / team member relationship. Be sincere with your praise and don’t go overboard. For the non-productive newbie this can spark further good work. If you feel he is attempting to outshine you, don’t try to extinguish his flame. Give him the recognition he deserves.

Accept mistakes. When he misses targets or makes a mistake, don't ridicule or yell at him. Recognize that he messed up and say something like, "that's ok, I'm sure you will do better next time." For honest mistakes this approach should make him try harder next time where yelling might reinforce failure. If he is deliberately messing up, you now have specific, documented instances of poor performance where expected work, based on agreed timeframes, is not being completed.

Report the facts. There are several resource reporting processes in most companies. For functional organizations (project team borrowed from different groups) the newbie’s reporting manager will want specifics. Many companies have a 90 day review process for new hires that may lend to an easy out. Your management may sense tension or the newbie may actually be going directly to your boss to stirring up trouble. Keep report the facts. Either the newbie is accomplishing his assignments or things are slipping. Feed your manager specific expected accomplishments ahead of time (i.e. "Based on newbie’s estimates the following tickets should be completed by Friday. I've asked them to..."). Then follow up with the results.

The idea is to train the newbie to recognize you as the manager and become productive without resorting to outright warfare. He will either fall in line and start acting like you are in charge or it will frustrate him to the point that his actions will be too visible to hide. By keeping management informed on a regular basis it will be difficult for him to paint a different picture of what is going on. From there disciplinary action can be taken.

There are many other aspects to handling difficult resources and we’ve barely scratched the surface on the topic. Here are two more notes to keep in mind. (1) You may have actually hired a genius that deserves to move up the ranks. Hopefully he can do it without being a jerk. Your approach can help mold his progress and may determine your future employment. (2) Jerks have a way of eventually ticking off the wrong person. If he is trampling people to gain control, chances are you aren’t the only one noticing.

Sunday, October 28, 2007

October 29, 2007 – Dealing with a Newbie, Part 1

Starting at a new place can be very daunting. It represents a clean slate. Few, if any, people know who you are, what your past is or what your capabilities are. Whether you are looking to clean up your act or just re-establish yourself in a different environment, it can be intimidating.
As a manager adding new people to your project or organization you need to be aware of the newbies in your midst and how to make them part of the team. This week we’ll take a look at some general ideas on how to make them feel at home. Next week we can address nuisance newbies.

Make the introductions. Take them around the office and introduce the team. The two most important sets of people to meet are management and the keeper of supplies. The supplies person is obvious, but the management is vital. The worst way for someone to meet management is by making a rookie statement during a meeting.

Give them the overview. Talk them through the purpose of your department or the scope of the project. Paint the big picture and where they fit in. Build them up by telling them why they were selected for this specific position. They don’t need to know that the first two recruits turned the job down.

Hand over the documents. Give them the Charter for the organization, the Statement of Work for the project or any other defining documents that they need to understand the environment. As you brush the dust off to hand it to them, you may want to take another look at it yourself.

Tell them where the pot holes are. Back before California, in Ohio and New York, there were two driving hazard seasons: the Orange Traffic Cones of road construction (May to October) and the car swallowing Pot Hole months (November to April). Point out the hazards in your work place. If there are people or topics that need to be handled with caution, let the newbies know. Without your warnings they could blow a tire or land upside down in an open trench.

Get them what they need. During the first day at my new job, Carmen showed up at my desk with pens, paper, paperclips, tape, stapler and a bunch of other essentials. In most of my previous entries I had to find these myself. Sometimes I was lucky enough to get the name of the keeper of supplies, but rarely a full stock delivered.

Solve their problems. In one of my previous lives a newbie was having a problem. Her name was misspelled in the mail system and it was causing issues with her login and with people trying to contact her. When she asked the admin staff they pointed her somewhere else which led to someone else and back so many times that she was getting dizzy from the run around. I used her phone and made a couple of calls to put her in touch with the right person. In addition to solving her problem, I showed her that she was a priority part of the team.

Let them make mistakes. People learn by making mistakes. The ideas above set your newbies up for success, but if they aren’t allowed to make mistakes they won’t be able to achieve greatness. Establish an environment that encourages strong effort but recognizes that errors occur.

I have developed the Newbie Card system to break the ice and help overcome the fear of failure. Drop me an email or register at the Cutting’s Edge and I will send you a copy.

Sunday, October 21, 2007

October 22, 2007 – Relationship vs. Task Oriented Management

Within project management there are two main types of personalities: Relationship oriented and Task oriented. It is fairly easy to tell the two apart. Aside from having a detailed project schedule, the Task oriented manager has a separate list of things they need to accomplish today and they feel great when all of them are checked off. The Relationship oriented manager’s schedule is really a guideline and they are more likely to have a list of people to call today.

Relationship Oriented managers are great at building a cohesive team. When planning out projects they take in the big picture and appoint people or groups to handle the details. Consensus is a major tool in their arsenal. One of the first artifacts they put together is an org chart and inevitably there is a spreadsheet with contact information posted close at hand. It probably even has birth dates written in. They make their teams feel comfortable. Deadlines are important but don’t seem to get in the way of progress. A good day for a Relationship oriented manager includes resolving conflict and holding productive meetings.

Task Oriented managers are good at directing people and moving the project forward step by step. On any give day they can tell you the status of each subproject, confirm if the project is on schedule, brief you on the budget and give you a graph of the progress. They know their team’s strengths and weaknesses but might not be able to remember last names. A productive day for a Task oriented manager probably doesn’t include too many meetings but does involve completing multiple things.

If you find yourself on either extreme you aren’t alone. Frankly, both types of project managers can be quite effective. Rather than telling you to be more like your opposite, I would like to encourage you to play to your strengths. You aren’t going to be able to change your stripes, so don’t kill yourself trying. Instead, invest in Personality Offsets.

Much talk has been made about using "carbon offsets" to pay for your global warming sins. Faulty as that logic may be, you can use "personality offsets" to keep the project warming to a minimal. Find someone on your team that can balance your weak areas. If tracking the project is not your thing, get a coordinator to handle the schedule. If your focus is "getting-to-done," put someone in charge of handling the touchy/feely aspects of the team.

This is not a free license to ignore your counter character traits. Give your "offset" the responsibility to tell you when to switch gears and take the appropriate actions. For the Relationship oriented this includes focusing on budget and schedule issues; discussing certain topics in meetings; and making decisive decisions when necessary. Task oriented managers need to be reminded to "socialize" certain ideas instead of dictating them; to recognize the efforts of team members; and to spend more time interacting with the team.

Your personality has successfully gotten you to where you are. Don’t abandon it, balance it.

Sunday, October 14, 2007

October 15, 2007 – How am I doing?

Today is the real test of how well I am doing at my new job. It is payday #2. If I don’t get a paycheck it might be a good indication that I am failing. Since they are unlikely to just drop me from the payroll, I guess I need to find a better way to check on my progress.

Which reminds me of a story I have heard a couple of times. A teenager knocks on his neighbor’s door and asks to use the phone. Curious, she lets him but listens in to the conversation. “Hello, sir, my name is Jeffrey and I was checking to see if you need a hardworking teenager to unload orders and stock shelves for you…. I see. Does he show up on time and work hard? Because I could…. So you don’t need anyone right now? ... Ok. Thank you for your time.”

When the teen hangs up the phone he smiles, thanks her and heads for the door with a spring in his step. By now her curiosity has gotten the best of her and she asks, “Why are you so happy? It sounded like you didn’t get the job.” To which he replied, “I knew he already had someone because I’m the one. I was just making sure I’m doing a good enough job.”

Unfortunately it isn’t as simple to make sure you are being successful at your job. Some employers have a 90 day review but if you wait that long it may be too late. Here are some things I have done to spot check my efforts for the first month.

Assessment and Recommendations. During the first week or two I gathered information on the current state of the PMO. Why was it started? What was already in place? How long had it been in existence? Where was the opposition? Who supports it? Where was it headed?

From this I developed an Assessment and Recommendations document. In it I laid out my understanding of the Critical Success Factors, Background, Current Assessment, Scope (in and out), Development Plan and Implementation Recommendations. This served two main purposes: (1) confirm my understanding of the PMO purpose and history and (2) outline my plans for moving it forward. By reviewing the document with management we quickly fixed any confusion and reset my direction.

Documentation checkpoints. Nothing is more frustrating than turning in a document or report you worked long and hard on only to find out it is exactly opposite of what was needed. To avoid this I started establishing checkpoints along the way to make sure expectations are met. The first spot check is an outline of the document. Use the outline to talk through what each section will cover and how they will all flow together. Follow this up with an updated version that includes a couple sentences for each section to confirm the discussion. Next take a section or two and create a rough copy of them. Verify the level of detail to ensure you have enough without drilling too deep. Finally, draft the entire piece for review. The results of that review will align you for completing the document.

Talk it through. When I spend a large part of my day thinking and typing I can get to the point where things stop making sense. Fortunately I sit next to someone who doesn’t mind me rolling my chair over and thinking out loud. We are able to bounce ideas back and forth until things start to click again. These kinds of conversations usually start with “Does this sound crazy to you?” or “Am I going nuts or…?” These thought checks are great to do with a peer before taking ideas to management. Not to self: Make sure you give credit for any great ideas where it is due.

These three ideas aren’t as bold as calling your boss and trying to steal your own job, but hopefully they will get you through that 90 day review with flying colors and keep that paycheck coming.

Sunday, October 7, 2007

October 8, 2007 – MS Project Resource Baseline Fix

Creating a baseline for your project is the starting point for tracking your progress. It is your line in the sand against which you measure your success. It may show that the first deliverable is over budget/schedule compared to the baseline but the next one is under. Evaluating the variances and trends allows you to make adjustments throughout the life of the project.

The baseline should remain unaltered throughout the project unless a Change Request is approved to modify it. The temptation is to re-baseline the entire project. Unfortunately doing so overwrites the baseline for all the tasks, eliminating any variances and wiping out your ability to see the trends. Instead, only those tasks associated with the Change Request should be re-baselined.

Microsoft Project historically does not deal well with saving partial baselines. Evidently the idea of a Project Manager only needing to re-baseline certain tasks isn’t logical to them. When I asked Microsoft Support if they intended to fix the problem they referred to it as a “User Perceived Bug” and said it was coded to the specifications.

The Problem:
When a project is baselined, Microsoft moves the values in the Work and Cost (for both Tasks and Resources) to the Baseline Work and Cost fields. Re-baselining the entire project moves the values for all levels (Tasks, Activities, Phases, Resources, etc.) over. Saving the baseline for only selected tasks doesn’t.

MS Project 2002 introduced the option to “roll up baselines” to the summary tasks from the subtasks when baselining selected tasks. That was a huge improvement. They stopped short of doing the same for the Resource totals.

Let’s say that Bill has a total of 100 hours scheduled for two tasks: Write Specification (40 hours) and Create Prototype (60 hours). A Change Request is approved to double the time and those two tasks are re-baselined at 80 and 120 each. In the Resource Usage view, Bill’s baseline totals would still read 100 instead of 200.

The Solution:
Historically I have had to drop the details to Excel, use Subtotals to do the summation and paste it back into the project plan. Not a lot of fun. A friend of mine, Jon Smith (yes, that is his actual name), recently sent me a macro for Project that essentially does the same thing for the Work field without leaving MS Project. I tweaked it to add up the Cost field, too.

If you would like a copy of the macro, drop me an email at

Sunday, September 30, 2007

October 1, 2007 – Mediocrity: Caring Enough to Give Your 2nd Best

On December 17, 1903, Orville and Wilbur Wright made the first successful powered airplane flight. It was quite an amazing accomplishment, but I don’t believe it would have been possible if they were working in today’s business world. The problem would have been the drive for perfection. It would have started something like this…

Orville: “Yes, sir, this is the design. The scope statement says you want us to build a self propelled machine that flies.”

Sponsor: “I see. But it only has two of those wing things. I was thinking it should have three. You know, one for a backup.”

Wilbur: “I suppose we could put a change request in for the third one.”

Finance Director: “We could actually save 25% by reducing it to one wing. With the cost overruns in the bike department it would really help increase our profits for the year.”

Orville: “The Functional Design clearly calls for two wings. All of the use case scenarios specify two.”

Marketing: “We could sell this easier if it was enclosed and had wider seats.”

Sponsor: “Yes! We should also place a phonograph on the back of each seat so people could listen to whatever they wanted to in flight. I saw it in a magazine once.”

Wilbur: “This was supposed to be the prototype.”

Upper Management: “Do whatever you have to do, but we told the stockholders it would be ready by the end of the year.”

The stakeholders have a grand vision of what the end product could be, but they need to get the thing off the ground first. Sometimes, aiming for great is overkill. But how do you know when it is ok to deliver something that isn’t perfect?

Meeting the Grade
There is a definite difference between grade and quality. Quality is a measure of how well a product meets its requirements. Grade is a category assigned to a product that has the same functionality but a different level of ability or requirement. Grade is the difference between a luxury vehicle and an economy car. Both are expected to get you from point A to point B and both will be tested for quality to ensure they meet their design specifications. A luxury car, however, is expected to be built better and have more features.

Anyone can snap a photograph but you wouldn’t turn your wedding memories over to your 13 year old nephew. By determining the expected grade of your product you can adjust the level of effort expended to meet that goal.

Setting the Priority
Along with any other critical success factors a choice must be made between three possibilities. Which one of the following is the most important to your project?

  1. Schedule
  2. Cost
  3. Scope
Don’t let anyone say all three or even pick two. One of them must be the most critical. If it was promised by the end of the year, you will be willing to pay more and limit the size. If certain features are key, then the schedule may have to slip and it may cost more. All the development decisions can then be made based on what is most important.

Consider the Cost of Perfection
Have you ever worked with someone who places a premium value in perfection? Pulling together a prototype takes as long as creating the full version. In the insurance business, getting a new product line to market ahead of your competitor is huge. Unfortunately you can’t sell it until your systems can handle it. With time to market as your driver, the cost of ergonomically designing the input screen looses value points.

Making it Mediocre
The architecture needs to be sound but not necessarily a work of art. Code doesn’t have to be pretty, it just has to work and be maintainable. Produce a quality product, but save the bells and whistles for the next release. It is better to get it out and improve it over time than give up ground to your competitors.

In the final analysis, second best can actually land you in first place.

Monday, September 24, 2007

Sept 24, 2007 – Starting Over

I survived the first week at my new job. Starting over can be exciting and a bit scary. Having survived nearly 15 years in the consulting industry, I am no stranger to rebooting my work experience. Actually, I even wrote an article for Computerworld about the topic (The New Guy's Guide to Building Trust).

Upon reviewing the list of 10 steps in the article, I think I’m off to a good start. I issued meeting minutes, started identifying preconceptions and even created an informative status report. With this new adventure I have discovered a couple of other steps to add to the newbie list.

Don’t Burn Bridges. It truly is a small world. I have run into several people from previous workplaces that have either worked with me or with someone who knows me. Fortunately I can work with almost anyone and know enough not to make enemies. Had I been a jerk to any of these people I would be paying for it now.

Don’t Jump the Gun. Like a runner, you need to be careful to not leave the starting block before the pistol is fired. Within the first day or so at a new client I began introducing myself to the extended team as the project manager. It soon became apparent that there were already two project managers on the effort and neither one of them knew I was coming. That was just a little awkward. Check with your management to make sure the announcement has been made before you step on anyone’s toes.

Know the Currents. On a camping trip to Martha’s Vineyard as a teenager we visited a beach with a riptide, a dangerous current that runs parallel to the beach. As you swim, you may think you are heading straight out from shore when in reality the current has pushed you 100 yards away. The best example of this in business came from an advertisement friend of mine.

While working a deal at a new client, one of the female executives asked if his company had done the ads for product X. In fact they had actually won awards for those ads and proudly said so. The executive said, “Those are the most sexist, degrading ads I have seen and there is no way we will be doing business with the company that created them.”

Deliver Value Quickly. On your first day start thinking about your status report. What are you going to put on it at the end of the week? Whoever hired you took a chance. They will be looking to see how soon you can be productive and contributing to the team. Identify some things you can accomplish during the first week to show an early personal Return on Investment. One of the new PMO objectives is to create project development standards and templates. I was able to report deliver of several draft templates on Friday’s status.

It may seem daunting to start over again, but soon those feelings will disappear as you pick up your new challenge.

Sunday, September 16, 2007

Sept 17, 2007 – Project Management Warnings Part 3

Alright, we get it. Project management is dangerous work and should be handled with caution. But sometimes it isn’t the project that is the problem, it’s the people. Some stakeholders and resources can cause more problems than any technical issues you will ever encounter. For that reason I suggest that they should be required to wear their own signs. Here are some you might need to hand out during your next meeting.

1. May cause irritation. I had a manager once that was mildly irritating. The technical team knew what we were doing and handled pretty much everything. He basically attended the client meetings and took all the credit. On the extremely irritating side is the stakeholder that decides to bring down your project. Both mild and extreme cases can be handled with patience. If he is irritating to you, he is probably irritating to others. Don’t try to bring him down yourself. Once he irritates the wrong person his days will be shortened. The odd thing is they always seem surprised with it hits.

2. Avoid contact with eyes. Once she has your attention you are likely tied up for an hour before she lets you go. Sometimes it is work related but other times it is just empty chatter. In the old days you needed an accomplice that could call you to break up the conversation. With the advent of the cell phone’s vibrate feature you can now fake a call at any time. If you as the project manager are the primary target of these conversations it may be that she is attempting to garner points toward promotion. On the other hand, if she is killing productivity on the project by talking with others all the time you may need to check her schedule and make sure she has plenty to do. If she isn’t getting her work done there are other consequences for that.

3. Beware of Dog. This is your basic “doesn’t play well with others” individual. He may be the best technical resource you have, but if he can’t work with anyone he is useless. Before you write him off completely, try:
· Interrogation. Find out what the real issues are and see if they can be resolved. Start with a simple conversation, “Hey, noticed you being a jerk the other day and just wanted to know what your basic problem was.” Ok, you may need to drop the jerk part…and then reword the rest of it, too.
· Intervention. Identify and document specific instances of bad behavior. Prior to the next blow up, walk through the reported problems with him and lay out the expectations going forward. Depending on the seriousness of the problems you may need to get HR involved.
· Isolation. If you don’t have a location to keep him away from others, try telecommuting.

There are plenty of other signs that could be awarded. If these three triggered some in your mind, drop me a comment and share your experience. I may need to run another edition at a later date.

Monday, September 10, 2007

Sept 10, 2007 – Project Management Warnings Part 2

Last week we established that project management should come with big yellow caution signs. The work place is a dangerous road trip and we need to look out for each other. Here is another batch of signs to keep us moving in the right direction.

  • Toxic Fumes. Status reports can be deadly if inhaled carelessly. First, never take at face value your team members’ status reports. You should expect a written report but it should be the opening statement in a conversation, not the sum total. Dig in and find out what they aren’t telling you. Second, get rid of the percentages unless you have metrics to back them up. How many tasks are currently 90% done on your project? How many weeks have they been “almost finished?” Instead, ask for specific completion dates and number of hours remaining. Finally, make sure your project status report is a fair and truthful representation of the current situation.
  • Maximum pressure 40 hpw. As I was getting out of my car Friday night I heard a hissing sound. I watched helplessly as my front tire slowly exhaled the last of its air. It no longer had a problem with too much pressure. Keep an eye on your team members, though, to make sure the pressure won’t leave them flat. Don’t set them up for failure by over allocating them. Forty hours per week should be the norm, not the exception. If overtime is necessary, keep it is in short durations at a time and ensure they are compensated accordingly. Grant compensation time for weekend implementations.
  • Dry clean only. Some of your cloths need special treatment. So do your resources. If you treat them right your team won’t wrinkle, shrink or fade. In general, people like to work where they are productive, provided for and appreciated. They like to be listened to and taken seriously. Take the time to understand how they prefer to be appreciated. Some want public recognition while others prefer quiet thanks.
  • Door must remain unlocked. Restaurants and stores sport this signs on side doors. The obvious reason is for easy exit in case of a fire or other disaster. There are 2 reasons to keep your door open and unlocked at work. The first is to allow your team to approach you at any time. An open door policy helps develop a connection with the team, both personally and job related. The second reason is to avoid misconduct or even the appearance of it. If you are meeting with an individual of the opposite gender, keep it visible. At the least you will avoid gossip and, at the worst, a harassment charge.
  • Objects in mirror are closer than they appear. At the beginning of a project everything appears achievable. You look out across the huge gap of time… 6 months… and think it is an eternity. In reality the end of the project is a lot closer than you think. One project I specked out was only 10 weeks in duration. It hardly seemed to start when we were in testing with only 2 weeks until implementation. Before you commit to a timeline, sketch it out with a realistic project schedule and review it with your team.

Unfortunately, potential problems with your project don’t come with warning labels. Perhaps these few reminders will help keep you on your toes without stepping in anything.

Monday, September 3, 2007

September 3, 2007 – Project Management Warnings Part 1

From where I was sitting by the pool in Palm Springs, California last week I could see the warning sign posted above the hot tub. As I read the words of caution I substituted the words “project management” for “spa.” Surprisingly, some of them actually made a lot of sense. Take the following two examples:

“For health and safety reasons, no children under the age of fourteen (14) years shall be permitted in project management without a parent or guardian present at all times.”

“Prolonged exposure to project management may result in nausea, dizziness, or fainting.”

Project management isn’t for the faint of heart and should be approached with caution. For safety reasons I think it is important to post big yellow caution signs. If you are thinking about dipping your toes into the PM swimming pool, take the following warnings into consideration:

  • No diving. Before jumping head long into the role of project manager you should check the water. First, hidden rocks can break your neck. Project management is a no man’s land, stuck between those that do the work and upper management. The hard objects hide on both sides. Second, don’t get in over your head. A wise manager once steered me away from a project for political reasons. The time line for the project was too short for the given scope but upper management had promised it would be completed in time for a very visible annual meeting.
  • Stay with your buddy. At summer camp we used the buddy system at the beach. No one swam alone. When the lifeguards blew their whistles you had to the count of five to get to your buddy or you had to sit on the beach. Get yourself a mentor for a buddy. Have them critique your status reports before you send them out and ask the hard questions before your management does.
  • Harmful or fatal if swallowed. Projects, like pools, have strong chemicals at work. One way to keep from being poisoned is to not believe everything you hear. Everyone has their own unique agenda and it will take time to figure out what each one is. Bill always pads his assessment to make himself look and Elaine under estimates to tell you what you want to hear. Your management will set dates and budgets to tie in with her bonuses. Sam bad mouths everyone. Learn to question estimates and assumptions, ignore gossip and push back when tasked with the impossible.
  • Do not swim during a thunder storm. A consultant friend of mine recently left a job because a manager took out his frustration on him with a yelling tirade. The company had purchased a software package and assumed it would do everything the sales team said it would. When the consultant explained the reality of the situation the discussion turned ugly. I am a firm believer that when I fail or my team messes up I need to take the heat, but to get blasted by someone for their own mistake is another thing. Frankly, anyone who resorts to yelling has issues.

    Project management isn’t a day at the pool but it doesn’t have to be shark infested waters, either. Swim with caution and don’t forget the sun block.

Monday, August 27, 2007

August 27, 2007 – Balancing Your Budget by Taking a Vacation

A word to the wise…do not go tent camping at Perris Lake, CA in August. You know you are in the wrong place when the locals say you are lucky the temperature dropped…to 102 degrees Fahrenheit (39 Celsius). As soon as the sun rises over the hills it immediately jumps to 85F (29C). As you can imagine, ground baked at those temperatures for extended periods of time tend to be hard. Not the best of sleeping conditions. There is a saying that goes “that which does not kill you makes you stronger.” In reality, it should probably say, “that which does not kill you makes you wish you were dead.” Fortunately this week we are headed to Palm Springs to stay at a resort with air conditioning and a big swimming pool.

It’s an odd segue but I was speaking with a Project Manager about taking vacation the other day. His small, four month project was running several thousand dollars over budget. I suggested that at his bill rate a couple of vacation days might bring the costs back into alignment. Here are a couple of other items that may help balance your budget.

Resource Rotation. Examine your resource allocations. Do you have senior people doing simple tasks or junior individuals struggling to perform in difficult areas? By moving less expensive resources to handle the simple things you can shave that added expense from the project. Conversely, where your junior team is struggling in deep waters, an expert may be able to blow through the issues in half the time, actually saving funds in the long term. Don’t get trapped in the mindset that cheaper is better. Each situation needs to be examined to determine the best option.

Of course this only works if you are tracking the true cost of your resources. I am surprised at how many companies do not distinguish between resources when counting the cost. Some only use the number of hours or a flat, blended rate to determine the cost. Using that method means your best players costs the same amount as your third string team. No one would consider fielding a professional sports team like that so why do we manage our teams that way?

Find Filler. Look to pull work from the future to fill in blank spots now. One project I managed involved testing multiple systems. Originally they were scheduled to be done sequentially but delays in the earlier ones were impacting the schedule. By pulling the analysis from future systems and performing it early we were able to fill in the gaps and keep the project from running long and over budget.

Consolidate Testing. Before I go any further, let me first say that I am not suggesting you cut corners for testing. What I am advocating is the consolidation of testing across multiple, interrelated projects and between common end users. Integrating the testing for projects that share resources (i.e. databases, common feeds, etc.) can save funds by using the same testing environments and testers. An added bonus is the assurance that the systems will function well together. Any problems caused by their interaction can be resolved prior to going to production.

Time Out for Training. Take advantage of projected down times to schedule training for your team. This is actually a multi-prong attack. First, the budget for training usually comes from outside of the project so the cost of those individuals can be offloaded during a time when their services aren’t vital. Second, if the training is specific to an upcoming aspect of the project your resources will be better equipped to perform, potentially increasing their productivity. Finally, investing in your team shows your commitment to them and will help keep them from seeking employment elsewhere.

Bottom line, if you need a vacation, tell your manager you are willing to take one for the team. Once he understands how it can help the budget he might just join you.

Monday, August 13, 2007

August 13, 2007 – Fortune Cookie Management

Not far from work is a Chinese buffet that we frequent to celebrate birthdays and any other excuse we can fine. It is called the World Buffet and in order to maintain truth in advertising they throw in French fries, pizza and Hawaiian chicken to give it a more global menu. You can still tell it is a Chinese restaurant, though, because they hand out fortune cookies with the bill.

While listening to everyone read their fortune recently it struck me that these pearls of wisdom applied amazingly well to project management. Here are some from our last visit.

They’ll definitely remember all your efforts. This is more than hopeful wishing. A month or more after turning over a project to another manager they encountered a problem. Evidently the infrastructure partner was claiming that we hadn’t informed them of certain responsibilities. I was able to retrieve emails and minutes showing the discussions and decisions. Keeping records paid off.

On another occasion it took nearly three months before I got the call. Phase 2 of a project was getting ready to go through a Sarbanes-Oxley (SOX) audit. The effort had changed hands twice since I left and the new project manager couldn’t find the evidence for the review. I had to think my way back through the SharePoint site layout to talk her to the location. Organizing the approvals and forms before handing over the reins saved her sanity.

Care and attention to the key relationships in your life will pay off. Stakeholder management immediately came to mind when I heard this gem. Understanding their influence levels, expectations, pressures and needs is priceless. You can’t solve needs or reset bad expectations you don’t know about. You will fail to interpret warning signs without comprehending the stakeholders’ points of view.

This fortune also made me think of resource relationships. I’ve seen key resources threaten to leave because they aren’t getting properly care. It really doesn’t take much. One individual is having trouble with immigration paperwork. His frustration is compounded because he can’t get an update on the status. A simple email or phone call to him would clear the air and keep him satisfied.

Step away from the power position for one day. This is a tough one for me. When I attend a meeting I am impressed if there is an agenda and the facilitator effectively directs discussion so we finish on time or even early. If a meeting is spiraling out of control I have to fight the urge to assume ownership.

In the same vein, for your team to grow and mature you can’t assume ownership of their work. When the coding is not getting done, it isn’t your job to step in and write code for them. You may need to negotiate more of their time, find help, apply forceful encouragement, remove barriers or a number of other things, but they are supposed to be the programmers, not you. Stealing that power from them leaves them without a purpose and it leaves you doing everything.

You’ll meet your big cheese today. Okay, this one didn’t make any sense to me.

If it seems the fates are against you today, they probably are. Sometimes it may just be better to go home and try again the next day.

On the back of many fortune cookies are words to help you learn Chinese. I’ve often wondered how many cookies you had to eat to become fluent. The Chinese on this particular paper slip says, “yao xe waon” which translates to “Hopeful.” That seemed appropriate for a project manager that all the fates are against.

By the way, your lucky numbers are 4, 18, 37, 14, 28 and 7.

Monday, August 6, 2007

August 6, 2007 – Time to take it Easy

Here in the sunny southern California my daughters have passed the mid point of their summer holidays. July and August seem to fly by faster than any other months of the year. Last summer I missed most of that time because I was working out of town, flying back and forth just to spend the weekend at home. That summer window of opportunity of spontaneous fun freedom slipped by with me out of town.

I have been working with a team to create a chapter for the second edition of the PMI Standard for Program Management. The father of one of the women on the team is suffering from dementia. His once brilliant mind is failing and the time to spend with her once strong and encouraging dad is slipping away.

The collapse of a major bridge in Minneapolis, Minnesota ended the lives of people who thought they were just running to or from work.

What’s my point? It is two fold. First, make sure you take time for yourself. Second, make sure your team does, too.

Be Good to Yourself
Those 60-80 hour weeks, 52 weeks a year are going to kill you eventually but they are taking you away from enjoying your life now. I’m not suggesting you quit your job and convince your family to join a circus. However, if your family calls you “Uncle Daddy” because they see their Canadian cousins more often than they see you there might be a problem.

Recognizing that my travel was detrimental to my family life, I opted to pull back from an exciting PM role to take one closer to home that lacked the challenge.

Delegation is another great way to drop a few hours from your schedule. Find items from your to do list that you really don’t have to do and share the effort with your team. One quick hit for this is team meeting minutes. If everyone on the team takes a turn publishing the minutes you shave at least a half hour from your schedule each week.

Sometimes cutting back isn’t possible. In order to add a little balance to the family / work equation, I do bring work home. I know, it sounds counter productive, but it works. I’m home, usually in time to have dinner with my family and spend a couple hours with them. Once the kids head to bed I pull out the work and put in another couple of hours. It is a great time to do minutes or review documentation. Fortunately I can operate on a limited amount of sleep for several days in a row.

Take Care of Your Team
Burn out is a real possibility for your resources, especially if they try to drive themselves as hard as you do yourself. Here are a couple of items to keep in mind that may help maintain some sanity in the work place.

1. Set realistic dates. Nothing kills the enthusiasm in a team faster than working from behind right from the beginning. It’s acceptable to agree to aggressive dates, but build in a little reality, too.
2. Don’t overdue the overtime. Scheduling everyone to work overtime from the start of the project in order to meet the deadlines will not work. Overtime only works for limited time frames and then only when the team sees the purpose and benefit of doing it. Get their buy in before assigning it. You may be better off obtaining more resources and dividing the work up further.
3. Understand timing on family events. Encourage your team to honor their family commitments. Ask when the big soccer game is or the piano recital and make sure they can make it. It will build your referent authority (see Referent Authority entry) and keep them safe at home.
4. Encourage time off. Many people I work with seem unable to use their vacation time. They keep busy through the year and never get around to it. The theory behind taking time off is to come back refocused. Another great idea is compensation (“comp”) time. When your team has to work the weekend to implement a system give them the opportunity to take that time off just before or just after the event. It is better not to let the time stack up unused because it becomes a pain to track and if the situation changes (ex. project ends) they might loose out on it.
5. Be flexible with time management. Most projects have deadlines, not office hours. If you can be flexible in the work hours your team may be more productive. Granted, there needs to be overlapping time to handle interfaces and discussions, but a flex-schedule adds to the well-being of your resources.
6. Recognize the extra effort. Don’t take the overtime and hard work for granted. Reward the team from time to time. Suggestions include restaurant gift cards or movie passes. Pick things that encourage them to connect with others outside of work and gain a little balance. I know it is appreciated because when it happens for me my wife usually says, “It’s about time they did something for you.”

If you have other ways you use to keep yourself and your team sane drop me a comment and share it with all of us.

Tuesday, July 31, 2007

July 31, 2007 – Cultivating a healthy Project Schedule

About a month ago my wife and I went out and purchased some plants, dug up one of the flower beds and replanted it. All the weeds and crabgrass were pulled and all the dead or dying plants removed. We followed the directions and placed the plants the recommended distance apart. We even added topsoil! The results were favorable. The new flowers filled in nicely.

When I walked by it this morning I realized that I have neglected it. Weeds have started sneaking in among the plants and the crabgrass is back. Some of the grass is even taller than the plants. It reminded me of project schedules I have attempted to revive. Neglect resulted in over allocations, missed deadlines and busted budgets. They were all things that should have been taken care of when the weeds first appeared instead of ignoring them.

When I review a schedule there are 5 questions that help verify its health.

1. When was the last time it was updated?

Weekly works the best. The Actual hours expended by the resources should be entered at the task level and a new Estimate to Complete (ETC) given for each task. Ideally this information should come from your team through the time reporting tool but I’ve had to do it by hand from printed individual timesheets, too. Finding out that the most recent schedule is three weeks old flashes a red light immediately.

2. Does the Estimate at Completion equal the Baseline?

The Estimate at Completion (EAC) is the sum of the Actual hours expended plus the ETC. In MS Project it is Planned Work. By comparing the EAC to the Baseline values for each task you can tell if any effort is being put into realistic forecasting.

The temptation is to add Actual hours to the task and allow the tool to subtract it from the original estimate. For a common example assume I worked 15 hours on a 20 hour task. I have 5 hours to go, right? Probably not. I could be done with the task or I might need another 20 hours.

If an individual is reporting that she needs 20 additional hours for a task that ought to be complete, ask questions. Why is it taking longer than anticipated? Do you need assistance? Are you the right person for the task? Do you need more training? Has the scope changed? Get to the root cause of the problem and solve it.

3. Is the remaining effort appropriately distributed?

For this I flip to a resource allocation view and check to see if everyone has just enough work to fill their timesheet for at least the next month or so. This should take into account holidays, vacations, training and other out-of-office factors.

Then I make sure there aren’t any major hills or valleys beyond that. The effort should average across the weeks to their maximum allocation throughout the remainder of the project. Beyond a month it can alternate a little low or high and be adjusted as the tasks get closer. If there are several resources that are over allocated, you may need to add more people in order to meet your deadlines.

4. Are you hitting the milestones?

A schedule that shows a history of missed deadlines is in trouble. Check to see if the misses are getting further apart or staying constant. Usually a project will miss the first on by 1 week, the second by 2, the third by 4 and before long all hope is lost. If they are staying fairly constant there was probably just one deliverable that threw it off.

If predecessors are established that link tasks based on order of completion you can see the impact of missed dates on the remainder of the effort. This is valuable information because you can see where to take corrective actions to bring things back into line.

5. Is the project projecting to be in budget?

With the updated ETC for the tasks and resources added to stay within schedule, odds are the budget has taken a hit. If it isn’t within reasonable tolerances you need to identify areas to reduce costs. Look for activities that can be combined. Consider juggling resources to different tasks. Perhaps a more senior resource can cut the development time in half, offsetting the per hour cost difference. Reassign lower cost resources to perform the testing. Moving work forward to fill in down time (ex. System documentation) may allow individuals to roll off to another project earlier. Get creative.

The answers to these five questions will help you find the weeds in your schedule and keep them from choking out a perfectly good project.

Monday, July 23, 2007

July 23, 2007 – Random Quotes, Sayings and Definitions

I’ve started collecting sayings and words of wisdom having to do with project management. Some of them may eventually become entries on their own, but most of them are just a little too random. So today I’m going to pull a bunch of them together and run with it.

Getting it in writing is a key concept in project management. Here are a few sayings about the importance of the written word.
· Verbal approval isn’t worth the paper it is written on.
· A meeting without minutes didn’t really happen.
· Unwritten, unsaid.

I’ve also found some definitions that should be used more often.
Yellow Pad Session – informal requirements gathering meeting where notes are taken on a yellow legal pad. This is a term used quite often on the east coast of the US but no one here on the west side seems to have heard of it.

Double Whacking – hitting someone up for information or action from 2 or more directions. This can be effective if the person historically doesn’t respond the first time. It needs to be applied carefully so that the person being whacked doesn’t strike back.

Overkill – taking follow up or actions to an extreme. It invokes the idea of using a bazooka to kill a fly. Usually it happens when you react to something like an email. You end up shooting one back that starts a fire storm. Another example would be calling a company wide meeting to give examples of inappropriate dress instead of a simple email reminder.

Some quotes just need to be repeated.
“Do you think he plans it all out or just makes it up as he goes along?” When I heard this line in Pirates of the Caribbean: At World’s End it struck me that the same thing could be asked of some project managers. With the good ones the planning is obvious, but every project needs a bit of improvisation and luck.

“If you really believe it, it isn’t a lie.” A friend of mine reported hearing a manager say this as he was preparing for a status meeting. I guess reality takes a break for some when it comes to status reporting.

“I love it when a plan comes together.” This was always my favorite line from the TV show A-Team. Hannibal always had a plan and managed to pull it off.

Finally, here are a few famous last words. If you hear these coming from your mouth, it may be time to run…fast.
· Sure, we can do that. What is it you want?
· It doesn’t look that big. We don’t need a Change Request.
· Risks? What risks?
· We’ll make up the time during the testing phase.
· It’s just changed a configuration file. We don’t need to test it.
· Everyone knows that isn’t our responsibility.
· Just one more minor change.

Thursday, July 19, 2007

July 19, 2007 – Authorized to Manage – in a Projectized Organization

This is the last in a series looking at authority. To wrap up we will focus on the projectized organization and give some practical tips for leading in this environment.

Control is but an illusion.

Projectized Organization.
In a projectized environment teams are formed of resources that, if not hired directly for the project, are assigned almost 100% to it. You, as the project manager, are given nearly total control of the resources, budget, scope and schedule. You are in control.

As a leader in this environment, the first thing to remember is that all authority is temporary. Your positional authority is highest at the beginning of the project. By decree of the Charter you have been crowned project manager. Use that formal authority as a basis to quickly build other types.

You can increase your referent authority as you get to know the team members. Understand their individual strengths, goals and motivations. Are they glad to be on this project or do they see it as a side step in their career? As you ask questions and interact with them they will begin to see your character and decide if they can trust you to lead.

Throughout the project, exercise your reward/penalty authority by offering additional training or better opportunities to your strong performers. Review the budget and see if there room for team lunches to mark major milestones. Address poor performance as it is identified. Do this by focusing on the performance (ex. Quality or Schedule), not the person.

Your project management abilities and organizational knowledge are part of your expert authority. By keeping the team informed of the big picture and how they fit in to it you can build their trust. This is especially true as the project moves toward completion. In a projectized organization there is no functional group to fall back to when finished. Resources tend to get nervous as they near the project end. Let them know well in advance when their end date is. If possible, work with them to identify the next project they will be working on. To address potential employee retention problems toward the end of a project you may want to consider monetary incentives to keep them through the end.

In the final analysis, the key to successfully managing any project is to recognize where the real authority lies, how much you personally have and where you derive it from. In the final analysis, project management is as much a position of dependency as it is one of authority. If you can’t convince the team to follow, you can’t lead. Understanding Positional, Referent, Reward/Penalty and Expert authority offers you the necessary tools to manage successfully.

Sunday, July 15, 2007

July 16, 2007 – Authorized to Manage – In a Matrix Organizational

This is the seventh in a series looking at authority. Focusing our attention on the matrix organization we’ll look at some practical tips for surviving in this environment.

You have officially lost control….

Matrix Organization.
A matrix environment can be a difficult place to manage. As we have seen, it is that fuzzy area between Functional and Projectized organizations. Project Managers that have successfully managed multimillion dollar efforts find they have lost all control when dropped into a matrix organization. At best they share control and at its worst they are little more than coordinators begging different departments to work pieces of the project. Because the weak matrix is the hardest to handle, we’ll center our focus on it.

Positional authority in this environment is held by the functional manager. She owns the resources and represents their security. When the project ends or fails they have a home back in her group; a safety net. In order to effectively manage you need to work through the functional managers. Since you lack positional authority you need to build up the other types.

Reward/penalty authority is your quickest option. As members of your team put in extra effort or make significant contributions send an email to their managers and copy them on it. Ask permission to give input to the team members’ annual review process. Do this at the beginning of the project and don’t keep it secrete. Announce it as a positive and tell them how you intend to use it to provide their management with an accurate picture of their contribution to the company.

Check with the functional manager up front to understand the best means to address performance issues and discussions. She may want to handle issues herself or at least be part of the process. Establish an escalation path from the beginning to resolve conflicts.

As you interact with the team you can develop referent authority. Through your actions they should begin to see that you are fair, trustworthy and willing to work through difficulties with them.

You can also demonstrate your expert authority by the way you manage. A solid, well communicated scope builds confidence in the project. Creating and tracking to a realistic schedule based on the resource availability shows foresight. Holding time conscience meetings using agendas and producing minutes lends credibility to your management abilities. All of these add up to the team having more confidence in your ability to lead.

To ensure the success of the project you also need to address two issues from outside of the project. First, without the hierarchical positional authority your project may lack a strong sponsor. If your company uses Portfolio Management, each of the projects will be ranked according to their priority. How does it compare to other projects? Can you leverage the project’s importance to obtain more commitment from the various groups?

The second problem is resource availability. Find out from the functional manager the percentage of time each resource is committed to the project. Then ask the individuals what other projects they are currently working and have them rank the importance of each. Rework your project estimates based on the reality of sharing the resources. Work with the other project managers to determine peak resource needs and coordinate the resource usage to fit everyone’s schedules.

As conflicts arise from resource availability or other areas, inform upper management and allow them to prioritize the projects and help resolve the issues.

Thursday, July 12, 2007

July 12, 2007 – Authorized to Manage – Organizational Types Matter

This is the sixth in a series looking at authority. Here we switch to practical uses of the four authority types within an organizational. This session will describe the difference between Functional, Projectized and Matrix environments.

Understanding your organization
puts the fun back in DysFUNctional

A Functional organization is divided by areas of specialization or function. There is the server group, the web development group, the legacy systems group, the security group and every other group you can imagine. Each group is managed by an expert in that area and their responsibility is to their silo of the company. Projects within a functional organization rely on using people from each of those groups as their individual managers make them available. The resources on the project still report to their functional managers and the project manager has little direct authority over them. When completed they fold back into the group they were in prior to the project.

The Projectized organization focus is on delivering projects. Project managers have full authority over priorities, resources and the effort of the people on the project. The team is created to perform a specific scope of work. When the work is completed it is dissolved. In some cases the same team may move intact to another project but usually they join other projects where their skills are needed. A good picture of this is a consulting company. As a project is awarded, a team is put together to complete it. When done they move on.

Somewhere in the middle of those two extremes lives the Matrix organization. It is a graduated scale authority from Weak to Balanced and then Strong where weak is next to the functional side and strong is closest to projectized.

In a weak matrix organization the project manager has very limited authority. Resources are on loan…and know it. Their loyalty remains with their functional manager and they understand that no matter how the project ends they have a home back in their group. Budgets are generally controlled by the functional manager and the project manager role is usually only part time. Even though most of the variables are out of the project manager’s control he will probably be fully responsible for the outcome. Sometimes the role isn’t even recognized and involves more coordination between groups than actual management.

The strong matrix swings the control more to the project manager. The positional authority level is closing in on high. Resources may still be shared but the majority of their activities are controlled by the project manager. Responsibility for the budget belongs to project manager and the role is full time.

In the balanced matrix responsibility is shared between the functional manager and the project manager. Positional authority becomes less of a factor between the two and there needs to be more give and take, which can become yank and shove if left unchecked by upper management.

Understanding where your company falls on the scale will show you where the real authority lies and allow you to manage accordingly. Trying to exert too much power in a weak matrix organization will cause friction with the functional manager and frustrate you. Fail to “own” your resources in a strong matrix and they end up on someone else’s project.

Monday, July 9, 2007

July 9, 2007 – Authorized to Manage – Expert Authority

This is the fifth in a series looking at Positional, Referent, Reward/Penalty and Expert types of authority, their use, abuse and challenges.

It’s not what you know…
It’s who knows you know it.

Expert Authority.
Expert Authority is based on the respect gained for your abilities. If you can earn the respect of your team and management you have the highest level of achievable authority. No, this isn’t the form of respect demanded by Al Capone or a dictator gained by roughing people up. This respect is earned by successfully managing projects and displaying your knowledge. It results in people wanting to work with you because of your abilities. They perceive you as a success and look to you for knowledge and direction.

In order to obtain guru status you need to consistently demonstrate your abilities. A history of successful projects shows your management strengths. Or, if your expertise is your knowledge you have shown it by always having useful information or offering sage advice.

You can also achieve expert authority by the acknowledgement of another authority. Gaining certification by a governing body adds credibility as offered by the initials PMP, CPA and PhD at the end of your name. Since everyone knows that idiots can get certified, you will need to prove your abilities match your credentials.

Because perception is a big part of this authority type, being published can bump you up on the expert charts. One individual I was attempting to mentor hardly gave me the time of day until he found out I was published in Computerworld. Somehow in his eyes I suddenly became a genius. Even though I was giving the same instruction as before, he was suddenly listening because now I was someone.

Appropriate Uses
I’ve mentioned two different types of expert authority. One is based on your knowledge in an area and the other is based on your success. From the knowledge perspective, share it with those that need it. Mentor people and keep other projects from hitting potentially deadly potholes. This can add referent authority and give you a stronger position. It also highlights your abilities and teamwork. That in turn may result in increased positional authority as more responsibilities are handed to you.

Your success can be used to obtain the best resources for your projects or even allow you to request better projects. People want to work for successful project managers and management wants their best people on challenging projects. To everyone it seems like a win-win situation.

Abusive Uses
There are times when even the guru is wrong but by sheer strength of their expert authority no one questions them. Getting people to blindly do something without question qualifies as abusive use.

Another form of abuse is withholding your knowledge or ability with the purpose of negatively impacting a project, group or individual. Whether you are doing it for personal gain or to just be a pain, your motive is an indication of misuse.

The most annoying challenge with expert authority is another genius. When you have dueling gurus, people look toward other forms of authority to determine who to follow. It is important to remember that there is a chance, however small, that you are wrong. Play your cards accordingly. Expert authority starts to unravel if you mess up too many times.

A change in leadership can also signal problems. When someone comes in that doesn’t know your abilities or history of success they may question your expertise. It just means you have to prove yourself all over again.

One thing to remember, just because someone disagrees with you it doesn’t mean they are challenging your authority. Further discussion may result in an even better solution.

Thursday, July 5, 2007

July 5, 2007 – Authorized to Manage – Reward/Penalty Authority

This is the fourth in a series looking at Positional, Referent, Reward/Penalty and Expert types of authority, their use, abuse and challenges.

The beatings will continue
until morale increases.

Reward/Penalty Authority.
Reward/Penalty authority is the use of both positive reinforcement and punishment to motivate people. Balance is the key. Too much reward and it becomes an expected entitlement and too much punishment causes people to leave. But both the carrot and the stick are required. Without rewards people don’t feel appreciated. On the other hand, a lack of consequences for poor performance or bad behavior will impact more that the disruptive team member. If you don’t address the issues your good performers will wonder why they bother working so hard.

For the longest time I didn’t feel I had much of this type of authority. What types of rewards could I dish out? How could I punish someone? As I better understood the role, I found some weapons you can add to your arsenal:
Better (or worse) assignments
More (or less) responsibility
Good (or bad) comments in annual reviews
Recommendations (or lack there of) for rewards, pay increases and promotions

When you think of reward/penalty authority in this light is evident that project managers have something to work with.

Appropriate Uses
Reward/Penalty authority is a tool works best when not overused. Right now I have two annual reviews in the pipeline that need my attention. Reviews are an opportunity to flex this authority but they can’t be the only time you use it. Keeping your people updated throughout the year on how they are doing stops them from being blindsided on their reviews. A “good job” email serves to reinforce their effort. A discussion about poor performance (calm, but direct with specific examples) is as a form of penalty to get them back on track.

Many companies offer standard awards. Look for opportunities to get your team on the list for these acknowledgements.

Remember to reward in public but punish in private.

Abusive Uses
Yelling is not my favorite use of penalty authority. I have seen project managers reduced to tears by directors that thrive on bellowing. If it is a tool you use regularly, stop. The objective is not to degrade the team member.

Another misuse is over applying the reward side. Continuously handing out bonuses, plaques and promotions can result in feelings of entitlement. People may begin expecting recognition and, like a drug, will need bigger doses more often to feel satisfied.

Challenges for this authority type can be subtle but deadly. They don’t come from external sources as much as from a misstep on your part. At the top of the list is sincerity. If you do not come across as sincere when rewarding or even punishing team members you are wasting the effort.

Maintaining equality is another tough challenge. Presenting the corner office to one top producer and offering a handshake to the next will result in rioting. I don’t suggest sharing it with the team, but keep track of what you give and why. It will give you ideas for the future and refresh your memory if questioned.

Finally, be careful not to overstep your bounds. Don’t promise what you can’t deliver as a reward and don’t demote someone without Human Resource’s involvement.

Monday, July 2, 2007

July 2, 2007 – Authorized to Manage – Referent Authority

This is the third in a series looking at Positional, Referent, Reward/Penalty and Expert types of authority, their use, abuse and challenges.

Character matters.

Referent Authority.
Referent Authority is the ability to influence others through your charisma, personality and charm. People are drawn to personalities. They like working for good natured, caring managers that take an interest in them for more than the hours they can bill. Interesting, though, some people are drawn to managers on the dark side. They see it as power and are drawn to it like moths to a flame.

As much as positional authority is about politics, referent authority is social in nature. It is more than your charming personality; it is the way people perceive you. Managers with higher levels of this type of authority are characterized as strong, hard working, just, even keeled or able. Lesser managers are those that appear indecisive, lacking in confidence, angry, hard to work with or easily pushed over.

One way to gain referent authority is to be helpful. One of my resources is working toward his Green Card status. There are very few papers I actually need to complete, but I am able to push the HR personnel and have hand delivered some of the signatures from other managers. Even just calling him to make sure nothing is stuck somewhere in process can show that I value him.

Appropriate Uses
There are many ways to use your personality to make people want to help you succeed. A sense of humor can be used to defuse tension during a heated meeting. A giving attitude may bring donuts to meetings. Level headed managers don’t snap at their team, they address problems. Caring ones make it a point to know their people and handle all that touchy-feely stuff.

Abusive Uses
Some managers use their appearance and allure to try to get people to do things for them. I encountered this once while in the project officer role on an account. For one project manager, whenever an issue came up I received the sad eyed, batting eyelashes, I-didn’t-know-any-better look.

Others may attempt to draw all of the talented resources to their group. There are even those that are smarmy enough to try move up the org chart by personality alone.

The biggest problem to look out for with referent authority is being taken advantage of. Some people think nice guys are there to be used. If you come across as trying to be your team’s buddy instead of boss they may loose respect for you.

Another challenge may come as an attack on your character. Skeletons in anyone’s closet can be used against them, but even false slander can be used to kill your referent authority.

PS. Happy belated Canada Day to those from up North.

Thursday, June 28, 2007

June 28, 2007 – Authorized to Manage – Positional Authority

This is the second in a series looking at Positional, Referent, Reward/Penalty and Expert types of authority, their use, abuse and challenges.

Authority extends only as far as those under you allow it
and only as long as those over you support it.

Positional Authority.
Positional Authority is based on where you sit in the organizational chart. Also known as Formal Authority, it is bestowed on you by some entity. CEOs get their position from the board and are subject to their vote. Project managers receive their right to manage from an approved charter, statement of work or other defining document. The extent of their power is defined by the bounds of the project scope.

Although culture plays a role in determining which type of authority is strongest, positional is the easiest to gain and loose. Since it is given it can also quickly be taken away. If the project is cancelled your role disappears. It is also in jeopardy if the entity that granted it changes. This becomes painfully obvious if your company is purchased and you are in an upper management position.

Appropriate Uses
During the normal course of managing a project, positional authority is a great starting point. Using it as a basis to push the purpose of the project forward, treat your team with respect and they will generally adhere to it.

You can also use positional authority of others. I have started many emails by referencing the project Sponsor or VP of something or other. The higher the title, the quicker the response tends to be.

Abusive Uses
This is the most often abused authority. Misuses include your standard harassment problems and basic dictatorships but also encompass more subtle ones. One example is to push work onto subordinates. One manager I mentored complained because her manager had her creating status reports for projects she wasn’t even managing.

Challenges come from many different directions on this one. If people don’t believe you have what it takes to fill the role they will be reluctant to follow. One individual I managed used age as his criteria. He was fine with me leading until he found out I was 6 months younger.

Another challenge will come from those outside the context of your project or organization. From the project side resources are always an issue. Portfolio Management is the key for that (come back for the Matrix Organization discussion). Organizationally, if your Sponsor is a VP there is always another VP that may try to trump her power.

The biggest challenge, though, usually comes from the person who thinks they should have gotten your position. One of the questions to ask as you step in is who else was considered or had eyes on the role. Your formal claim to it won’t appease them. One way to get them turned around is to include them in more of the management activity. This is especially useful with junior people looking to move up. By giving them opportunities to grow and be mentored you will actually be using Reward Authority, but that is a topic for another day.