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.

Dangerous ideas – and how to address them (part 4)

Yesterday I looked at how to overcome the problems of multi-tasking, proximatic competency and inaccurate reporting Today, I have the final two lessons from Ernest Baker’s presentation at last month’s PMI Global Congress North America, ‘Ten troublesome project management ideas and how to combat them!’.

9.  Low stakeholder engagement

Project managers working on projects where the stakeholders aren’t engaged are going to have a hard time. You need stakeholders who can put the effort in to support you and your team, and to manage effectively. You can read more about a way to manage your stakeholders using my INFORM method here (link to Wellingtone). However good your management upwards, sideways and downwards for your stakeholders, you will still struggle if they aren’t interested in your project. You have to ask yourself if the project is worth doing, because if they aren’t bothered about it, why should you be? Baker’s approach to dealing with low stakeholder engagement is:

• Set ground rules at the beginning of the project and maintain them
• Create a stakeholder matrix, covering who is responsible, accountable, consulted and informed for each part of the project (a RACI chart)
• Understand what ‘complete’ looks like for every task
• Share the ownership of project activities with the team

Baker’s final ‘troublesome idea’ was:

10. Failure to use history

Ever wondered why projects still fail today, when we’ve surely come across all the issues already in other projects? Well, we don’t learn from previous mistakes. Baker pointed out that this is a really common problem, and if you want to know if your organisation suffers in this way you should look for:

• A failure to collect and analyse data
• Mistakes made several (or more) times
• No single repository for knowledge, or shared approach to the content of that repository
• No way of managing continuous process improvement

What you’re doing today is history tomorrow, so if you want to stop making the same mistakes over and over again, you need to start learning from your errors. Baker provided some tips on what to do including:

• Collect data, and make sure it is accessible to others
• Compare plans to the baselined versions so you can see the differences
• Change things that don’t work
• Provide coaching and mentoring for project team members, to make sure the knowledge gets shared about
• Make lessons learned an agenda item for status meetings (PRINCE2 is also big on this)

Baker’s presentation was very comprehensive, and he had an easy style to listen to. If you want the one big takeaway message from the presentation and the following Q&A it was that stakeholder management is the project managers responsibility – and that setting expectations is part of stakeholder management.

Missed the previous articles?

Read part 1 here

Read part 2 here

Read part 3 here

Project Management Institute Opens Call for 2010 PMI Professional Awards Nominations

Source Reuters.com

On the heels of a successful PMI® Global Congress 2009-North America, commemorating the organization`s 40th anniversary, the Project Management Institute (PMI), the world`s leading project management professional membership organization, has opened the call for nominations for its Professional Awards Program. Through this program, PMI recognizes outstanding achievements in project management, including those of project professionals, scholars, organizations and their successful and innovative projects and products, as well as continuing professional education providers and authors.

While perhaps best known for the coveted Project of the Year Award, PMI Professional Awards include:

• PM Distinguished Project Award
• PMI Community Advancement Through Project Management Award
• PMI Distinguished Contribution Award
• PMI Eric Jenett Project Management Excellence Award
• PMI Fellow Award
• PMI Linn Stuckenbruck Person of the Year Award
• PMI Research Achievement Award
• PMI David I. Cleland Project Management Literature Award
• PMI Continuing Professional Education Provider of the Year Award
• PMI Continuing Professional Education Product of the Year Award
• PMI Project Management Journal® Paper of the Year Award

Nominations for the Project of the Year Award are due by 1 March 2010, while most other nominations are due on 26 April 2010. More information and instructions for nominations and each award nomination deadline can be found here: http://www.pmi.org/AboutUs/Pages/Our-Professional-Awards.aspx.

Don’t Kill Your Customer – It’s Bad for Business

Whether you are a project manager working in a large corporation with a PMO, or a PM-inclined individual in a smaller company thrown into the PM role, or a skilled consultant recruited by any sized organization to lead critical initiatives, you’re going to run into customers who drive you absolutely crazy.

I’ve discussed in previous articles some negative things about customers. These aren’t surprises to the experienced IT veteran. Usually the customer does not have the necessary expertise or knowledge that is needed – otherwise they wouldn’t be customer and they wouldn’t be coming to us for their project. Whatever it is – there is some need and they’ve come to you specifically, or your company in general, to fill that need.

If you come from a software development background then you know the attitude I’m talking about. It’s easy to put yourself above the customer and talk down to them. You need to both avoid coming across as knowing more than they do while at the same time resisting the urge to throttle them when they can’t seem to get a grip on what it is they really need and what you’re trying to do for them.

Customer Service

While customer service may not really be in the job description of most software developers and other key members of your project delivery team, it is a key responsibility of the project manager. The PM is the face of the company to the customer and the first point of contact for issue resolution during the project engagement process…and sometimes for a period of time following deployment. How you respond to that customer may mean the difference between ongoing revenue from them in the form of add-on business and change orders and a work stoppage on a project if they feel like they’re being treated like second-class citizens.

An Example of Bad Customer Service

I had one customer where my team was performing an enterprise software application configuration and rollout. It was, of course, one of five or six projects I was running at the time and one of three or four projects that most of my team members were involved with also. I had a junior business analyst on the project and a senior business analyst – supposedly the junior was being mentored by the senior. What actually was happening, though, was all the work being performed by the junior and no oversight by the senior.

What resulted was a functional design document that was full of errors – even easy typos – and it took four or five iterations to get it cleared up. At that time, peer reviews of documents like that were performed by position peers – meaning the senior BA was supposedly reviewing the document…but that never happened. Policy changes following this fiasco meant that peer reviews were performed by the whole team (something I personally should have required anyway as the PM…lesson learned, definitely).

What the customer saw, however, was a bad document being delivered to them repeatedly and they then realized that the senior BA was too busy with other critical work to be involved in the project. They actually had to state that they felt like they were being treated as a second-class project. Wow…I ended up with a lot of damage control on my hands.

The Lesson

The lesson here is to be proactive when these situations arise and correct the problem before the customer feels that they’re not high on your priority list. They know you have other work to do, just don’t make them feel like they’re at the end of your list. Your customer came to you out of need and because they lack the skills, resources and probably time to perform what you and your team can perform for them. Understand their need, work with their weaknesses and help them to fully understand the solution. You’ll end up with a very satisfied customer and likely a long-term customer.

Another Take on the Statement of Work Document

In an attempt to continue to provide PM Tips readers with various templates and descriptions of key documents that are normally part of the project management process, I’d like to present this article with additional information on the always-critical Statement of Work (SOW) document. I’ve already provided much of my viewpoints on this extremely important piece of project information and it’s role in project inception and kickoff in the article “The Statement of Work.”

Here will present more information on this document as described by Carl Pritchard in his book “The Project Management Communications Toolkit.” Mr. Pritchard provides a discussion of the purpose and uses – from his point of view – of the SOW as well as a sample layout of the document.

Since many of the PM readers are looking for help in putting together good templates and understanding how some of these types of documents are laid out and used (especially for the newer PMs or individuals considering a PM career) I feel it is critical to provide our readers with as many examples of these tools as possible.

The Statement of Work

Purpose

The statement of work serves as a guideline of the agreements on performance between a purchasing organization and a seller of goods and/or services. It is frequently an attachment to a contract or a memorandum of understanding between two organizations. The SOW affirms how the purchasing organization wants the work to be performed and the context of that performance, including any specific management practices or protocols the contractor must follow.

Application

The SOW is normally used as an attachment to the contract or agreement and is one of the very earliest documents developed to clarify communications between organizations. As a component of the contract, it is frequently used to settle disputes over what work should or should not be included in a project. It establishes expectations for a variety of issues in the contract relationship, including (but not limited to) the following:

• Overall project scope
• Primary tasks and/or deliverables;
• Costs
• Reviews and reports
• Testing
• Support
• Performance requirements
• Period of performance
• Payments and invoicing

Because the SOW is normally an attachment to the contract or agreement, it is a primary reference document for the project manager throughout the life of the project.

Content

Because the SOW is most often developed by the organization requesting the project product or service, it normally reflects a functional, rather than technical, perspective. Although the customer may have technical expertise, the work they will identify in the SOW is frequently performance oriented or performance based.

An outline for a SOW might look like the following:

1.0 Project Scope and Objectives

This is often a rewrite (or a copy) of the scope statement for the project, providing a general, overall perspective on what the project is intended to accomplish.

2.0 Description of Deliverables/Services

If the project can be defined into the key components or elements of the deliverable or service, they should be defined in sufficient detail to guide the project organization on the buyer’s desired approach. This may include physical deliverables or reports, testing, and support components of the project. The description of deliverables and services is normally the single longest section of the statement of work.

3.0 Costs

In an internal or cost-reimbursement contract situation, a table for the anticipated costs by deliverable, month, quarter, or fiscal year may be provided. This would not be included in a firm fixed-price contract. This may include personnel and materials usage and rates, particularly in a time-and-materials contract.

4.0 Reviews and Reports

This is a detailed description of the regular reporting requirements associated with the project and the level of depth anticipated for those reports. It may include not only timing for the reports, but also the forms and formats required.

5.0 Testing

The testing component details what types of tests are considered mandatory and how and when they must be applied. This may include both formative (in-process) and summative (upon completion) evaluations.

6.0 Support

This component may describe support both during and immediately following the project. It should include some details about response times, type(s) of support (telephone, on site, e-mail, chat, and so forth), and what general areas may or may not be covered as a component of the support agreement.

7.0 Performance Requirements

If any specific organizational protocols must be followed, they should be included in the SOW. This might include security, team behavior, configuration management, risk management, and other managerial requirements of the purchasing organization.

8.0 Period of Performance

This should be a date-certain window of performance for the contract, from [date] to [date], with no work to be performed outside that window without a contract amendment.

9.0 Payment and Invoicing

This should provide specific guidance on any provisions for interim payment and identify any specific individuals responsible for ensuring payment in a timely fashion. It may also cross-reference any protocols for invoice submission.

Approaches

In some contracting organizations, the SOW is used as a place to incorporate any special contractual clauses that may not normally be embedded in the contract. If the organization does not normally have a “furnished property” clause or other clause that may directly affect performance, such clauses are sometimes included here. In other organizations, clauses that are nestled deep within the contract, but which are often overlooked, are repeated here for emphasis. The purpose of the SOW is to clarify what work is to be performed by the project organization. If those clauses have direct influence over how the work will be performed, their inclusion here may be appropriate.

Some organizations use SOWs even for internal projects. In such environments, the SOW is used to emphasize the contractual nature of the relationship among the functional managers who may be responsible for the effort.

Considerations

Project managers frequently use the SOW as virtually the sole arbiter of how they will move forward on the project. In some organizations, the SOW is the only customer-authored documentation the project manager ever sees. The project managers may not have access to the full contract, but they almost always have access to the statement of work. As the guiding force for project performance, regardless of legal consequence, the SOW is likely to be seen by the project organization as the final determinant of what the customer wants.