Never Miss a Date!

Loren S. DeLaOsa, CIPT, PMP Practice

You can make every software development project successful.

Interested?

Ready?

Here’s the secret: Apply PMI’s project management knowledge areas.

It’s that simple.

I’ve been in software development since before high school, and have seen every type of success and failure imaginable. Maybe your project isn’t year-long, involving 200 people across many countries with a budget of a hundred million dollars. Maybe it’s five developers in a basement for a couple of months. I don’t know the particulars of your situation, so I couldn’t do the business analysis necessary to suggest one development methodology over another. Instead, I’m suggesting that the application of knowledge will make your projects better in general. If you understand these knowledge areas, and understand them well, you will understand what trade-offs you are making in your process and projects. That will enable you to better direct your projects to successful outcomes, regardless of the size of your project or development methodology you choose.

In order, the top ten reasons for failure, in order of importance:

  1. Communication Management – Three articles on communication so far. That wasn’t an accident. Projects, first and foremost, live or die by communication.
  2. Risk Management – The solution has been architected, coding has progressed, things are looking good, however the implementation can’t be stabilized. Review indicates a different architecture must be chosen. The schedule is blown, the budget is gone, the project fails. The qualification and quantification of uncertainty is what risk management is about. Every project I’ve seen that failed to “make its dates” had no risk management strategy. It’s not only identifying risks, it’s actively communicating and managing them in a timely manner. A good risk plan will save a project by stating what conditions it will trigger and how act appropriately to manage the impact. Think of it as carrying an extra set of batteries for when you take photos on vacation. Batteries die? No problem! You have another set. Yup, it cost a little money – but documenting your vacation experience is priceless.
  3. Time Management – The usual cycle is for managers to look for estimates, wring every bit of “buffer” out of estimates (the estimator’s attempt to manage uncertainty, which is to say risk), then create a ship date. Has this ever produced an on-time project? Not that I’ve seen. A schedule is a map of the project. It contains all activities (scope), resources to complete (cost), and when those resources need to do the work (time). Failure to create a realistic schedule, then failure to manage against it, cause project failures.
  4. Integration Management – This failure happens on two dimensions. The first is the organization’s leadership doesn’t believe that they need any project management, so either fails to have a project manager or fails to listen to an experienced project manager. The second version of this failure is assigning a project manager who doesn’t have the knowledge or skills to do the job. “You’re great at laying bricks, Bob – we’d like you to manage the construction of our next building.” Unfortunately, Bob is great at bricks, but doesn’t know anything about monitoring and controlling a project.
  5. Scope Management – As the project progresses on an agreed plan, things get added – hey, it should be a simple fix to allow users to change background colors, right? Sure! Scope is everything you’re going to do, and, inversely, everything you’re not going to do. Poor change control, along with an unwillingness to adjust either schedule or cost baselines, results in failed development projects. Every accepted change changes the whole project; have a change control process. Reject scope when appropriate, or accept and re-plan other aspects of the project.
  6. Stakeholder Management – The project was completed in record time, and is ready for implementation. The IT director is assigned the job of deployment and says, “Hey, wait – this won’t work. Half our users are only intermittently connected!” There are basic questions for the start of every project: Were all the stakeholders enumerated? Where their needs and requirements considered? What is the urgency of solution delivery? Failures in this area causes work products to be rejected. Scrum tries to control for this with a product owner who is the source of requirements, but also assumes the product owner has done the right business analysis and thoroughly understands all other stakeholders. If the product owner isn’t a business analyst, you’re probably doing it wrong.
  7. Cost Management – A project merrily moves along, assuming full dedication of all personnel. The reality is that developers are often assigned to many different projects. Managers often fail to account for that and consequently over-allocate developers. Part of that is failure to account for the productivity loss in context switching. Also, managers wrongly assume their project is top priority. Just because it is important to YOUR career doesn’t mean it’s important to someone else’s! Adding more developers doesn’t necessarily mean a project gets done quicker, even if those developers are more senior. As the number of people go up, more work is lost to the “friction” of working cooperatively.
  8. Quality Management – Yup, we wrote a lot of code. Too bad it doesn’t work in integration. Guess we should have planned for that. A quality acceptance plan is important to ensure a development project meets the goals that are set out for it. It can also be a check against gold-plating.
  9. Procurement Management – Okay, okay, stop me if you’ve heard this one: Manager throws out an RFQ, picks the lowest quote, and three months later gets something that doesn’t remotely resemble what was expected. There’s a whole process for managing procurement properly. Not every project has a procurement component, but if one does, it is essential to manage it properly.
  10. Human Resource Management – Each part of this list has started with a dreary failure. Instead, let’s talk about success. A couple years ago, Avengers was a popular movie. I held a “bug smash” (“bash” == “finding”, “smash” == “fixing/resolving”) for one of my teams. It was Hulk-themed, as in “HULK SMASH!” A twice daily report went out recapping the contest, morning and night, for a week. We gave out $50 gift cards along with Hulk-themed prizes for most bugs, most severe bugs, most code reviews completed and most helpful as nominated by peers. It was the most fun we’d had all summer and a good team building exercise. Be a source of motivation and inspiration, and celebrate success with your team.

There you have it – your spell book for success. Go study, then be successful.

Numerical Nonsense

Loren S. DeLaOsa, CIPT, PMP Cantrips
Figures often beguile me, particularly when I have the arranging of them myself; in which case the remark attributed to Disraeli would often apply with justice and force: “There are three kinds of lies: lies, damned lies and statistics.”
– Mark Twain’s Own Autobiography: The Chapters from the North American Review

It wasn’t actually Disraeli, but numbers are persuasive. If I said, 68.7% of statistics are deceptively presented, that sounds pretty authoritative, doesn’t it? It’s also completely made up. That’s an egregious example, but one of the first uses that occurs to any student of statistics is misuse. For a clear view of what that looks like, head over to Math With Bad Drawings’ article “Why Not to Trust Statistics.”

There’s two messages here. First, as a consumer of statistics (the language of business), understand numbers and question them. Know how the information was gathered, how it was summarized and why it was presented as it was. Remember that correlation does not imply causation. Second, as a producer of statistics, you are ethically bound to represent information in an unbiased fashion. Manipulating math to use a “magician’s force” on a decision is unethical.

Spellbound!

Loren S. DeLaOsa, CIPT, PMP Cantrips, Communication

I’ve suggested you follow James Whittaker before, and he has a new book that blends perfectly with this site’s theme. You can buy a copy from Amazon.

I like to have signed copies of things, so I attended one of James’ talks today. James was demonstrating how a single word can evoke the person who spoke it. It went something like this:

James: “I say DREAM, you think…”

Me (thinking): NEIL GAIMAN! No, that can’t be right. Well, hold on. Is that Tengwar in Quenya mode that James has tattoo’ed there? I mean, he must know about Magic the Gathering based on these slides. Probably AD&D, too, since he’s referred to verbal, somatic and material components in other talks. That’s all pretty geeky. Maybe he does mean Neil?  But that doesn’t…

James: “… that’s right! Dr. Martin Luther King!”

Me (thinking): Oh. Yes, of course. That makes more sense in context. Obvious even. <Pause> How does my brain even work?

Skill and Genius

Loren S. DeLaOsa, CIPT, PMP Practice

I never really know what to say when I meet famous people.  It’s awkward.  I mean, we’re complete strangers, but I often know weird and interesting facts about them – that seems uncomfortably invasive.  For actors and writers, I’ve now settled on a simple autograph moment, “I enjoyed your work; thanks for sharing.”  It’s one thing, however, to appreciate skill, but another to appreciate genius.  I’m going to define genius as someone who blends multiple, unrelated skills into a single package that seems marvelously and magically unique.

Paul Reed Smith visited The Seattle Guitar Store in July 2015.  I heard in person some of the stories I’d watched online.  When it was my turn to get my guitar signed, I was so beside myself that I put my guitar case on the counter upside down.  Why?  I’d been reading about PRS Guitars since I was young, long before I could afford one, and here I was meeting The Man Himself – and he is a genius.  His guitars are, literally, like nothing else I’ve ever played or heard.  It’s just not the wonder that are his instruments, it’s the unusual blend of skills that got him to where he is.

What makes Paul Reed Smith a genius?  It is abilities and skills he both possessed and developed.  He started repairing guitars and determined his passion was to build them.  It’s not enough to just build guitars, you have to sell them.  He developed sales skills, pitching them to artists, with his big break coming up when Santana bought one.  To be able to scale meant learning about manufacturing and the business of manufacturing (“If you make 8% in manufacturing, you’ve had a pretty good year”).  He became an expert in marketing, creating a set of differentiated product price points for every budget. He sought mentors in the great builders of guitars to perfect his craft.  He became a better musician along the way, providing even more insight into making guitars. Most of all, the thing that sets him apart from other luthiers, is that he is an engineer and a scientist.  His quest is to understand what makes an instrument great, to know what physical qualities make an instrument special.  He creates a hypothesis, tests against it, and incorporates what he learns.  Year over year, you can see the evolution in the resulting instruments.  I’m passionate about clever engineering and, as far as I know, that engineering skill is unique among guitar builders.  Musician, manufacturer, engineer – an unusual combination.  His passion was building guitars; his genius was in building them better at scale, creating a $40M company renowned for quality and sound.  He did it by constantly learning, constantly improving, constantly developing new skills.

The photographer at Musicstorelive.com is a *genius*. Check those folks out.

What does integration of all those things looks like?  Look at the guitar on the right.  Beyond the masterful photography that highlights its beauty, it is an amazingly figured piece of maple that is unlike any other I’ve seen – look at how the grain on the horn points to the center.  Why are PRS guitars almost “too pretty to play”?  I can nearly hear Paul Reed Smith’s thoughts:  If you see it, and it’s pretty, you’ll want to pick it up.  If you pick it up, you’ll want to play it.  If you play it, you’ll hear the sound.  If you hear the sound, you will buy it.  It starts with how it looks.  If you have any doubt, watch Rob Chapman try to talk himself out of a guitar that sounds wickedly good in his hands… because of the looks!  Paul Reed Smith got it exactly right.

I write about project management, but to be successful, you are going to need to do and be more.  Although it’s said that project managers don’t need to be subject matter experts, to have a career, it’s essential to think of the full range of talent and skills you bring to the table.  What insights do you have that make you unique?  What can you dive into deeply to provide value?  What new things will you learn to maintain marketability beyond your employer?  What synthesis of things make you a genius?

Answer those questions and maybe your next introduction to genius won’t be awkward, because you’ll look in the mirror and that genius will be you.

(If you’re curious, here are some additional links about Paul Reed Smith, with the last highlighting my awkward connection to Andertons…)

Communication, Part Three

Loren S. DeLaOsa, CIPT, PMP Communication

Okay, we left off with the idea that communication planning is the process of determining the information and communication needs of project stakeholders. Information needs to be available to them in a timely fashion. Projects don’t have problems, people do – communication allows you to manage stakeholders and resolve their issues. Project performance information which is accurate and predictably timed (“this report goes out every Monday morning!”) is what allows the project to be managed.

The best communicators use the appropriate medium for their message. If a matter is urgent, a text, phone call or office visit may be better than email. If a matter is long and complicated, a short paper with follow up meeting might be best. If an official document, certified mail, return receipt requested, might be the best choice.

Here are some notes on topics I think are important:

Emails

  • The best emails are:
    • Precise – clear, unambiguous
    • Concise – no one is paid by the word
    • Direct – what do you want?
    • Easy to understand – simple is good
  • Noise and misunderstandings arise from:
    • Cultural differences
    • Technical vs. non-technical
    • “Tone and voice” of writing
    • Dashing off email replies too quickly

See what I did there? 🙂

Presentations

Do you want to give awe inspiring presentations? How about a perfect interview? Look no further than Dr. James Whittaker’s presentations on stage presence and other topics.  Follow all the links on his site, watch his videos.  Here’s one of my favorites, the power of story.   Fair warning: Judicious use of bad language to make sure you’re awake.

Have Better Conversations

Crucial Conversations is a book that has been recommended for ages, and I’m doing it here. Behavior gets pathological when the pressure is too high. Stress shuts down cognitive process and starts a fight-or-flight response. This book goes through some tools to account for that. If you, or your listener, is amped to eleven, it can be very difficult to get your message across.

Put Stakeholders on a RACI Chart

RACI charts can important tools to segment the audience for communications. You can read more about them here. A RACI chart expresses roles for producing deliverables at any level of a work breakdown structure. I don’t use them a lot, but find them pretty handy when dealing with matrix organizations.

  • Responsible – Role responsible for performing the task. There may be multiple “Rs”
  • Accountable – Role with overall management responsibility for a task; accountable for “showing up with the deliverable”. Only one “A” per line
  • Consulted – People who provide input to help perform a task
  • Informed – People with a vested interest who should be kept informed

Status/Performance Reports

Reports help manage the project. The best status reports clearly direct the reader to action. Like email, they should be precise, concise, direct and easy to understand. It’s important to be consistent report to report. The reports should contain information, not just a collection of data.

Status reports are meant to answer questions and direct action. Where are we on schedule, budget, and deliverables? What was planned for and what changed? What corrective action do we need to take? Consider, if your features are getting completed, but your bug counts are skyrocketing, *maybe* you want to a) review your code quality validation procedures and b) pause to remediate those bugs. “Testing in quality” is almost always more expensive than producing better code in the first place. And are we “done” if we’ve produced all the features, but the product isn’t good enough to ship?

Meetings

Meetings are expensive gatherings of resources, yet frequently are neither well organized nor well facilitated. I’ve also seen meetings go the other way, rigid and formulaic rituals devoid of any actual information. The first type of meeting is usually junior personnel, the second type of meeting usually executive level.

Before holding a meeting, ask some questions:

  • What do I hope to accomplish?
  • Who would need to attend?
  • Do we really need this meeting? Can it be done some other way?

There are two great resources I’m going to direct you to. The first is a book, Death by Meeting. The second is an entertaining video by John Cleese, Meetings, Bloody Meetings.  Meetings, Bloody Meetings has been used as instruction for over forty years. It is an absolute classic for structuring meetings. The video can be can be summarized as:

  • Goal: Have a clearly defined goal
  • Agenda: Publish and follow an agenda
  • Participants: Include necessary people and only necessary people
  • Structure and Control:
    • Start/end on time
    • Make introductions when needed
    • Structure logically, discuss in order of importance not urgency
    • Keep moving forward, drive toward making decisions
    • Recap
    • Listen and communicate collaboratively
  • Document: Document discussions/decisions and action items/owners
  • Summary: Send out summary and meeting notes

So that’s some tips and tricks.  Go forth, and communicate better.

Beware — Here There Be PMs!

Loren S. DeLaOsa, CIPT, PMP Cantrips

What does it look like when two professional project managers live in the same house?  A lot like this:

This is in the back corner of our home office. There’s a deep backlog and epics on the left, backlog on the board and scheduled house items. There’s daily things that we don’t bother with (cook meal, clean dishes), but everything else gets scheduled. The calendar is rolling three weeks, since four seemed like too far out. This photo was taken in the middle of coffee scrum, as Saturday morning is when things are planned out and the calendar adjusted.  It might be too much for some — but household projects get finished.

Communication, Part Two

Loren S. DeLaOsa, CIPT, PMP Communication

In June 2013, Australian Chief of Army Lieutenant General David Morrison released a powerful message about demeaning conduct and harassment. This video has nearly 1.8 million views. Take a moment to look at it. What makes this video so powerful?

Watch the General’s body language. “Earlier today, I addressed the media, and through them the Australian public…” he starts out flat, but his frown starts to deepen the more he speaks. When he says, “By now I assume you know my attitude to this type of conduct,” he raises his chin in a sign of his authority and distain for the conduct he’s speaking about. “If that does not suit you, then get out!”, his eyes widening and head moving, indicating strong emotion. “I will be ruthless in ridding the army of people who cannot live up to its values.” Eyes narrow, fury and determination. Finally, an expression that can only be described as serious, “If we are a great national institution, if we care about the legacy left to us by those who have served before us, if we care about the legacy we leave to those who, in turn, will protect and secure Australia, then it is up to us to make a difference. If you’re not up to it, find something else to do with your life. There is no place for you amongst this band of brothers and sisters.”

Wow. Did you get the message? Was it loud and clear? When working with verbal communication, non-verbal cues account for 55% of the message content. What makes the video resonate is the clear and palpable, yet completely contained, fury he feels at this event. Paralanguage, use of pitch, tone, pauses, etc. further enhance his message. That phrase, “I will be ruthless” is particularly powerful in emphasis. His belief in his words shine through. His demand that his personnel live up to better standards couldn’t be more clear.

To analyze it further on written/verbal and formal/informal axis, this communication was verbal, but was it formal or informal? It was an official statement, released by the Australian Army. He was dressed in uniform. This was a formal communication, but lacking in some most formal trappings. How might this appeared differently if he was in formal dress uniform, as if giving a report to Parliament? Might that have provided the wrong image? The every-day barracks uniform was more appropriate when addressing the rank-and-file members of the military, yet still provides distinction to the civilian audience.  He did wear a more formal uniform in speaking with the press.

Let’s review this communication on the five elements I spoke of in my first article:

  • Goal – Make a clear statement about repugnant activity and demand change
  • Message – Women are service valued members; demeaning and harassing conduct will not be tolerated
  • Audience – The public and members of the Australian military
  • Medium – A video posted on a web site (we’re looking at it four years later!)
  • Metric – No further incidents of this kind take place

You can look up more of Lieutenant General David Morrison, retired, comments at women’s conferences. He’s a powerful speaker. A lot of that power comes from his commitment to his message and the way that commitment shows in his delivery. The video is inspiring, and I have often used it when speaking about communication, not only for its instructional value, but to emphasize my own commitment to an inclusive environment.

For the second half of this article, let’s look at a project situation and talk through how we might use communication to coordinate activity.  Some version of this situation has been used by development teams for ages, and different version control systems use different methods to manage source code.

  • Situation: Let’s say we have a sizable company producing an on-prem product. Code flows up from many development branches to one of eight group branches to the aggregation branch to the main branch. The aggregation branch moves to main whenever it builds cleanly and passes build verification tests. When the aggregation branch goes to main, those changes are pushed down into group branches by the build team. The code is tightly coupled, meaning that changes in one group branch may break code in another group branch. Thus, the aggregation branch is often broken and requires fixes after group branch merges. Sad-face.  🙁
  • Stakeholders: The company contains 320 individual contributor developers (with a quarter of them formally dedicated to test) and 80 individual contributor technical PMs. The development team is divided into forty teams headed each headed by a lead, five leads report to a group manager, eight group managers report to the VP of Engineering. The technical PMs are dedicated to a development team, with 10 TPMs reporting to a TPM lead who reports to a group manager. A build team, part of an engineering tooling team reporting to a group manager, is responsible for producing all of group branch builds, the aggregation branch builds and the main branch builds. The project manager reports to the VP of Engineering. Marketing, finance, etc. are interested in the project, but not in code movement aspects.
  • Goal: Your mission, if you choose to accept it, is to move code from group branches to the aggregation branch – while minimizing conflicts and maintaining the high-level project schedule. Refactoring code to reduce dependencies is not in scope.

How might you organize this?

One way to do this would be to create a calendar for aggregation branch integrations with the goal of reducing conflicts through intelligent scheduling. If you know one branch always breaks other branches, isolate its integration.  With a web based calendar (pull communication), groups could put their chosen integration dates on the calendar ad-hoc, or could be scheduled specific days for predictability. The build team could produce daily mails (push communication) indicating progress and resolutions for integrations, build results and build verification test results. The build team could also hold a daily integration meeting (interactive communication) for build, reviewing incoming payload, possible conflicts, possible delays, reviewing build breaks, assigning engineers to integration failures, etc.  The project manager could hold weekly project hot issues meeting (interactive communication) for the Engineering VP and group managers (along with emailed meeting notes with action items, emphasizing verbal communication with written).  The project manager could also send  a weekly status and direction mail for the whole team (more push communication). Graphically, it would look like this:

 

What if the company had more than one product division? This situation could be more complicated if a third of code and functionality came from outside this division. It would be necessary to add some communication to ensure those groups were on track and their code products could be integrated properly. This division’s project manager’s discussions with that divisions’ project manager (and review of their status communications), along with a bi-weekly meeting of all contributing group managers, might suffice – or it might not. What if this project is only part of a larger integrated project, and there are ten more divisions just like yours? The complication increases exponentially.

Consider that this example is merely one part of a project, code flow.  There are many ways to structure code production (business analysis) and equally as many ways to manage communications on the process (project management). There’s also managing what you are producing, is that production happening according to plan, is that product meeting expectations, and many other aspects of managing the project.  We spent no time talking about marketing teams, finance requirements, or other project matters. A communication plan must account for all stakeholders and all activities, and is vital to monitoring and controlling an overall project.

 

Communication, Part One

Loren S. DeLaOsa, CIPT, PMP Communication

“Communication is 90% of what a project manager’s job.” That thought has been a part of my professional DNA for so long that that I don’t remember if it was from the PMBOK® or one of RMC’s PM courses. Project management, at its root, is methodology for social organization to accomplish a time bound goal – and communication is absolutely key.

Communication is a huge topic. I’m constantly learning new things about it, and you should as well. The larger the organization, the bigger the project, the greater the need for strategic communication planning.

How can we break down types of communication? Well, communication can be formal or informal. Formal items are like corporate filings, presentations to management, annual reviews and court summons. Informal is like phoning a friend, hallway conversations, email or texting. Formal/informal communication is mostly a distinction of how “official” the message is. Addressing a court summons vs. returning the call of a friend have very different failure consequences, and therefore different priority and urgency.

Communication can also be written or verbal. Written is like a billboard, newsletter, pamphlet or email. Verbal is a speech, radio or TV news. Written/verbal can be mixed to maximize impact. If I give a presentation, and then also give you handouts to take home, you’re much more likely to remember and retain the information I’ve presented.

Formal and informal, written and verbal — those are the types of communication you’ll be using in a project.

Let’s break down communication into its simplest form in order to better understand it. The model used in most communication theory is the Shannon-Weaver Model. (Side note: Do you know how hard it is to get professional, culturally sensitive, graphics at a reasonable license price? Hard. Please enjoy my meant-to-be-inoffensive-and-inclusive doodles!)

Let’s explain our simple 1:1 interaction. There’s an idea the sender has. The sender encodes that idea, transmits a message over a channel, the receiver decodes it, and hopefully winds up with the same idea as the sender. That can be validated by the receiver taking their concept of the idea, encoding it, sending a message which the original sender decodes and compares to their idea. If the sender agrees it sounds correct, we can confidently say “communication has happened!”

As you can see, communication is a complex activity. What happens when we have more participants? How many different channels with four people?

The more people, the more complex this gets. The formula is x = n * (n-1)/2.  So the number of possible channels are:

  • 4  people:  6
  • 10  people: 45
  • 20  people: 190
  • 50  people:  1,225
  • 500 people: 124,750
  • 5,000 people: 12,497,500

So, if your project involves 5,000 people, there’s nearly 12.5 MILLION possible communication channels. That’s a lot. Maybe it would be good to strategically plan how you’re going to communicate in that project?

A communication plan answers who needs to know what, when. It’s essential to address communication needs from the beginning of the project through its closing. To determine the “who, what, when and where” of project communications, a stakeholder analysis must be performed. What information do stakeholders need, how will it be distributed, how often using what methods, how will it be stored and archived to be available as needed?  These are all questions that the communication plan should address.

Every individual communication should involve consideration of five elements:

  • Goal – what is trying to be accomplished
  • Message – what needs to be said and its timeliness
  • Audience – who needs to know and why, segmented
  • Medium – how the message gets out, meeting, web site, email, RSS
  • Metric – measurement of whether the goal was accomplished

The first and second elements are goals and metrics, which go hand-in-hand. The goal is what is trying to be accomplished, and should be specific, measurable, achievable, realistic and timebound (SMART). Goals in communication could be action, informing, persuasion, motivation, decision making support or education. The metric is a measurement of whether the goal was accomplished. Example metrics for the goals listed are:

  • Action metric – did the desired action happen on time and by specification?
  • Information metric – did the audience receive the information, understand it
  • Persuasion metric – audience mind changed?
  • Motivation metric – is output measurably increased?
  • Decision making support metric – do follow-up questions indicate understanding?
  • Education metric – do class scores on tests demonstrate absorption of material?

The third element is message. The message is what needs to be said and its timelines. In its simplest form, it’s an object of information. The formation of the message is based on its goal. There are other things that influence a message. If you consider, communication patterns change depending on the relative positions of the participants; a person speaks differently to their boss than their children. Here are some items that influence the way that a message is both encoded and decoded:

  • Social context (professional, informal, etc.)
  • Assumptions (underlying framework of the interaction)
  • Perception (different people see the same event differently; a coach vs. a player vs. a spectator)
  • Attitudes (towards self, receiver, subject)
  • Past Experiences (how prior interactions have gone; see my post on ethics)
  • Culture (different countries, different age groups, different genders)

Noise is a result of these influences.  This is a reason why it is critically important to check that the message was received appropriately. The best way to do so is for a receiver to decode and repeat back the understanding to the original sender in a feedback loop.

The fourth element is the audience. What I mean by segmentation is consider the different groups of people. You’ll have individual contributors, leads, group managers, directors, executives etc. You could have software developers, technical PMs, marketing, engineering support, etc. You could have multiple companies involved. You could have multiple geographic locations and time zone considerations. A message may have a primary audience and a secondary audience. The message might need to be different depending on the audience. Different stakeholders will have different information needs. If you have too many messages, or untargeted messages, audience “numbness” results.

The fifth element is the medium. The medium is how the message gets out, for example, a meeting, web site, email, RSS feed, and so on. The choice of medium is based on timeliness, cost effectiveness and reach. A medium can be interactive (a meeting, social network), push (newsletters, status reports, email) or pull (web sites, posters, billboards). Choice of medium is important. Meetings are good for back-and-forth idea generation or for decision making, but they shouldn’t be used to disseminate information that can be given in email. A fire alarm, noise and blinking lights, is a very particular type of push message, its timeliness is immediate and meaning well socialized in fire drills. Web sites, a pull medium, are good for collaboration and for reference; they aren’t very good for immediate information. You wouldn’t want a web site to say “FIRE! GET OUT OF THE BUILDING NOW!”

So that’s the essentials of communication, part one of three.  In part two, I will share and analyze my favorite communication of all time and provide a high level example of communication planning. In part three, I will share thoughts and tricks that I’ve collected over the years.