- Start your discussion by praising the other person who has just finished talking, even if you disagree with him or her. Normally we do not disagree with all the points of the other person, but we tend to ignore the points of agreement. Starting with praise will help you listen to the other person completely, and you will be compelled to try to find points where you agree rather than disagree.
- Remember that more talkative people spill more information, and that can be used against them. As talkative people listen less, their questions also often go unanswered. When you are aware that you may be providing unnecessary information to others, you'll make an effort to speak about only what is necessary.
- Better listeners get more information from others, which they can use to fine-tune their point of view and present it more effectively. When you're eager to improve your thoughts, you listen more carefully, because that helps you strategize. Listening will make you a better negotiator.
- Write down points of agreement and disagreement. When you write down the points, you have little option but to listen.
- If you do not get the opportunity to talk, the sky will not fall. Moreover, it is of little use talking in a forum that does not give all participants an opportunity to present their point of view. Most of the time, when someone says, "Listen to me," the opposite happens.
- Don't try to win the speaking contest. Instead, focus on winning the hearts of the people by understanding them. Many times, more talkative people appear to win the battle, but they lose the war. More talkative people do not converse, but instead force their viewpoint on others. This creates a negative perception of such a person that sustains beyond the conversation and impacts the overall relationship.
- Establish simple, fair rules. In a group, ground rules help create an environment of listening. For example, solicit opinions one at a time, give everyone two minutes to put up their points in round-robin fashion, or ask that everyone reiterate the previous speaker's point of view before making his or her own.
- Take an example from the deaf. I will leave you with a thought from A Comma in a Sentence by Indian businessman and author R. Gopalakrishnan, in which he gains a valuable perspective from hearing-impaired teacher Bruno Kahne. The book paraphrases Mr. Kahne: "Deaf people look at the speaker in the eye and make sure they are fully present in the interaction. They absorb more and retain more. In many management situations...there are simultaneous and multiple conversations. That will never happen with deaf people. They follow a strict protocol of one person speaking at a time. Consensus and agreement are reached faster than out of a heated and overlapping conversation. In the long term, slower is faster. Deaf people are direct and they communicate with their thoughts and feelings.... They are economical about the way they communicate. For the same reason, they listen well, too."
More posts in Communication
- The government's desire to look good by reducing patient waiting time
- The hospitals' desire to achieve the maximum budget income for the year
- The administrators' desire, both in the hospital and the government, to avoid rocking the boat
- The KPIs you choose communicate to stakeholders what you think is most important. What is easy to measure is not necessarily important.
- What you choose to measure will change behaviors. Focus on things that matter, such as value and benefits, not easy-to-measure statistics, such as time and cost.
- Make sure the data is validated.
- A KPI system cannot solve the problem, but it can be a powerful facilitator of solutions if it's set to measure the right statistics and ask the right questions.
- Build communication into your everyday plan. Project managers tend to get pulled in multiple directions. So instead of being the driving force behind the information flow, you end up reacting to the latest problem or sponsor demand. While you are never going to be free of these things, you can manage them more effectively by creating a communications plan. This can be as simple as having a daily status meeting to cover where everyone is, or as elaborate as a multilayered communications plan that accounts for interactions with sponsors, team members and stakeholders. Either way, start by planning for how you want to manage your daily communication, and your project management will get easier.
- Be specific. We find ourselves dealing with very complex and difficult projects. With this complexity comes the challenge of making clear your directions, instructions, timelines and goals. The best way to overcome that is by being extremely specific. As a project manager, you may not have the industry-specific technical skills needed to understand every aspect of your project, but you should know what goals are driving the project, which means you have the ability to set and understand very specific objectives for your team. This is going to help you not only manage the workflow more efficiently, but your communication with your sponsors, stakeholders and teams will be more efficient because you are going to have more specificity with which to address their questions and concerns.
- Show empathy and support. You know what pressure from sponsors, stakeholders and team members feels like. So take a step back and think about how those parties feel as well. After all, you are often at the center of the flow of all information into and out of the project. So to really move your communication and project management skills forward this year, be consciously aware of how the flow of information -- or lack of it -- can make your team and stakeholders feel. Let them know you understand how they feel about being a little behind on the information curve. Express your support for the project and the work that is being done. Often this little step of positive communication can win you big points with stakeholders.
- Realize that the sky will not fall if you lose the opportunity to express your viewpoint.
- Focus on content and not on speaker's style of delivery.
- Paraphrase the speaker's viewpoint before presenting yours.
- Stop multitasking -- prioritize and focus on one item at a time.
- Feelings, respect and experience are more important than results. Better feeling, respect and experience will bring better results.
- Organize your meetings to reduce interruptions. Do not rush your meetings. If you're crunched for time, allow fewer people to speak, but listen to everyone fully, respond and take notes.
- Seek feedback, publicly or anonymously.
- Appreciate! The more you appreciate others, the more others will appreciate you.
- Information or good advice that is of value to the receiver
- Help or a kind gesture
- Recognizing and appreciating a person's contribution
- Remembering events that are of importance to others
- Rewards, celebrating personal or group achievements and successes
- Sharing job opportunities or networking leads
- Creating convenient services for employees, such as complimentary or subsidized meals for workers or on-site child care
- Free services for clients and customers
- Thank-you messages
- Public acknowledgment or mentions of good work
- Stifles your talent and limits your opportunities for advancement
- Twists circumstances and conversations to their benefit
- Punishes you for a mistake rather than help you correct it
- Reminds you constantly or publicly of a disappointing experience or unmet expectation
- Takes credit or withholds recognition for new ideas and extra effort
- Focuses solely on meeting their goals and does so at your expense
- Fails to respect your need for personal space and time
- Manage your time. Set a limit on the amount of time you spend beyond the hours needed to complete the project work. For example, you should politely but firmly decline an invitation to a peripheral meeting.
- Express yourself. Reveal aspects of your personality that reinforce your values. Sometimes it's a matter of letting people in a little bit to help keep your boundaries intact. If aggressive behavior offends you, say so (in a firm, but non-aggressive way), but you also need to consistently act in an assertive (rather than aggressive) way.
- Build your reputation, and do it carefully and consistently. Everyone plays a role at work. Your co-workers should know what you stand for and what to expect from you. Then, don't waiver. Authenticity is the key -- behave in the way you expect others to treat you.
- Change the conversation. Stay focused on the project and away from nonproductive behavior. Avoid gossip, criticism and other negative conversations by simply stating: "I don't really have time to discuss that just now, but I really do need your input on this project issue." If the attack is on you personally, ask to "take the conversation off line and focus on this important project matter now."
- If you can't see and articulate how the change is actually going to work, it probably won't work. Explain "how" and keep explaining to everyone affected by the project's outcomes.
- While it's painful to integrate change management planning into your project planning, it's even more painful to watch your project fail. Make sure all aspects of the change are covered in your project plan or the associated change management plan -- and that the two plans are coordinated.
- Keep explaining the "whys" behind the change. Once is never enough! You need a well-thought-out and implemented communication plan.
- The only antidote to scaremongering is information. And that information needs to be accurate and believed. What's actually going to happen is never as bad as the things people imagine "might happen" in the absence of easy-to-understand, well-communicated facts.
- With clarity. Clarity is the most important factor for the success of portfolio management. People can't commit to what they don't know or don't understand. Clearly state and communicate the portfolio objectives, policies and procedures.
- With openness. On top of developing a nice-to-have framework for project selection, prioritization and portfolio monitoring, spread the word throughout the entire organization on why the company needs portfolio management and how it works.
- With alignment. Corporate objectives -- and how portfolio management can help the organization reach those goals -- have to be part of the message. Alignment means credibility for portfolio management, because it shows how it adds business value. To communicate the value, show the organization the selection criteria and key performance indicators and their rationale.
- With discipline. Portfolio management requires consistent feedback, information and reports -- mainly from projects and programs, but also from functional managers, senior managers and more. Discipline means setting up processes and procedures to push and pull communications in a dependable way for the organization. In other words, in-and-out communications have to flow without interruption, overcoming organizational barriers to get information needed and to provide useful, timely information.
- With accountability. Everyone in the organization should be responsible, in one way or another, for the portfolio results. That means project KPIs and portfolio KPIs should align better. And the best way to achieve that alignment is by ensuring everyone is on the same page about the corporate portfolio strategy, through rigorous governance and consistent communications.
- Be 100 percent attentive to what your speaker is saying.
- Let the speaker know that you are listening: establish eye contact and nod often.
- Be open to what he or she has to tell you and encourage honest communication, no matter what.
- Avoid making judgments about what you are hearing. Try to be empathetic about what is being said and wait until the conversation is concluded before responding. When something is not clear, try to rephrase it to make sure that you understood correctly, prefacing it with: "What I am hearing is that..."
- Provide feedback appropriately. If you feel upset or annoyed in any way, then call for a pause. The worst thing you can do is to continue a conversation that is making you feel uncomfortable, because inevitably, you'll stop listening and the speaker will stop talking.
- Don't be cute in the subject line. Attract the attention of the recipient using powerful, descriptive language in subject lines. Include a call for action when needed, including statements like: URGENT, FOR YOUR IMMEDIATE ATTENTION or ESCALATION REQUIRED.
- Limit the distribution list. Include only the interested parties in the messages. Beware the "Reply All" button.
- Start fresh. Remove unnecessary email trails -- for example, when the messages start to deviate from the original topic. Better yet, when possible, create a new message to continue the discussion.
- Manage response expectations. Let your team members know the reason for a delay, in the event you are not able to take immediate action on a request or conversation.
- Filter and follow the thread. If the number of messages on a topic starts to get out of hand, sort them by subject or conversation. Return to the first of the sequence to find clarity on the issue at hand. Then, scan the rest of the message's trail to determine what requires attention and action.
- Do not engage in email battles. Avoid confrontation online. It is just not productive and creates clutter in your inbox. If you spend more than 10 minutes crafting an email, you are better off scheduling a meeting or call with your counterpart to address the problem in an actual conversation.
- Turn on auto-reply. As a courtesy to your teammates, enable the "out-of-the-office" feature. Specify your length of absence from the office and who will be covering while you are out.
- Make thorough meeting invitations via email. List the agenda and attach any documents that will be reviewed during a conference call. Do not send documents minutes before the call, expecting that attendees will be online.
- Always include the meeting location. In the location box of your calendar invite, include the meeting room data and any pertinent communication information, such as the conference bridge number and PIN.
- Check the availability of meeting participants. As many email clients allow you to check a participant's availability, do not send calendar invitations knowing that one or more participants are unavailable. This will reduce email traffic.
- A "best alternative to a negotiated agreement," such as outsourcing that activity or employing externally for that role.
- A "worst alternative to a negotiated agreement," which may include canceling or delaying an activity.
- A "walk away point or price." This is the point at which parties agree to step away from the issue to regroup later to consider the options — or end the negotiations because options are unacceptable.
- A "zone of possible agreement," where interests overlap with the other negotiating parties. For example, that could be an agreement to have the resource part-time, do a resource swap or take some responsibilities from the department.
- Each stakeholder needs something from the project to further his or her interests, or alternatively, needs nothing from the project.
- The project requires the active support (assistance or resources) of the important stakeholders, or alternatively, requires nothing from the stakeholder.
- Project needs nothing/stakeholder needs nothing: Stakeholders in this quadrant are usually protesters. In this case, you have two communication options: You may be able to defuse their opposition by providing better information, but this only works if the protesting is based on false assumptions. Otherwise, you may choose to limit communication with the stakeholder whilst keeping the communication channels open.
- Project needs nothing/stakeholder needs something: The stakeholders in this quadrant are the easiest to manage from a communication perspective. You are already providing their requirements as part of the project deliverables. All that's required is to provide reassurance that their needs will be fulfilled. If their requirements are outside of the project's scope, the stakeholder should initiate a change request.
- Project needs something/stakeholder needs something: This group needs active management. Project communication must clearly link the stakeholder's support or resources to how the project fulfills his or her requirements. Take the time needed to develop robust relationships to facilitate cooperation.
- Project needs something/stakeholder needs nothing: Stakeholders in this quadrant are a major risk. They're typically regulatory authorities, or people who have to inspect or approve the project's work as part of their business. Carefully build a proper professional relationship that respects the integrity of the stakeholder's position while at the same time ensuring your communications are received and acted upon.
- Did you regularly communicate with the team? Were there provisions for local team members vs. members located abroad?
- Did you establish a systematic process, such as a daily phone call or e-mail?
- Did you make face-to-face rounds from time to time to show your interest and have diligent participation with your team?
- Did you express the positive and negative project information?
- What communications methods and tactics did you use?
The challenge of effective communication is keeping a consistent point and changing your presentation and rhythm to avoid becoming boring.
Great communicators use a similar approach to great music. It does not matter if you listen to Beethoven's "Symphony No. 5" or Queen's "Bohemian Rhapsody." You find consistency and variety in both. Patches of high intensity contrasted with quieter movements create a memorable and complete masterpiece.
The same effect can be achieved in your communication by balancing positive and negative elements of a message or changing the direction of the information flow.
For example, if you want someone to stop an undesirable behavior, point out the problem, but also highlight the benefits of the change you want to occur. Or rather than telling the team they are behind schedule, change the direction of the information flow and ask them for ideas to regain the lost time. The point you are making is consistent, but the variety in presentation leads to engagement.
Another key element is to finish on a high note. Great music does not fade away. It builds to a crescendo!
Great communicators such as Martin Luther King Jr. or Winston Churchill had a consistent, heartfelt message they communicated in a way that would create a strong reaction in their listeners.
Both had different speaking styles, but each had a real sense of rhythm and performance. Their speeches are carefully crafted for effect, but the presentation adds enormous weight to the message.
While you may never need to 'fight on the landing fields' or 'have a dream' to change a nation, taking the time to think through how you will present the information in your communication in a way that is engaging and memorable will help you be more effective in getting your message across to your audience.
Do you spend more time drafting your message or thinking about how you will communicate the message?
But what about when your sponsor or upper management is present? What are their roles?
Rather than shelter upper management from lessons learned, consider their value in these sessions. Don't have upper management viewed as attendees who just want to hear the rehash of problems that the team doesn't want to relive anyway. Nor should you have upper management included to be a part of the blame game.
Ask your sponsor and upper management to be open minded and supportive advocates in receiving feedback toward improvement.
Here are three ways to get upper management to engage:
Talk: You, the project manager, must engage upper management in the discussion. Review the timeline and other milestones that took place on the project. Upper management could talk about how the goals of the project and the team's successes intertwined with the strategic goals of the company. The team would appreciate this perspective on the significance of their activities.
Listen: While some discussion points may not be pleasant for upper management to hear, their presence assures a level of impartiality to the team. Knowing someone from "up top" is listening reinforces the team's drive to be a part of a high-performing group. Getting to more favorable end results in future projects would become even more desirable for the team.
Share: Have your sponsor share comments about the purpose of the project and its greater use to the organization, the end users and the community. Have them elaborate on processes. Ensure early on that they recognize processes mentioned in the discussion that could be rewritten or are no longer necessary. This sharing will foster bonding with the team.
How do you involve your sponsors and upper management in lessons learned sessions?
I have actually done this myself as a project team member. As someone technical, and who also has project management experience and knowledge, I have tried to impart that wisdom to my project manager.
I clearly remember one project manager I would advise on a number of things. It's in my nature that when there's a gap -- whether in communication, documentation, project planning -- I want to point it out.
The dilemma is that if you impart your knowledge too forcefully, you are possibly invalidating the project manager.
In certain situations, that advice becomes unmanageable and puts more pressure on the project manager, not only to manage the project but also to manage you.
If we feel there's a need to bring something to the table that is going to add value to the project, it needs to be brought up as such. You should not expect that the project manager would just implement it because you said so.
Before you even do that, consider asking yourself why you are thinking a particular way about a situation. Why are you asking for the changes? How does it resolve a specific issue that you are dealing with?
Challenge yourself. See if you can adapt and work with your team, deliver what you are required to deliver and, as appropriate, bring up the items that you feel can add value to the project. Understand the value of your place in the project and fulfill on the expectations others have of you.
How do you handle project team members who forcefully suggest their ideas?
Communication, of course, is what we project managers spend the majority of our time doing. Public speaking is common enough for us.
All communication is about sharing meaning. To be effective, we need to have a good understanding of whom we are talking to and what will influence his or her understanding of the message we are trying to communicate.
The best communicators have a keen ability to be very attuned to the other person. It helps them develop a rapport that makes real understanding happen more readily.
Effective public speakers bring this ability to the group setting. They master the ability to be dialed in, not to the group, but rather, to many individuals simultaneously.
Some people who are extraordinarily good in "one-on-one" situations can be very ineffective as public speakers because they find it so distressing. Much of what people find distressing stems from self-consciousness -- they are overly concerned with how people perceive and react to them.
Forget self-consciousness. Be other-conscious. If everything we do is focused entirely on the listener as an individual, it can help us have the kind of rapport essential for good two-way communication.
The mistake people often make is to view public speaking as addressing an audience -- a nameless, faceless and even a potentially hostile audience. Rather, we should view our listeners as a collection of individuals with whom we need to establish separate relationships in order to effectively communicate with them.
But don't ignore yourself in the process. On the contrary, because of the importance of the speaker's role, visibility, prominence and leveraged influence, the speaker must pay particular attention to him or herself. And that means, with a mind toward the other.
What do you think? Does being self-conscious help you be other-conscious in all communications, not just public speaking?
Read more about speaking in your project management career.
Get more career help.
We concurred that when the person receiving information has a low retention, it results in false assumptions and misunderstanding the topic of discussion.
Why is this happening? Why, if the person receiving information confirms that everything is clear, do we still we face communication issues in projects? Usually, it's because taking notes in a meeting is going away, as many team members wait for a meeting recap that notes their action items.
In face-to-face communication, we spend most of the time listening -- and apparently, we're not good at it. We filter what we want to hear and that may result in a broken message.
The senior member of my team referenced earlier is part of the silent generation. He mastered his listening skills in an environment without all of the ways to "replay" conversations that we use today.
In addition, he mentioned that the communication environment was "less polluted" than today, where we are bombarded with things that affect our ability to pay attention.
I asked the senior team member what are the key elements of good listening skills, based on his experience. He recommended:
- Pay attention to the dialogue and receive the message.
- Acknowledge the message using positive expressions, such as "OK" or "I see."
- Confirm the message was received by summarizing what was discussed.
- Ask questions to the person giving information during and after the discussion.
Editor's note: The title of this post was changed on 9 December 2011.
Do you make time to identify your requirements for managing a project? Sure, you plan and manage the project, but as a program or project manager do you also identify your needs for running the project and the team?
It's important to know what we require of our team and stakeholders. When these needs are clearly identified and communicated, it's easier to track and manage the related project tasks and variables.
For example, I recommend that you require your stakeholders to attend meetings and give input during the change management process. You'll need the decision makers to assist you in evaluating the need for change.
When you set and express this participation as a requirement, your stakeholders understand your requirements and their own importance. Further, when a change is requested during the project, it doesn't come as a surprise that you expect stakeholders to be involved in the process.
When it comes to your project team, maybe you require team members to be on time for meetings and to submit progress updates. Communicating this as a need and setting the expectation helps ensure that team members give timely feedback when needed. When team members meet this particular need, you're able to meet your own deadlines with the customer.
Setting and communicating project management requirements are nothing new. For the most part, these needs are automatically expected from everyone involved in the project. But failure to pen down and communicate each need usually leads to more project challenges. For example, team members may start to argue, finger-point or shake off their responsibilities. There's also the possibility of missing a milestone -- and that's something to avoid.
Take time as the project manager to set your requirements for running the project. And do so as a high priority.
What requirements do you establish for managing a project? Do you communicate these to the project team and stakeholders?
Projects act as catalysts that play a vital role in building "a better tomorrow." But without a sophisticated project management platform, it's difficult to be successful.
A project management platform includes policies, procedures, standards, guidelines, integrated project management processes, tools, techniques, templates, project assets library, best practices, learning assets, lessons learned or next practices.
Many micro and small organizations, governments or those in emerging economies frequently don't have the enough money to invest on sophisticated information technology in building and maintaining a project management platform of their own.
This major divide in the profession could be reduced through cloud computing -- providing businesses, governments and individuals with access to a reliable project management platform over internet at an affordable price as per usage (on rental basis). This is called Project Management Cloud (PM Cloud).
Following are a few indicative PM clouds:
• Engineering & Construction PM Cloud
• Information Technology PM Cloud
• Research & Development PM Cloud
• Government PM Cloud
• Education PM Cloud
Those using cloud computing can avoid not only major capital investments, but also the ongoing complexity of managing the technology challenges.
When project management clouds (PM Clouds) are available at an affordable price, as and when needed, they can impact project management in the following ways:
• Provides leapfrog opportunities to emerging economies and small enterprises able to compete globally by leveraging "best-in-class" PM clouds
• Fosters innovation as companies leverage more affordable PM cloud options to experiment
• Minimizes the divide between small and large enterprises. Provides equal opportunities as project management clouds become available at an affordable price
• Allows for global collaboration with project talent around the world
• Facilitates global and interactive learning at an affordable price
We're still in the nascent stage of providing sophisticated integrated project management platforms in the cloud, but eventually, cloud computing will impact the way the project management is done in the future.
How do you think cloud computing is impacting project management?
Every major turning point in my career within the last eight years -- everything that I would call progress -- can be traced back to one thing: public speaking.
Eight years ago, on the advice of a few colleagues and friends, I decided to take my project management stories and experiences to a broader audience and enter the world of public speaking. I hadn't anticipated how wonderful it would be to share stories and experiences with so many fine people. Nor could I have ever imagined the world of possibilities it would later open up to me.
Success in project management certainly depends on capability. But it also depends on exposure and on the image you convey. What better way is there for you to gain exposure and to project an image as a capable project manager than to stand before a group of colleagues and share your knowledge on the profession?
When asked about public speaking, people often say, "I wish I could do that."
I say, "Why can't you?"
Each one of us has a unique perspective and unique experiences. All that remains to be done is to tell the stories in a compelling way. That takes some work and some practice, but it is within reach of any professional. I'll address some ways you can be a great public speaker in my next post.
In the meantime, I'd like to know if you ever considered public speaking? Why or why not? How has it helped shape your career? What tips can you share?
Many of today's agile project teams are distributed around the globe. While simple implementations of agile processes assume co-location, in larger enterprises, this is rarely the case. Selecting tools to assist remote communication helps, but it's not enough.
Here are some human factors to consider, beyond the tools, to work successfully with a distributed team:
Cultural differences can become apparent when working with global talent. Some people are uneasy if some social small talk is omitted as part of doing business. Some are uncomfortable if we don't simply get to the point. This affects agile teams as they implement practices such as self-organization, pair programming, and retrospectives. Remember people's assumptions can vary.
Time-zone differences can be helpful by providing longer hours of coverage. But check with your teams on when they begin and end their workday. Different cultures have different laws and traditions on when to go home. Not all people have private transportation, and not all countries use daylight savings time.
Finding teams in compatible time zones can be an advantage with more hours of coverage, if the hours and needs are remembered. Partnering with teams that are north or south of each other makes this easier because the time difference is less extreme.
Communication differences among distributed teams also require forethought. Agile teams will notice a need for engaging and informative tools in their story grooming, estimating, planning and retrospective meetings.
Telephone calls can be awkward because there is no visual cue as to who is speaking and no person to look at. Also, sound varies for each person depending on if they are in the same conference room, on a speakerphone, using a headset or cell phone. Make it a point to include people on the phone if part of the group is face-to-face.
Video conferences or webcams might be a better option. Be aware of the background so it is not distracting. Also be aware of the lighting quality and direction -- illuminating an attendee's face is better than a dark silhouette.
Spatial user interfaces, which extend traditional graphical user Interfaces by using two or three-dimensional renderings, give people someone to look at and allow positional body language and gestures to convey nonverbal information. However, be sure to allow training time for participants so they can make the most of these environments before needing to concentrate on a meeting.
By using the right tool and having the right mindset, agile teams can work together across wide distances.
How do you work successfully with distributed teams?
Now, there are many choices in terms of outsourcing, and technology plays more of a role in project communication. As such, GDM 2.0 is on the horizon. And project managers must reorient themselves to the changed environment of cloud, social and mobile computing.
I would describe GDM 2.0 as "intelligently distributing the project's work, team, leadership and governance across multiple locations and leveraging technology to provide high-speed, high-quality and low-cost solutions to global customers."
A few of the tenets that contribute to providing customer value using a GDM 2.0 are:
- Reduced cost: Executing projects at low-cost locations spanning multiple countries, cultures and languages
- Abundant talent: Accessing talent across different locations
- Follow the sun: Leveraging time-zone differences to maintain continuity in managing projects
- Quality of service: Using best practices, lessons learned and standards to provide faster, better, cheaper and steadier services
- Knowledge and collaboration: Implementing robust knowledge-management systems to help build a seamless flow of information across multiple teams, projects and locations
- Continuous learning: Using ongoing training to prepare project professionals for the market, customers and projects
Here are a few of my thoughts on the future of GDM 2.0:
1. Almost all IT service providers are now building their own private clouds, making the provisioning of IT resources faster and cheaper. In the past, project managers had to wait for weeks or months to get certain IT resources.
2. IT service providers that develop applications using platform as a service (PaaS) and that implement package applications using software as a service (SaaS) now involve cloud providers. Project managers must be aware of the various risks, contractual obligations, security issues and potential legal issues of working in this multi-party environment.
3. IT service providers are building process platforms that leverage cloud infrastructure. That means project managers must learn to work with competitors, as customers might select process platforms from multiple IT service providers.
4. Mobility in project management will be a norm in the GDM 2.0. IT service providers have to mobilize their project management, software engineering and other critical governance processes to improve project performance. These service providers will need to make investments to rebuild their project management tools and applications to work on mobiles or to procure mobile project management applications.
What do you think the future of GDM will hold?
See more posts on project communication.
Research by behavioral economists has demonstrated people are naturally irrational. The challenge is to accept people as they are and then work rationally within our innate biases.
When your project has an issue that has already caused a cost overrun and needs more expenditure in the short term to potentially recover some of the losses later, you and your stakeholders may experience a bias called loss aversion. Most people will make risky decisions to avoid a loss, but are reluctant to make a decision of exactly equal to achieve an exactly equal gain. And most people also tend to prefer short-term gratification to long-term benefits.
Therefore our natural instinct is a strong bias towards not losing more money -- even if the short-term loss is significantly outweighed by a longer-term gain. The best antidote is a credible communication process that outlines the issues and risks, supported with additional reference materials such as the PMBOK® Guide.
Proximity bias is to prefer our own creations to other people's creations. This tendency is reinforced by what behavioral economists call the "IKEA Effect." The more labor we expend on a project, the more we love the result -- regardless of its quality.
Before your manager expends too much effort on her own solution the problem, you should communicate in a way that allows a jointly crafted solution to develop.
When communicating with senior stakeholders, try to help them resist these biases while working to avoid them yourself. Rather than provide your solution, offer a range of ideas that allows stakeholders to own the solution (with your help). Aim to shift their thinking to a viable benefits-focused solution.
How do you cope with biases among stakeholders?
Read more from Lynda.
Read more on stakeholder management.
The PMBOK® Guide differentiates between the:
• Message -- what you want to communicate
• Medium -- the way you send the message and
• Noise -- things that interfere with comprehension.
The concept of noise disrupting communication is easy to appreciate when you are talking with a stakeholder, either face-to-face or on the phone. But what many project managers fail to realize is that the same principles apply to written communication.
A significant body of research suggests a well-designed document can communicate up to 80 percent more information to your stakeholder than one that is poorly designed.
Consider these elements when designing your next project document:
Page layout: In most cases, the eye starts naturally at the top left of a page and flows down to the bottom right. Ignoring this flow disrupts the natural reading pattern and reduces comprehension.
Clutter: Multiple fonts, font sizes and colors may create a great visual impression but fail the communication test. The best combination for text color is a black font on white background.
I find that serif fonts, like Times New Roman, are easiest to read in the body of a document. Sans serif fonts like Ariel look cleaner in headlines. Use one of each with minimal embellishment to reduce noise.
Page design: Leave plenty of white space at the margins, between paragraphs and around images. Place key messages in headlines, use diagrams wisely and caption them effectively.
Designing an effective document layout is an art -- you need to balance creating an attractive document with making the information inside easy to read and understand.
Do you think document design can impact your project's communications with your stakeholders? Why or why not? Tell us about your experience.
Read more posts from Lynda.
Read more posts about project communications.
Arguing with your stakeholders is never good.
The basis of an argument is to defend your position while defeating the other person's in the process. It's easy to suggest using active listening to understand the other person's viewpoint, but this advice overlooks the inevitable build up of emotions inherent in any argument.
Asking the help of a third party to mediate an argument with a stakeholder can be very useful. First, the presence of an observer helps contain excessive emotions. Secondly, a third-party observer can bring fresh insights to help move the argument to a constructive discussion and, ultimately, a solution.
Transitioning from a sides-based argument to an "us"-based solution does not require the third-party observer to necessarily solve the problem. Rather, the mediator should help those arguing to develop a solution.
An ancient legend demonstrates this concept beautifully:
A farmer died and left his herd of 17 camels to his three sons. In his will, he left half of the camels to his eldest son, one third of the camels to the second son and one ninth of the camels to his youngest son.
The three brothers were having great difficulty working out a fair way of implementing their father's will and could not agree on who would have more and who would have less than the amount willed. Before their relationship became too stained, the brothers went to visit a wise old woman who lived in their village to seek advice.
She told them she could not solve their problem but would give them her only camel if it would help.
The brothers thanked her and took the camel back with them. With a herd of 18 the problem simply disappeared; the first brother took 9 camels, the second six and the youngest two.
But, 9 + 6 + 2 = 17, so they gave the spare camel back to the wise old lady with their thanks.
The point of the story, from a project management perspective, is that belaboring arguments with stakeholders will only succeed in delaying the project. For the sake of keeping the project within the triple constraints, it's best to resolve arguments promptly and for the good of the project.
In your projects, how have you handled arguments? Do you seek help before positions become entrenched?
Make a sign that says, "I will communicate better!" And then place it where you can read it aloud once or twice a day. After all, 90 percent of a project manager's time is spent communicating -- do it better and you can expect better project outcomes.
The first part of better communication is learning to listen for meaning, which goes beyond just hearing the spoken words. As the late U.S. State Department spokesman Robert McCloskey once famously said, "I know that you believe that you understood what you think I said, but I am not sure you realize that what you heard is not what I meant!"
This applies to most people when they speak about technical subjects they're not totally comfortable with. Understanding that person's meaning taps into his or her expectations, emotions and requirements. Manage those three things and you are on your way to success.
The second part is learning to communicate what you mean effectively. A few ideas to help keep your message clear and concise:
• Either avoid jargon and acronyms or make sure everyone understands them. Note that people are reluctant to admit they don't understand.
• Remember Albert Einstein's advice: "If you can't explain it simply, you don't understand it well enough." Clarity is inclusive and builds understanding.
• Make sure your meaning is clear by checking for understanding before worrying about agreement, or disagreement. If your listeners misunderstood something you said, and agree to it, you have a problem.
You've probably been doing the other 10 percent of your job right for a long time. Make improving communication a defined action plan for 2011 and see what happens when you get better at the 90 percent that involves communications.
What other project resolutions do you have for the upcoming year?
Problems have one right answer that can be reached by analyzing the information you have.
Dilemmas don't have one right answer. Any solution will be at least partially wrong, unfair or harmful to some stakeholders. But not making a decision will be harmful to all stakeholders. The challenge is to minimize the damage and, occasionally, to optimize the benefit.
Mysteries are often hidden within too much information. Understanding them is closely aligned to the ideas contained in complexity theory and risk management. Accepting your inability to know the answer to a mystery is critical: Make the best decision based on the limited information available while staying prepared for surprises.
Puzzles can often be resolved through measurement and research. Gather the right information and skills, and you reduce a puzzle to a problem and can then calculate the optimum answer. If there's insufficient time to gather and analyze all of the necessary information, though, you may be forced to deal with the decision as a mystery,
When confronted with a difficult decision, recognize the differences between the types of possible decisions and then use the best approach to reach your conclusion. Many issues around decision making stem from a false hope that we just need a little more information to reduce a complex decision to a problem with just one right answer. Yet in many cases, this is just not possible.
All project managers make decisions. The difference between good project managers and great ones is the percentage of decisions they get right.
But we don't often talk about honoring our word -- acknowledging when we can't meet a commitment.
There will inevitably be times when we can't keep our word as circumstances change for one reason or another.
Say you've committed to meeting a milestone on a specific date, for example. To keep your word, you have to do whatever it takes to make that date. But to honor your word, you only need to follow up with the person you made the commitment to and clarify why you can't meet the deadline. I'd also recommend recommitting to a different date, time or scope.
This way, you're not simply hiding and hoping that things will work out, or that you won't be asked about a deliverable. Be confident enough to raise the issue directly, knowing that it will maintain a workable relationship.
Even if you're unable to deliver as promised, you can at least be relied upon to raise red flags early enough, without downplaying the severity, to allow the client or team time to align their activities accordingly. And that saves time and money.
To maintain a healthy relationship on your team, you must honor your word. It impacts the results of your work, your reputation, and your ability to earn a renewed trust from your clients and project team members.
Honoring your word restores your integrity and creates workability. But the better you assess estimated target dates for the project tasks and milestones and your ability to manage your day-to-day activities per your own commitments to others, the easier it will to keep your word and "do it right the first time."
Agencies and clients who spent the past century perfecting project management functions around print, broadcast and direct mail are being forced to readjust systems to the complexities and rapid-fire change of digital marketing.
Two worlds are colliding.
Digital teams view process as an essential science. The project manager is the team lead that everyone depends on for risk management, communication, client management, profitability and ultimate success.
But traditional advertising teams tend to see process in a different light. They look to their account and creative directors as the team leads. The project manager, while important, often takes on a more administrative role, ensuring resources are in place, schedules are communicated to vendors and paperwork is complete.
When I took on my first role as a manager of a project management office (PMO) for a large ad agency two years ago, the difference between these two worlds became vividly clear to me in a conversation with one of our creative directors:
Me: We need to translate the client brief into a statement of work so we have a specific record of what we'll be delivering.
Creative Director: We don't know what we'll be delivering yet.
Me: Then we should meet with the client to understand business requirements and document them for sign-off.
Creative Director: I know what the client wants, but I'm going to tell them what they need.
Me: Then how do I budget resources, document our success metrics and track the progress of the project?
Creative Director: That's your problem. We'll let you know when we get there.
It was an eye-opener, to be sure. But eventually I was able to adjust my view of what the team was trying to achieve. I set a baseline process to create a flexible methodology that would allow us to pull in elements that were appropriate, and not commit time to requirements that didn't lend a lot of value.
Some of these changes included a flexible, scalable methodology that allowed teams to pull in elements relevant to their process. This allowed them to:
Have you ever been in a situation like this? What have you done to maintain rigor in your environment when the project at hand did not readily lend itself to the traditional project management processes?
- Maintain efficiency while ensuring consistency across the agency
- Reinforce the "triangle of truth" (good, fast, cheap) in the scoping process to ensure profitability
- Implement grassroots efforts to reinforce the importance of maintaining rigor in the process through tactics like "Lunch and Learn" sessions to discuss our process and the risks inherent in not following it.
As a number of commentators correctly suggested, the appropriate quality for the documentation depends on its intended use. Certainly information sent outside the organization should be as close to perfect as possible and "two sets of eyes are better than one."
This wasn't the core issue, though. Sebastian is proofreading and correcting minutes, notes and other internal, short-lived documents to the same high standard.
The purpose of technical documentation within a project is to get ideas across in a way the concerned audience can understand. Sebastian's team may need training and support to create effective documentation, but striving toward perfection doesn't add value.
The key to solving this problem is helping Sebastian understand that continually criticizing people for not achieving perfection can be extremely debilitating and will reduce his team's effectiveness. This is not his intention, but is the perception of people who receive Sebastian's heavily corrected documents.
The ideal solution is to get Sebastian to understand how detrimental his behavior is. Achieving this may require people who Sebastian sees as experts and advisers to coach him to improve his team-management skills.
Alternatively, effectively "advising upwards" by focusing on Sebastian's real interests, such as product delivery, may be a solution. Neither of these options, however, is likely to provide a quick solution. Changing habitual behaviors can take years and requires the person making the change to want to change.
A more practical alternative may be to reframe the problem. Written communication is only one way of conveying information. Alternative approaches may include scheduling brief discussions to resolve issues, using web portals to make documents shared resources where everyone contributes or changing the media to something where grammatical structures are less important.
Unfortunately there are no easy answers to this problem. For those on the receiving end of Sebastian's corrections, recognize that a criticism of a document you have written is not a criticism of you and use the opportunity to improve. (You should see what the editors do to our posts...LOL)
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.
When the C/SCSC came out in the United States in the late 1960s to early 1970s, the Department of Defense insisted that organizations with whom they did business had a fairly advanced project management information capability. Because this insistence was attached to large amounts of business, companies took notice and quickly put into place the codified project management practices called for in C-Spec.
Coming as it was from the United States Department of Defense, you just knew there would be plenty of acronyms.
The time-phased budgets were known as the budgeted cost of work scheduled, which quickly became BCWS and shortened again to just "S."
Similarly, earned value was the budgeted cost of work performed, abbreviated to BCWP and then "P."
Actual costs, being the actual cost of work performed, then ACWP, had the same last initial as earned value, so it became just "A."
Three of the most important concepts in project management information theory had been reduced to single letters. It could even be argued that this entered the realm of code: a code that only the true believers of project management knew by heart.
But there was no earthly reason to know what the project managers were talking about if you were a newly minted MBA or an accountant.
Their faces would likely assume aspects not unlike those of archeologists trying to understand hieroglyphics pre-Rosetta Stone.
Project managers could discuss their cost and schedule performance openly, even the ugly parts, without fear that the non-believers of project management had a clue what was being asserted.
Indeed, the folks in accounting took the opposite tack. Their communications lost their original precise definitions and are now mainstream. The "bottom line," originally the last line of information on a profit and loss statement, entered the business lexicon and eventually became synonymous with the final outcome of a process or event.
But you know you're in the company of project managers if you overhear a discussion on the merits of the CPI and SPI at the cume level (the reporting of the schedule performance index and the cost performance index at the cumulative, or life-cycle-to-date, level). The Defense Acquisition University actually publishes a "Gold Card," which is, in essence, our secret decoder ring, defining most of the commonly used project management acronyms and formulae.
At least we have the "Gold Card." What do y'all think?
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.
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?
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.
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?
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.
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.
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.
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.
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 the 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.