Tag: project communication

PM as Leader

One aspect of being a PM that a lot of people overlook is the fact that the PM is in charge of all activities of his/her project. Some people have the idea that the PM just takes care of check lists and scheduling status calls. However, there is a reason that the word “manager” is in the title.

The PM is responsible for the success of his/her project and if a proper charter or SOW has been singed, he/she has been given the power to make decisions about the project and the team that is under him/her. Of course if you are in the situation where you do not have a charter or SOW signed, then you probably should be running away from that project as fast as you can. But that will be a post for another day.

OK, so now we have established that a PM receives power over a project from another authority, such as an executive of your company or the customer you are providing services to. That power is transferred in the signed document that allows the project to have existence. This power now gives you the authority to assign resources and expend budget as you see fit to meet the goals of the project. You are effectively the leader of the team.

With great power comes great responsibility. That means that the buck stops with you. Because of this, you need to be aware of and a part of all decisions that are made, all schedules that are set and all work that is performed. The best way to make sure you are in the loop is to publish and review with the team and stakeholders a communication plan that shows who needs to be informed in various types of communication that may take place in the project.

In small projects, where there is only one or two resources in play, this is simple and can be communicated in the kickoff notes. On larger or more complex projects, you might want to use a RACI chart. RACI is an acronym that stands for responsible, accountable, consulted and informed. A good discussion on RACI charts can be found at HOW TO DO RACI CHARTING AND ANALYSIS: A PRACTICAL GUIDE ~ By Royston Morgan.

Ok, you have the authority, you have established that you are the leader, you have communicated the process for getting things done. Everything should go smoothly and usually does. But, every once in while someone (manager, sales person, resource, etc.) will decide that they have something that needs to be done and will direct someone on the team to do execute some action and not inform you. Hopefully, the resources on your team will let you know when this is happening.

When this happens, you need to have a private one on one with the offending party. The discussion needs to emphasize that there can only be one leader in the project communicating actions to the team.  If directions are coming from multiple sources that are not in sync, then confusion will be generated and project can go south quickly. Let them know that if something is needed, they only need to let you know and you will take care of making it happen.

The point is that as the leader you need to defend your turf for the good of the project.

Gantt Charts – Double Edged Sword

Anyone who has done PM work is familiar with a Gantt chart. It is a wonderful combination of text and graphics that lets us see dependencies, durations and start and stop dates. It is a very useful tool for planning and tracking your project – but it has a dark side as well.

First conceived in 1896 by Karol Adamiecki but first popularized by Henry Gantt around 1915, the chart was a labor intensive means of visualizing the flow of a project and the relationships between tasks and milestones. Every time a change was made in any aspect of the schedule, the whole chart would need to be manually re-drawn. Not until the advent of software to take care of updating and changing the chart did the Gantt chart become widely used.

The software I have used often to plan the execution of projects over the years is MS Project. There are other software tools just as capable but my experience has been limited to MS Project. I don’t believe this will invalidate any of the ideas I will be expressing in this post since it addresses the perceptions surrounding Gantt charts and the strategies of their use.

Because of the wide use of this type of software, the past three decades have seen Gantt charts become a common and often an expected document in status reports to management and other stakeholders. In my mind, the Gantt chart is not meant to be a status reporting tool, but rather it is a planning and tracking tool to be used by the PM and his/her team to manage their activities. This misuse as a reporting tool has lead to a couple of perceptions that I find problematic.

The first perception that goes against the grain of those of us who understand the technical details of project management is the idea that the Gantt chart is “The Project Plan“! This is far from the truth, since the Gantt chart represents only one aspect of a total project plan, the schedule.

A project plan is made up of many parts that cover not just the schedule but such things as the communications plan, risk plan, resource plan, scope definition and all the other items that make up a total project plan. Calling the Gantt chart a project plan puts too much focus on the schedule and can lead to misunderstandings and incorrect perceptions of the project.

The second perception that causes problems, is the fact that people perceive the schedule presented in the Gantt chart as immutable and set in stone. Maybe this would be true if we PMs had access to a crystal ball that could tell us all the things that we will encounter in the execution of a project before we started. But since such a thing does not exist, the expectation that a Gantt chart does not change is unrealistic.

The Gantt chart is, as I said earlier, a tool for planning. As such, it is used to project what our current knowledge says should be the schedule. With new knowledge gained – as we uncover things we did not know earlier – we are able to use the tool to see the effects of this new knowledge. Since the Gantt chart depicts the work efforts and dependencies, it allows us to see the impact of changes and thus allows us to adjust our plans to react appropriately to the changes.

Due to the above perceptions, I have a few strategies I use when dealing with Gantt charts.

  • First, I make an effort to refer to it as a schedule, not a project plan.
  • Second, I try to avoid using the Gantt chart as a part of a status report.
  • Third, in those situations where I must provide a Gantt chart style of reporting, I will create a high level chart that excludes specific dates and shows durations over periods of weeks or months.

I would be most interested in hearing from you on how you view the use of Gantt charts. I am sure there are other strategies and views on this subject that I could learn from.

Just the Facts

In my previous post I talked about how to deal with mistakes that I as a PM make. A sometimes more difficult situation, is dealing with mistakes others on your team (coworkers or customers) make. The general approach is the same as for your own mistakes, but must be handled with more delicacy.

Humans are complicated creatures and they each develop their own particular view of themselves and the world around them. When someone makes a mistake, a broad range of reactions can be observed. Some cannot admit to making a mistake and will react with denial and even push the blame to someone or something else. Others are mortified that they made a mistake and will punish themselves to the point of becoming unproductive or withdrawn. There are many other reactions that are exhibited besides these two, but I will not go into them at this point. Just suffice to say that most of them are bad in some way.

Talking about others mistakes in a public forum will amplify these reactions and usually result in defensiveness, arguments, name calling and sometimes hanging up on the call or storming from the room. All of these scenarios are bad for the team, bad for customer relations and bad for the project. However, anything in a project that affects scope, schedule or budget needs to be documented, analyzed and reported. How to do this with minimal impact to the inter-relations of the team mates and stakeholders is the meat of this post.

Let’s say the scenario is a data center move is scheduled for a weekend and all systems needed to be back up and fully tested by Monday 8 AM. While bringing the systems back online, problems were encountered where critical applications were unable to connect to their data sources. This results in the whole team working day and night, Saturday and Sunday and on into Monday. The problem is not resolved until 10 AM on Monday. It turned out that two mistakes were made in the network configuration having to do with a route statement and a firewall rule. A single person was responsible for the configuration of both items.

The crucial things to remember when reporting or discussing the mistake is to stick the facts and keep personalities out of it. In this case I would report in my status that “An incorrect configuration in the firewall rule was detected and corrected and a route statement adjusted to the correct route.” Note that no one was named as being at fault. This is as it should be. All humans make mistakes and there could be extenuating circumstances such as the person responsible could have been working for 24 hours straight when the mistakes were made.

The followup postmortem would concentrate on the nature of the failure and that it was human mistake and not that Joe fat fingered the commands. We would then move on to a quality control plan to provide some kind of check and balance for future actions.

The important points to keep in mind are:

  • Stick to the facts
  • Keep personalities out of the discussion
  • Make no judgements

I would be interested in any comments or feedback you might have on this post. Please take advantage of the comments section below. Your email will not be used for anything beyond helping me combat spam.

Dealing With Mistakes

Recently, I screwed up. On a simple install I set an expectation with a high-profile customer  that was completely out of scope. Offline, the engineer and SE let me know the extent of my blunder. It was going to open a black hole of services that we would not get paid for. Crap! What do I do now?

My mind races going through the various scenarios that could ensue.

I could just ignore it and hopes it goes away. But, that is not likely, since the customer now has an expectation that he will be anticipating.

I could throw my hands in the air and quit this job. But that won’t work either. I need the income and I like what I do.

I could pass it up to a higher level to be dealt with. Again, that is not a good solution since I am sure management would not be pleased and besides, I made this problem and I should be the one to fix it.

But how?

We, as PMs, we are charged with leading the project and making sure all of the stakeholders needs are addressed and if possible, satisfied. People expect us to know what we are doing and not to make mistakes. But alas, we are only human and we make mistakes. The more experienced you are the bigger your mistakes are when they happen – and they will happen. I have found that there is only one way to deal with this.

I got on the phone with the customer and explained that I had not understood the simple addition of task that I had said we would do had a lot more baggage attached to it than I had been aware of. There were design and troubleshooting aspects associated with the task that would take us way out of scope and really should be addressed as a separate project. The customer was not happy to hear this but after some discussion he accepted the situation and my apology. The next day on the status call, I explained the situation to the whole team and we are now moving ahead on the simple install within scope.

The fallout from all of this is not as bad as I had thought it might be. In fact, the customer is now seeking more professional services from us to help implement the added scope. Prior to this, he had been looking at doing it on his own.

This experience reminded me of things I have learned over a number of years dealing with customers.

  • Don’t let issues fester. Deal with them as soon as possible.
  • Honesty is always the best policy.
  • Admit to and take ownership when you make a mistake.
  • Many times a problem can turn into an opportunity.

Let me know what you have done to deal with mistakes. There are always more than one way to deal with them.

Noted – I Heard What You Said

Meetings are an everyday part of a PM’s life. We have meetings to align a team’s efforts, receive reports on work done, issues encountered, risk uncovered and to make plans for our next steps. Those plans will include schedules, action items, roles and responsibilities, coordination of work, etc. After an hour of discussion, there are a lot of details to keep in one head. To come away with useful information, someone must distill it all down into concise, readable notes.

Continue reading Noted – I Heard What You Said

Email Communication for Project Delivery

Managing the delivery of IT PS on a number of projects daily requires that I use email to stay in touch and direct execution. Because of this, I have evolved a methodology that is focused on getting not only the message across, but also eliciting the response needed from those receiving the message. Continue reading Email Communication for Project Delivery