Voices on Project Management

> Back to Voices Home

December 2012 Archives

Tailoring Communication for Top Stakeholders

| | Comments (1)
Given the amount of work involved, most of your project communication efforts should focus on the stakeholders crucial to the success of your project. And this requires answering two key questions: Who are the most important stakeholders, and why are they important? 

Determining who's important is usually straightforward, based on an assessment of the stakeholder's power and involvement in the project. Understanding why each "important stakeholder" is important helps you define the type of relationship you need to develop for effective communication.

Enter the mutuality matrix, a useful project communications tool that starts with two dimensions:

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

These assumptions create four quadrants for categorizing each of the important stakeholders:

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

Once you understand the mutuality matrix, the way you communicate with each of the important stakeholders can be adjusted to ensure both parties achieve a satisfactory outcome. For example, the time and effort saved by minimizing communication with intractable objectors can be invested in building relationships with your key suppliers.

Keep in mind that each stakeholder will also be either supportive of or opposed to the project. Important stakeholders against the project — typically competitors and objectors — usually need nothing from the project and your communication should be focused on minimizing the objections. Similarly, important stakeholders who need something from the project are usually either passive or supportive, and your communication should be focused on building robust relationships.

How do you identify and communicate with important stakeholders?

Integrating Project Communications into Lessons Learned

| | Comments (0)
Lessons learned sessions typically focus on project deliverables and budget. But I'd recommend adding project communications to the agenda of elements to review.

Take a hard look at the communications plan and how well it worked. This process should include evaluating the stakeholders listed, the way the tool was manipulated throughout the project life cycle, or even the categories listed on the communications plan, such as audience, frequency and deliverables. 

Then discuss other communications documents — status reports, issues lists and risk registers — and how to make them more worthwhile. Consider the frequency with which these documents were published and the need to develop communications tools specific for each of your different audiences.

Finally, look at your communications with team members and executives. How you communicate with team members is different from how you communicate with management, so these should be separate areas of discussion. Yet for both groups, keep in mind how time zones, language barriers, leadership style and working relationships may have affected communications.

When examining your team communications, here are a few questions to ask:

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

When looking at your communications with management, keep in mind that this probably required less day-to-day communications than you had with the project team. Management's interest is in the big-picture, milestone items, such as presentations on status, the budget and the go-live date. When looking at your communication with executives, ask yourselves:

  • Did you express the positive and negative project information?
  • What communications methods and tactics did you use?
One last thing to keep in mind: As with any topic in a lessons learned session, be prepared to discuss unforeseen issues. Some project communications mishaps that I have heard about include not bringing in the data owner, issues reported too late or misalignment of user feedback with a requirement.

How do you evaluate your project communications in lessons learned?

A Project Management Wish List for 2013

| | Comments (4)
Another year for project managers has come and gone. And while this is the time for all the usual year-end activities (budgets, status reports, etc.), it's also a good opportunity to look toward the future.

To project managers around the world, I wish you health and prosperity. I also thought I would share a few other dreams I would like to see come true in the New Year:
1. Talking project plans. From GPS systems to smartphones, just about every device offers a verbal communications mode nowadays. The same technology should be applied to project plans. They could alert you to urgent issues: "Your resources are overloaded" or "You need to add more tasks." A talking project plan could even present an entire status report without you speaking a word. Think how much fun your meetings would be when the project plan says, "Just go home because your project will never make its projected end date."
 
2. Project issues that solve themselves. Project managers know that early detection of project issues is the key to staying on schedule and budget. We hold resolution meetings. We collaborate with leadership to craft brilliant solutions. Yet every so often, it would be great for issues to just solve themselves. For example, say your project is over budget. Then suddenly you get an e-mail from your project sponsor that grants extra funding due to your company's outstanding performance this year. A project manager can dream, right?

3. Resources ready, willing and able to jump into the action. We spend a considerable amount of time identifying resources and negotiating for their availability on a project. And still, we see our schedules fall apart when they're pulled away by other demands. Just once I'd like to have a project where everyone is fully dedicated, with no other distractions to threaten the schedule. It would make me very happy to hear a project team member turn down a meeting with the company president to work on my project.

4. No change requests. During the early phases of a project, we work to create the most accurate set of requirements possible. We consider it all — the many functional needs and the hidden complexities. After all that work, wouldn't it be nice if everything remained precisely the same throughout the life cycle of the project? Think of the time you could save by canceling those painful weekly change-request meetings.  

5. Give back all contingency funding in the project. We typically reserve contingency funding to guard against unforeseen events. Imagine the sheer joy of having no project risks that required budget or schedule relief. Just think of the satisfaction of telling your project leadership "We have no weather, people, software, hardware or network risks, so we are returning all contingency funds!"

What's your project management wish for 2013?

The Basics: Skills for a Successful Lessons Learned Session

| | Comments (5)
Project professionals wear many hats. As writers, you prepare the project's charter to initiate the project. As leaders, you manage project teams. And as an accountant of sorts, you control the project budget.

With the many skills you must possess to oversee a project, you should also be cognizant of the basic skills you'll need when conducting a lessons learned session:

1. Time management

The session should be arranged with a specified meeting start and finish time. Team members will have other projects and tasks to work on, so it is imperative to respect the time they give you during the session.

Start on time and keep the meeting moving. Pay attention to the clock to control the lengthiness of the discussions. This way, the meeting ends when it was arranged to end. To keep the meeting on track, you may have to tell team members when to close on a discussion point or ask them to discuss it more in-depth at a later time. If needed, schedule an additional meeting to talk about that point, or add it to the meeting notes and solicit feedback when you circulate the document.

2. Ability to engage

As the facilitator, you must be able to persuade everyone to participate — from team leads to database administrators.

You should also detach yourself from ranking attendees by their titles. After all, the goal of a lessons learned session is to collect details and feedback on a project's activities and decipher what may or may not be relevant to the next project — no matter the team member's position.

3. Shared vocabulary 

Many times, project teams use jargon that only they know. For example, the word "call" could refer to a programming term or simply to describe a customer service method. If you have not been a part of the project all along, make a point to familiarize yourself with some of the terms that may have been used on the project or may be mentioned in the discussion.

What other basic skills do you use for conducting effective lessons learned sessions?

5 Communication Tips for Better Stakeholder Management

| | Comments (5)
Over the past few years, I have written numerous posts looking at different aspects of stakeholder management. But what really matters and what is just useful to know? 

Here are my top five things to know to achieve effective stakeholder management:

1. Know who really matters. Make sure that the majority of your limited resources are being used to communicate with the stakeholders who really matter. They might not always be the bosses, either. The most important stakeholders will almost certainly change from month to month, so you need to regularly re-assess who is a top influencer at any given time. 

2. Know why those stakeholders matter and what they need or want. Mutuality is important. If you need something from the stakeholder, you need to be able to link your needs with their requirements. Trading is far more effective and realistic than relying on charity or altruism. 

3. One size fits no one. If you want your communication to be effective and deliver the outcome you need, you must understand the stakeholder with whom you're communicating. If you want your communication to have its intended effect, you need to have the right information for the receiver, in the proper format and delivered through the channel he or she prefers. 

4. Attitudes change constantly. People change their minds all of the time. What you knew about your stakeholder's attitude toward your project last month is probably out of date. To compensate for a shift in focus, constantly re-assess the important stakeholder's attitudes and adjust your communication plan to deal with the current situation.

5. Everyone is biased (including you). When managing stakeholders, rational objectivity is nearly impossible to achieve. You are using your perception of your stakeholder's perception of your project to plan and manage your stakeholder communication effort. But perceptions are not real -- they are simply a person's understanding of what they believe to be real, filtered through their innate and acquired biases. 

To be successful, you need to be pragmatic, design the best communication plan you can with the resources available to you, and then see what happens. 

Knowing these five basic concepts and adapting as the situation changes won't guarantee success, but it will at last give you a fighting chance. Your project will always be better off if you spend time thinking about the best way to manage your stakeholder's needs and expectations. 

Gather More Than Just Requirements

| | Comments (1)
When managing requirements, we naturally focus primarily on the business need or opportunity the requirements will address. We pay attention to how requirements are formulated, and whether they are clear, comprehensive and aligned to the project goals.

There's nothing wrong with focusing on the "what" of requirements — that is, what is asked to be delivered. But to avoid any major problems during the project, it's also important to identify the related assumptions, constraints, dependencies and risks. 

A requirement assumption is a condition or event that's assumed to be true or false, or that is supposed to happen or not, that directly influences the requirement's context. On the other hand, a requirement constraint is an imposed limitation to the requirement's context.

A requirement dependency is a direct correlation between two or more requirements, where the result of one requirement influences the outcome of others. And a requirement risk is the uncertainty of a requirement. 

For example, consider a project to develop a shopping website. One of the business requirements is to allow customers to perform credit card payments for their purchases. 

This particular requirement assumption presumes that customers will both own a credit card and be willing to pay with it online. 

If we would limit credit card payments to U.S. customers only, we would be dealing with a requirement constraint

The requirement would have an additional assumption and at the same time a requirement dependency on another requirement — that the website must be capable of handling credit card transactions. 

On the other hand, one of the requirement risks would be the security of payment transactions.

While this may seem like too many factors to keep track of, gathering these related elements doesn't have to be difficult. Personally, I document requirement assumptions, constraints and dependencies in a dedicated log, and include them as part of the project scope statement. I also use them while sequencing activities on the project schedule, and for assigning activities leads and lags.

Concerning risks, I consider project scope and project requirements as two of the main sources for identifying risks on a project. Interestingly, another risk will be the assumptions, constraints and dependencies themselves, because they can also create a negative or positive possibility of risks.

Regardless of the risk source, I recommend tracking requirements risks in the risk register and addressing them during the scope-definition stage and as part of the risk management process throughout the project.

How do you manage requirements assumptions, constraints, dependencies and risks on your projects?

5 Things I Learned from My First Project Manager

| | Comments (2)
In the early days of my career as system analyst, I had my first assignment working directly for a project manager. 

My project manager -- let's call her Rita -- was assigned to turn around a failing software package project. Over the next several months, under Rita's direction, the project was implemented with great success. 
   
When we parted ways at the completion of the project, I asked Rita for her keys to project management success. While tools and processes have changed over the years, what she said has served me well managing all types of projects. 

Following her advice has led to successful delivery outcomes and helped me mitigate risks along the way:
1. Schedule project meetings on Mondays   
Rita maintained that Mondays are better than Fridays to catch up on project progress. Her rationale was that you could better forecast and make the work for the current week visible. It also had the extra benefit of re-charging our minds for project work after a weekend.
 
2. Enable progress  
Instead of providing input on how the system would function, Rita spent time orchestrating the actual work of the project to enable progress. For example, during the project's design phase, she provided useful requirements and design templates that allowed us to better organize and align our efforts.

In addition, rather than assigning risks and issues to others on the team, Rita took personal ownership of solving them. This allowed team members more capacity for work while Rita worked in parallel to mitigate issues.  

3. Functional design is everything  
Rita always stressed that it was essential a project have sufficient time to complete a full functional design process with no shortcuts. She mandated that a full functional design process would also include the tracking of the design back to the requirements. On the project I worked on with Rita, this additional focus ensured that the software package was configured properly to meet all requirements. 

Rita also directed us to exhaustively pursue the design of interfaces. One of her constant comments was, "The value of what we implement is tied to the success of how it interfaces with everything else."  

4. Use prototypes where possible 
Rita often said, "It's easier to see a system than to talk about it." Presenting system functionality by drawing pictures on a marker board is not an effective method of conveying how a system will work. Rita acquired access to a prototype software installation. This prototype not only allowed the project team to readily show what the software would do, it also enabled quicker design of the software configuration. 

5. Manage delivery first, then costs 
Presenting a complex analysis of project budget during steering committee meetings is okay sometimes, but you must be able to answer fundamental questions around project progress. 

During her steering committee meetings, Rita would present escalated risk, issues and mitigation strategies for review and approval. This shifted discussion to delivery-related topics, which accelerated the progress of the project. "If you deliver successfully, the costs take care of themselves," she said. 

What are some project management principles you learned from your first project manager? 

6 Ways Agile Keeps Projects on Track

| | Comments (1)
Using an agile approach allows project managers to spot right away when things are falling behind.

Here's how:

1. Different levels of planning. Agile gives us the best of both worlds: a broad strategic picture and a real-time focused view.

In Scrum, for example, teams plan at three levels: release, sprint and daily commitments. The release plans are designed to be risk tolerant and prevent teams from missing strategic goals because you can change 'in-flight' during the product release. The sprint plan pauses the changes so teams can focus for two weeks.

At the daily stand-up meeting, individuals commit to their team members to finish something that day, which helps people collaborate when needed.

2. Blocker busting. One of U.S. statistician W. Edwards Deming's 14 principles for management is "remove barriers." Agile implements this at the daily stand-up meeting, where team members are encouraged to voice any blocker impending the project so that the team can assist in eliminating it.

3. Visibility. Agile uses tools like the release burn-down and sprint burn-down charts, as well as the task board to immediately show trouble in projects. Having them, using them and taking action when they highlight problems results in getting the most benefit.

4. Story flexibility. The waterfall approach assumes that all requirements can be explicitly defined at the start. Care is taken to create a solid plan and then control scope. In agile, it's an iterative and incremental approach. We admit pressure for scope changes will occur. 
Agile builds the ability to deal with change into its approach. A story, which is a means to show current and new project requirements, can be added during the release between sprints, and stories that are likely to suffer quality problems can be dropped from a sprint or release. 

5. Empirical planning adjustment. Agile plans look at previous results with the current team and environment to better estimate how much work to do in the future. Every sprint and release teaches the team more about how much it should plan for future iterations.

6. Retrospective actions. Agile has a built-in step to openly discuss the difficult parts of the team's process and focus on actions to improve in the future. Rather than wait until the end of the project when it's too late to improve the outcome, agile features 'retrospectives' or 'lessons learned' at the end of each iteration.These meetings review what went well, what went wrong, and how to improve for the next iteration.

Given these six opportunities to spot problems during all stages of the project, it's unlikely trouble will escape undetected for long.

How else do you think agile helps keep projects on track? 

About This Blog

Voices on Project Management offers insights, tips, advice and personal stories from project managers in different regions and industries. The goal is to get you thinking, and spark a discussion. So, if you read something that you agree with — or even disagree with — leave a comment.

All posts represent the opinions of the bloggers.

Follow PMvoices on Twitter

About Bloggers

Keep checking back because the voices for this blog will continue to grow and change to represent a variety of regions, industries and opinions.

Read blogger profiles

Voices Poll

Categories