Communication, Part One

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

 

Yup. Still Magic…

Hermione and I were watching Moana on Netflix with friends, when she said, “Wait — the chicken!  Did they have chickens?” Someone looked thoughtful, “Weren’t they introduced by Captain Cook in 1778?” Out came the phones, and Hermione said “Huh.  Polynesians brought a form of chicken with them. ‘Red Jungle Fowl‘. Totally looks like the chicken!” We all agreed, absolutely does. Cluck-cluck-cluck-ba-bawk!

Phones. Still changing the way we interact. Still made of magic.

Hello, Dolly! Using the Right Tools

Ever change a tire? How much work is it to carefully wrestle a wheel onto its car mount, avoiding banging the calipers or rotors? If those wheels are nearly a foot wide, 27 inches in diameter, and weigh nearly half of what you do – quite a lot! Faced with the problem, I bought a wheel jack – Dolly. With the car on jack stands, Dolly works perfectly to remove one wheel, move it, place another wheel on the Dolly’s rollers, align it to the mounting bolts, and gently place the wheel on the car. This simple tool makes the whole job of swapping tires much less of a chore.

Normally, four wheel jacks are used to lift and move a car. This can be handy if you’ve removed the engine, or if you have a large garage and want to tuck the car a corner for storage. Seeing wheel jacks in use, however, gave me (and apparently many other people) the idea to use one to change tires. Using a single wheel jack to change a tire isn’t the primary use case, however, once you’ve done it, it seems obvious – but my dad, who first taught me about cars, never showed me the trick!

Having learned a trick that works for this job, is a wheel jack the right tool for all jobs? Of course not. Just as there is no one tool for every job, there is no Excalibur to make you Ruler of All Great Projects. Rather, if you know process groups and knowledge areas well, and therefore how to effectively run a project, you can decide what to optimize for in your projects. In software, the quest is not for “the single, best software development practice for ALL projects”, but rather “the single, best software development practice for THIS project.”

Think of it this way – knowledge is your tools. Knowing how and when to creatively use tools to best effect is what makes a craftsman or artist. The process of sizing up the problem provides the insight on how to resolve it. When organizing a development project, it is essential to understand the requirements and constraints, both from your organization and your customers, and then create the best development practices for that specific product and project. Sounds a lot like business analysis, doesn’t it?

Let’s consider organizational requirements and constraints. Two areas to consider is what the PMBOK® calls “enterprise environmental factors” and “organizational process assets.” Enterprise environmental factors are the company culture and existing systems that the project can make use of – or will have to deal with. You could substitute the word “baggage” and get most of the idea. “How we’ve always done it” might help or hurt your project, making it essential to ask questions and review basic assumptions. Organizational process assets are existing process, procedures, and historical information – do you have a bug tracking database you can review? A build system already in place? Other projects to compare? Can you take advantage of process assets to benefit your project? What assets could your project contribute to others?

Think about your development team. Is it one developer or hundreds? Are they in one place or geo-distributed? How many languages and cultures are involved? Is it one unified team or many disparate teams with different managers and goals? Is the team fixed for the duration or the team members rotate and change over time? Is a single company or many companies involved? The team and resources available shape the development project, and shape when and where you’d use traditional or agile methodologies. Planning to use Scrum in a large monolithic, complex, tightly coupled and not well-documented Version 1.0 design with a global team of hundreds across multiple companies? Well, have fun storming the castle!

Customer requirements and constraints are the other influence. Customer requirements will not only define the product, but how you produce it. Whether your product is an embedded system or a cloud application dramatically changes how it can be serviced. Is the product consumer or enterprise? One user or hundreds of millions?  Single installation or high volume on many platforms? Are there legal or industry (healthcare, finance, government) considerations? Is the software free or cost millions of dollars? Is the product a simple game or mission critical avionics? Answers about customer requirements for your product will inform how to optimize your development process. Reliability/quality vs. velocity is an important balance, and needs to be determined by customer expectations and use cases. Software quality issues can be trivial. The “exit seat position” feature in my car has an “arrays start a zero!” bug – it means the seat doesn’t quite return to preset driving position, so I don’t use the feature. For another application, however, software quality issues can be extremely expensive – or even deadly.

There are gotchas in the process.  Micro-optimization can cause poor decisions. If the company produces a million cars, and instead of using a $2 switch per car, you substitute a $1 switch, you’ll get a pat on the back for saving the company a million dollars. If, however, those $1 switches have a MTBF of one year, instead of ten years for the $2 switches, you will cost the company three million in warranty costs (assuming the cars have three year warranties), plus reimbursing dealership labor (which will easily bury the cost of the switches). Also, data-driven decision making can cause difficult-to-metric costs to be ignored or trivialized. Loss of customer trust and goodwill can be devastating, but hard to quantify.

To summarize, project management knowledge is common regardless of the project – but the techniques and details of execution in software development can be very different. Traditional or agile, know the fundamentals, then make intelligent optimizations to meet business and customer goals.

For another take on this topic, read “The Right Way to Ship Software”.  For a story of development gone wrong, read a story about a video game.  You, like me, probably have some genuine empathy for those folks, along the lines of “Oooooh, ouch, yeah, I remember something like that.”

Business Analysis

Let’s talk about business analysis (not to be confused with business analytics, which is different).  Consider a SQL development project.  Defining it is a matter of answering three questions:  Why, what and how?  “Why” are you doing it is the business requirements, “what” are you doing is the logical and functional design, “how” you are doing it is the physical design and code.  If you think of those answers in a continuum from requirements to code, usually a systems analyst or technical PM is the one to provide those answers someplace short of “code”.  In Scrum, the answer to “why” is owned by the product owner, who provides and stack ranks requirements and accepts work products as meeting those requirements.

So what is business analysis?   PMI defines business analysis from the context of a project manager who works with stakeholders to enumerate project or business requirements, and ensures projects drive successful business outcomes.  The International Institute of Business Analysis™ (IIBA®) defines it more expansively.  Their definition is more encompassing, and probably closer to what used to be thought of as business consulting, a practice to achieve organizational improvement.  Rather than paraphrase, read IIBA’s description.

I really enjoy my time as a business consultant, but it seems to me that the reality for most organizations is PMI’s view of business analysis.  Companies are always trying to get “closer to the customer”, to better understand requirements and thereby efficiently produce products customers desire.  Even so, it’s also my feeling that there’s a lot of value in IIBA’s Business Analysis Body of Knowledge (BABOK®) and understanding it makes for better projects.  It’s no trick to say the more knowledge a project manager has, the better are the projects they manage.

Doing The Right Thing

“Once you start down the dark path, forever it will dominate your destiny.”

That quote from Yoda in The Empire Strikes Back has two meanings. The first, and clear, meaning is that once you start justifying bad acts “for the greater good,” when will you stop? As time goes on, you will justify more and more questionable acts. The ongoing risk-reward calculus blinds you and normalizes bad behavior. The second, and subtler, meaning is once you have a reputation for heinous deeds, it will follow you. No matter how many “good” deeds you do, a single “bad” deed will be remembered. It damages the trust others have in you. People will expect you to behave unethically, and will act accordingly.

What can you derive from this? Ethics. Matter.

The popular news is filled with examples. How do you feel about Volkswagon right now? The $2.8B in penalties and resignation of executives is the least of their trouble. How about Uber? Issues with the company’s culture and ethics have leaked out, forcing change. Turing Pharmaceuticals and the behavior of its former CEO?  My guess is that no one in business is claiming to be that guy’s friend. These are just recent examples. There are many, many more.

The root of many intentional and unintentional lapses is the pressure to perform.  Do it faster, cheaper, or with fewer resources – make more money.  These values can become such a part of a company’s culture that individuals are strongly incentivized to short term gain.  It’s false economy.

Unimpeachable conduct has its benefits. An article in Bloomberg suggests that ethical companies are stronger and last longer. The Wall Street Journal suggests that companies perceived as ethical don’t reap premium prices, but that companies that are perceived as unethical are forced to sell at a steep discount. Forbes points out it is easier to be ethical than unethical.

The message should be clear. It is best to not only avoid impropriety, but the appearance of impropriety. Reputations are hard earned and easily lost. Ethical lapses can have both civil and criminal consequences. Winning at all costs is not winning, it is just the slow and inexorable deterioration of your professional integrity.

Today’s message is to encourage you to really think about ethical behavior and implement in your daily dealings.  Company culture starts with every individual.  Lead by example.   Don’t wake up one day in a black mask with a breathing problem, and wonder “How did I get here?” Instead, be honest and ethical until it is just second-nature.

Yoda: “Once you start down the dark path, forever will it dominate your destiny, consume you it will, as it did Obi-Wan’s apprentice.”
Luke: “Vader… is the dark side stronger?”
Yoda: “No, no, no. Quicker, easier, more seductive.”

Wise words!

(Disclosure: I work for Microsoft Corporation. Microsoft has a clear, and unambiguous, statement about business conduct. It has yearly training for all employees to reinforce that company culture. As a manager and mentor, I’m a passionate supporter of these policies.)

Agile and Bending Over Backwards

Every been asked to do the impossible?  I remembered a troubled project I was brought into.  The prior manager had been relieved, and there was three months left on this project.  By “three months left”, I mean “this is completed or scrapped by July 15th.”   No pressure.

On that project, I didn’t use traditional project management or the waterfall method of development.  You know how waterfall goes, you gather requirements, then you design and write specifications, then you implement in code, then you validate your code, then you put into production and maintain… three YEARS later.  If the requirements change in those three years, well, you’re taking costly DCRs.  Or maybe just borked.   Remember the Standish Group’s Chaos Report?  Waterfall development is organized, predictable, serene, and stately.  The results can also completely miss the point (particularly if no real project manager is involved).

Enter “The Manifesto for Agile Programming”.  It was pretty new back then, and I had gone through a seminar on XP (Extreme Programming).  The premise of agile read like the Jedi Code:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

With two developers and a government-provided database administrator, we tackled the project.  It was quickly divided up into modules (Larry, Moe, Curly, Schemp and Joe), each programmer assigned to the areas they worked in best.  I worked the database side and interacted with the client, bringing work for acceptance daily and getting weekly signoff.  Did finish on the agreed time-frame?  Yes.  Was the customer ultimately satisfied?  Yes.  And, most importantly to me, did I get paid and also get an excellent reference?  Oh, yes.

It might not have turned out that way.  The resources were the same.  I had two great, if a little temperamental, coders.  We used  good system design practice, which is to say “loose coupling, well defined interfaces” and so on.  Lots of projects have those and still fail.  What was different was how we approached doing the project.  We eliminated overhead, white-boarded specifications, increased customer interaction and rapidly responded to change.  Every day, work products were shown to the customer; if something wasn’t right, it was fixed by the next day.  It was thrilling.  And terrifying.  And it worked.

These days, I find myself using Scrum a lot.  This is an overview.  This is the website of the creators.  Finally, if you were looking for Certified ScrumMaster® certification (which, a few years ago, you couldn’t get a development PM contract job without), head over to the Scrum Alliance.

Before I close, a couple of cautions.  I’ve seen plenty of development organizations declare “we’re agile!” and use that as an excuse to do what I call “water-fail.”  Huge, predictive and stately development projects on specific timetables that use NONE of the design practices of waterfall because “we’re agile!”  Meanwhile, sprints are multi-month long, communication is lacking, specifications are non-existent.  Don’t do water-fail.  And even if you avoid that trap, watch code velocity vs. stability and react appropriately.  You’ll thank me later.

North Star of Project Management

The point I knew I wanted to be in technology project management in college. I had attended a class in organization and environment, and they told us about the Polaris Missile Program. A process was developed by the US Navy, Program Evaluation and Review Technique, that enabled the program to manage complexity and deliver a project on time and budget. Wow! Of course, the Navy immediately applied their PERT process to the next program with, shall we say, sub-optimal results. That was interesting to me. There was more to the magic of getting things to turn out right.

The Project Management Institute (PMI®) has spent a lot of time coming up with project theory, learning materials and tools for project management. The Project Management Body of Knowledge (PMBOK®) is the result. By definition, what is a project? Well, it’s a time bound effort with a unique end result. That would make “designing a car” (a car design and relating tooling being the unique product, that process having a beginning and end) a project, but “assembling a car” (putting parts together in a factory resulting a daily production run) is operational work.

PMI has defined the framework as “Process Groups” and “Knowledge Areas”. Process groups is what you go through over the lifetime of the project, which is to say Initiating, Planning, Executing, Monitoring & Controlling, and Closing. Knowledge areas are project management processes required to ensure various areas of the project are coordinated, and they are Integration, Scope, Time, Cost, Quality, HR, Communication, Risk, Procurement and Stakeholder (new in the past couple of years!) management. These can be arranged in a grid, with process groups as columns and knowledge areas on rows. When I refer to project management, that’s the overall framework. We’ve come a long way from the simple view of a Scope/Time/Cost triangle, or as my general contractor is fond of saying, “You can have it good, fast or cheap — pick two!”

[Updated 6/16/2017]

Generally, I write, edit, add links and then double-check facts with searches (if I feel I need to).  Anyway, after publishing this, I searched for some project management links and decided that PMI wrote a better short article about what is project management.  If you search the internet, avoid the Wiki topic — particularly if you think you might someday take the PMP® exam.  If you want an interesting site of articles, I’ll suggest projectmanagement.com, which is sponsored by PMI, but there’s a lot of possibly overwhelming detail there.  If you want to go all sorcerer’s apprentice, in my opinion your best bet is the RMC book PMP® Exam Prep.  I suggest buying the most recent edition, but if you’re just using it for random study, a used older edition is fine.  Just realize that the knowledge areas are evolving over time.

Clarke and Conjuring!

Rather than being a project manager, wouldn’t you rather be a project magician? What if every project you did came out like magic? Tada!

Projects can run smoothly, like magic, but, like technology, there are a lot of things to know and understand.  Complex things behind the scenes are integrated to produce amazing experiences.

My wife and I used to have discussions that were sometimes punctuated by “that can’t be right”. One of us would say “The US had a plan to invade Canada after WWI” (turns out, we did). Once upon a time, you had to go to the library, or boot a computer, or otherwise figure out the answer. Now? Middle of the discussion, out comes a cell phone. BAM! There’s an answer. We go, “huh!” and keep talking. Cell phones have fundamentally changed the way we conduct conversations. And use maps, buy tickets, etc.

How does that technology magic happen? Well, the answer is “a lot of work and services under the covers”. For example, GPS, which involves satellites all around the globe. Each one of those services is very complex, requiring skill and resources to create. If you’re not in the industry, and just interested in sharing pictures of your dog, a cell phone is simply magic.

How do you learn to do project magic? Sorting the wheat from the chaff, or the magic from the dust, can be difficult. Sometimes you need a guide. What I will provide you is some tools and understandings across a variety of topics and linked articles, all things to add to your bag of tricks.

Let’s do some magic.