Saturday, July 28, 2012

Project Vision: Getting Into Focus

One of the many comments I have received on my blogs was regarding vision, specifically the “blurriness” that a Project Manager (PM) must contend with when beginning or during a project. One of the things I have learned is that a project must be aligned in some way with the organization’s strategy. No matter how small the project is, it must tie back to the strategic vision of the organization. Now, in a Professional Service Organization (PSO), a project will most likely be revenue generating, implementing a product, or providing consultative services. So in that case, the vision can be explained in that the PSO is delivering a service to other organizations. However, in a Project Management Office (PMO) or an Information Technology (IT) group that has its own Project Management  group, the vision for a project has to be defined in a project for the PM and the project team. So let’s take them separately.

Project Vision in a PSO
As I stated in my opening paragraph, project vision in a PSO should be straightforward. The PM has to keep focus on the scope of the project using the scope statement and statement of work (SOW).  The major issue that confronts a PM and the project team is scope creep. This is especially hard in a consultative environment, considering the users or client in the project team would most likely want to stretch the funding of the project as far as it can go. This is only natural and should be expected by the PM of the project. What I have found effective is to review the SOW and the scope statement at project kickoff, reviewing what is in scope, and stating for the record that everything else is out of scope. During the project, with the Risk and Issues list and the Status Report as tools, the PM must keep the project schedule on track.
Project Vision in a PMO
In a PMO, one must ask:  does this project directly or indirectly tie into to the organization’s strategic vision? The PM and the PMO lead must ask this question before committing to take on a project. If the project does not, then the PM begins the project with the knowledge that this project is not a strategic one and the resources provided may reflect that knowledge. The PM must be responsible and provide a project schedule that reflects the importance of this project.
If the project is strategic, then the PM may be provided the resources that reflect the necessity of implementing this project and ensure that that scope creep (similar to a PSO project) does not rear its ugly head. However, it should be noted that there is a different dynamic with the project team from a PSO project. In a project run by a PSO, the PM should strive to make the client or users in the project team the champions of the project. In a PMO project, or a project that starts from the strategic management of the PM’s Organization, the PM should make the project sponsor the PM’s best friend. This person holds the purse strings and usually has some members of the project team reporting to them. Once a project begins to enter a yellow status, the project sponsor should be one of the first to be notified by the PM.

The scope statement and the SOW should also be used by the PM to ward off any scope creep that other project team members attempt to bring into the project.  These documents should be the PM’s most reliable asset. If the PM must re-emphasize the scope of the project to the project sponsor, there is no better tool than a signed SOW, especially if the SOW has been signed by the project sponsor. I find this is a task that a PM must do continuously in a PMO project.
Conclusion
The PM walks a tight-rope in keeping the vision of a project, whether it is a PSO or a PMO project. The scope statement and the SOW are the PM’s best tools to keep the vision of the project. Remember that the dynamics of the two projects may be different, particularly in the members who make up the project team. Reviewing the SOW at the project kickoff is a good tool and is strongly recommended.
If you would like to comment about this blog, please do so by responding in an email at Benny A. Recine, or if you would like to publicly comment in this blog. I will respond as soon as I can and you may inspire a blog article.
My next blog will be about conflicts in a PSO. Until then, be well.

Sunday, July 15, 2012

The Tools of Communication – Part 4 – The Remaining Reports

The next several reports are not “critical” communication tools but are important. Since some of the documents that I discuss below may not be used in a project, I thought it best if I included them in one article.
Meeting Minutes
This report seems to be the most controversial of all the reports involved in a project. The controversy revolves around who will take the minutes. Until recently, I have advocated that the Project Manager (PM) or the Business Analyst (BA) of the project team take the minutes. With my recent association with Professional Service Organizations (PSO) and Project Management Offices (PMO), I have come to the conclusion that the most important document from the team is the Risk and Issues List. If the team is focusing on the meeting minutes, then the project member taking the minutes most likely may not participate in the meeting. Since there are multiple formats of the meeting minutes, I will not comment on the actual document. I will however suggest that if the Risk and Issues List is properly documented, then the “minutes” can be taken from there. If the meeting minutes are taken, it is my opinion that the duties of the “scribe” should be shared by the project team so no one person will always be taking notes.
Project Risk Document
The Project Risk document should be developed as soon as the project is approved and given to the PM. This document is an identification and ranking of the risks. This document should include both qualitative and quantitative analysis and should rank the highest risk to the lowest. Also, this document should contain the possible resolution of the risk if it becomes a reality. This document should be started by the PM and then reviewed by the project team members to comment on and possibly come up with solutions. The high risk items in this document should be reviewed by the project team on a regular basis and risk items should be added to the document as appropriate.
Communication Plan and Contact List
What’s the difference between the communication plan and the contact list? The contact list is just a listing of individuals, their role in the project, and their contact information. However, a communication plan develops an approach to communication during the project. This is not just the number of status meetings the project should have, but also identifies who should be involved in the status meeting, who should receive the Status Report and Risk and Issues List and so on.  Also, and just as important, if there is a show-stopper issue, who do you call first?
The Project Schedule
The most misunderstood document of a project is the Project Schedule, which is sometimes called the project plan. The project plan includes all of the documents of the project, including the budget. The Project Schedule is the tasks and their duration, resources associated with the task, and if the task is on the critical path. This is the full-view of the project, from initiation to project closure. This is the document on which earned value calculations are done.
Vacation Schedule
Most PMs will enter the vacation schedule of the project team in the Project Schedule. This is a necessary document for the PM to have. However, a separate document that all project resources can access and update is also necessary. All project resources have to be aware of the vacation schedule of the team.
Where does all this documentation go?
In this era of emails and attachments, it is necessary that all documents go in a central repository. The tool to create this repository is up to the management of the PSO, PMO, and the organization.  This repository must allow access management to all project resources. There are several options to use, even an actual cabinet if the team is collocated. Whichever way is used by an organization, the method of filing must be consistent with every project.
In my next blog, I will discuss vision in a project. This was a request from one of the many emails I have received from my blog postings. Please keep them coming by sending them to Benny A. Recine.

Saturday, July 7, 2012

The Tools of Communication - Part 3 - The Status Report

There is no other communication tool that management likes better than the Status Report. It is a two-page view of the status of the project. It is very clear and unambiguous in its communication; the project is green, yellow, or red. There is no confusion in that message. What is sometimes confusing is the explanation of a yellow or red status. Below, I will discuss how to make the Status Report the most understood report in a project.


 The Status Report
The Status Report, sometimes referred to as the “Red, Amber, or Green (RAG)” report, is the most common report on a project. In one or two pages (no more than two), this report should provide the project team and senior management the entire picture of where the project stands. However, its brevity is as important as the message that is conveyed. In addition, one of the most important rules in project management comes into play here: no surprises.
If the project is green, or on track, the message should be short and to the point, summarizing what will happen next and which risks will be closely watched in the upcoming period. This is the easiest communication a Project Manager (PM) has to deliver.
If the report is amber or yellow, then the report may be two pages. This report must elaborate why the project is yellow and what will be done to bring the project back into green status. This is where the PM should be specific on what is needed from senior management, the project sponsor and the PM’s Manager (the PM would have discussed this with them prior to the publishing of this report). Most likely, a change order will be needed. This must be presented to the Change Review Board, of which senior management would run or be a participant of.
If the report is red, the PM must communicate critical information to senior management and the project sponsor. The PM would have already warned the project sponsor, senior management, and of course his manager (the PMO and PMO Lead), but the report must detail:
·         The specific problem
·         The solution to the problem
·         How much this solution will cost in time, resources, and scope
After the problem is corrected, there should be a discussion regarding why this problem happened. Questions to ask include:
·         Was the problem flagged as yellow first?
·         If it was, why couldn’t it be resolved then?
·         If it wasn’t flagged as yellow, why did this problem “creep” up as red?
·         Who was responsible for this task(s) that became red?
·         Does this person (for example, an overwhelmed developer) need help, or did the customer miss deliverables they were responsible for?
The problem must be studied separate from the project work and be resolved. If the PM was “blind-sided” by this problem, then he or she must resolve the communication breakdown immediately.
Next
As I have mentioned in my last blog, I look forward to any and all feedback on this article. I ask you for feedback because in my next blog I discuss the remaining documents that are common during a project: meeting minutes, the project risk document, the communication and contact list, the project schedule, and the vacation schedule.
As we continue in these discussions, you can provide your opinion on the specific article or section within the article. I will respond to you via email Benny A. Recine and possibly consider it a topic for another blog.

Sunday, July 1, 2012

The Tools of Communication – Part 2 (2)

The Risk and Issues List – Redux
I have received a number of comments on my blogs. One comment was about vision and how to instill it in the project team. I intend to address this topic in a future blog. I will also be writing about delivering bad news in a future blog.
 In my last blog, I discussed the Risk and Issues List as the best document to communicate items in the project to the project members and stakeholders. One of the comments I received was to expound my views on how to present the risks and issues. Basically, this person believes that communication is sometimes the great equalizer of the actual content and that management never likes surprises. I couldn’t agree more that management never likes surprises and that communication is not only the equalizer, but the main reason why projects fail. So the way a Project Manager (PM) communicates this document to management is critical.
Communicating the Risk and Issues List
The most common ways to communicate the Risk and Issues list are: 1) via email and 2) in the actual status meeting. The mistake PMs make is that these are the only two ways they communicate the Risk and Issues list.  Earlier I mentioned that management NEVER likes surprises. A common mistake that PMs make is that they believe that everyone reads their emails. If a PM must communicate bad news, especially an issue from the Risk and Issues List, the PM must first discuss the message with their management and then the project sponsor. These may be two different types of communication, so let’s take them one at a time.  
Delivering the Risk and Issues List to the PM’s Management
Let’s face it, the PM’s Management is more concerned about the status report and that it stays green or on course.  However, as I mentioned before, probably the more important document is the Risk and Issues List. The two documents should refer to each other and be presented as one: the status report as the summary document relating to the project and the Risk and Issues List regarding any risk or issue. If it’s a risk, the status report can refer to it by mentioning it when summarizing the phase the project is in (initial, project planning, execution, control, or close). If it’s an issue, then the issue on the Risk and Issues List must be well documented and self-explanatory. This makes it easier for management to understand and to react if the project sponsor calls on the PM’s Manager. This is the most important communication the PM has in a project: ensuring that his management is fully informed and armed with the correct message.

Delivering the Risk and Issues List to the Project Sponsor Prior to the Status Meeting
Prior to the project status meeting, the PM may want to have a separate meeting with the project sponsor if there is an issue that needs to be explained in detail. This isn’t always bad news, but if not treated and delivered properly by the PM, it can easily become bad news quickly. What I mean by this is that sometimes an email cannot communicate the issues properly and the project sponsor may not understand the communication from the PM. I strongly suggest that the PM speak to the sponsor one-on-one, preferably in person, or schedule a separate call with the sponsor prior to the status meeting.  With this communication, the PM can fully explain the issue or risk properly and not “blind side” the sponsor.
What the Risk and Issue List Can’t Communicate
The Risk and Issue List cannot communicate the status of the project, which is my next blog. I do expect more comments on this blog and as I have done in this blog, make your comments another blog topic. Thanks again to the person who made this comment on communicating the Risk and Issues List.  If you would prefer to email me instead of leaving a comment, please do so at Benny A. Recine.