Saturday, June 23, 2012

The Tools of Communication – Part 2

The Risk and Issues List
It is well known that the SOW is the primary document for every project, especially in a PSO. It is the legal document that defines what is in, and most importantly, what is out of scope. However, a document that is just as important is the Risk and Issues List. I say that they are equal in weight of importance for two reasons: 1) The SOW states what is in and out of scope, and 2) The Risk and Issues List ensures that scope creep does not begin in the project. As a matter of fact, the PM should have the SOW when beginning a Risk and Issues list for definition’s sake.

Let’s quickly define a risk and an issue. A risk is a possible issue that MAY happen. An issue is a risk that HAS happened. The level of importance of each can be defined as critical, high, medium, or low. If an issue has a critical status, that issue must be resolved.
Now, some say there should be a Risk List and a separate Issues List. I do not have any argument with that except this one: Who is your audience? If your audience is management or your project sponsor, do you really want to inundate them with more reports to review? I believe that a Risk and Issues List that correctly combines them, documents each risk or issue appropriately, includes the name of the person who is responsible, and provides a date on that risk or issue, properly distinguishes the two separate items. You want to keep the report as “thin” as possible, with the correct amount of information needed by senior management. This is not easy, but it is very necessary.

So, what are the important ingredients in a Risk and issues list? Each item should have the following:
·         An item number
·         The current date of the update to that particular item
·         The level of importance – critical, high, medium, or low
·         The description of the issue/risk. This can be detailed or can have supporting 
      documentation attached to it
·         The person/group who reported the issue/risk
·         The person/group responsible for the resolution of the issue/risk
·         The current status of the issue/risk
·         The date the resolution is due for each issue
How do you communicate from the Risk and Issues List?
The Risk and Issues List can be used as the second tool during a project status meeting, after the status report. The PM can introduce the Risk and Issues List by first discussing each risk quickly based on the level assigned to the risk. Then the PM should discuss the issues. If there are more than three issues, the PM may take the majority of the meeting discussing these issues and how to resolve them. The steps involved are dependent on the level given to each issue. If they are critical, then the PM must get the PSO’s management involved. If they are not resolved, they can keep a project in red and delay its completion. If they are high, the issue may have a short term work-around until a solution is delivered. Low and medium issues are usually product deficiencies that the product management team of the PM’s Organization must address.

The Risk and Issues List must not be viewed as the document that brings the meeting to a halt. With the Status Report, it can be used to move the meeting along smoothly, as long as the risks and issues are defined and described well.
Our next report of communication is the Status Report. However, I do look forward to your comments on the Risk and Issues List.

Saturday, June 16, 2012

The Tools of Communication - Part 1

Wikipedia defines communication as the activity of conveying information. Communication requires a sender, a message, and an intended recipient, although the receiver need not be present or aware of the sender's intent to communicate at the time of communication. Thus, communication can occur across vast distances in time and space.

Well, this definition can also describe documentation from a Project Management Office (PMO) because in a Professional Services Organization (PSO), communicating to our clients is the ultimate responsibility of the Project Manager (PM). The communication between a PM and the customer is extremely important. However, what is more important is that whatever communication is provided, that it is documented. There is an old axiom of project management: “If it is not written, it was not said.” If it is stated, even if the customer or another project team member disagrees with certain statements that may be amended or not, the conversation must be documented.
The issue that arises is how much documentation is enough? We do not want to burden a PM with so much documentation that the PM has no time but for documentation. However, one must define which documents are necessary and which documents are “nice to have.”  I believe there are some critical documents that communicate essential project information and each have their place during a project.

In my next several blog articles, I will discuss the tools that are necessary to have a good and proper line of communication, not only with the project team and project sponsor, but also with the PM’s management.  I look forward to your comments in regards to this and my next blog articles.