"Superhuman effort isn't worth a damn unless it achieves results." - Sir Ernest Shackleton

Recently I wrote about project leadership vs. project management and how our role as project managers also puts us in a leadership role in many organizations. I was sent a job description for a PM that indicated that companies are seeing PMs as leaders as well as managers. The following is a portion of that job description.

·    Project team leadership skills including:

·    Estimating and setting project goals and milestones
·    Building team(s), motivating and leading team members to reach project milestones
·    Working closely with customers and vendors on project teams.
·    Keeping all team members involved, productive and challenged.
·    Sharing project information freely and on a timely basis
·    Using other resources and teams in a productive manner
·    Communicating and working with other Information Technology departments
·    Coaching and mentoring staff.

What is important to note here is that as PMs we need to understand that our role is to be a leader and a project manager. As a leader we set the tone for the team on how to get the project done. As a manager we coordinate the tasks and resources to execute the project.

Seems like a big task but as Shackleton alluded to if we achieve the results then the effort is worth it.

"I like to connect to people in the virtual world, exchanging thoughts and ideas, when in the physical world we might never have the opportunity to cross paths."  - Demi Moore


The quote above says a lot about how we interact with others because of today's technology. With social media allowing us to connect with others regardless of geography we are truly becoming a virtual society. This is also true for our working relationships. The virtual workforce is growing. Currently 25% of the US workforce works remote at least one day a week. Forrester estimates that by 2016 43% of the workforce will be virtual. Virtual teams are not new to project management but they do require special attention to work well.

Last year I moderated a panel on the virtual workforce. One of the questions asked of the panel is how do their organizations address team building of virtual teams? Some of the answers dealt with the use of technology such as video conferencing and chat rooms. Other answers focused on establishing regular meetings. governance, and cadence. However, one specific answer triggered my though process the most. One of the panelists mentioned that personal things such as acknowledging team members birthdays or holidays in different countries was important. This answer got me to realize that although the project team may be virtual it is still a team and the team dynamics needs to be managed.

When managing a virtual team encourage interaction among the team members. When a issue arises think about assigning it to two team members to work jointly. Encourage team members to reach out to each other with questions. Use team meetings to conduct peer reviews. The more the team interacts in this manner the less it seems like a virtual team and the more it functions as a well built team.

"You're Outta Here!" - Managing Conflict on a Project

 I wrote this tip a couplf of years ago. With spring training around the corner I thought this would be a good opportunity to repeat it. Readers of the weekly tips and those people who know me are familiar with my love of baseball. Many however may not be aware that I have been a High School baseball umpire for 18 years. When people I work with discover this they look at me like I'm mad. "So you're telling me that after being yelled at all day as a project manager you willingly go to a ball field and get yelled at by coaches and parents?" The answer is yes, I love it! In baseball the umpire has the final say as he / she can eject a coach or player if their arguments become overzealous. I will admit that early in my umpiring career my arguments with coaches resembled those famous scenes of Leo Durocher kicking chalk on a major league umpire. As time has passed I have learned a lot about handling these situations better to avoid throwing coaches out whenever possible.

 As project managers we don't have the ability to throw somebody out. However, many of the techniques I have learned on the field can be applied to the everyday project world. So when dealing with conflict, keep the following in mind:

1.   Watch your body language. As umpires we are taught to stand erect with our hands at our side when talking to coaches. Crossing your arms, slouching etc will tell the other person you don't want to listen or don't care.

2.   Control your language and tone of your voice. If the other person raises their voice, don't raise yours. That will only escalate the argument. Pick your words carefully when responding.

3.   Acknowledge what the other person says to show you are listening. Look for common ground in the discussion. Make sure the other person has concluded their comments before you explain your position.

4.   If the conflict occurs during a meeting or in a public area, suggest that you meet in private to discuss the issue. If the discussion is heated, suggest meeting later to provide a cooling off period.

Leo Durocher once said, " I've never questioned the integrity of an umpire. Their eyesight , yes." Keep this in mind when dealing with conflict. You and the other person may not agree but you are both trying to accomplish the same thing, a successful project. If you treat others as professionals they will do likewise and you will both solve the issue together.

"When you wish upon a ....."

Requirement. Such a simple word, but one of the major causes of project stress. All projects have requirements. IT projects, houses, ships, marketing campaigns all have functionalrequirements that must be fulfilled. Yet on may projects the requirements are not fully documented or even missed. On other projects there are two many or too complicated requirements for the time, resources, or money available. How does this happen?

 

Project issues due to the requirements arise because important aspects of requirements gathering were not done. These aspects include:

·Understanding the current processes being used

·Making sure that each requirement is understood and agreed to

·Making sure each requirement is testable

·Associating a cost with each requirement

·Having a business owner for each requirement

·Tying each requirement back to a scope statement or goal

·Eliminating "wish list" requirements

On any project, the requirements to be delivered should be only those that are truly needed. There really are no nice to have requirements

Replanning a project that is failing

When a project is in trouble and the delivery date is clearly going to be missed, the project stakeholders immediately start asking for a new date. Usually the team's inclination is to answer the question with a revised date that is derived in one of three ways:

1.A new date two to three months out is selected out of thin air.

2.The team discusses options and selects a new date that they believe is aggressive but doable.

3.The team does a replanning exercise and comes up with a new date based on revised estimates.

All three of these methods can lead to only one final answer, disaster. Option 1 assumes that time was the only factor impacting the project and adding an extra month or two will magically fix the those issues. Option 2 is doomed because the stakeholder's inclination is to believe the team wasn't aggressive enough and will insist that they be more aggressive. Option 3 is always a non-starter because the stakeholders don't trust the new timeframe because the original one was obviously incorrect. In most cases the final result is that the stakeholders select a new date that borders on the realm of science fiction or a least a "B" horror film.

Why does this happen? Business stakeholders and senior executives see project work differently than those of us who deliver the project. The goal of the project is to deliver a result that provides strategic or tactical value to the company. When a project is delayed, the reward the stakeholders were counting on doesn't occur. Their number one driver is to get that reward as soon as possible. By providing a new date for delivery without  providing them additional information on why the new date is necessary, the stakeholders will generally react negatively. To avoid this, the stakeholders need to see three things from the replan:

1.That the project team balanced being aggressive with risks.

2.The project team looked at options for delivery and took into account business needs.

3.The team addressed the underlying issues that caused the project to get into trouble in the first place.

"Never for me the lowered banner, never the last endeavor"  - Sir Ernest Shackleton

In 1914 Sir Ernest Shackleton led an expedition to Antarctica that was intended to cross the entire continent through the South Pole. The pole itself had been conquered a few yeas earlier by Amundsen and his team. Shackleton being one of the great polar explorers hoped to increase the knowledge of the area. Unfortunately their ship, the Endurance became ice bound and eventually  crushed resulting in one of the greatest survival stories of all time. Ultimately, all hands were rescued after over 18 months lost on the ice. Many attribute this feat to Shackleton's leadership skills. He was able to manage a team of experts, motivate the crew, maintain discipline, communicate orders, and make critical decisions when needed so that every man would survive a terrible ordeal.

 For the past few weeks I have been discussing project leadership as the next progression of project management. The leadership skills that Shackleton used almost 100 years ago are the very same that project managers need today.

·         Ability to communicate not only status but direction to the team.

·         Discipline in making sure that tasks are assigned and executed per the schedule.
·         Motivation. Many project teams consist of people who do not directly report to the PM and / or work remotely. The PM must be able to motivate the team to contribute to the overall success of the project.
·         Manage a team of experts. PMs must be able to manage a group of experts who have different project roles and different skills.
·         Ability to get obtain input and make critical decisions in a timely manner.

 Today's projects require project managers to be true leaders that manage projects that help move their organizations forward. Take a lesson from Sir Ernest and take the mantle of leadership to heart.

"Some key questions need to be asked continually throughout a project"

Many times we ask questions early in the project concerning both business and technical issues. If an application is being updated we might ask; "Do we need to load test the application?". If the answer is no the first time can we really assume that it will be no 3 months later? Questions like these need to be asked again because things may change on the project. A change request might occur that will increase the size of a transaction. A new server may be added to balance the load. Not asking the question again may lead to a surprise the night before implementation when you find out that the network team has concerns. Keep asking those questions!

"Stick with the basics."

Paul Richards, The Baltimore Orioles Manager from 1955 to 1961 once said about baseball:

"It's just throwing and catching and hitting and running. What's simpler than that?"

Baseball can be complex but the first thing that every player learns is to practice the basics. Projects too can be hard to manage particularly if they are large and complex. You can make your life easier by paying special attention to the basics such as :

·Good risk management

·Keep the stakeholders informed and engaged

·Regular team and stakeholder meetings

·Scope management

·Contingency planning

By paying attention to the basics, you will be in better position to deal with new issues and problems as they arise.