Gurus love to tell us that we learn the most from the mistakes we make. I’m not sure that is true, and I’ve made lots of mistakes, so I should know. I will say that my mistakes have been some of my most memorable and conscious (painful!) learning opportunities. I thought that by sharing some of them, I might help others to not repeat them. Although, based on my experience, I am likely to make these mistakes again and so are you!

 Don’t take things personally
This could possibly be the golden rule of project management. If you ever entirely master this skill, please let me know. I will sit at your feet to learn how you achieved greatness.

 Taking things personally as a project manager can lead to poor decision-making, poor performance and seriously disrupted team dynamics. Because as project managers, we tend to sit at the center of a lot of communication pathways and at the intersection of a lot of personalities, it is easy to get the brunt of peoples’ frustrations, insults and other petty behaviors.

 Recently, in a project team meeting, I was going through a list of tasks with a group of developers. One of the team leads in the meeting did not want me to cross a completed task off the list and proceeded to argue with me in a loud voice about whether or not this item should be crossed off. I was so offended by his behavior that I just put down the marker and sat down. We did not cover all the agenda items during that meeting and we did not follow an agreed upon process that we had developed. As a result, the project status suffered that week.

 Feeling personally attacked caused me to shirk my project management responsibilities and the project suffered. The next time I had a negative interaction with this team member, I was able to focus on the project deliverables and keep moving by reminding myself that this wasn’t about me, personally.

 If things don’t “feel” right, they aren’t right
Do you ever get that funny sinking feeling about something on your project? I do! And it is the times that I have ignored this little tickle in my gut that things have gone the most off track.

 Intuition is an important skill for project managers. Honing this skill can make you a better project manager. My instincts in this area have improved with practice. These days, I try to pay close attention to what people say but also to what people do not say. I also pay close attention to what people say vs. what people do. And it’s when I am not paying attention to these things or when I actively chose to ignore them that I get in trouble.

 Once, when working through a contract with a vendor, I failed to realize that we were approaching the deadline for the terms of the contract. Because I was working with someone in our accounts payable department, I assumed that this person had read through the contract and was successfully shuttling it through our vendor management process. When I checked in with her, she would give me some fairly generic responses like “it’s still with legal.” Then, the vendor started contacting me to see how things were going. These two clues in my gut, were they not ignored by my head, should have alerted me that things would end badly. They did. I spent an entire day, the day before the contract had to be signed, running around getting special favors from people who would not have needed to be bothered if I had paid attention the week before to the signs that things were not going as planned.

 Don’t surprise your stakeholders (ever!)
There are good surprises and bad surprises. But as far as stakeholders are concerned, there are no good surprises. Anything that is going to be a surprise to a project stakeholder should be raised as soon as possible and with as small of a group as possible. This requires a lot of extra work sometimes, but is almost always worth it.

 If there is bad news to deliver on a project, always try to do this with your core team members first and build out from there. I always try to deliver this news one-on-one, because this is the best way to let people react without embarrassing you or them and to brainstorm about solutions before taking it to the bigger group.

 This was the approach that I took on one large project until I got to the project sponsor. This project was scheduled to run significantly over budget, and we were in the process of going back to the well for more water, so to speak. I had done a lot of analysis and discussion with the core delivery team and one of our main subject matter experts. I sent this analysis to the main project sponsor prior to a meeting that we were having with him and the CTO – his boss. However, the sponsor was on vacation and getting back the day of the meeting. I didn’t alert him on vacation or even prior to the meeting that we were going to ask for A LOT more money – like $1M more. I didn’t want to disrupt his vacation and I had also assumed that he had looked at my analysis document and it was so good that he didn’t have any questions (see the example above for the funny sinking feeling… I had this, too).

 Needless to say, our sponsor was very surprised when he popped open the document and sat with mouth agape beside the CTO while I explained why we needed the extra money. Fortunately, I had a great relationship with the project sponsor prior to this meeting, so after it was over he asked me very nicely to never ever do that to him again. I didn’t.

At the beginning of a project, aside from the business stakeholders, there are typically two key project delivery team players making significant contributions to the project definition and progress: the Project Manager and the Business Analyst. On small projects a single person may play both roles. However, it is important to understand the distinction between the two roles, including the different deliverables generated by each role.

Business Analyst (BA)

In many cases, a BA is engaged on a project before a project manager. The primary responsibility of the BA is to understand the full depth and breadth of business needs for the project. Typically, the BA interviews a wide variety of business stakeholders, examining current business processes and tools and producing documents that describe the current and future state of those systems or processes.

The most important activity that the BA performs is to describe accurately and in detail, the outcome, or the product of the project. Usually, the product is best described through the delivery of one or more of the following:

• Business requirements
• Functional requirements
• User requirements
• Report specifications
• Traceability matrix

Project Manager (PM)

In contrast to the BA, the PM’s primary role is to ensure a project successfully meets the business requirements. A PM who runs a project well introduces appropriate processes and controls to promote the highest quality, most cost-effective, timely creation and execution of the product. In many ways, the PM is impartial toward the actual definition of the product or process. The PM does not (and should not) have a stake in whether the product is round or square or blue or red. But, the PM should be fully engaged in the processes to make sure that if the business stakeholders want a “blue square”, it will be the highest quality, lowest cost and most quickly produced blue square possible.

To do this, the PM typically delivers one or more of the following:

• Project charter
• Scope description
• Project plan with schedule, resource assignments and budget
• On-going and regular project communications about adherence to the plan (for example a status report)
• Risk planning and risk management documents.

Each role has a distinct function with different deliverables that contribute to the overall success of the project.

It is very common these days to hear people talk about multi-tasking. Many believe multi-tasking helps them to be more efficient, get more things done and generally be available to everyone all the time. Ready access to information through Blackberrys, cell phones, text messaging and e-mails perpetuate the ability to multi-task.

But numerous studies have demonstrated that multitasking — at least in the way that most people hope it will work — doesn’t really exist. Sure, most people can walk and chew gum at the same time as the old saying goes, but if you used your mouth to walk it would be significantly more difficult. The point being, when you start to use the same or even similar cognitive skill sets during multi-tasking, it becomes literally impossible to do two things at once.

For example, talking on the phone and reading email is not possible because it requires very similar verbal processing skills in your brain. Talking on the phone while driving, an activity that has been studied intensively by scientists and highway safety experts, is possible, but even that tends to severely degrade one’s driving skills. And many states are imposing significant penalties for texting and driving, because not only is texting a distraction because it requires concentration to think and type, but it also typically requires people to look away from the road. So, forget it, texting and driving is impossible.

Instead of excelling at multi-tasking, people are actually best at “task switching”. We are good at applying focus for short periods of time on multiple things, but this attention is almost always sequential. One 2005 study found that many people were interrupted at work approximately every 11 minutes. After each interruption, it took about 25 minutes to circle back to the original item. Frequent task switching can seriously erode productivity because of the time required to switch from one task to the next.

At one company I worked at one of our develops had stopped listening to her headphones at work. Initially, I thought it was an effort to concentrate more on her work and less on the favorite songs that were playing in her ears. But as it turned out, she had stopped listening to her head phones, because she couldn’t listen to a single song from beginning to end without being interrupted by someone in the company asking her a question! Considering that the average song is only about 4 minutes long, this poor woman really only was able to complete her work before the rest of us got there or after we left.

Project managers are the hub of all project communication and as instant communication technologies mature, there are more and more ways of distributing project information and equal numbers of methods for escalation of issues. Unfortunately, all too often the “instant” nature of communications in emergencies has lulled us into a sense of complacency about planning. Organizational culture is evolving in the direction that mass media has already gone; The timeliness of information is now considered more valuable than the quality of the communication. In other words, information that is partially correct or even wrong, delivered sooner is considered better than good, thorough and contextual stories that help us to think about problems and solutions. But these habits can breed other problems.
Take the example of a project that is experiencing a Web site outage. E-mail, text messaging, pagers and instant messaging communications can essentially indicate immediately to the team that there is a problem. For better or for worse, this typically leads to an instant response from everyone! If there is planning in place for this outage, which means that a) the team has considered before now that an outage is a possibility and b) they have planned how they will respond, then an instant response from everyone is likely to help the problem be resolved sooner. However, if the planning is absent, chaos is sure to ensue.
Everyone on the team will start to do what they do best. Technical people will likely start trouble-shooting to find solutions, project managers will think about communication damage control and the help desk will start updating the problem tickets. However, without a previously designed plan of action, it is likely that these activities will contradict each other and are more likely to lead to more problems and a longer outage.
Project managers should work to minimize their own “instant communications” addictions and instill these habits in the people on their team. For example, minimize the number of conversations and project decisions that are made via e-mail. (You may also win a prize for reducing e-mail storage capacity requirements for your company.) Provide project information in well-formated, predicable, contextual format, such as a weekly newsletter, status report or on a project Web site. Do this at a regular time each day or each week, so people will know when to look for information and will know that they can get a thorough and comprehensive view of the project when it is needed. This will avoid “getting pinged” about project information outside of regularly scheduled meetings and updates.
The more project managers learn about the successful use of different types of communication devices, the more successful projects will tend to be.

To learn more about our coaching and communication services, please visit What If Project