Project Management Blogs

Foundations for Effective Communication

Last month's blog highlighted the need to speak up at the right time in project life to avoid problems and minimize the impact of those that are not avoided. In an earlier blog I discussed Improving Communication: Controlling Your Body Language and Tone.

This month we'll explore communication techniques that can be used to make speaking up easier and more effective and enable the control needed to moderate behavior and speech.

Effective communication relies on mindfulness, emotional intelligence, right intention, basic facilitation skills, the right vocabulary and courage. Over the next few months we'll explore these in the context of project work.

Mindfulness

Let's start with mindfulness, the ability to be consciously aware of what is happening in and around you. It implies clear, objective observation. Mindfulness is the foundation for effective communication. It enables emotional intelligence and the ability to facilitate. It enables you to choose the right words and behavior for each situation.  Increased mindfulness has also been shown to promote good health, better memory, concentration and enhanced performance in general.

Mindfulness is cultivated by mindfulness meditation. It is a very simple practice, just comfortably observing things like your own breath, feelings, thoughts and mental constructs (models, beliefs, opinions, etc.). These are objects of mindfulness. Additional objects of mindfulness are the way other people behave, what they say and how they say it. In effect anything that occurs in or around you can be an object of mindfulness.  By observing these phenomena as objects the mind is trained to become more objective.  Objectivity leads to better decision making and that leads to better performance.

For an instruction on how to do mindfulness meditation go to http://www.pitagorskyconsulting.com/articles/article/6339267/106485.htm.

Why Mindfulness is Important

Mindfulness is a key to communication because it makes it possible to be responsive rather that reactive. If when faced with a stressful situation a person can feel his or her feelings before reacting to them, then there is the possibility of choosing what to say and how to say it. 

The ability to see and feel the reactions of others to what one says and does makes it possible to shift behavior, body language, tone and the content of communication to get the kind of response one is looking for. 

When faced with a challenging situation in which the desire to speak up about a sensitive topic is being blocked by fear or lethargy, it is mindfulness that enables clear thinking to arrive at the optimal course of action.  It does so because it enables a "step back" that separates oneself from her feelings and provides the "space" to decide. 

Typically, people are so identified with their feelings and emotions that they do not have, or even think they can have, the ability to decide. Anger results in scowling or yelling; fear in withdrawal and avoidance.  One becomes stuck in his or her conditioning.

Mindfulness meditation gives the practitioner the ability to see experientially that there is choice; the ability to break old habits and respond creatively and appropriately in every situation. Anger is felt as anger, fear as fear, but these emotions are not immediately converted into unskillful behavior.

Don't forget to leave your comments below.

“Those who cannot remember the past are condemned to repeat it”. 

                                                                       - George Santayana

In my previous posts in the From the Sponsor’s Desk series, I’ve focused on real projects and the lessons we can learn from those experiences, good and not so much. My reference point in each case has been Project Pre-Check. It provides a framework of best practices, mined from a variety of sources including project management, software development, management of change, strategic planning, quality practices and others, that project stakeholders need to consider at project launch, throughout the course of the change and into the post completion review. But what can an organization or an individual do with those learnings to gain ongoing value? This post suggests an approach.

Project completion reviews or post-mortems are often seen as an essential best practice that enables organizations to learn from their experiences. However, all too frequently, the insights gained from post implementation reviews are lost to posterity.

There are a ton of books, periodicals and articles that address project management, software engineering and management of change disciplines and practices. But the rate of success for major business and technology changes is still well below 50%? Why? The bottom line - we lack a common mechanism where findings can be stored, examples cited and recommendations for future undertakings recorded and accessed. And, we lack the structure and discipline to ensure that our knowledge is managed and referenced consistently and rigorously.

According to Nancy Dixon in her conversation matters blog, “NASA learned its lesson about losing knowledge early in 1990. They experienced “the sad recognition that much of the knowledge about how to build the Saturn V rocket that took the astronauts to the moon, had retired along with the engineers who had been encouraged to take early retirement”. In response, NASA created the NASA Engineering Network, a knowledge network to promote learning and sharing among NASA's engineers. The Network includes the NASA Lessons Learned data base, “the official, reviewed learned lessons from NASA program and projects”.

Most stakeholders involved in a change aren’t aware of all the best practice information out there and aren’t inclined to spend the time and money to find out. They’re business people, financial types, actuaries, engineers, marketing folks, business analysts, IT practitioners. They’re not project management or management of change experts. They don’t really understand the role they need to play and the knowledge they need to have to ensure success! They just want to get the job done.

So, what do you do as a sponsor, stakeholder, PM, BA or other interested party to leave a legacy of lessons learned? There are five critical steps:

1. Identify and confirm accountability for managing lessons learned

Somebody needs to own this practice, to establish the goals and objectives, to measure performance, communicate to stakeholders and establish and drive initiatives to increase organizational value. Even open source software groups, which count on thousands of interested volunteers to deliver and enhance functionality, have managing entities to oversee progress. Find an owner and hold him or her accountable. More on this later.

2. Build or acquire a framework

Even with lots of great experiences, insights and findings, without some kind of organizing structure, a collection of project post-mortems will pose an unwieldy and perhaps insurmountable barrier to leveraging collective lessons learned. Fortunately, PMI, ISO, ISACA, SEI and many other organizations have developed frameworks and a wealth of best practice information. I personally developed the Project Pre-Check Decision Framework to bring together the best of project management, management of change, software development and other practices and provide a Lessons Learned framework in my consulting practice. Select a structure you and your organization are familiar with and build it up with real world experiences and examples to facilitate effective use and enable real performance improvements. Or build your own framework.

3. Enforce usage

Having a comprehensive, easy to access, easy to use facility for mining best practices adds absolutely no value if no one uses it. So part of the Lessons Learned challenge, and a critical responsibility for the owner, is to ensure that everyone uses it, on every assignment, for every project. That use needs to involve a thorough review to identify and leverage applicable best practices and contributed learnings in a form and structure others can use. I can hear the groans already! More bullshit! More red tape! Get over it! If your organization wants to improve its ability to deliver major business and technology change successfully, a certain level of rigor and compliance is essential. What would you rather be, a sponsor, PM, BA or architect with an incredible track record of successful project deliveries, enabled by an organizational ability to leverage lessons learned, or an incredible individual contributor with a mixed record of project successes? Your choice!

4. Manage the transformation of project experiences to organizational Lessons Learned

A key challenge is gathering the experiences and insights of each project participant and the collective wisdom of project teams and abstracting that information into the selected framework. Don’t leave it up to the BA or PM to post the project learnings to the Lessons Learned framework! The owner needs to assume that responsibility and establish the analytical mechanisms and quality and usability standards that will ensure that others, in different circumstances and on other assignments, can quickly and effectively gain value from the information.

5. Manage Lessons Learned value contribution

There is no point in doing anything beyond individual project post-mortems if you’re not willing to manage the organizational value contribution. Getting a return from Lessons Learned means measuring usage, compliance, value derived and contribution frequency and identifying gaps and discrepancies in content and application. The measurement results provide the fodder to develop and implement continuing improvements to the practices, increasing the value delivered to the organization.

Where should Lessons Learned be managed? The PMO is an obvious suspect. The PMO mandate is usually very compatible with a Lessons Learned program. It typically has a broad view, encompassing enterprise or organizational initiatives, programs and projects. It should be tracking and reporting on aggregate project performance and taking steps to improve that performance, actions that are very compatible with a Lessons Learned program.

But, implementing a Lessons Learned practice across an organization is another change that has to be sold, prioritized, funded, initiated, staffed, managed and monitored. It is still very worthwhile but there is another option – the individual Lessons Learned practice. As a professional, you have undoubtedly committed yourself to a program of continuous improvement. An individual Lessons Learned practice starts and ends with you. You need to follow the same five steps reviewed above but you don’t have to sell anybody else on the idea. You are the decision maker. As you gain value, and confidence, you’ll build a track record and reputation others will notice. Also, share your experiences with your peers. Chances are you’ll find an enthusiastic audience and perhaps an attentive sponsor in waiting. Good luck.

Don't forget to leave your comments below.

 

As an agile coach, one of my favorite expressions in response to nearly any situation I encounter in an agile team is—“trust the team” or “trust the process”. So here are a few examples of what I mean:

If you think the team has underestimated their work and are leaving velocity on the table, “trust the team”…

-          If they have underestimated they can always pull in more work. And you know, you could be wrong, so allow the team to sort through how they understand, size, and execute their work. They’ll appreciate the trust you’ve given them and will invest in doing good work.

-          If you do see poor estimation or poor execution & adjustment, then bring this to the attention of the team within their retrospective. Give them examples, but allow them to explore the most effective way(s) to improve.

If you feel that the team isn’t working hard enough or are committed enough to their work, “trust the team”…

-          Unless you’re a direct member of the team, it’s fairly presumptuous of you to assume they’re sand-bagging and not working hard. Or thinking that they lack commitment. Rather observe how hard they do work, handle their challenges, and deliver on their sprint commitments. Assume that the wonderful professionals you’ve hired are just that—hardworking, honest, and professional.

-          And remember, just because people are putting in hours, that doesn’t mean they’re doing good work or working hard. It just means you have their butt in their seat…not their brain in the game.

If you feel that quality is poor and it isn’t improving sufficiently or you feel that the team isn’t taking product quality seriously, “trust the team”

-          Ensure that your concerns are visible to the team and that they’re looking into root cause within their retrospectives.  However, let them tailor their activities to improve deliverables each and every sprint. Explore objective data on their defect & quality deliverable trending with them. Give them clear and complete done-ness criteria. BUT, allow them to discover how to do a good job as a team.

-          Agile is not a magic formula. It cannot take a crappy product and, simply because you’re ‘agile’, remove all technical debt and bugs overnight. Improvement takes serious effort, commitment, and time. No silver bullets allowed!

If you’ve got a fixed date software delivery to make and you wonder if the team is going to get there, “trust the team” and “trust the process”

-          First of all, solid agile teams make everything transparent. Secondly, they approach delivery in iterative chunks. Put these two together and you’ll actually get a heartbeat of how well the team is meeting your projections & needs. If they aren’t, then you get the chance to negotiate scope trade-offs with them.

-          Agile projects can ALWAYS hit fixed date targets with fixed cost & quality goals. And they can ALWAYS deliver a set of your highest priority features. The variable in these situations though is scope—so you must be prepared to pare back scope via dropping low priority features and making micro-adjustments to other features—generally delivering Must-Haves over Nice to Haves.

If you feel that the Product Owner isn’t making good decisions surrounding feature priority, “trust the process”

-          The Product Owner will get plenty of feedback in the Sprint Reviews as to whether they’re focusing the team on the ‘right’ features, at the ‘right’ time within the flow of the project. The key is to get stakeholders regularly attending and to encourage positive and constructive feedback.

-          Quite often the Product Owner is a surrogate without real decision-making authority. That is NOT setting them up for success. Ensure your Product Owners are empowered to make decisions and have the seasoning and domain experience—to make the ‘right’ decisions.

These are only a few of the many real-world situations where we have a choice in how we actively demonstrate our understanding of agile principles and exhibit trust to our teams. You see, it’s not about saying you trust the team—it’s about truly trusting them and demonstrating that in in your words and actions. Next I want to explore a few, how shall I say it, trust anti-patterns or excuses that I commonly see.

There’s trust, and then there’s TRUST

Here are a few anti-patterns I frequently hear that indicate to me that the organization, leadership, project, management and other stakeholders don’t fully trust the team. I’m sharing them to broaden your thinking around trust and the ways we can frame it organizationally. By no means is this an exhaustive list, but more so a list that illustrates how our words don’t always necessarily align with truly trusting.

And of course this doesn’t apply to anyone reading this blog. So please just read it for future reference—in case you run into some of these anti-patterns…

Trust, but Verify

Of course I trust you, but I’m just simply verifying that what you’re telling me is true—as a simply checkpoint. Don’t worry about it, I’m just verifying…

Don’t be fooled, this anti-pattern isn’t about verification. It’s about distrust and the use of micro-management techniques to get into the heads of the team and control how they’re attacking the project. Yes, verification is important, but not daily. The Sprint Review is the ultimate verifier. Attend them.

The process is making me do it

Of course I trust you, but I need to get this information into the CMMI Level 3 artifact repository so that we pass our audits. Did you know that an audit was coming next month? Very serious stuff…

Another common anti-pattern is blaming distrust on the methods or process patterns that you’ve adopted as an organization. We’re CMMi Level 4, so I must have you fill out a detailed test results plan and sign at the bottom to confirm that you’ve tested everything you’ve said you’ve tested.  

Sure, processes carry some weight and responsibility. But this anti-pattern extends that as an excuse to hover over the team and control approaches & outcomes.

I’ve been doing this a long time and I know this path will lead to a disaster

Of course I trust you, but in my 25 years of experience, I’ve never seen a team deliver on a large scale refactoring effort. I simply don’t think it can be done…

While your experience is certainly valuable, times have changed and contexts are different now. Your team is exploring their own experience and finding their way. They’re establishing their experiences, and need to do that largely on their own…as you probably did.

I’m paid to prevent us from making mistakes

Of course I trust you, but my job is to prevent us from making mistakes and to develop the best products possible. It’s actually in my job description that I lead the team by the sheer force of my will and experience.

That I’m responsible and accountable for all of the results my teams produce. That leadership is about leading—showing team the way forward in practices and approaches. Trust does come into play, and of course I trust you, but only so far. Only when I have a belief that the outcomes will align with our organizational goals and my bonus plans.

True Trust

I have a favorite story I use for describing effective delegation. It goes like this—

Delegating is easy when you know how someone will approach the problem you’re delegating. Or when they’ve been asked to do the task many times before? There is no outcome risk.

But what if they would approach the solution differently than you? Or what if they might try a novel, but risky approach? Or, what if you’ve seen them fail at this sort of problem many times before? You ‘get’ the idea…but you still delegate to them. To me, this delegation, regardless of outcome risk, or approach, is true & pure delegation.

It means you trust the individual enough to encourage them to try something new. You’re enabling their creativity and you’ll be there if they ask for your help or advice. But they ‘own’ the task you’ve delegated to them and ultimately the results.

Now THAT’S delegation!

Adapt this definition and re-focus it towards trust. Then accordingly, start trusting your teams more. For example, here are a few transitional trust adjustments you might need to make—

• Trust that they are estimating work based on the best information they have—and that the estimates are accurate given their context
• Trust that when they run into trouble, they’ll let you know; otherwise they are making progress and don’t need your ‘help’
• Trust that transparency and Sprint Demo’s will give you sufficient progress information—both on velocity and quality of their efforts
• Trust that the team knows best in how to solve product development challenges related to architecture, design, and implementation
• Trust that your Product Owner is effectively driving customer value—and are making the best decisions balancing business needs against team capacity
• Trust that your Scrum Master is emphasizing done-ness, quality, and working collaboratively as a team. That if something needs attention, they’ll raise it as an impediment
• Trust that when the team recommends refactoring a component of your system—that it’s truly broken and needs attention
• Trust them to trust your own judgment and skills; that they look to you for high level guidance, goal-setting, support, and impediment resolution. 

Wrapping Up

True trust, like delegation, can be really hard. As leaders, many of us have engineering backgrounds and are natural problem solvers—so our efforts to engage the team with our ‘advice’ emerges from our own backgrounds, skills, and interests.

We’ve also been programmed not to trust our teams. The inherent dynamics of Taylorism and Scientific Management influences our behaviors when it comes to telling our teams what to do and hovering over them until they do it.

But trust is what a truly empowered and self-directed team needs from you. Of course you can inquire measure, establish vision and set goals, measure results, and provide feedback. Surely you’ve earned that right with your experience and role. However, try and give true trust as often as you can. You’ll see a huge difference in your teams’ performance and the results.

Thanks for listening,

Bob.

Don't forget to leave your comments below.

As we know, 80-90% of a project manager’s time is spent communicating.  The challenge for some project managers is that their communication appears to fall on deaf ears.  Team members don’t follow established procedures for status reporting or issue notification and senior stakeholders procrastinate or avoid decision making, issue resolution or risk response execution.

When asked, the project manager might point to minutes from meetings, project status reports and e-mail messages to prove that the requests were made.  Sadly, this ignores a core principle of the basic communication model as per the PMBOK Guide, 4^th edition: “the sender is responsible for making the information clear and complete so that the receiver can receive it correctly, and for confirming that it is properly understood”.

If the message encoding the information the project manager is hoping will generate action is not perceived by the receiver to be as important or urgent as the project manager feels, the outcome will not be the expected one.

The project manager may wish to have team members follow certain “common sense” steps for sharing information or for escalating appropriately but if the impact of their not doing so is not clear to them, the team members are likely to perceive this as bureaucracy or micro-management. 

If the project manager takes the time to explain the linkage between the requested information and gaining greater predictability on achieving the project’s objectives and is successful in  communicating how the success of the project aligns with the success of the team members, they are likely to at least understand what’s in it for them and why it is important to the project.  This does not guarantee 100% compliance, but at least expectations were appropriately set.

With senior stakeholders such as a project sponsor, a different challenge presents itself.  If the project manager cannot clearly articulate the business impacts of a decision, issue resolution or risk response, at best, the senior stakeholder will procrastinate, but worse, this poor communication will impact the stakeholder’s perception of the professionalism and effectiveness of the project manager. 

While observing the body language or verbal reactions of senior managers to a project manager who is clearly missing the mark with their communication attempts, I’ve often mentally drawn cartoon bubbles over the senior stakeholders’ heads with the thought “Why are they wasting my time?”.

Even if the project manager clearly explains the business impacts of not fulfilling a request, it may still not be perceived as a high enough priority.  Sometimes, there is nothing more that the project manager can do in this case beyond further escalation but if there is the potential of a downstream impact to other more critical business outcomes, it is the responsibility of the project manager to help the senior stakeholder understand these ripple effects.

It would be wonderful if Star Trek’s Universal Translator existed, but until it does, project managers who are unable to answer the “So What?” question might suffer the same fate as an average red shirted crew member!   

Don't forget to leave your comments below.

Recently I talked to a colleague with a communications dilemma. She wondered how she should communicate with her various stakeholder groups. Thinking out loud she pondered, “When I’m with business people, I always try to use business language, including their acronyms, which I’ve gone out of my way to learn. But what about when I’m talking to the technical experts? Should I talk techie to them?” She went on to say, “I write a lot of proposals. I have some stakeholders who let me know right away about typos or if my grammar is not exactly right. I have other stakeholders who have told me that my writing style is too formal and that I shouldn’t use such correct grammar. They feel it’s intimidating and unfriendly.”

 As BAs and PMs we know we’re supposed to be good communicators, but what exactly does that mean? We are trained to be aware of others’ communication style. We use our intuition, empathy, and awareness of body language to “read” others. But is that enough? And does that apply equally to our written and our verbal communication? What about the language we use? I have always loved the quote from the poet William Butler Yeats, “Think like a wise [person] but communicate in the language of the people.” Does that mean, however, that when we are talking to someone who misuses the language, that we should match our language to theirs? I don’t think so. Matching the communication style does not necessarily mean mimicking their language. However, we do want a communication style that makes our stakeholders comfortable.

How can we solve this communications dilemma? Here are three tips for both written and verbal communications that can help.

1. Take the time to keep it simple. We are all aware of the wisdom of keeping it simple, but simple doesn’t mean easy. Simple doesn’t mean careless. It is often harder to keep it simple, because keeping it simple requires thought, precision, and a good command of the language. I find that it takes a great deal of thought to write concisely and say everything I want to in language that all stakeholders will understand.

That same principle of simplicity applies when we paraphrase, or restate what was said in different words while keeping the nature of what was said intact. I think paraphrasing is one of the most difficult skills to master. It requires the ability to     take in a lot of information, to synthesize it, to concentrate on what is being said, and at the same time to rework the ideas to make them understandable. It’s tough work!

2. Be correct without being pretentious. When we use incorrect grammar or when we don’t bother to check our work, we run the risk of being judged poorly, of reducing our credibility, and of not being taken seriously. On the other hand, when we use ornate language and complex sentence structure, we run the risk of losing our audience. I remember taking a multiple choice test in high school where the correct answer was “It is I who am going shopping.” Wow. And of course there’s the famous line from Churchill. Apparently his editors rewrote a sentence to make it grammatically correct, and apparently he responded with the famous line, “This is the sort of bloody nonsense up with which I will not put,” pointing out the ridiculous nature of obscure grammatical rules. In a nutshell, I think we should strive for communications that are both intelligent and clear.
3. Use language that both technical and business people understand. I have found that when I use technical language with business people, they have a harder time understanding me than if I use business language with technical people. Using business language, then, tends to be more easily understood by all stakeholders. As a project manager working on software development projects, I always encouraged the developers to use business terms, even when the subject was technical in nature. For example, instead of saying DB17, I encouraged the team to talk, even among themselves, about the Price Change database.

Another example I use is that when we need to find out about data business rules, we might walk into a requirements workshop and ask about the cardinality and optionality, but we’d probably get some blank stares. However, we can translate those concepts into questions our SMEs can understand and answer. For example, we might ask if end-users can set up customers who don’t have any accounts. Or what information the end-users need to enter before they can leave the web page. I have always believed that translating technical concepts into business English, while annoying to some team members and technical whizzes, has always been worthwhile. It encourages us to focus on the business need rather than the technical solution.

Finally, let’s look at the intent of the communications. If we all understand each other and what we’re trying to say, then I believe we are communicating effectively, even if our grammar isn’t perfect or we don’t use the right words. And I believe that most stakeholders get that and won’t judge us harshly. However, for those stakeholders who want each “i” dotted, let’s proof our work. It will help build our credibility. The key is to know our stakeholders, but that’s a topic for a different day.

Don't forget to leave your comments below.