Results tagged “Lynda Bourne” from Voices on Project Management

There's big -- and then there's mind-blowingly big! Everything about the World Expo 2010 in Shanghai, China defies easy definition. Covering a total area of 5.28 square kilometers (2.04 square miles), the site is divided into five zones spread along both sides of the Huangpu River in downtown Shanghai. The CNY18 billion extravaganza includes gardens, wetlands, paved walkways and hundreds of buildings.

The expo is not only a triumph for project managers from the Shanghai region and the Chinese construction industry, but also from all of the nations that built and fitted out their pavilions. The design, construction and management of the Shanghai 2010 World Expo projects went beyond the traditional iron triangle of "time, cost and quality" to include sustainability and safety.

The projects represented a true integration of Western and Eastern cultures, demonstrating project management as a truly global profession crossing all sectors. There are more than 200 countries and international organizations represented, ranging from Tuvalu to the United States; the World Bank to the International Council of Museums, as well as numerous corporations and Chinese provinces.

In one long day, I only managed to see a small section of the total experience, but could start to appreciate the overarching purpose of this great festival.

The remarkable British Pavilion's "dandelion" is made up of 60,686 acrylic rods, each 7.5 meters (25 feet) long, to allow light into the inside of a 20-meter (66-foot) cube. Embedded in the end of each rod are one to 10 seeds representing Chinese plant species growing in the United Kingdom. Project managed by Mace Construction Group, the remarkable "seed cathedral," is already winning awards.

In the two months since opening, the Expo has hosted more than 25 million visitors. And organizers expect 70 million will get a glimpse of the urban vision before the Expo closes in October.

My visit was a once-in-a-lifetime experience to see project management on such on a grand and global scale. If you can't make the trip personally, you can be a virtual tourist online at http://en.expo.cn/. It's well-worth the visit.

In March I introduced you to Sebastian, a highly competent, upwardly mobile executive who happens to be your boss. A very detailed person, Sebastian works from 6 a.m. to 10 p.m.

That post sparked quite a discussion and prompted some ideas for building a relationship with him. Now it's time to put these skills to use!

This time around, we're focusing on Sebastian's habit of proofreading. While it's a fact some people can see mistakes in documents that others just miss, his copious corrections are starting to cause issues.

Sebastian can and does act strategically. But his habit of correcting everything is causing the project managers and project management office staff in his division to spend an excessive amount of time focusing on the documents' presentation (style, font, grammar, spelling) to the detriment of the more important issues of content and strategy.

How do you advise him that his ability to see and correct minor errors might be counterproductive? And what is an acceptable standard for internal project documentation?  

Post your comments and ideas, and we'll review and consolidate the answers in a few weeks.

My last post posed the question, How do you manage trust with a new team? Some suggested taking a cautious approach to building respect and rapport. Others addressed the long-term nature of trust developed in a traditional framework.

These are valid, but there's a different form of trust that can also be highly beneficial to project teams: swift trust.

Swift trust occurs when a diverse group of experts are brought together in a temporary organization such as a virtual team created for an urgent project.

It's especially prevalent when the team is required to deliver a result that requires interdependent working and there are significant external pressures. The team has to work out their differences on the fly and "blindly" trust one another to do their jobs simply because there is no alternative.

In these circumstances, team members tend to exhibit behaviors that presuppose trust. Each person knows they're trustworthy and assumes they can trust the others. Therefore, the team simply acts as if trust is present even though there has been no opportunity to develop the more traditional forms of trust.

This is swift trust, and although it can be a powerful force, it is also fragile and easily broken. Activity contributing to the team's common goal, professional behavior and an effective team leader allow swift trust to develop. But it will only last as long as everyone behaves in a trustworthy way.

One aspect of developing swift trust is the presence of recognized expertise. We tend to trust modern medicine and therefore tend to trust doctors. Very few people when rushed into hospital in an emergency want to check the credentials and track record of the doctors working to save their life. They trust the hospital to provide competent doctors to help solve their problem.

Another aspect is a clearly defined objective and clearly defined roles and responsibilities. The key to developing swift trust is interdependent work focused on a common objective. Each member of the team needs the other's particular expertise for the team as a whole to be successful.

Swift trust is not a random occurrence. By understanding the criteria that encourage its development, a manager can create a favorable environment. Then the act of trusting tends to become a self-fulfilling prophecy.

By trusting others we encourage both trustworthy behaviors and engender trust in return. However, as with traditional trust, swift trust can easily be destroyed by untrustworthy behavior. It needs nurturing and support.

The concept of swift trust is not new. There have been papers and books on the subject for at least a decade. But making pragmatic use of the concept on project teams has not been widespread.

If you've been involved in a temporary team under pressure, did you notice swift trust between you and your colleagues, or was it missing altogether? Please share your experiences to help build a better understanding of this interesting phenomenon.

Trust is a fascinating element of business and relationships. Where trust exists, all that's needed to manage most work is a brief conversation to ensure understanding and a handshake -- real or virtual. It's lack of trust that leads to the constant measuring and checking of performance, writing complex and detailed contracts, and meeting with people.

Trust speeds everything up and lowers transaction costs. As the level of trust goes down, the speed of doing business goes down, costs go up and relationships and communications are largely ineffective to the point everything has to be proved or validated.

Interestingly, it would appear trust is not a fundamental element of a relationship. Relationships can work with remarkably low levels of trust, as long as both people have a common objective, and at the beginning of any new relationship there is little to base trust upon.

Within both personal and business relationships, trust tends to build as the overall relationship is established. It is built over time and is based on your observation of the other person's actions within the relationship. The effectiveness of the relationship progressively improving as trust between the two people builds.

According to Stephen Covey, PhD, author of The Seven Habits of Highly Effective People, trust is built on three behaviours:

- Transparency: Tell the truth in ways people can verify and validate for themselves.
- Keeping commitments: Do what you say you will do.
- Trusting others: Extend trust to your team and they will trust you in return.

Trust that has taken years to build can be destroyed in minutes and rebuilding trust is far harder once it has been lost.

The first challenge facing project teams and their stakeholders is to identify a pragmatic level of trust that will allow the work of the project to proceed effectively but to also have sufficient checks and balances in place to insure against untrustworthy behaviours.

The second challenge is to create trust quickly enough to allow the teams to function in the early stages of a project. This is particularly true for virtual teams.

How do you manage trust with a new team of people you don't know well and may never meet? Post your advice and I will combine them with a few of my suggestions in my next post.

The more than 40 comments on my last post Hey Boss, What About Work-Life Balance? provide an interesting mix of views. Here are my thoughts on how to work effectively and build a relationship with someone like "Sebastian." This input comes from a position of advantage since I knew the real person.

The first key to building any effective relationship is to avoid stereotyping. Sebastian was a very effective, upwardly mobile manager with a focus on being promoted to the main board. Interestingly, most people liked him as well as respected him. It's just that he had a different life focus, which is not uncommon in successful senior executives.

The second key is to recognize that in every relationship there is a power dimension. How a manager like Sebastian would use his power is to an extent a generational issue. Many younger managers would see nothing wrong in you setting reasonable boundaries and procedures, as long as they understand their purpose. Managers with more experience are used to operating in a command and control environment are likely to react negatively to a "junior" pushing rules upwards.

The third key is mutuality. Team members need to understand what he or she needs from the relationship (support, resources, backing) but also what Sebastian needs from the relationship. Then, work to negotiate mutually beneficial outcomes that meet both sets of requirements.

For the team member discussed in the post, the requirement was time-related; Sebastian's requirements were not defined in the original post. However, by defining what's important to Sebastian, then linking your requirements to the achievement of his requirements, you can start to achieve real communication inside an effective relationship.

Finally if you wish to be taken seriously, you need to develop a reputation for credibility. Senior management needs to recognize that if you say something, it is backed up by facts, and if you commit to something, it is delivered. Credibility is earned by performance, but there is no harm in quietly making sure your performance is noticed in the right places.

In the end, relationships all depend on the situation. But mutuality and credibility are the two keys to advising upwards. If you are seen as a serious contributor to the organization's success and can link your needs to the needs of senior management, there's a high probability of achieving your desired outcome and benefiting the organization at the same time.

The last hypothetical I posted, Is This Your Project Stakeholder? attracted a wide cross section of responses.

It made me wonder what you think of this real life experience (only the names have been changed):

Sebastian is a highly competent, upwardly mobile executive and your boss. He works 6 a.m. to 10 p.m., and is a very detailed person. He proofreads everything, making copious corrections and is also studying for his second master's degree.

You have found the best time to approach Sebastian to discuss anything is after 8 p.m. when the office is quiet and he is working on his studies. In fact, at this time of night he seems to appreciate a brief chat.

The problem is you have a "life" outside of the office and feel 8 a.m. to 6 p.m. is a very fair day's work.

How would you approach building rapport with Sebastian to allow the discussion of important project issues and enhance your career prospects without waiting until after 8 p.m.?

I will review all comments and based on your feedback I will suggest some solutions in my next post.

Developing reports is an art form--and it's one that every project management office manager needs to master.

Well-designed reports contain large amounts of useful information in a time series, making them a valuable data repository. And if the report covers the right questions, the process of gathering the information can generate valuable insights for the project team to act upon.

That information also allows stakeholders to extract trends and status.

And if you deliver them in person or attach a note to highlight specific issues or messages, reports can form the basis of a targeted, purposeful communication.

Some people simply like getting reports--and dropping those people off your distribution list make them more upset than you realize. This also applies to cutting content. As a rule of thumb, by the third month it's probably too late to remove sections or drop recipients without encountering some issues.

Another benefit of reports is only starting to be recognized. Jon Whitty of the University of Southern Queensland here in Australia has been measuring the emotional effect of project artifacts. Based on Jon's work it seems a well-formatted report will in itself increase positive emotions.

The project manager feels comfortable because she or he has a "proper report'' that is part of the "clothing'' every project manager wears along with their Gantt charts and other expected artifacts. And senior managers experience positive emotions because the existence of a well-presented report suggests control, order and capability.

The challenge is to design reports that are relatively easy to produce, ask the right questions, are well-structured and well-formatted, and contain needed data.

What are your experiences with reports?

(Also, I will be presenting my paper "Beyond Reporting--The Communication Strategy" at the PMI® Global Congress 2010--Asia Pacific in Melbourne from 22-24 February. It continues on a theme I've often covered here: If you're trying to influence someone, then specific and targeted communication is essential. And so is measuring the effectiveness of your message. If you are attending the congress, I hope to see you there. The best place to find me during the congress will be at the PMI Melbourne Chapter booth in the exhibition hall.)

My last post received a wide range of comments and I wanted to draw some conclusions based on those comments and my thoughts.

The majority of those that left a response said they would choose "option one." If you selected "option one" and well managed your relationship development and engagement processes, then helping "Mary"--the stakeholder in question--and her team contribute to the change should be beneficial. Why?

The first thing to consider is that Mary would be a key stakeholder at several different levels in the overall change management program.

As a long-term employee leading a group of workers, she is a stakeholder in the overall organization and is likely to have many unofficial contacts and significant influence.

As the leader of a group of workers who will be disadvantaged by a planned reorganization, she and her team are critically important stakeholders for the change manager. The group will never like the consequences of the change, but they need to be included so they at least cooperate for the good of the overall organization.

Because they can contribute knowledge and support, Mary and her team are also stakeholders of the program and particularly your project. The assumption that your team has enough knowledge to bypass her people is risky. You don't know everything that happens in Mary's section on a day-to-day basis.

The second important consideration is where the value is created. Ultimately, there is no value to the organization unless the change is successfully implemented.

Your project may deliver a key component needed for the reorganization but if it is not used, there is no value. This is something IT people in particular need to remember; 99 percent of IT projects require changes to business processes and are a complete waste of time if the business people reject the new processes.

If you selected "option two" and chose to ignore Mary, she is likely to become an active opponent of the change (no involvement equals no commitment and no support). This puts your most important stakeholder at a disadvantage: the overall change manager.

Imagine for a moment your organization has decided on a major restructure, and as a consequence has initiated a change-management process and appointed a change
manager.

The change manager develops the business case for a major program of work. The executives responsible for the organization's portfolio management approve the business case and agree to fund and resource the program.

The program manager sets up the program management team, establishes the program
management office and charters a series of projects to develop the various deliverables needed to implement the change. And you have been appointed project manager for one of the projects.

In this situation, your life as a project manager would be fairly straightforward; you have direct-line management responsibility to the program manager, and the change manager is your project sponsor. The program management office looks after most of the issues of sourcing adequate funds and resources.

All you have to do is deliver the project's outputs as defined in the project charter.

However, part of your project ideally needs the cooperative input from a group of people
who will be significantly disadvantaged by the overall reorganization. This group is led by a 20-year veteran of the organization, whom we will call Mary. At the moment, Mary's loyalties are divided--at one level she wants what's best for the organization she has worked for all her life, but she also wants to preserve her team and keep the status quo.

Fortunately, you have enough domain knowledge in your team to bypass her input and produce the deliverables anyway. So what should you do?

Option one is to work to get Mary and her team's input--if not their positive cooperation--but risk delaying your project's completion and overspending the budget.

Option two is to use the knowledge you already have in the team to produce the deliverable and bypass the problem, thereby ensuring on-time and on-budget delivery. This option also minimizes the chance of Mary interfering in the overall work of the project and program.

What would be your recommendation to the program manager? Option one, two or something different? Post your thoughts in the "comments" section and we shall draw some conclusions in my next post.

As I said in my last post, customers' perceptions are their reality--and if you're going to make the sale, you need to deal with their reality not yours. This poses a number of challenges for technically oriented people (i.e., project managers) focused on "the facts."

The first challenge is recognizing that if you want someone to take on your ideas and work to help you, you have to get them to accept your ideas. This is a sales process. Even the terms we use to describe the transfer of the ideas are sales-based. You have to "sell the idea" to get "buy-in."

The second challenge is recognizing perceptions are highly unlikely to change quickly. You can deal with this in one of two ways:

- Accept that the perception is real and deal with it by providing a direct solution (even if it's not really needed)

- Differentiate yourself from the perception by separating yourself from the general stereotype

Pretend your type of business is plagued by a reputation for overcharging customers and
arriving late for appointments. You can differentiate your business by guaranteeing a time, offering a US$10 discount for every 5 minutes you're late and proposing to quote a fixed price before starting work. This solution is partly differentiation and partly working within the reality of the perception by offering a benefit (the discount) if the perception holds true.

The difficulty with managing perceptions is that most people don't advertise their views openly.

The only way to unearth another person's perceptions is through a combination of observation, active listening and careful questioning -- in that order. This takes time and effort and needs to be focused on the stakeholders who matter.

At the PMI Asia Pacific Congress in February I will deliver a paper called, "Beyond Reporting--The Communication Strategy" that builds on this idea. I will discuss more on this idea in upcoming posts.

One of the first things salespeople learn is that perceptions are reality. And the same goes for project managers.

Your perceptions and your reality may differ, but if you want to communicate effectively with someone you need to understand their version of the truth.

Perceptions are also closely aligned with expectations. If a stakeholder perceives an organization as unresponsive and inefficient they will expect bad service. From this starting point, the stakeholder will readily accept as true every experience that contradicts their view of the world. A good experience can be written off as "the exception that proves the rule."

This presents a distinct challenge to project managers who are developing a communication plan. Your stakeholder's perceptions of project management will be based on prior experience with other projects in other times and even other organizations.

This is neither fair nor reasonable but it is a fact!

The situation is made worse by another trait: our tendency to feel and remember bad experiences more strongly than good ones.

Where negative attitudes occur, your solution is basically hard work. You need to assess the current attitude of your key stakeholders, determine the optimum attitude and then work to improve the stakeholder's perceptions of your project.

There are three key elements to consider when working to change poor perceptions. 

1. Build rapport and open communication channels that will be effective. You may need help from supportive stakeholders to achieve this.

2. Build your credibility by providing accurate, timely and useful information that precisely meets the needs of the stakeholder. Help them to be successful.

3. Whenever possible, differentiate your current project from the person's previous negative experiences.

The bad news is one slip and you immediately reinforce the old perceptions. So stay focused and ensure every communication, authentic and credible.

A Guide to the Project Management Body of Knowledge (PMBOK^® Guide) is developed by hundreds of volunteers to represent generally accepted good practices in project management. But is this enough?

There are already extensions to the PMBOK^®Guide for the construction industry and government that expand the basic framework to meet the needs of these sectors. Is there a need for extensions to meet the needs of different cultures?

The value of diversity and the challenges of managing culturally diverse teams was the focus of Tom Sullivan's feature article "Common Ground" in the October issue of PM Network^®. My column in the November edition of PM Network, "Culture Shock," highlights some contractual issues that impacted a major mine development. As projects and teams become more global, managing appropriately within and across cultural boundaries is a key project management skill.

Although there's no right or wrong in culture, different societies resolve challenges in different ways and use very different structures to communicate information within businesses and projects.

As PMI moves toward the start of the next PMBOK^® Guide update project, I would like to take the opportunity to discuss issues and challenges of managing projects in a cultural context. Do we need cultural extensions to the PMBOK^® Guide or is there more value in retaining it as a core definition of good practices that apply worldwide?

I've had my say in PM Network, now it's your turn to weigh in. Over to you!

Stakeholders must be important. A Guide to the Project Management Body of Knowledge (PMBOK^® Guide)--Fourth Edition has over 380 separate references to the word "stakeholder."

But the thousands of managers struggling today to meet stakeholder expectations may be interested to know that only a few years ago no one bothered. The whole concept of business or project stakeholders is a relatively new phenomenon.

The legal concept of a stakeholder is not new. Neither is the concept of "having a stake" in something.

One must also presume the concept of delivering a quality product to meet the needs of the end user, customer or client is not new.

In fact, many 19th century businesses had enviable reputations for customer service. Which leads to the question: What changed?

The origin of a business stakeholder in management literature can be traced back to 1963, when the word appeared in an international memorandum at the Stanford Research Institute. Stakeholders were defined as "those groups without whose support the organization would cease to exist."

The concept of business stakeholders was also a core part of the work on systems analysis in organizations conducted by researchers at the Tavistock Institute in London, England in the late 1960s and early 1970s. The concept has since grown from those beginnings.

During the last 30 years, the people and organizations covered by the term "stakeholder" have continued to expand and evolve. Stakeholder theory now includes the concepts of corporate social responsibility, organizational theory, systems theory, customer relationship management and governance.

And in the last few years, stakeholders have come to encompass anyone with an interest in or who is affected by the work of an organization or its deliverables, or as someone who contributes to the work or its outcome.

Now that the idea of a stakeholder has come of age in the project world, the new challenge is stakeholder relationship management maturity. Organizations that develop this capability quickly are likely to have a significant competitive advantage--at least until their competitors catch up.

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.