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.

Time and again we see projects with a trail of issues that, if not dealt with, build up into this "issues bag," as I call it. The further you get into the project, the bigger and heavier the bag becomes--making it harder to control.

Carrying around these unsolved issues creates several risks.

1. Schedule risks: The project isn't completed on time because the issues left unresolved have caused delays in project activities or phases.

2. Budget risks: An unresolved issue creates a requirement to redo the work. If this work isn't done within the allocated timeframe--when it's still possible to refine requirements and while keeping the changes within the scope of the project--any changes would require additional funding.

3. Staff risks: The issue, if not dealt with by the project team, may be passed on to the baseline/production support team. This would impact other departments--and their time and money.

So how can you make sure the issues bag is empty at the end of the project? Here's what I suggest:

•    Keep track of the issues.
•    Maintain a list of the risks involved with these issues.
•    Keep a list of assumptions about what? and validate them.
•    Maintain a list of all changes executed during the project.
•    Perform quality assurance and close-out any outstanding quality? issues.
•    Ensure appropriate user-acceptance testing phases and garner signoff on the testing.
•    Pay attention to the organizational and business environment your project is impacting and any issues that arise.
•    Notify systems support teams of any impacts that may be caused by your project, directly or indirectly.

Escorted on stage by a bagpipe rendition of Amazing Grace, Alistair Cockburn, Ph.D., began his keynote address for the Agile 2009 Conference by waxing Shakespearean on the death of agile as we know it:
 
I come to bury agile, not to praise it;

The evil methods do lives after them,
The good is oft interred with their bones,
So let it be with agile.

The noble Waterfall
Hath told you agile was ambitious:
If it were so, it was a grievous fault,
And grievously hath agile answered it.

(Adapted from Julius Caesar, Act 3, Scene 2. You can read Alistair's full monologue here.)

Melodramatic (in a good way) to be sure.

But Alistair, an IT strategist and co-author of the Agile Manifesto, doesn't really believe agile has "met its maker" as the saying goes. Instead, he said agile is in transition--it's not the agile of the 1990s. The landscape has changed. It's grown beyond small organizations and is being applied to much richer, much more complex concepts and projects.

Agile shouldn't be "new news," he said. "We're focusing so heavily on things that are 15 years old, I want to start focusing on things that are current."

He also shared three pillars of 21st century software development:

•    Software development is a craft: Developers must pay attention to their skills and to the medium--they must relearn every few years.
•    Software development is a cooperative game of invention and communication: It relies on teamwork, communication and strategies.
•    Software development should use lean processes: That means small queues, cross-trained people and varied processes.

Hosted by the Agile Alliance, the conference has pulled in 1,400 attendees from more than 38 countries. You can follow all of the conference happenings on Twitter.

Did you attend Alistair's keynote address? What did you think?

More to come. 

I'm going to spend the next several posts discussing commonly held, but, in my opinion, profoundly erroneous tenets of project management.

Two esteemed colleagues, David Hampton and Alice Skehan, PMP, rated my list of 10 assertions in order of contrariness to common project management precepts, as well as the extent with which even they disagreed.

Here, then, are my numbers 10 and 9:

Myth 10: Trying to leverage organizational power to implement project management in the macro-organization is futile. Oh, I know, people try it all the time, and in many cases the ultimate outcome bears a strong resemblance to a legitimately installed project management office (PMO).

As I discuss in my book, Things Your PMO Is Doing Wrong, the so-called coercive strategies don't work in the long run for the simple reason that people are being, well, coerced into doing project management.

The moment they can opt out of the system, they will, and no reason that can provide reasonable cover will be considered too silly. I once had a project team that tried to use a paperwork-reduction initiative as a reason why they shouldn't have to send along their earned value reports. Really.

Myth 9: There is no cost performance management without earned value. Period. No exceptions. And yet, the comparison of budgets to actual costs persists.

When I'm instructing new cost engineers in earned value, I like using the following scenario: You're a project manager, assigned to get 2,000 widgets created in two months, with a US$2,000 budget. You time-phase your budget US$1,000 in month one and US$1,000 in month two.

At the end of month one, your accountant comes to you and says that your project has spent US$1,100.

Then I spring the question: "How are you doing?"

Invariably, one of them will say "Poorly, because I'm overspent."

"What if I told you that you had made 1,300 widgets?"

Obviously, that little fact changes everything. In this instance, comparing the budgets to the actuals was not only useless, it was actually misleading. Management information systems can be forgiven for offering up the occasional jejune tidbit, but never for misleading. And yet that's all you're left with if you don't have an earned value management system.

Next up, I'll be taking on the capabilities of the general ledger and re-visiting the bottoms-up estimate at completion debate.

Projects don't run in silos or in a vacuum. They run in organized, chaotic environments where everyone is working toward the end result. There's nothing wrong with that--it's how organizations achieve multiple results in a short period of time.

The key, of course, is to manage all these changes and interdependent projects.

But what if you are part of a project that's not a part of any program or portfolio with an assigned program or portfolio manager or director? How do you manage those interdependencies that are not part of your scope?

In my view, it's a matter of paying attention and linking yourself to three key areas:

•    Organization: Culture, processes, standards, rules, events, special blackout periods, etc.

•    Operations: Operational teams responsible for change management, incident management, delivery and quality management/control

•    Project Delivery: Such as a project management office or a business committee or unit that's responsible for project delivery

No matter what dependencies may exist, they will be manifested through these three main channels.

Project leaders often conduct peer reviews in an effort to improve project performance. Part of the process typically includes the review of statistical process control (SPC) analysis to continuously monitor and improve the team's effectiveness in producing quality work products.

But there's a danger for team members to just "check the box," going through the motions of conducting a peer review because they were told to do so. So while organizations may have a peer review process in place, not all of them are actually measuring just how effective their peer review process is via SPC metrics.

Organizations need to have people who are trained in the role of process mentor to review what the SPC analysis is telling you and take the time to follow up. In our organization, continuous process improvement means the combined use of SPC analysis and the art of reviewing what the analysis is telling us..

Sometimes the project manager may have to take on the role of process mentor--interpreting and discussing the SPC results with the team.

When I review a SPC analysis for a project in which items have gone awry, I try to understand what possible areas the team needs to improve upon or what resources and training the team is lacking.

If you are already performing in this role of SPC analyst? Of process mentor? What role exactly? What has your experience been like?

Acting with integrity with other project team members implies being honest with them--and clear about your expectations, intentions and opinions of the work they do.

As a project manager, one has to have integrity in order to sell to the project team the need to succeed and deliver the project on time, on budget and within the scope of the project.

Not only will the team members buy into the plan of action and your project management methodology, they will also become a solid extension of you and remain committed to going out there and getting the job done.

Here are three tips for acting with integrity:

Be Impartial: Be fair and objective. Listen to both sides of the story, various opinions, without attaching oneself to any specific one due to prejudice or favoritism. Objective decision-making fleshes out the problems and allows teams to get to the bottom of them rather than patching them.

Be Thorough: Finish tasks completely, in a comprehensive manner. I find that being thorough in project planning activities means evaluating project requirements and any gaps in details. It also means validating steps against the chosen project management methodology. This ensures a much more comprehensive project management plan and that supporting documentation is produced.

Be Focused on the End Business Result: No matter when team members are introduced, they should verify--within the scope of their project role--initial business requirements and the work that is being requested of them. This allows them to provide their own input based on their subject matter expertise and strengthens the chances for project success.

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.

Acknowledging people for the contribution they make to a project team or to their organization is such a simple matter. It's something I say repeatedly wherever I can get on my "soapbox": We can acknowledge people at any time, at no cost, without having to buy anything, install software or study an instruction manual.

Last night my soapbox was a live webinar attended primarily by project managers from all over the world, including Hong Kong, China, India, Brazil and the United States.

During the seminar I asked participants, "How do you feel when you complete a project that you put your whole heart, soul, body, mind and spirit into for the past several months, the users love the end result and your manager gives you nothing more than a quick 'thank you?"

This was the response via text chat:

Thomas: discouraged
Tanya: feel used
Srikrithiga: not interested to work
James: discouraged
Suganthi: Discouraged
James: feel indifferent
Sanjib: feeling of being empty--what was I doing all the time?
Ravindra: No motivation
Tanya: I won't give my best effort
Linda: lack of loyalty
Linda: feeling insecure, not as interested in working so hard
Fabricio: lack of motivation
Jade: feel not being valued, lack of respect

Then I asked, "How do you feel if your manager tells you what a difference your work made to the project team, how your contribution made the project a success, how much the users loved it, that she was getting wonderful feedback on it, and that the next time you would get more resources so you didn't have to work so many nights and weekends?"

And they answered:
 
James: I would feel appreciated; that motivates me
Shelley: Motivated...willing to give an even greater effort
Linda: enthusiastic
Ravindra: I would make extra efforts
Mariano: I would feel like a giant
Jade: more loyalty
Linda Benedict: my confidence would be boosted by the acknowledgement
Srikrithiga: I would give 200% for work

Performance, loyalty, engagement, confidence, motivation, self-worth are all functions of acknowledgment rather than compensation.

Especially during these challenging economic times--when everyone is working harder and having to do more--let's do our best to create a culture of appreciation in which people know their value and their worth.

There could be nothing simpler and more satisfying and with greater results.