Lonnie Pacelli's Blog, page 83
February 14, 2014
How to Enter the Field of Project Management
My friends at Projectmanager.com posted a short Youtube video about how to enter the field of project management. Some good points but I think the 5th reason is one that aspiring PMs should keep front and center. My best learnings came from watching more experienced project managers operate when things were going well AND when things were going awry. Don't underestimate the value of finding a mentor who can really help you learn what it's like in the trenches and give you guidance when everything looks bleak. Give the video a look.
Don't Fool Yourself; There is No Work-Life Balance?
Fast Company published a thought-provoking article with an interest-piquing title. When you dig into the article, though, the core message of the article comes through:
Being dedicated and ambitious is admirable, but allowing work to define your self-worth and identity is dangerous. Man I couldn't agree more with this statement. I've seen many ambitious career-minded people crash and burn because the god they worshipped - work - didn't care about them at all. The reality is that at any point in time your employer can say to you, "I'm sorry, but we no longer need your services." The god they worshipped is now no longer there. I've seen people turn to substance abuse, nervous breakdowns, and worse because they allowed themselves to be defined by their work. I wrote a seminar on this topic because I feel so strongly about it. Check it out if you think your work defines you. Amazon.com Widgets
Being dedicated and ambitious is admirable, but allowing work to define your self-worth and identity is dangerous. Man I couldn't agree more with this statement. I've seen many ambitious career-minded people crash and burn because the god they worshipped - work - didn't care about them at all. The reality is that at any point in time your employer can say to you, "I'm sorry, but we no longer need your services." The god they worshipped is now no longer there. I've seen people turn to substance abuse, nervous breakdowns, and worse because they allowed themselves to be defined by their work. I wrote a seminar on this topic because I feel so strongly about it. Check it out if you think your work defines you. Amazon.com Widgets
February 8, 2014
Project Management Screw-Up 6 - The Team Didn't Gel
Excerpted from The Project Management Advisor - 18 Major Project Screw-Ups And How To Cut Them Off At The Pass (Prentice Hall, 2004)
I played the drums as a kid starting in fourth grade up into college. My family suffered through many hours (and headaches) of me beating the skins to jazz, funk, and rock music. When I started playing with the school band, I had to learn that making music wasn’t about how fast I could do flam-a-diddles or how loud I could play, but how I played in relation to the other band members. If the music called for adagio (slow & leisurely pace) it would be a bad idea to break into an In-A-Gadda-Da-Vida drum solo while everyone else is playing elevator music.
The important thing was to match my playing to the other instrumentalists and to make beautiful music together. While I never got to rock stardom with my own entourage and groupies, I did learn that music is about how the entire band sounds -- not any individual player.
By now you’re probably wondering why I took a mental trip to Tahiti to tell you about my musical aspirations. To me, a well-structured project team where each team member understands their role in making the project successful is like the musicians playing in a band. Each project team member knows what they need to contribute to the project, when they have to perform, what other project team members are doing on the project, and what it takes to be successful. Just as important, each of the project team members helps each other to ensure overall project success.
Amazon.com Widgets How it happens:
There was not a clear project organization with clearly defined roles - This goes beyond a hierarchy chart. Each person needs to know what function they play on the team, how they fit into the other functions, and what happens if they don’t do their job.
Depending on your industry or functional discipline, there may be standard or customary roles that you employ on your project. There are a few things that I have learned, though, about project standard roles as follows:
Start with the standard or customary roles that are typical for your type of projects
If the project need warrants a special role which is outside of standard, create a special role
If the project doesn’t need a standard or customary role, eliminate the role
These may sound like overly simplistic statements, but I’ve been amazed over the years with seeing cumbersome project role structures because the project manager was reluctant to deviate from standard project roles. As experienced project managers, our job first and foremost is to make sure that the right people are assigned to do the right tasks to produce the right result at the right time. At the end of the day, I’ve never been graded on how well I adhered to a standard project role structure; I’ve been graded on results.
If the project environment doesn’t have standard or customary project roles or if I’m taking on a unique type of project, I like to take a very pragmatic approach to role definition, as follows:
Define the 3-6 things on the project that I am most concerned about or pose the greatest risk to me
Create roles that encompass the concern or risk areas
Cross-check the roles with the work that needs to be done in the project schedule to ensure that all the major roles are being defined correctly
By doing this, I am addressing concern or risk areas head-on by defining a role with a singular point of accountability to manage the areas of my project that are most likely to fail. This technique has helped me on more than one project to sleep better knowing that I had my most crucial areas covered.
The team finger pointed and fought in public - On any project you do, so long as there is more than one person involved, there are going to be lively discussions. When this happens, it is very likely that something good will come of the discussion and that in some way the project will move one step closer to the finish line as a result. On past projects I have managed, I was very deliberate about letting these discussions happen and in letting team members question each other. I did put a few rules in place, though:
It’s very cool to challenge and stretch, but when we make a decision we need to get behind it as a team
What happens in the room stays in the room; outside of the room we are a unified team
If we made a wrong decision we accept the decision as a team; no finger pointing allowed
We focus on the problem and not the person; don’t make the problem personal
So, were the rules followed 100% of the time? Sadly, no (myself included). After all, we are human. However, you should still strive to get some ground rules in place to avoid team strife where you can.
There was no “rallying cry” - You can look at many major successful campaigns and pull some slogans from them which embodied the message behind the slogan: “Where’s the beef,” “Milk, it does a body good,” and “Plop, plop, fizz, fizz” are all unifying messages that cause you to think about a product. Similarly, when driving a project it helps the team to have some kind of a rallying cry or mantra that the team embodies when driving work. On one project, we wanted to be extremely cautious of not over-designing a solution and putting too many bells and whistles in to help us keep our costs down. We started using a “good enough” rallying cry during the design phase to be a continual reminder that we wanted to not overdo the solution. It worked incredibly well because the team would critically question itself with “Is this good enough?” when looking at the architecture and functionality. Aside from helping to make sure that our solution was cost effective, the rallying cry helped the team to better bond.
Team members weren’t held accountable for delivery - With project teams, I firmly believe that each role needs to clearly understand what they need to do, when they need it done by, and how their work fits into the big picture. I also firmly believe the project team isn’t only accountable to the project manager, they are accountable to each other because if any of the other roles fail the entire team fails. Given so, it is vitally important for each role to be visible as to what each other role is doing for the following reasons:
Each role should be continually looking at other work that is happening to ensure that they know if and how they fit into the other work
Each role should feel that if they miss a deadline or do not perform their job adequately, they are letting down the team as a whole, not just the project manager.
Meeting or missing deadlines and deliverables are a team issue and should be exposed to the team.
The point here is accountability. Each member needs to feel accountable for their work and needs to experience the joy of success as well as the discomfort of failure. The project manager needs to use discretion on making sure that things do stay constructive. Focus should be very much on how the team gets things back on track and moving forward versus badgering the team member.
In some instances, though, you may just have someone in a job who is not suited to perform. The project manager needs to deal with those situations swiftly because if he or she doesn’t, he or she is not doing his job nor being accountable to the team by dealing with a problem performer.
The project manager wasn’t suited for the job - The project’s needs and criticality to the business will be key drivers in the required experience level of the project manager. For relatively simple projects, you may be able to staff the project with an inexperienced project manager with a more seasoned project manager serving as an occasional mentor. As projects increase in complexity and criticality to the business, though, there’s no substitute for an experienced, seasoned project manager.
I’ve been incredibly fortunate to have worked with some outstanding project managers over the years. In thinking about the best project managers, they’ve had the following things in common:
They knew the techniques of project management cold
They knew (through experience) where they could bend the rules on the techniques to be able to buy time or be more efficient
They always kept things moving forward
They knew when to shift from “let’s discuss” mode to “let’s decide” mode
They held others accountable to do their jobs
They praised success
They were excellent communicators
They took the heat for the team when external criticism happened
They were calm and focused when things started going bad on a project and everyone else was wigging out
I know of no magic formula for fitting the project manager for the job; what I can say is you’re better to err on having an over-experienced project manager versus an under-experienced one.
I knew of a very gung-ho young project manager (let’s just call him “Author”) who felt he was an outstanding project manager because he knew the techniques well (cost and schedule management, status reporting, and so on). Because Author knew the techniques, he felt he could simultaneously take on three complex projects that really should have each had a dedicated project manager. Not only did Author learn some very valuable lessons, he unfortunately also cost his company a lot of money because others had to come in and mop up his mess. Both Author and I can’t stress enough to make sure your project manager is suited for the job.
The team didn’t celebrate wins - Driving through a project is tough work. It is incredibly easy for people to get discouraged whenever the team hits roadblocks or has setbacks. It is vitally important for a team to celebrate hitting key milestones simply to keep morale up and keep project momentum. I’m not talking about three-day cruise type celebrations, it could be as simple as bringing in pizza or cake or something that allows people to let their hair down and take a bit of a breather. I would caution you about doing this too much; doing too much celebration lessens the effect of the celebration and could actually annoy your team members. I was on one project where people did not like the morale events because it only meant that they had to stay later that evening to get their work done. So, celebrate, but do it in moderation.
Warning Signs:
The team shows confusion about who is doing what - Confusion can exist either due to poor communication on who is responsible for what tasks or because tasks can reside under the responsibility of more than one role. It’s important not only to get people to agree on areas of responsibility, but to ensure that the responsibilities are clearly documented and communicated to the entire project team. Also, be prepared to pull this document out and remind the team of its respective responsibilities as confusion creeps back into the project team.
Discussions are destructive and unproductive - You know what this looks like; if you’re team can’t have discussions without getting personal, derogatory, or outright mean this is a pretty clear sign you’re not gelling as a team. The project team doesn’t have to be best friends with each other, but they should at least respect what each other bring to the table.
Team members aren’t helping each other - I’ve actually been in some environments as a consultant where some team members enjoyed seeing other team members fail and did absolutely nothing to help them for the good of the project. Project team members who carry an “every person for themselves” kind of attitude are not going to perform anywhere near their full potential.
Turning it around:
Clarify the confusion - Get team members locked in a room and hammer this out. If you get stuck on a particularly contentious area or if you see tempers flaring, set it aside and work on other things, then come back to the contentious area. Make sure that responsibilities are documented and clearly accessible for all members.
Address the problem team member - Never a pleasant task, but I on more than one occasion have had a project team member taken off the project because they simply were going to remain a destructive force on the project. At the same time, I’ve also been able to turn a destructive situation around. In either event, address the issue swiftly before it does further damage to the rest of the project team.
Co-locate the team - I’ve had some of my greatest successes where the project team was physically located in the same area and had minimal physical barriers to inhibit communication. This may or may not be entirely possible depending on your project, but where you have the opportunity to co-locate team members, strongly consider doing so.
Go out for a milkshake - Sometimes it’s great to just get people away from their work environment and socialize over a favorite food and beverage. As a consultant on out-of-town projects, our project teams were typically very effective because we had more time to socialize and bond during non-work hours. Getting to know each other a bit and being able to laugh as a team pays huge dividends in overall team effectiveness.
All work and no play…- ...makes for a really dull and demotivating project. Take some time out of the project to have a laugh. I have certainly been known to play an occasional practical joke on a project or to bring some occasional levity to a particularly stressful time in a project. Just be careful that the use of humor isn’t too excessive or inappropriate; but by all means make sure that you share a laugh or two even if it’s at your expense.
Be the unifier - As the project manager, you are expected to take responsibility for getting the team to gel and to know the barriers that exist which are preventing the team from being a highly cohesive, collaborative, high-performance team. At times, it’s likely to be the most uncomfortable part of your job, but it can also be one of the most rewarding when done well.
Take Aways: Define a clear project organization with clearly defined roles
Be a team through thick and thin; don’t publicly finger-point when things start going south
Develop a “rallying cry” which focuses the team on the mission
Let the team members do their jobs, but hold them accountable for results and dates
Make sure that you have a project manager that who is appropriately seasoned for the project
Celebrate the wins as a team
I played the drums as a kid starting in fourth grade up into college. My family suffered through many hours (and headaches) of me beating the skins to jazz, funk, and rock music. When I started playing with the school band, I had to learn that making music wasn’t about how fast I could do flam-a-diddles or how loud I could play, but how I played in relation to the other band members. If the music called for adagio (slow & leisurely pace) it would be a bad idea to break into an In-A-Gadda-Da-Vida drum solo while everyone else is playing elevator music. The important thing was to match my playing to the other instrumentalists and to make beautiful music together. While I never got to rock stardom with my own entourage and groupies, I did learn that music is about how the entire band sounds -- not any individual player.
By now you’re probably wondering why I took a mental trip to Tahiti to tell you about my musical aspirations. To me, a well-structured project team where each team member understands their role in making the project successful is like the musicians playing in a band. Each project team member knows what they need to contribute to the project, when they have to perform, what other project team members are doing on the project, and what it takes to be successful. Just as important, each of the project team members helps each other to ensure overall project success.
Amazon.com Widgets How it happens:
There was not a clear project organization with clearly defined roles - This goes beyond a hierarchy chart. Each person needs to know what function they play on the team, how they fit into the other functions, and what happens if they don’t do their job.
Depending on your industry or functional discipline, there may be standard or customary roles that you employ on your project. There are a few things that I have learned, though, about project standard roles as follows:
Start with the standard or customary roles that are typical for your type of projects
If the project need warrants a special role which is outside of standard, create a special role
If the project doesn’t need a standard or customary role, eliminate the role
These may sound like overly simplistic statements, but I’ve been amazed over the years with seeing cumbersome project role structures because the project manager was reluctant to deviate from standard project roles. As experienced project managers, our job first and foremost is to make sure that the right people are assigned to do the right tasks to produce the right result at the right time. At the end of the day, I’ve never been graded on how well I adhered to a standard project role structure; I’ve been graded on results.
If the project environment doesn’t have standard or customary project roles or if I’m taking on a unique type of project, I like to take a very pragmatic approach to role definition, as follows:
Define the 3-6 things on the project that I am most concerned about or pose the greatest risk to me
Create roles that encompass the concern or risk areas
Cross-check the roles with the work that needs to be done in the project schedule to ensure that all the major roles are being defined correctly
By doing this, I am addressing concern or risk areas head-on by defining a role with a singular point of accountability to manage the areas of my project that are most likely to fail. This technique has helped me on more than one project to sleep better knowing that I had my most crucial areas covered.
The team finger pointed and fought in public - On any project you do, so long as there is more than one person involved, there are going to be lively discussions. When this happens, it is very likely that something good will come of the discussion and that in some way the project will move one step closer to the finish line as a result. On past projects I have managed, I was very deliberate about letting these discussions happen and in letting team members question each other. I did put a few rules in place, though:
It’s very cool to challenge and stretch, but when we make a decision we need to get behind it as a team
What happens in the room stays in the room; outside of the room we are a unified team
If we made a wrong decision we accept the decision as a team; no finger pointing allowed
We focus on the problem and not the person; don’t make the problem personal
So, were the rules followed 100% of the time? Sadly, no (myself included). After all, we are human. However, you should still strive to get some ground rules in place to avoid team strife where you can.
There was no “rallying cry” - You can look at many major successful campaigns and pull some slogans from them which embodied the message behind the slogan: “Where’s the beef,” “Milk, it does a body good,” and “Plop, plop, fizz, fizz” are all unifying messages that cause you to think about a product. Similarly, when driving a project it helps the team to have some kind of a rallying cry or mantra that the team embodies when driving work. On one project, we wanted to be extremely cautious of not over-designing a solution and putting too many bells and whistles in to help us keep our costs down. We started using a “good enough” rallying cry during the design phase to be a continual reminder that we wanted to not overdo the solution. It worked incredibly well because the team would critically question itself with “Is this good enough?” when looking at the architecture and functionality. Aside from helping to make sure that our solution was cost effective, the rallying cry helped the team to better bond.
Team members weren’t held accountable for delivery - With project teams, I firmly believe that each role needs to clearly understand what they need to do, when they need it done by, and how their work fits into the big picture. I also firmly believe the project team isn’t only accountable to the project manager, they are accountable to each other because if any of the other roles fail the entire team fails. Given so, it is vitally important for each role to be visible as to what each other role is doing for the following reasons:
Each role should be continually looking at other work that is happening to ensure that they know if and how they fit into the other work
Each role should feel that if they miss a deadline or do not perform their job adequately, they are letting down the team as a whole, not just the project manager.
Meeting or missing deadlines and deliverables are a team issue and should be exposed to the team.
The point here is accountability. Each member needs to feel accountable for their work and needs to experience the joy of success as well as the discomfort of failure. The project manager needs to use discretion on making sure that things do stay constructive. Focus should be very much on how the team gets things back on track and moving forward versus badgering the team member.
In some instances, though, you may just have someone in a job who is not suited to perform. The project manager needs to deal with those situations swiftly because if he or she doesn’t, he or she is not doing his job nor being accountable to the team by dealing with a problem performer.
The project manager wasn’t suited for the job - The project’s needs and criticality to the business will be key drivers in the required experience level of the project manager. For relatively simple projects, you may be able to staff the project with an inexperienced project manager with a more seasoned project manager serving as an occasional mentor. As projects increase in complexity and criticality to the business, though, there’s no substitute for an experienced, seasoned project manager.
I’ve been incredibly fortunate to have worked with some outstanding project managers over the years. In thinking about the best project managers, they’ve had the following things in common:
They knew the techniques of project management cold
They knew (through experience) where they could bend the rules on the techniques to be able to buy time or be more efficient
They always kept things moving forward
They knew when to shift from “let’s discuss” mode to “let’s decide” mode
They held others accountable to do their jobs
They praised success
They were excellent communicators
They took the heat for the team when external criticism happened
They were calm and focused when things started going bad on a project and everyone else was wigging out
I know of no magic formula for fitting the project manager for the job; what I can say is you’re better to err on having an over-experienced project manager versus an under-experienced one.
I knew of a very gung-ho young project manager (let’s just call him “Author”) who felt he was an outstanding project manager because he knew the techniques well (cost and schedule management, status reporting, and so on). Because Author knew the techniques, he felt he could simultaneously take on three complex projects that really should have each had a dedicated project manager. Not only did Author learn some very valuable lessons, he unfortunately also cost his company a lot of money because others had to come in and mop up his mess. Both Author and I can’t stress enough to make sure your project manager is suited for the job.
The team didn’t celebrate wins - Driving through a project is tough work. It is incredibly easy for people to get discouraged whenever the team hits roadblocks or has setbacks. It is vitally important for a team to celebrate hitting key milestones simply to keep morale up and keep project momentum. I’m not talking about three-day cruise type celebrations, it could be as simple as bringing in pizza or cake or something that allows people to let their hair down and take a bit of a breather. I would caution you about doing this too much; doing too much celebration lessens the effect of the celebration and could actually annoy your team members. I was on one project where people did not like the morale events because it only meant that they had to stay later that evening to get their work done. So, celebrate, but do it in moderation.
Warning Signs:
The team shows confusion about who is doing what - Confusion can exist either due to poor communication on who is responsible for what tasks or because tasks can reside under the responsibility of more than one role. It’s important not only to get people to agree on areas of responsibility, but to ensure that the responsibilities are clearly documented and communicated to the entire project team. Also, be prepared to pull this document out and remind the team of its respective responsibilities as confusion creeps back into the project team.
Discussions are destructive and unproductive - You know what this looks like; if you’re team can’t have discussions without getting personal, derogatory, or outright mean this is a pretty clear sign you’re not gelling as a team. The project team doesn’t have to be best friends with each other, but they should at least respect what each other bring to the table.
Team members aren’t helping each other - I’ve actually been in some environments as a consultant where some team members enjoyed seeing other team members fail and did absolutely nothing to help them for the good of the project. Project team members who carry an “every person for themselves” kind of attitude are not going to perform anywhere near their full potential.
Turning it around:
Clarify the confusion - Get team members locked in a room and hammer this out. If you get stuck on a particularly contentious area or if you see tempers flaring, set it aside and work on other things, then come back to the contentious area. Make sure that responsibilities are documented and clearly accessible for all members.
Address the problem team member - Never a pleasant task, but I on more than one occasion have had a project team member taken off the project because they simply were going to remain a destructive force on the project. At the same time, I’ve also been able to turn a destructive situation around. In either event, address the issue swiftly before it does further damage to the rest of the project team.
Co-locate the team - I’ve had some of my greatest successes where the project team was physically located in the same area and had minimal physical barriers to inhibit communication. This may or may not be entirely possible depending on your project, but where you have the opportunity to co-locate team members, strongly consider doing so.
Go out for a milkshake - Sometimes it’s great to just get people away from their work environment and socialize over a favorite food and beverage. As a consultant on out-of-town projects, our project teams were typically very effective because we had more time to socialize and bond during non-work hours. Getting to know each other a bit and being able to laugh as a team pays huge dividends in overall team effectiveness.
All work and no play…- ...makes for a really dull and demotivating project. Take some time out of the project to have a laugh. I have certainly been known to play an occasional practical joke on a project or to bring some occasional levity to a particularly stressful time in a project. Just be careful that the use of humor isn’t too excessive or inappropriate; but by all means make sure that you share a laugh or two even if it’s at your expense.
Be the unifier - As the project manager, you are expected to take responsibility for getting the team to gel and to know the barriers that exist which are preventing the team from being a highly cohesive, collaborative, high-performance team. At times, it’s likely to be the most uncomfortable part of your job, but it can also be one of the most rewarding when done well.
Take Aways: Define a clear project organization with clearly defined roles
Be a team through thick and thin; don’t publicly finger-point when things start going south
Develop a “rallying cry” which focuses the team on the mission
Let the team members do their jobs, but hold them accountable for results and dates
Make sure that you have a project manager that who is appropriately seasoned for the project
Celebrate the wins as a team
Exercise and Work/Life Balance
Through my own work/life balance journey I've learned that regular exercise is key to keeping stress in check and helping me have more stamina when things get hectic at work. I came across an interesting Harvard Business Review Blog about the importance of regular exercise to a balanced life. Something I've taken to doing is foregoing the elevator and taking the stairs wherever I go to help integrate exercise into my daily routine. If you want some additional tips on achieving better work/life balance, check out my Straight Talk Seminar - 17 Tips to Help You Find True Work/Life Balance.
Seek First to Understand your Recipient - Strategies to Make you a Better Communicator
Buy
PC
|
Kindle
|
iTunes
|
Nook
Think back to some great communicators like Reagan, Martin Luther King Jr., or John F. Kennedy. What made them great communicators? It wasn’t that they were great orators, had flashy teeth, sported perfect hair, or demonstrated a flawless writing style. They had courage, conviction, wisdom, clarity, and credibility; five attributes that build the foundation of all great communicators.
Buy PC | Kindle | iTunes | Nook
Four Leadership Qualities Employers Look For
I ran across this article on four Leadership Qualities Employers Look For. The four qualities highlighted, Integrity, Good Judgment, Competence, and Vision are all good undisputed qualities. In my Straight Talk Leadership Seminar 27 Tips to Conquer the Seven Deadly Sins of Leadership I focus on seven sins that can the best leaders avoid, as follows:1. The Sin of Arrogance
2. The Sin of Indecisiveness
3. The Sin of Disorganization
4. The Sin of Stubbornness
5. The Sin of Negativism
6. The Sin of Cowardice
7. The Sin of Untrustworthiness
Whether you're a new or experienced leader, honestly assess your leadership capabilities against the seven sins and grow those leadership skills!
20 Cloud Computing Stats Every CIO Should Know
I ran across this compelling article which validates that Cloud Computing is here to stay and is only going to increase in prominence over the next several years. If you're behind the curve in your cloud knowledge or are in denial of its applicability, give these stats a look. Stay up on this trend; don't turn into a typewriter repairman.
Big Data and Sports
Man what an interesting thought. Big Data is about analyzing lots and lots of structured and unstructured data to help an organization do something better and be more prescriptive in responding to events. Phys.org published a super intriguing article about how big data could be used in professional and amateur sports to give athletes a winning edge. Think about the possibilities of extracting data from video which helps coaches and players prepare for upcoming games. Big Data and sports; whoda thunk!
February 1, 2014
Attributes of an Effective Project Manager
Recently I did an interview talking about the most important attributes of an effective project manager and those attributes which undermine a person's ability to manage projects well. It was fun putting together the list and I thought I would share my raw bullets with you, as follows:Attributes of an effective project manager:
Skill in negotiating win-win solutions between stakeholders and the project team
Ability to understand the needs of the stakeholder organization and take those into account when making day to day project decisions Ability to objectively present decision alternatives and consequences and drive to a rational decision based on the alternatives Staying calm particularly during turbulent times
Avoiding showing biases toward any team member or stakeholder organization
Skill in clearly articulating a project workplan, its dependencies, and the resulting deliverables Desire to hold the team accountable for deliverables Amazon.com Widgets Ability to clearly articulate and communicate the mission of the project and continually remind the project team of the business purpose behind the project
Ability to earn the respect of the team regardless of reporting relationships
Willingness to be held accountable for results and not deflect blame when things don’t go well
Ability to effectively leverage a project sponsor to get him/her to help the project manager through difficult issues
Skill in managing virtual teams
Things which undermine a PM’s ability to manage effectively:
Inability to stay calm when problems arise
Blame-shifting when things go wrong
Poor articulation of work assignments and deliverables
Biases towards team members or stakeholder organizations
Political or hidden agendas which influence project decisions
Inability to compromise or negotiate win-win solutions
The Last Lecture by Randy Pausch
I review the book The Last Lecture by Carnegie Mellon Professor Randy Pausch. With only months to live, Randy conducted a final lecture entitled "Really Achieving Your Childhood Dreams". I was very conflicted after reading his book and couldn't decide if the book was a selfless act of love to preserve his memory after dying or if it was about a man who put his work first before his family. I strongly recommend you read The Last Lecture and you draw your own conclusions.
You can find the review here.
