How to Make Project Management Work in Your Company

I ran across the list below – which is actually a subset of the original list – while reviewing the book “The Fundamentals of Project Management” by James P. Lewis. This book was published in 1995 so thoughts and processes have changed a little. I’ve selected what I believe are the most relevant items from Mr. Lewis’ original list for inclusion in this article. I’ve made some changes and additions as well. Read on…

It is one thing to know how to manage projects effectively. It is another to get people actually to manage them that way. Running by the seat of the pants seems a lot easier than doing all that planning, scheduling, and monitoring. Even when people invest three or four days in project management seminars, you find that they soon forget what they have been taught and go back to the old ways.

I have struggled with this problem for over fifteen years, and I finally have some answers. Here are suggestions on how to make the principles of project management work in your company.

• Get top management involved in the process and the projects. They should be asking questions about how projects are doing. In other words, show an interest in the subject.
• Build into performance appraisals items that evaluate a project manager’s use of the tools of effective project management. Reward people for practicing the methods. But be careful. Be sure upper management is not keeping managers from practicing good methodology.
• It helps to have the entire team trained in project management basics.
• Senior management need to understand the company’s PM process and methodology to effectively set their expectations. One of the ten most common causes of project failures is unrealistic expectations on the part of senior managers.
• Practice a lot of MBWA (management by walking around – or at least very frequent communication) as the project progresses, but do it to be helpful, not in the blame-and-punishment mode. Give people strokes for letting you know about problems early, rather than after they have turned into disasters. Don’t be too quick to help, though. Give people time to solve the problems themselves. Just ask them to keep you informed, and tell them to let you know if they need help. Be a resource, not a policeman.
• Do audits to learn, and try to improve whenever possible. Verify that processes are being followed, status reports are being produced, customers are getting the info they are supposed to get, and project plans are being updated regularly. Make sure the processes that are in place are being followed.
• If you find you have a problem individual on your team, deal with that person as soon as possible. Don’t ignore the problem, as it can wreck your entire team.
• Be very pro-active, not reactive. Take the lead. Break roadblocks for your team members. Go to bat for them.
• Have team members make presentations to senior management on their part of the job or periodic presentations on their key projects. Give them credit for their contributions. Build ownership.
• If you are running a project to which people are temporarily assigned while still reporting to their own bosses (matrix organization), keep their managers informed about what they are doing. Try to build good relations with those managers. You may need their support to get the job done.
• You may find that you have to co-locate the people doing activities on the project’s critical path so that you don’t have them constantly pulled off to do other jobs. This method is being used more and more by major corporations for highly critical projects.
• It is also possible to appoint a project administrator to either do the project support or delegate it and to sit in on project review meetings and hold the team’s hands to walk members through planning, audits, and so forth. Naturally, you need to be running quite a few projects (at least ten to twenty) to justify creating this position, so this depends on the size of your organization.
• Benchmark other companies to find out what they do with project management.
• Have individuals take responsibility for championing various parts of the project management process. One person, for example, the earned-value champion, might go around the company trying to get everyone to use the method. Another might take responsibility for dealing with WBS notation, and so on.
• Read PM Tips and follow everything on here! (ok, just kidding, I added this one….)
• Look at managing projects as a challenge – keep it exciting. Stick to a process, but change things as needed to accommodate the project and the customer.

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.

Balancing Critical Project Success Factors – Enforcing IT Excellence

This is the sixth and final article in the series of excerpts on Balancing Critical Project Success Factors from Paul Tinnirello’s book “New Directions in Project Management.” So far, we’ve covered:

• Introduction
• Selling Good Ideas
• Building a Common Vision
• Generating a Commitment to Ideas
• Engaging Conflicts Directly

In this sixth segment we assertively enforcing standards of IT excellence.

Assertively Championing Standards of IT Excellence

In certain circumstances the primary task of the IT professional is to ensure compliance with organizational standards concerning how IT technology is used. In other words, IT professionals are sometimes asked to give greater emphasis to their role as enforcers of senior management IT policy and less to their role as internal consultants. Occasionally, it is necessary for IT professionals to use the full measure of the positional power vested in their role by the organization and prescribe specific actions that users must take to be in compliance with corporate IT standards.

Although such standards help optimize the efficiency management of IT resources, on occasion, they can be inconvenient for some user managers. When users fail to comply with important standards, tough but skillful enforcement is required. Consider the following case as an illustration. An IT manager was working with a user manager who disagreed with corporate IT policy and began contacting IT suppliers directly to acquire the technology he desired. In response, the IT manager approached the user manager with the goal of assessing the particular difficulties the officially sanctioned technology was creating for the manager and offering assistance in working through such problems. The user manager responded by complaining that the IT professionals were being unresponsive and resisted attempts to assess his particular objections to the approved technology options. Further, the user manager began manipulating the IT professionals against themselves to secure the technology he wanted.

The project manager’s response was to talk with the manager directly about the policy violation and IT’s role as enforcers of this policy. The IT manager also offered his support in helping the user manager escalate the issue to senior policy makers. The IT professional said that he would advocate an exception to corporate policy as well as minimize the negative consequences the user manager feared the approved technology would create for his group if the exception was not granted. As this approach was more firm and direct than the user manager had experienced from other IT professionals, the IT manager wisely briefed his management before undertaking his plan.

In this case, the IT professional applied the positional power invested in his role by the corporation to enforce established IT policy and practices. Using the positional power invested in one’s role is another underutilized means of managing IT priority pressure.

Summary

The starting point for effectively managing priority pressure is to view IT work from the perspective of project management. In particular, this means recognizing that IT professionals must engage end users in the decision making about how the balance between quality, time, cost, and customer satisfaction is preserved. When IT professionals adopt this perspective, they embrace the practical politics of implementing innovation. This requires both courage and competence from the member of IT organizations. Effective human resource management practices can ensure that both traits are being selected for and systematically groomed. By encouraging the expression of courage and competence, IT professionals can become masters of, and not victims of, priority pressure. The investment organizations make in IT and the effectiveness of the professionals who are stewards of its appropriate application depend on this mastery.

Paul C. Tinnirello is the editor of “New Directions in Project Management” from the Best Practices Series.

Balancing Critical Project Success Factors – Selling Good Ideas

This article contains another excerpt from Paul Tinnirello’s book “New Directions in Project Management.” In the Introduction article we outlined the five prescriptions for preserving the balance between project success factors. In this article, we look at the first prescription – sell good ideas by emphasizing benefits that the user perceives as valuable.

Selling Good Ideas

The starting point for an IT project is selling senior management within the user group and within the IT function on the idea. Consequently, the efficiency with which ideas are sold is one important means of managing priority pressure. The power of persuasion depends largely on whether the rationale used to support an idea resonates with the decision-maker’s interests. To sell ideas more efficiently, the rationale for an idea must reflect the user’s priorities. In short, reasoning should always outline “what is in it for them.”

When selling ideas, IT professionals sometimes get stuck on technical issues, specifications, and justifications. Although technical details are critical, as facts, they have limited power to influence users and senior IT management. As a result, one of the main priority management prescriptions is that IT professionals need to develop sufficient business expertise to engage users in terms that they will find compelling. IT professionals who add this expertise to their technical competence have the greatest organizational impact. Many IT organizations are experimenting with the role of user or client relationship manager to help establish client sensitivity within IT organization.

Selling ideas effectively also means having good ideas. Good ideas are designed with knowledge of the practical time and resource constraints within which they will be implemented. Not all business problems require state-of-the-art solutions.  Sometimes, small is beautiful. Making incremental enhancements over time can moderate the negative influence of organizational politics, limit risk, and create success experiences. A track record of successful enhancements can build momentum for bigger, more ambitious projects.

Having a good idea is not sufficient, however. Good ideas are often not met with enthusiasm. How the IT professional responds to the objections raised by others as the idea is being sold affects one’s eventual success. Arthur Schopenhauer, the nineteenth-century philosopher said that ideas go “through three distinct phases: ridicule, opposition, and finally enthusiastic acceptance.” Advancing ideas through these phases means (1) increasing perceived need for the idea, (2) modifying the idea itself to increase personal and organizational benefits to key stakeholders, (3) reducing costs, both personal and organizational, and (4) decreasing perceived risks. By adjusting good ideas iteratively based on feedback from stakeholders, IT professionals can efficiently win a critical mass of support for IT projects from key stakeholders.

Paul C. Tinnirello is the editor of “New Directions in Project Management” from the Best Practices Series.