More on Project Communications Plans

As I’ve been stating recently, I feel it is necessary that both new and old project managers have access to as many potential processes and templates as possible – especially those working as consultants that may be acting outside of PMOs with their own processes and governing policies.

I’ve previously posted the article entitled “The Project Communications Plan” and have supplied actual communications plan documents to many readers over the past few months. The offer still stands – email me if you want a copy.

Carl Pritchard presents nice information on the details and uses of the project communications plan in his book “The Project Management Communications Toolkit.” For the benefit of our readers – mainly to give you different perspectives and templates to choose from, I am presenting Mr. Pritchard’s outline below.

The Communication Plan Defined

Purpose

The communications plan provides direction on which stakeholders should be discussing project business with which other stakeholders, the tools they should use, and the degree to which they should be sharing, documenting, and storing that information. Because of the number of stakeholders involved in a single project and their diverse roles, the communications plan orchestrates project communication through a cohesive approach to information sharing. It is a critical deliverable to the planning process.

Application

The communications plan is shared openly with all internal project stakeholders to help them understand how they should communicate and with whom. For external project stakeholders, the communications plan is normally filtered to present information only germane to their role and use.

Ideally, the list should be built in a spreadsheet program that allows the user to filter stakeholders by communications modes, contacts, frequency, or other category as appropriate.

The communications plan should reflect communications as dictated by the contract, memorandum of understanding, or statement of work, as well as any other protocols that became self-evident during the project’s evolution. Different project participants will use the communications plan in different ways:

• The project manager uses the communications plan to ensure that the various stakeholders are aware of their communications responsibilities to each other and to the organizations.
• Team members use the communications plan as a combination contact list and guide, with an interest in the types of communication preferred by the various users.
• Senior management and customers may use an abridged version of the communications plan to be clear on when to expect certain reports and documentation, and for contact information on their primary points of contact.

Content

The communications plan is a matrix of information, normally built in a spreadsheet program with the following data:

• Stakeholder name
• Primary contact
• Secondary contact
• Telephone
• E-mail
• Postal mail address
• Preferred communications mode
• Best time
• Frequency of communication

Because it is built in a spreadsheet format, the communications plan can be sorted and reordered in a variety of ways. If the types of communication (status reports, team meetings) are most important, they may be the first column, followed by frequency of communication and stakeholders (recipients and attendees, respectively). If physical proximity is an issue, the primary consideration may be the postal mail address, which can be sorted to determine which stakeholders are in common regions or locales.

Because communications breakdowns are frequently rooted not in miscommunication, but by a lack of communication, the notion of the “best time” for meetings, reports, contacts, and phone calls is crucial. If certain team members can only attend project meetings before 3 p.m. because of personal concerns, the project communications plan should highlight those interests. If a customer is never available before 10 a.m. for phone calls, such concerns should be noted as well.

Approaches

The communications plan is one of the most publicly available of the project documents. Because it serves as the framework for open communication among team members, the customer, and other stakeholders, complete and abridged versions of the document may exist, depending on the audience. If varying versions are used, some form of version control (e.g., 1.0 = complete plan, 1.1 = customer abridged, 1.2 = management abridged) should be applied.

The communications plan serves as more than just a phone directory. It provides information on the communications sensibilities and sensitivities of all of the personnel involve.

Considerations

While the plan is widely available, some stakeholders are proprietary about their contact information, and those concerns need to be respected. The communications plan should not become a medium for those who wish to broadcast information randomly to all project parties. It should be used to focus communications on an as-needed basis.

The Project Business Case

Every project needs a business case. This may be informal – especially for small and/or internal projects. It may also be very formal, as is likely the case for very large and very visible projects run for customers outside of your organization. In most cases, the customer has put together a business case in order to gain their own funding for the project. In some cases, they’ll need your help – as the project manager – in putting together the project business case and thus justifying the project and associated expenses to others within their organization.

Below is Carl Pritchard’s take on the Business Case documentation as outlined in his book “The Project Management Communications Toolkit.” I found it to be an interesting read and hope that some PMs find this of value on the projects they are working or getting ramped to work on.

The Business Case Documentation

Purpose

The business case establishes the fundamental rationale for a course of action. It is the documented history of why a project, effort, or approach was selected. It details the objectives, the projected outcomes, and the projected investments associated with the effort. As such, it allows decision makers to examine the breadth of information currently known about the effort to determine whether or not the project is a good idea in terms of cost, benefit, and organizational objectives. It may include statements about the impacts on existing business practices, resource constraints, and environmental considerations so as to provide a comprehensive understanding of the project. In some instances, risk analysis is a key component. It is the primary document defending the rationale for the project.

Application

The business case is normally applied early in the project and may be developed by senior management, marketing groups, the project office, or by any group or organization responsible for initiating large-scale activity within the organization. Business cases in mature organizations follow consistent formats to allow managers to review multiple projects in similar contexts.

The business case will list the key proponents of the project, the sponsor, the users or beneficiaries of the project, and any deliverables. At a high level, it will describe the approach to be used and the business justification or rationale for that approach. Normally, that rationale will incorporate some form of cost/benefit analysis, although the types of cost/benefit analyses and their applications vary widely.

A general outline for a business case might look like this:

• Executive Overview
• Project Description
  • Proponent(s)
  • Sponsor(s)
  • Users/Beneficiaries
  • Deliverables and Quality Criteria
  • Rationale
  • Cost/Benefit
  • Schedule/Time Frames
  • Communications and Reporting Requirements
• Environmental Considerations
  • Project Development Environment
  • Project Implementation Environment
  • Organizational Processes
• Risk Factors/Risks
  • Risk Management Approach
  • Preliminary Risks Identified
• Assumptions

Content

The information supporting each of those outline components should be developed as objectively as possible. To achieve that, each element should be reviewed by at least one other person. The content may be expanded (or compressed) based on the business needs of the organization conducting the analysis. At a high level each section should contain the specific information discussed in the following subsections.

1.0   Executive Overview

The executive overview is a general scope statement identifying the time, cost, and requirements for the project, as well as the business need driving the effort. It should include the names of the project sponsors and project manager, as well as a description of the beneficiaries of the effort. The executive overview should provide a synopsis of the cost/benefit analysis, regardless of whether those costs and/or benefits are tangible or not.

2.0   Project Description

The project description should provide more depth on most of the issues raised in the executive overview, including the background, sources, and history for any data provided as rationale for the project or the cost/benefit analysis. This section may include cross-references to other project documentation, including draft plans, product descriptions, and stakeholder analyses or surveys.

3.0   Environmental Considerations

The cultural, technical, or physical environment may described here in depth, providing information on the practices and protocols typical within the environment.

4.0   Risk Factors/Risks

The risk approach described here may include the means and practices to

be employed for risk identification, qualification, quantification, response development, contingency allocation, and risk reassessment. Any initial or signifi

cant risks identified in developing the preliminary information (like the cost/benefit analysis) should be identified here as well.

5.0    Assumptions

Assumptions are beliefs that are held as true to allow for ongoing planning. In an effort to ensure that they have value, assumptions identified here regarding all aspects of the project (resources, environment, client culture, organizational behavior, and so on) should be validated as practicable.

Approaches

Business cases in some organizations may be voluminous and detailed. Others span only a page or two. Regardless of the level of depth, they should provide insight into the considerations that were used to determine if there is a valid business reason for moving forward with a project. They should be directed at an internal audience, because they may include information about the internal response to and structure for the customer relationship. The internal audience should, at a minimum, include the project sponsors, the project manager and executive management.

Considerations

Because the business case may contain sensitive competitive information, it should be disseminated only to those who have achieved a level of trust within the organization. The author of the document should be clearly identified, and contact information for that individual should be included as well. Although the business case is an initiating document, it should be reviewed and revisited on a regular basis to ensure that the cost/benefit analysis and proposal are still being pursued.

CIO Budget Dilemma: How to Choose Which Projects Live and Which Projects Die

This is a great article written by Howard Anderson for InformationWeek. Howard gives some very straightforward insight into how to quickly decide what projects to hang on to when you’re faced with a critical IT budget issue. I like his style of writing and the content is great…please read on….

Project Triage: Skippy Must Die

You have a problem. Your project budget has been decimated. The suits are under serious budget pressure and are mouthing expressions like “shared pain,” which is never what you want to hear. So you’ll have to decide what lives and what dies. Further, some of your best people are on projects that will never see sunrise. Did I mention that there are some Sacred Cows out there protected by their Godfathers, but which should logically die? Can you figure out which Godfathers are on their way out?

This isn’t about technology; it’s about management. And you need help to plow through this mess to get to a point where you can do the fun part: showering money on sexy things that will wow Mahogany Row and drive business forward. But now is no the time.

Some of these projects are “strategically important” but might not survive the bloodletting – is there a way you can hide them? Some of these projects have so much management attention that you are not kill them, but they should mercifully be put out of their misery, because either they’re never going to work or the real cost is three times what anyone thought. Other projects made sense at the time but don’t now. Want to take that Big Write-Off now? Not such a good time.

Want to play company politics? Very risky. Ignore politics? More risky. This isn’t the time to bet your job. Here are Howard’s Rules:

• Find a common enemy. Maybe it’s the economy. Maybe your company is at a crossroads. But use the common enemy argument to kill obvious losers. Kill any project where the ROI – and you know how to fudge those numbers – is more than two years out. Kill projects where the resultant savings/benefit cuts over multiple cost centers. Kill projects whose justification is flimsy, like they will save everyone 6.3 minutes per week.

• Move your best people into Safe Harbors, projects that can’t be killed, even if those projects aren’t quite as much fun or challenging. A great programmer is worth 10 average ones. A great project manager is the difference between on time, on budget” and Excuse City. Yes, you may lose a few people, but you’ll live to fight another day.

• Protect projects that keep the lights on and will carry you to a better day. There’s a tendency to put off upgrades until “next year” – but next year may be worse.

• Find projects to throw under the bus. You must show that you are a Team Player, so know what you want to kill and why. Smart CIOs will start to move their deadwood to those projects, so when they get killed, the people you’d like to go will go with them.

• Get the operating divisions to kick in some of their budget to the Sacred Cows. That will force them to choose.

• Keep one or two Knock Your Socks Off projects. You need to retain a little sex appeal to give hope to the superstars. Do as little as possible as loudly as possible.

• Pass out enough sugar to international so they don’t feel completely neglected.

• Combine projects where possible.

• Realize that what you’re buying is Time. You just don’t have the budget you thought you did. Some projects must be cut to zero. And they must be cut right now.

This article was written by Howard Anderson for the March 14, 2009 issue of InformationWeek.

Project Success Series: Delivering a Workable Solution

We are now ready for the final article – at least for now – in my Project Success Series. As with any blog, I reserve the right to come up with new content to add to any series like this so consider yourselves forewarned.

To recap, the premise here is that there are four main questions that your company CEO could ask you concerning whatever highly visible or mission critical project you are currently managing or just completed if you were to run into him in the hallway. Understandably, since this is your CEO, it is best for your career if you can be ready with meaningful and accurate answers to these questions and the proof to back them up. These questions are:

• Was the project on budget?
• Was the project on time?
• Was the customer satisfied?
• Did the project deliver a usable solution?

Part 1 dealt with the question concerning whether or not your project was on budget. In Part 2, we dealt with keeping your project delivery schedule on track. Part 3 dealt with the concept of customer satisfaction.

Now in Part 4 we will cover the concept of delivering a workable solution to the customer. And not just one that is bug-free, but a solution that the customer wants and needs and it’s your job to deliver that even though we all know that the customer often isn’t truly aware of what it is they actually need. Frustrating? Yes! Let’s discuss ways we can ensure that we’re delivering the best possible solution for the customer.

Never Assume the Customer Knows What They Want

I’ve covered this one elsewhere, but it’s an easy trap to fall in to. After all, they’re the customer and all we have to do is build to their requirements, right? Wrong! Be sure to ask the right questions up front and don’t be afraid to ask the customer to go back to their end users and SMEs and make sure that they understand what the final solution really needs to be. Many times though don’t truly know that when the engagement starts. If that is the case, one of two things happens:

• It becomes apparent part way through the engagement and then the customer is faced with change orders, a stretched out timeline, budget overruns due to re-work, and a lot of frustration for both teams.
• It doesn’t become apparent until deployment when the end user finally gets their hands on it and it’s not what everyone dreamed it would be. Sure, you built to the customer specs, but the lasting legacy is that the customer has an unusable solution and the finger often gets pointed at you and the delivery team.

Assemble a Skilled Delivery Team

As with any engagement, the more applicable skills your team has for delivering on the engagement, the better chance you have for success. With a good SOW and detailed requirements, you’ll know what skills you need. Fight for those with your management and work hard to keep that team engaged…meaning manage the schedule tightly, etc. Less ‘down’ time during the engagement means less likelihood you’ll lose skilled resources to other projects.

Don’t go overboard acquiring the best skill set in each area of need if that’s unnecessary because you’ll end up costing the project extra $$ that aren’t necessary. Protect profitability by going after the right skill level for the need and then work hard to manage the resources well and keep them engaged on your project.

Track Requirements As Though Your Life Depended On It

During Exploration and Design, map out the customer requirements well using a Requirements Traceability Matrix (we’ll cover that in another article) and manage those requirements closely. Keep track in the matrix of where those requirements are implemented in the final solution. Missed requirements mean a solution that doesn’t match your customers documented needs.

Test and Re-Test

This is an easy one. Have the customer build their own test cases and also use those during your own system tests prior to UAT along with your own test cases. Make sure the customer has solid, knowledgeable resources engaged for the User Acceptance Testing (UAT) sessions and definitely get their signoff on UAT once it’s completed.

A well-tested system goes along way in ensuring that the delivered system will work for the customer.

CYA – Get All Signoffs Just In Case

This one can’t guarantee that the customer is getting what they want, but it does help guarantee that even if they don’t, your butt is covered. Signoffs on requirements, UAT, and deployment go along way in removing blame from you if the shoe drops. Not that we ever want an unsatisfied customer. But the only thing we want less than an unsatisfied customer is an unsatisfied CEO or PMO Director who signs our paychecks. Get signoffs…you’ll sleep better at night…I promise.

This concludes my Project Success Series…at least for now. I’d appreciate hearing your comments and any additional areas that you think should be included.

Project Manager Needed

Location: Malaysia
Salary: £80000 per annum
Company: Leap 29 Ltd
Sector: Oil / Gas / Power
Job role: Civil engineer
Job type: Permanent

The client is one of the largest oil and gas production companies based in the Asian Pacific region and due to the increase development of one the key sites they are now looking to bring on board a project manager.

The appropriate candidate will be based in the region located close to Malaysia and this will be based on a rotation basis of denominations yet to be decided. A suitable candidate must be degree qualified and it would be advantageous if the candidate was a member of an engineering professional body.

The candidate must also have 10 years experience working within a project management position and this must be supported by experience of working within the oil and gas industry also. The candidate must exhibit and posses all the soft skills required of a senior program/ project manager, this included good analytical skills.

Due to the location of this project the client is only looking to bring on board a candidates that is of an Malaysian or Thai nationality and there is no room for movement on this prerequisite.
If you feel you are an eligible candidate for the above position, send a copy of your resume to the contact details below and I will be in contact in due course
Apply here.