The core purpose of communication is to share information or direct a behavior change. This is particularly true of communication with your project team members.

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?

In a lessons learned or project review session, your attendees will usually provide feedback freely. Hopefully, they know the purpose of these sessions and their roles in it.

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?

Have you ever been at a meeting where someone tries to tell you what you should be doing and how? Even though you are the project manager -- the one who guides the team and makes decisions -- you still have people offering their two cents. The advice can come from a project team member or a credentialed project manager on a different project.  

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?

In my last post, Contagious Enthusiasm in Public Speaking, I talked about how being overly self-conscious can inhibit your effectiveness as a public speaker. I also know that public speaking is a valuable way to enhance your career growth. I promised to explore the idea of being fully "other-conscious" a little more deeply.

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.

After a recent project progress meeting with my team, one of the senior members and I discussed the face-to-face communication challenges we have with other members.

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.

What are the face-to-face communication challenges you have experienced with your team? Do your team members pay attention when you speak?

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?

The first global delivery model (GDM 1.0) was created a few decades ago to reflect the outsourcing and offshoring of IT services, mostly in India. A global delivery model is typically a method of executing a technology project using a team that is distributed globally.

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.
 

Have you ever wondered why communication with senior stakeholders so often breaks down? It's because of the deeply embedded cognitive biases innate to all of us.

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 purpose of communicating with any stakeholder is to build his or her understanding of a project. But there is a huge gap between looking at a written message and understanding its contents.

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:

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?

New Year's resolutions are rarely maintained. But one simple action plan can dramatically improve your project outcomes.

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?

Making decisions is a central part of any project management role, but some decisions are tougher to make than others.

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.

We often talk about keeping our word -- making a commitment and sticking to it, no matter what.

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."

Some people see advertising as primarily a creative business -- antithetical to the rigor and disciplines of project management. But the complexities of today's marketing mix are changing that perception.
 
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:

• 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.

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?

In one of my last posts, "How Much Proofreading Is Too Much?" I wrote about another hypothetical situation involving Sebastian and his habit of correcting everything written.

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)

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.

Frankly, I have no idea why or how the perfectly working lingo of the old cost/schedule control system criterion (C/SCSC, also known as "the C-Spec") has been superseded by the more recent, trendy jargon, but I am pretty sure project management, as a discipline, would be greatly enhanced if only we could go back to the way it was.
 
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?

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.

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?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

More on this soon.

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

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

But at least some of that detail is important.

My suggestions to resolve this conundrum are:

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

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

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

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

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

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

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

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

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

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

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

Other challenges include:
•    Identifying the right people to communicate with--the project manger is 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.

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

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

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

The key is helping your boss look good.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Here is what they said:

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

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

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

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

When the University of Maryland University College Graduate School of Management & Technology e-Business and Project Management Program adopted my book, The Power of Acknowledgment, for one of their courses, I began leading live, interactive online seminars once a semester. Several students sent me discussion questions ahead of time. These questions from these adult learners in critical jobs have been very thought provoking, and I wanted to share my thoughts on one of them. Others to follow...

Question: "How do I handle a supervisor that doesn't give acknowledgments?  ... It has gotten so bad, that I'm happy when he doesn't come to work and I have to deal with his supervisor who has a totally different management style.  I think you may have some ideas that I can use."

And I do:

•    Create a culture of appreciation in your organization. You personally can be a champion of change in your team's or department's or your company's culture. I know this sounds difficult, but you can start the process by making sure to acknowledge both your peers and the people who report to you in a heartfelt and authentic way. Your example will start generating a desire to "pay it forward" and after a time your manager won't be able to ignore the shift he or she is seeing around him or her.  

•    Acknowledge upwards! I believe our managers or bosses are among the most under-acknowledged people in the workplace. And even a boss who doesn't give acknowledgment can see and feel the impact of being acknowledged truthfully and in a heartfelt manner. And yes, you may have to really search for that acknowledgment but I promise you, something worthy of being acknowledged for is there.

•    Speak as off the record as possible to your "grand-boss." (i.e. your manager's manager.) There is some risk here of word getting back to your manager but it depends on how desperate you are, in order to see if this approach makes sense.

•    Know how much you can take. If the lack of acknowledgment and appreciation is too devastating for you, you may have to request a transfer to another department or even leave the company. This is not an action to consider except as a last resort.

   E-mail me your questions about establishing a culture of appreciation throughout your organization, and about using the power of acknowledgment to create miracles on project teams, in your departments and throughout your organization. You will be amazed at the results once you start using the power of acknowledgment.

Editor's Note: Judy Umlas is author of The Power of Acknowledgment, published by International Institute for Learning Inc. through IIL Publishing, New York.

If I had a dime for every copy of every project management article that prodded the reader to further engage stakeholders, I wouldn't have to spend time writing this blog. I could probably buy New Zealand.
    Indeed, failure to engage stakeholders has become the cardinal sin of the project management industry if you read all the trade journals. I do believe that they are only a short distance away from requiring all managers of failed projects to wear a scarlet FES, for Failed to Engage Stakeholders, reminiscent of Nathaniel Hawthorne's novel of a very similar name. Being the hopeless iconoclast that I am, I can't help to make the opposite assertion: Project managers should eschew these all-wise, all-knowing stakeholders for the following reasons.
    First off, who are we talking about here? Which "stakeholder"? If it's the customer, then, of course, "engage" them (which, I assume means, you talk together). But keep in mind, customer involvement often involves their asking for additional stuff on your project or higher quality standards. The desire to accommodate these stakeholders is the most common cause of that most fatal of project-killers: scope creep. And, once a good dose of scope creep has wrecked your project, it won't do the culpable project manager any good to respond, "I was just engaging the stakeholders!"
    Then there are the stakeholders who are neither on your project team nor in your customer's organization: These are "nuisances." If the scope of your project involves doing something that provably impacts others in an adverse manner, that's your customer's problem, isn't it? They probably should have spent a little more time getting the appropriate permits before they ponied up the money for your baseline. And, if these stakeholders don't belong to your or your customer's organizations and aren't provably adversely affected, then they should probably shut up and go away. Does that sound harsh? Okay, they don't have to be ignored or exiled, but they absolutely should not be consulted on what should happen on your project. Indeed, to do so is akin to project management malpractice.
    So there. I was getting a little tired of nobody posting comments on my blogs, and I figure this piece will pretty much cure that.

I often find that communication between project managers and senior management is very limited or nonexistent. There are several reasons. One reason is the busy schedule of executives. And other reasons might be the lack of interest shown by the project managers, as well as the need to perhaps hide something that project managers feel should not go up to senior management.
    But it is an important part of keeping up with project progress.
    Reviewing progress and profitability should not be something that waits until year's end. Instead there should be some monthly or quarterly checkpoints in between. This regular communication should also include client feedback--both good and bad.
    In most organizations, senior managers or account managers require project managers to conduct daily/weekly status meetings and publish the minutes of meetings. These meetings are usually kept internal to the team and there is rarely communication with the senior manager or account manager about the discussion.
    Senior Management Review (SMR) reports--which lists things such as project risks milestones achieved--prepared by project manager for senior management and other support/effected groups also do not promote accountability as they can be manipulated for convenience.
    How can project leaders and senior management solve this problem? By having someone independent of the project of someone on the client side (e.g. business analyst) prepare a monthly status report. The report should include:
1.    Resource Utilization
2.    Billing Done for the Month (to be provided by project manager and this should match with the value submitted to accounts)
3.    Earned Value generated by the Team (to be provided by project manager and this should match with the value submitted to accounts)
4.    Work Projection for Next Month
5.    Testing Quality (mainly for IT projects)
6.    Highlights/Lessons Learned
7.    Operation Decision that need SM/Account Manager's review
8.    Items to be taken in company's Interest
    By doing this, senior management will have an insight to the project and can act accordingly before it gets too late. Project managers should not behave like a stranger in a crisis situation.

People want more accountability out of U.S. federal government programs, according to a new study. Conducted by Primavera, Government 2.0--The Performance Opportunity reveals "that both federal managers and average Americans are calling for management reform in the next administration."
    Some of the key takeaways from the online survey of 3,868 members of the general public and 382 federal managers, included:

• 75% of Americans would like the government to notify them when a program goes over budget, why it went over budget and how they will fix the problem
• 65% of federal managers suggest a standardized system for reporting and tracking project updates and changes
• 55% of federal managers recommend a standardized system for reporting project problems in real time

    So what's so interesting? First of all, I think the ideas behind the findings are something that can be applied to project managers around the globe, not just ones in the United States.
    And it is just more proof that project management adds value--and that it's not something that just project managers see. Even though the general public may not know all the proper terms, they understand the basic concepts behind project management. They are the stakeholders and they want full transparency. And they understand the value accountability brings.