Recently in Communication Category

In my last post challenging project management myths, one responder noted that I was unclear about what part described the myth and what part described the challenge statement. Here are numbers 5 and 6 on the hit parade, with the parts a bit better defined.

Myth 6: Complete and detailed procedures are an essential part of a successful project control system implementation.

Truth: Writing procedures are generally a waste of time and they don't help advance project management maturity.

Think about it, is there anything in the universe easier to ignore than a document? But the myth persists that procedures by themselves can advance an organization's project management capability.

Usually these procedures are signed by  a high-ranking member of the organization, who is attempting to compel obedience or participation in the project control system.

But unless the organization has authorized someone to actually  fire or demote others for failure to comply with the document--which happens rarely if ever--then the procedures themselves won't help.

Myth 5: If a schedule based on the critical path method isn't available, a good interim step to manage a project's schedule is to create a list of milestones or action items and meet to review them on a regular basis.

Truth: Action item lists and milestone databases are essentially polls and have no place in legitimate management information systems.

I once worked on a major program in which participants entered project data into a milestone database and provided monthly updates to those milestones.

At the beginning of the year, all of the milestones were scored "green," meaning the milestone would be met on time.

Byabout the ninth month, a few "yellows" would show up in the status column, indicating a possible delay.

More yellows would show up in month 10, followed by even more in month 11 along with a few "reds," indicating the milestone would be missed for that fiscal year.

By the last month, easily half of the milestones were either red or yellow. Lots of scolding and badgering would then ensue, followed by a new "baseline" for the next fiscal year, and-- shazaam!--all the milestones would be green again.

Asking participants what they think of their performance is not a performance management system -- it's a poll. And polls are not substitute for real management information systems.

I look forward to your responses because I know a whole bunch of people are going to disagree with these two.

I've been discussing stakeholders and communication for some time now without focusing on the key question: Why do stakeholders matter? Well, on most projects, stakeholders equate to risks.

There are a few risks that don't involve people--inclement weather, for example--but 90 percent of the risks on most projects are caused by one or more people:

•    Quality risks  almost always occur because people do not follow or not understand processes.

•    Design risks are usually the result of people not communicating.

•    Time and cost risks typically tie back to the performance of people doing the work.

•    Even inclement weather is influenced by people's perceptions--what's deemed "too wet to work" in a temperate climate may be seen as okay in a tropical monsoon climate.

People also determine if a risk is acceptable or not. Whether a risk is perceived as acceptable or not is 100 percent inside a person's mind.

As project managers, our job is to reduce risks to a level that gives the project the best overall chance of success. Yet extreme risk aversion will kill a project more effectively than a gung-ho attitude.

Of course, what constitutes a sensible level of risk is totally dependent on the perceptions and risk attitude of your key stakeholders.

That's why a central part of effective stakeholder management is ascertaining the risk attitude of your stakeholders. And then you must either adapt the project to fit within these parameters or provide the necessary information to help the stakeholder change his or her perceptions of what is acceptable.

The more that people feel they understand a situation, the more willing they are to accept risks.

Similarly, if you have a trusting relationship with someone, you're more likely to rely on their capability to safely manage risks on your behalf.

The most useful risk management strategy you can use on your project is effective stakeholder management supported by good communication. What has your experience been?

Everyone is talking about stakeholders these days. Surprisingly, this has not always been the case. The modern concept of stakeholders seems to have emerged from the work of the Tavistock Institute in London, England in the late 1960s and early 1970s.

Forty years later, the concept of stakeholder has expanded to include all of the people and organizations that have a real or perceived '"stake" in the project or its outcomes.

A Guide to the Project Management Body of Knowledge (PMBOK® Guide) breaks down a stakeholder as a person or organization that:

•    Is actively involved in the project
•    Has interests that may be positively or negatively affected by the performance or completion of the project
•    May exert influence over the project, its deliverables or its team members

In my work on mapping and managing stakeholders, I have found it important to expand on this basic definition to understand the "stake" of the stakeholder. This helps determine the best way to engage with them.  

Here are some of the different stakes a person or organization may have (most have more than one):

Interest: To be affected by a decision related to the work or its outcomes

Rights: To be treated in a certain way or to have a particular right (including legal or moral) protected

Ownership: To have a legal title to an asset or a property

Knowledge: To possess specialist or organizational knowledge needed for the work

Impact or influence: To be impacted by the work or its outcomes, or have the ability to impact (or influence) the execution of work or its outcomes

Contribution: Relating to the support or assets including the supply of resources, the allocation of funding, or providing advocacy for the objectives of the project

Once you understand the stake the stakeholder is seeking to protect, profit from or enhance, you can structure your communications to let the person know you understand their hopes or concerns. From this starting point, you're in a much better position to manage the relationship to the benefit of both the project and the stakeholder.

My last post touched on stakeholder attitudes. Attitude is derived from perceptions--in this context, the stakeholder's perception of the project and how its outcomes will affect the stakeholder's interests.

Fortunately, perceptions are negotiable and can be changed by effective communication. Change perceptions and a change in attitude will follow.

In my research, I considered two key dimensions to attitude:  
1.    How supportive or opposed the stakeholder is toward the project
2.    How receptive the stakeholder is to communication from the project team

Although receptiveness may seem less important, you cannot change a stakeholder's level of support if they refuse to communicate with you.

Levels of support can range from active opposition to active support. For each of the important stakeholders, the project team needs to understand the stakeholder's current level of support and then determine a realistic optimum level.

Exactly what that realistic optimum is varies. For example, environmental activists can never be realistically expected to support a new road through a wilderness area. The realistic optimum may be passive opposition and a communications plan developed to negotiate an outcome that the environmentalists can live with.  

Your project sponsor should be an active supporter. Communication needs to be planned to engage the stakeholder in actively supporting the project.

That means open communication. If the stakeholder is unwilling to communicate, ways need to be devised to open channels. This may involve using other stakeholders in the network around the project to open the communication, changing the way you communicate or just plain persistence.

Only after communication channels are open can you start to listen to the other person and understand their needs, concerns or ambitions. Once these are known, you're in a position to either explain how the current project meets those needs or consider risk-mitigation strategies to modify the project to reduce issues and enhance opportunities.

The whole point of stakeholder management is to optimize the overall attitude of the stakeholder community to allow the project to succeed.

A very significant proportion of the risks around most projects are people-based. The only way to identify, manage and/or mitigate these risks is by effective two-way communication. More on this later.

Any project team will have far more stakeholders to potentially communicate with than they have either the time, money or people to manage. But selecting the right stakeholders for a sustained communication effort in a project is not simple and can be a very resource intensive process.

My research over the last 10 years suggests a three-phased approach works best.

One: Identify the stakeholders and figure out what you need from them and what they want from the success (or failure) of the project. This is called 'mutuality'. If you can show the person they're likely to achieve at least some of their aims, they're far more likely to provide you with what you need from them.

Two: Work out which stakeholder is most important. This requires assessing at least three aspects for each:
•    How powerful is the stakeholder? Can he or she close the project down, force change or do they have little direct impact?
•    How much effort is the stakeholder likely to invest in asserting their position or 'rights'? Some stakeholders will go to almost any lengths to assert their position while others are really not that interested.
•    How close is the stakeholder to the project? People actively working on the project have more impact than those who are relatively distant.

Three: Determine the attitude of each important stakeholder towards the project and how receptive they are to your communication.

Now you have the information needed to focus your communication efforts where they can achieve the greatest benefit. People who have a supportive attitude simply need 'business as usual' communication. On the other hand, important stakeholders who are assessed as having a less than optimal attitude may need heroic communication efforts to change their views if the project is going to succeed.

And always remember: People change. Reassessing the stakeholder community on a regular basis helps ensure the communication plan is working or if it needs changing.

More on this soon.

My last post highlighted the challenges of designing a project communication system that works. Now I will try to suggest a few solutions.

To quote Peter Taylor's book, The Lazy Project Manager, "Reporting is not communicating." Executives don't have time to read fantastically accurate and detailed reports--people are simply too busy to take that kind of deep dive.

But at least some of that detail is important.

My suggestions to resolve this conundrum are:

•    Separate push and pull communications. Make the detail available in a repository such as a project portal) where people who need the detail can easily retrieve it (pull). Anything you send out (push) should focus on the highlights and information that requires action.

•    Separate history from future. Reporting what happened last week is of no value to the project unless it contains information that will influence future decisions. Historical data is needed by accountants and business administrators. project leaders and team members need information that is forward-looking, focusing on what might happen in the future and what needs to be done to improve the situation.

•    Focus on the needs of the receivers. Make sure you give your audience the information they need to help make the project successful. Team members need to know what work to do in the next week or two. Managers need to know what they have to decide.

Achieving this type of communication requires planning and information design. Each element of the overall controls system needs to be elegantly designed to support both management decision-making and the work of the project.

More importantly, the communication effort needs to focus on the important stakeholders who influence success: both internally to leaders within the team and externally to decision makers and influencers. (More on this later.)

And remember Cohn's Law: The more time you spend in reporting on what you are doing, the less time you have to do anything. Stability is achieved when you spend all your time reporting on the nothing you are doing.

Describing scheduling, earned value management (EVM) and financial management as "project controls" is, I would suggest, dangerous!  

The steering mechanism on a car is a control system. You move the steering wheel, and the front wheels turn and if the car is in motion, its direction of travel is altered. Control systems cause a change.  

Altering the duration of a task in a schedule, or calculating the current cost performance index and estimate at completion for an EVM report changes nothing. All you have is new data.

If the data is going to cause a change, it needs to be communicated to the right people. They need to receive, understand and believe the data--this changes the data into information. Then they need to use this new information to change their future behaviors.

This is a communication process. The challenge facing schedulers and other controls staff is recognizing their primary role is communication not controls. Certainly they need to be able to gather and process information effectively but this is wasted effort without equally effective communication.

Other challenges include:
•    Identifying the right people to communicate with--the project manger is only one
•    Formatting the data in a way that can be easily understood by the receiver. Without understanding, there will be no action.
•    Focusing the information on what matters in the future

No one can change the past and it's always too late to change the present. The only value a project control tool can offer is to influence future actions and decisions. This requires making schedules, cost plans and the like as simple as possible to improve communication and facilitate understanding by the project team.  

Only after the project team fully understands the information can you expect them to use the information to make wise decisions about future actions.

In most organizations project managers need to be skilled in both communicating downward to motivate their project teams and communicating upward to influence their managers. Yet while inefficient communication with  team members comes with its own set of issues, ineffective communication with senior management may put the whole project at risk.

Senior managers today generally operate in "command and control" mode, and most organizational processes support this view. Despite theories of team motivation based on empowerment, delegation and job enrichment, control is still the favorite with most senior management.

Project managers need to develop the skills needed to advise upward effectively. In so doing, they must align the project's objectives with the organization's strategic objectives and, more importantly, ensure the key senior managers appreciate this fact and contribute to the project's success.

The key is helping your boss look good.

This can be achieved by providing good information and analysis for decision-making; never escalating a problem or issue without options and recommendations for a resolution; and always communicating in business language with an understanding of the manager's business drivers.

A cooperative, supportive relationship is a two-way street. Project managers need to earn the respect and support of senior managers by adopting a positive approach to communicating up the ladder. Some positive options include providing helpful notes to assist the manager deal with difficult situations, and providing a full analysis of the recommendations and options for resolving issues or making decisions.

Advising upward or helping your manager help you requires a long-term view. There is no silver bullet! You must build credibility over time by developing and maintaining a reputation for being ethical, efficient and open. And above all you must be an effective project manager in your space and a supportive team player in your manager's space.

I recently presented a keynote session on the power of acknowledgment to 800 attendees at a global project management conference in Helsinki, Finland.

Before my presentation, I kept hearing project managers say things like: "In Finland you know you are being acknowledged when your boss says, 'That wasn't too bad a job that you did.'" They told me repeatedly that acknowledgment was just not done in Finland.

I'd heard a similar trend in Germany--being acknowledged is when your boss doesn't say anything to you, I was told.

Now, I'm a perpetually optimistic person who always tells people they can single-handedly be agents for dramatic and powerful change--that it only takes one person to start the process. If someone acknowledges others in a heartfelt and authentic way, it will start to catch on.

But an entire culture? Could 800 project managers turn a whole culture around? Even I had my doubts.

During my presentation, I invited everyone to think of one person in their professional life that wanted, needed and deserved their acknowledgment but to whom they had never fully delivered it. Two brave people stood up and shared their profound and heartfelt acknowledgments of their Finnish bosses--who just happened to be in the audience!

Each time I asked both the acknowledger and the acknowledgee to stand. People in the audience were deeply moved and said this kind of exchange never occurs in Finland. Well, it did. Just because something is missing from a culture does not mean that it is not desirable or essential. Acknowledgment is, I believe, a basic human need, no matter what one's cultural conditioning.

I have since received e-mails from people in Finland telling me they've started to acknowledgment colleagues and family members in a profound and sincere way and are extremely pleased with the results. So I'm now becoming confident enough to say that yes, one project manager can certainly begin to change a culture.

Now just think of what 800 can do!  Germany, stay tuned!

It's hard for me to predict the future. Although our team meets project deliveries, we normally range from -5 percent to +15 percent of the scheduled delivery date with one exception. We struggled on one project and finished past the promised delivery date by 50 percent of the project schedule.

We documented lessons learned much like what Dmitri Ivanenko has described in a previous post.

But I was not satisfied, so I surveyed my colleagues on how they thought we could better estimates next--and every--time.

Here is what they said:

•    Anticipate volatility and plan frequent feedback opportunities with customer. If every project you manage starts with a solid set of requirements that never changes, count yourself lucky. Most of the time, that's not the case. Be in the mindset that projects go through changes and have frequent feedback sessions with your customers to help minimize last-minute surprises.

•    Utilize both top-down and bottom-up approaches. Visions, objectives or problem statements provide the boundary of the project scope. Agree on top-level requirements and then work with the experts on coming up with quality estimates for the detailed tasks. Clarify any assumptions/questions during this time and use A Guide to the Project Management Body of Knowledge (PMBOK® Guide) processes and/or any parametric modeling tools to create the initial schedule.

•    Plan the high-risk item(s) early. How many times have you seen a schedule task showing 90 percent complete only to have it continued at 90 percent for a long, long time? Make sure the risky development work is scheduled up front. This practice gives you the greatest flexibility on mitigating risks you may not have planned for.

•    Assess your team's experience with the project effort. Understand how experienced the team is with the kind of problem you are asked to solve. And staff the project with the right people for the jobs even during planning stage. You may not need all of the positions filled, but you will need to have experienced experts to provide quality estimates.