Showing posts with label Resource Management. Show all posts
Showing posts with label Resource Management. Show all posts

Sunday, December 14, 2008

December 15, 2008 - Killing False Confidence

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Sunday, July 20, 2008

July 20, 2008 - Random Thoughts

While on vacation I am pulling together a chunk of my blog entries to publish in book format entitled Project Management RX: 101 Daily Doses. This hasn’t left me much time to sit down and write anything new, but I did have a couple of random thoughts to pass on to you.

Red, Yellow, Green.
The often used RYG symbols indicating project status risk levels have proven very useful. But what if you were sitting at a stop light and the color never changed? It can be very frustrating. Sometimes I am tempted to jump out of my car and press the crosswalk button to make it change. For your project, anything other than Green should be temporary, too. Items causing your project to be Yellow should be resolved within 2 weeks. For Red issues, fast action should be taken to back it down to Yellow within 2-4 days.

Intolerable. While mentoring projects managers I occasionally hear the statement, “I guess we just have to live with it.” We cave in on many issues and inconveniences, including poor performers, additional scope, old resources, impossible time lines, or slow responses from other department. We feel like there is nothing we can do to stop it. Instead of whining about it, here’s a suggestion. Document the items as change requests and present them to the sponsor and PMO. Explain the impact to the project and receive their buy in stating that they are okay with it. When they see it in black and white it will be harder to ignore, forcing some action to be taken. If you put up with it, nothing will ever change.

Sunday, July 6, 2008

July 7, 2008 – Making the Time Tracking Switch

Over the next several months, our company will be upgrading the project management system and adjusting our processes to take advantage of new features. One of the features getting a significant amount of interest is resource management. The ability to plan resource availability in advance will allow us to understand our project capacity and identify bottlenecks in time to adjust.

The key to making this work will be creating and maintaining realistic project schedules with resources assigned and hours tracked at the task level. The tricky part of making this time tracking switch is getting the team members to buy into the concept of entering actual hours into the system and re-estimating the time remaining. In order to make this happen you will need an EDGE.

Expect Resistance. Your team will push back when you inform them of the new expectation to record their project hours at the task level. The obvious reactions you will get include:

  • It will take too long to break up my time.
  • I work on too many projects for this.
  • Why are you micromanaging me?

Anticipate these issues and have answers available. As an example, include additional time on the project schedule for status and timekeeping; up to an hour per week per project.

Direction from the Top. Communicating the change needs to come from as far up the organization as possible. When the CIO says this will help make us successful it carries a lot more weight than just you as a project manager advocating it. The directors and supervisors need to buy in, too. If management doesn’t take action when time isn’t recorded then nothing will happen.

Give Up Some Detail. In order to make this work you may need to cut down on the level of detail in the schedule. Trying to divide time up into 2-4 hour chunks for 3 different projects will drive them insane. The opposite temptation is to drop all the way back to the Phase level or, worse, the Project level. Either one of these is too high. Break tasks down to between 8 and 80 hours (approximately 2 weeks of effort). Additional details can be listed and tracked as started / completed in a spreadsheet to ensure specific tasks are assigned, worked and closed.

Explain the Purpose. It is important to clearly communicate why a more detailed accounting of the project time is required. Begin by explaining the need to understand resource usage and availability but make sure you follow up with these:

  • Being over or under an estimate is expected. The theory is that they will balance each other over time.
  • A realistic understanding of where we are off schedule allows us to discuss how to get back on track.
  • Re-estimating at the task level allows us to re-plan when future resources are needed. This is especially useful if we are ahead of scheduled or if other projects require the same resources.
  • This is not intended to single any individual out or micromanage the team.
    It will help identify areas where additional resources, training or other assistance can make a difference.
  • By reviewing the workload across all projects, management can find workload issues and take actions to correct them.

As the team sees this information being used to make project decision they will realize its importance get on board.

Sunday, June 22, 2008

June 23, 2008 - 10 Ways to Avoid Falkirk

The Falkirk battle scene in the movie Braveheart has William Wallace engaging the English army. At a crucial point in the fight, the Scottish nobles that were supposed to be his allies betrayed him and withdrew from the field, leaving him to be defeated. Knowing who your allies are is important. Knowing you can trust them is vital.

This goes both ways. You need to know your team is behind you but they need to know you have them covered, too. Failing to protect them, you can imagine how quickly they would hunt you down and dispose of you, much like William Wallace did to his enemies.

Keep yourself and your team from being destroyed with these 10 points.

Be aware of conflicts and issues within the team. Not all disagreements are unhealthy, but when it becomes a conflict it needs to be aired and dealt with quickly.

Recognize a challenge from outside. Some people are able to couch their attacks in a manner that hides their intent. It starts out supportively with “Your team does have an aggressive timeline and seems to be over allocated.” Then it turns to “Obviously they can’t estimate properly and are incompetent in other areas as well.”

Address the attack. If a member of your team comes under fire during a meeting it is your job to set the record straight. You don’t have to defend the guilty, but you can keep them from being executed on the spot. Let the attacker and anyone he has told know that the issue is being handled and, if appropriate, how.

Verify the facts before laying blame. Nothing kills credibility with your team faster than assuming they are guilty. A manager I once knew failed to find the truth before assuming his new team was in the wrong. It took him nearly three months to realize his mistake. He never regained the confidence of his team.

Eliminate flashpoints. If you have team members that can’t stand each other, don’t make them work together. One individual I worked with lacked any verbal filter and could be a little abrasive at times. Unfortunately he was heading up a task force that dealt directly with upper management. He said some things to the CIO that should have been left unsaid. Luckily the CIO was extremely patient and handled it well. That person didn’t stay the head of the group long afterward.

Have an open door policy. Give your team the opportunity to talk through problems and address things directly with you before they get explosive. My principal in high school had an open door policy and it probably saved me from being expelled. An idiot named Bubba moved in during my junior year. For no apparent reason he started spreading lies about my girlfriend. He deserved a thrashing, and I told the principal I was going to do it if he didn’t stop. Mr. Stockin was able to talk me down and save my academic career.

Escalate major issues to upper management. If there are problems that have further reaching impacts, senior management needs to know and be involved in resolving them.

Allow time for the situation to cool down. Like a cut, some things take time to heal. If you keep picking the scab the situation is going to scar.

Revisit the situation to ensure the coals aren’t smoldering. After the cooling down phase, loop back around and check with the involved parties to address any lingering problems.

Treat everyone with respect, even the difficult ones. I’ve been asked to be a reference for people I did not enjoy working with. Evidently they were clueless that I couldn’t stand working with them.

Notes:

  • There several historical inaccuracies in the Braveheart movie. Falkirk may never have truly happened.
  • I generally hide the identity of my examples, but it felt good to finally take a swing at Bubba.

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 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 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 ThomasCutting@yahoo.com.

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, 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.

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.

Challenges
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
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.

Challenges
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.

Wednesday, June 27, 2007

June 27, 2007 – Authorized to Manage - Introduction

My first experience with management responsibilities was as an account manager for the consulting company where I was working. For my group of consultants this meant making sure their timesheets were in on time and compiling their annual review documents. In the grand scheme of management it was pretty low level. What was interesting, though, was the way some people treated me when they found out I was their manager. It was as if that tiny step gave me control of their entire career. I, on the other hand, pictured it as simply a means for the company to handle basic logistics that upper management didn’t have time to do.

Looking back I realize that the reality of the role encompassed both ends of the spectrum. It was a necessary, tedious part of management that someone had to pick up, but by contributing to someone’s annual review and permanent record it also impacted their career, too. I had Authority.

So, what do we mean by authority? A Webster definition of authority is “the right and power to command and be obeyed or to do something.” I like this definition because it covers both pieces. The right to do something without the power to get it done is futile. The power to do it without the right leads to tyranny.

The Project Management Institute defines authority as “the right to apply project resources, expend funds, make decisions, or give approvals.” This is a little too restrictive for the subject at hand.

A better definition is “the responsibility to manage resources (people, products and funds) to the full extent of your influence.” The use of the work responsibility implies an expectation to treat your resources properly. Substituting influence for the term power more accurately reflects reality as a project manager. Power implies force. Influence covers more options.

There are four main types of authority: Positional, Referent, Reward/Penalty and Expert. Over the next several entries we will look at each of these authority levels and then discuss how they work in both Matrix and Projectized organizations. I’ll even define Matrix and Projectized, too.

One key point to remember is that the purpose of authority is to accomplish the goals of a project or an organization. The purpose of authority is not to make you look important, control others or for self gain. There are numerous examples of authority being used to take advantage of others including hostile contract negotiations and sexual harassment. For each authority levels we will examine ways it should be used appropriately, how it can be abused and the types of challenges you are likely to face from others.