Communications

Know Your Customer

Communications with your customer(s) and team(s) is key to your success.  Knowing what they want is just as important as what you plan to deliver.  I laughed out loud (uncomfortably) when I saw the graphic to the left.  Though I'm not Jewish, I've worked with a lot of people from around the world.  I've grown to appreciate the things that make us all unique.  Trying to sell some Jews a ham on Chanukah is almost as bad as offering an all-you-can-eat meat buffet to a vegetarian.  It doesn't matter how good of a deal you can offer, the product itself must meet the needs (and wants) of the customer.  Perhaps if the vendor of the boneless smoked ham had the list below, they could have avoided this embarrassing (and potentially costly) situation. Problem Statement

Describe the business reason(s) for initiating the project or building a product, specifically stating the business problem.  Identify the high level goal it relates to.

Description

Describe the approach the project or product will use to address the business problem.

Goals and Objectives

Describe the business goals and objectives of the project or product. (I like user stories)

Scope

Describe the project or product scope. The scope defines limits and identifies what is delivered (inclusive). The scope establishes boundaries and should describe products and/or services that are outside of the scope (exclusive).

Critical Success Factors (Acceptance Criteria)

Describe the factors or characteristics that are deemed critical to the success of a project or product, such that, in their absence the it will fail.

Assumptions

Describe any assumptions related to business, technology, resources, scope, expectations, or schedules.

Constraints

Describe any constraints being imposed in areas such as schedule, budget, resources, products to be reused, technology to be employed, products to be acquired, and interfaces to other products. List the constraints based on the current knowledge today.

I want to thank my wife for sending me the image.

No, I’m Saying…

I was in a contract negotiations meeting for several hours yesterday.  The most notable quote came after the customer was asking for the basis of estimates for the scope of work being proposed. I think both the vendor and customer could have done a lot better if they had just valued customer collaboration over contract negotiation.

I felt like I was watching a first-time buyer at a used car dealership.  When the sticker price is in the Millions of dollars, it becomes a very interesting game of poker.  As usual, my job was not to negotiate.  It was merely to observe and advise.

Vendor: You're saying the LOE is too high.

Customer: No, I'm saying I want you to justify your LOE.

Like the image?  Find it at Pictofigo

(Zombie) Customer Service

I'm currently enjoying Delivering Happiness, the book by Tony Hsieh of Zappos.  In the book, his approach to customer service reminds me a lot of what Seth Godin wrote about in his book, Linchpin.  For those looking to map this to an activity in the PMBOK, I see this falling under Manage Stakeholder Expectations (Executing and Communications).

In any case, I can relate to my intent to communicate directly to people as people, not as mere customers, vendors, or colleagues.  Every day, I see people act as though they have no free will to make a decision.  They ignore what is right or wrong.  They act like they need permission to be honest and humble. They act like...wait for it...zombies!  Yes, zombies!

I recently sat in a meeting and heard how the vendor screwed up.  I'm talking completely-their-fault nobody-else-to-blame screwed up.  When confronted by the customer, their reaction was "I'm sorry you feel that way about [this].  I respect how you feel."

My reaction?  [expletive] YOU, man! I don't care if you respect how I feel or not.  And don't try to feed me that Dr. Phil line about me owning my own feelings!  What I want to hear you say is "I'm sorry we screwed up.  I will do whatever I can to make this right."

Another scenario that comes to mind was my wife contacting a credit card company about something.  The customer service rep was painfully unprepared to talk to a human being.  They could not deviate from a script one word without needed to talk to a supervisor.

Thank you for calling.  We appreciate your business.  Can we interest you in buying our credit protection plan? [my wife complaining] Oh, I'm sorry, can I put you on hold while I discuss this with my supervisor? [5 minutes later....click]

People, you want to provide great customer service?  Empower your customer service representatives.  Vendors, you want to provide great customer service? Empower your teams to admit when they screwed up and offer to fix it, not just cover it up.

I've always seen the best performance from my teams, when they knew what we needed to do but were not being told how they needed to do it.  I believed they would make the right choices for us all to reach our goals.  Those of you in the Agile community get this already.  Empower the team and communicate with everyone as much as possible.  Don't just communicate.  Talk to them.

So, as I step down off my rant soapbox, I want you to take a look at the Zappos core values (listed below). They actually remind me of the 4 values, 12 principles of the Agile Manifesto or Agile community as a whole.

Zappos core values

  1. Deliver WOW Through Service
  2. Embrace and Drive Change
  3. Create Fun and A Little Weirdness
  4. Be Adventurous, Creative, and Open-Minded
  5. Pursue Growth and Learning
  6. Build Open and Honest Relationships With Communication
  7. Build a Positive Team and Family Spirit
  8. Do More With Less
  9. Be Passionate and Determined
  10. Be Humble

If you had 10 core values for your project or team, how would you refine this list?

Like the image?  Find it at Pictofigo


Identify Stakeholders (& Zombies)

The Program Management Body of Knowledge (PMBOK) would have you Identify Stakeholders at the crossroads of the Initiating process group and the Communications knowledge area.  Basically, what the Project Management Institute (PMI) is trying to say is you should be identifying all of the people who are somehow related to the project.  Who holds a stake in the success or failure of your project?  You should complete this activiy at the beginning of your project lifecycle. This isn't bad advise.  It doesn't matter if you're a Project Management Professional (PMP) or an Agile practitioner.  The idea here is to lower the risk of having someone, who may be for or against your project, from disrupting things.  You have to accept that everyone has different and unique motivations.  Know your sponsor, product owner, stakeholders...zombies.  Zombies!?  Of course.  Once you identify everyone even remotely associated with your project, try to understand their motivations so you will be able to build relationships.  But look out for the zombies.  They won't listen to you and just do what they want.  Don't pass judgement on them.  Zombies are zombies.  They're going to do whatever they want and you and everyone else is just going to have to deal with it.

Today I was in a meeting with a zombie.  Everyone in the meeting appeared to have the same opinion of the topic at hand. Everyone, that is, but the zombie.  The topic itself really isn't important.  But it was basically a room of people against one zombie.  You may start to ask yourself what the zombie must be thinking.  Seriously, it's an exercise in futility.  Just make sure you know who they are early on and make some contingency plans.

So, remember kids, identify stakeholders (and zombies) early in your project.  Start building relationships with the people.  Find out what motivates them.  Know who are the zombies!  Take appropriate action, either by buying large quantities of plywood to board up doors and windows to the office or get some brain flavored mints.  If you can't keep the zombie away, the least you can do is freshen their breath.

Like the image?  Find it at Pictofigo

Communicating Effectively

When referring to communications and project management, you should be aware of what you do and what you should do.  A lot of issues we suffer from are caused by poor communications.  I can't stress enough how much of a positive or negative impact communications can have your project. What do I recommend you do?  Here is an ordered list of communications methods.  The first on the list is your last resort and the last on the list should be your preferred method.

First up is email.  Yes, email.  For most people, this is their preferred method of communications.  Actually, it should be your last.  Have you ever sent an email that was completely misunderstood?  Did you ever write an email that showed up in someone's inbox it shouldn't?  Has email become a complete time suck?  Well, stop feeding the fire.  Get your butt out of that chair and go talk to the person or people.  Go to the bottom of the list and work your way up.  You last resort is to send an email.  By the way, don't be checking your email every 5 minutes.  It's a compete time suck.  Check it, at the most, once an hour.  Make sure everyone knows you don't check your email that often.  It helps manage expectations and could even encourage one-on-one communications (if it's that important)


Our second to last communications choice is telephone.  Yes, telephone.  It's a little better than email.  At least you can sense emotion if you're listening closely.  When communicating, use the senses you have available to get indirect feedback.  Try smiling when you talk on the telephone.  I bet the other person will know you are.  I know telephone calls can really dirupt you flow of work but it's better than someone showing up at your desk unannounced.  Timing of communications is almost as import as the method used.  Try to plan your telephone calls.  Voicemail is nothing more than audio email, as far as I'm concerned.  Make sure you leave your name and telephone at the beginning of the voicemail (and end).  Explain why you are calling.  Don't just say you'll just call back.  Voicemails are fragmented and can easily be taken out of context, if the relevant information is not included.


Next on our list is video-conference.  If you are working with distributed teams, video-conference is a really great way to communicate.  One-on-one communications is still our primary choice but this is a very close second.  As technology advances, so do our efforts to have good meaningful exchanges.  A picture is worth a thousand words and so it being able to look your colleagues in the eyes (or at least see their face).  When talking with someone, I believe body language communicates a lot.  Video-conferencing also allows a much more rapid exchange of "visual" ideas.  Image putting you hands in the air and saying "the fish was this big".  Now imaging trying to communicate the same idea via telephone or email.  Need I say more?


And so we arrive at my primary choice of communications... face-to-face talking.  Lisamarie Babik and Menlo Innovations refer to this as High-Speed Voice Technology™. When is doubt, get up out of your chair and into the face of another person.  Remember, the things you say and the things people hear are not always the same thing.  You can’t have agreement until the thing you say and the thing someone hears are the exact same thing.  So, what is a way to help ensure someone hears what you intended them to hear?  You need to ask questions.  The next time you are talking with someone, ask questions so you feel completely confident they heard exactly what you wanted them to hear.  Once you make it past that, things should go much smoother because you’ll both be seeing eye-to-eye.  Try that with email sometime.

Just because I'm advocating face-to-face communications, I'm not saying you should be having more meetings! Do what makes sense.  But, let's say there is going to be a meeting?  When inviting people to your meeting, choose High-Speed Voice Technology™ first and then move on down the list.  Imagine having a daily 15 minute meeting with 5 people.  Now imagine what you would do, and the level of effort and complexity, if you couldn't all meet in person.  It should make you appreciate a face-to-face talk just a little more.

Like the images?  Find them at Pictofigo

Zombie Communications

The focus of this post is on communications or the lack thereof. One of the definitions of "communicate" is

to give or interchange thoughts, feelings, information, or the like, by writing, speaking, etc.

Team communicating before zombie attack

When dealing with people, regardless if its your customer or your team, you have to communicate.  This involves, in one fashion or another, speaking and listening.  I've written about how I feel speech can be presented different ways.  I know my wife is going to call me a hypocrite but you really need to stop....listen....stop...talk.

First, you have to be in agreement as to when, where, and how you're going to communicate with each other.  Once you get that out of the way, the things you say and the things people hear are not always the same thing.  You can't have agreement until the thing you say and the thing someone hears are the exact same thing.  So, what is a way to help ensure someone hears what you intended them to hear?  You need to ask questions.  The next time you are talking with someone, ask questions so you feel completely confident they heard exactly what you wanted them to hear.  Once you make it past that, things should go much smoother because you'll both be seeing eye-to-eye. (Thank you Simon Sinik for that)

Above you see a very simple graphic.

A is doing all of the talking

Notice that he is facing the listeners.  He's engaging them.  He's talking but is he listening?  Is he asking any questions?

B are doing all of the listening

Notice how engaged these two look.  They must really be listening to what A has to say.  Unfortunately, they are not reciprocating.  They should inform A that his brain is about to be eaten.  Granted, they may have said something like "You need to watch your back".  If A doesn't ask "when"  or "what do you mean" he needs to watch his back, he's going to be zombified.

C is a zombie

Zombies are not good communicators.  They don't speak, other than an occasional moan.  They don't listen, unless you're crying for help.  In that case, they come and eat your brain.  For example, I can scream "Don't eat my brain, don't eat my brain!"  Will a zombie listen?  No, they'll eat your brain because all they hear is "brain".  Note to self:  Zombies are not team players and they are also poor communicators.

This is what happens when people don't listen.  The zombie attacked A, who was doing all of the talking.  Both A and C zombified B.  This is what you get if you're not a good listener.  Perhaps this would not have happened if they were reading each other's body language.  But that will be left for another post.

Like the images?  Find them at Pictofigo

Lacking Empathy

empathy

As a project manager, I personally believe empathy is one of the most important virtues.  I think it's one of those attributes that makes us most human.  You can't expect to take care of your team, or even customers, if you are unable to be empathetic.  Regardless if you can help someone, ask anyway.  Regardless if you can understand what they are thinking or feeling, try anyway. I recently participated as a juror in a criminal trial.  Though I knew it would be a personal inconvenience, I did it because I thought it was the right thing to do.  It was my obligation as a citizen, to do my part in ensuring justice was served.  Some would argue if it truly was, but I digress.  So, what's the point of this blog post?

About a month ago, I informed the necessary (corporate) parties who pay me that I had been selected to be part of a jury pool.  Upon sending them the necessary information, I was told I would be paid for a full 8 hour day, minus $20. (The amount Frederick County pays a juror for one day of service).  Considering the cost to short my paycheck was probably more than $20, I wasn't going to argue.  If that's what they wanted to do, it was a wash for me, with the exception of the work I had to delay for my customer.

Upon submitting my hours on the second day, I received a (billing) submission error.  Because it was an ambiguous error message, I send an email to accounting.  I said, upon completing my second day of jury duty and billing my time, I received the error.  Within a few minutes, I received a very short email response. It informed me I would only be paid for 1 day of jury duty, that "it's in the handbook" and I would have to bill my time to my Paid Time Off (PTO).  I was surprised I didn't get a "I'm sorry if there was a misunderstanding..." or "I regret to bring this to your attention..." email.  Seconds later I got another email.  It was one line.  "You can also take Leave Without Pay".

Let's take a moment to reflect.

Both of these emails came from the Human Resources department, not from my direct chain of command.  I did get a telephone call from my Director within a few minutes.  He apologized if I had misunderstood the corporate policy to only pay employees for one day of jury duty but added he would work with me if I had already made plans that would result in a PTO deficit.  I want to commend him on having empathy.  He showed true leadership in picking up the telephone and calling me.  He showed true leadership in listening to me vent for several minutes.  It didn't change anything but he certainly scored a few points in my book.

We're all human beings.  We all like to be treated like human beings. When in doubt, pick up the phone or go talk to someone directly. Most importantly, don't ever send a one line email that basically says "RTFM"

Like the image?  Find it at Pictofigo

5 Twitter Retweet Rules

I spend a lot of time online, perhaps too much.  I read blogs and tweets and engage people wherever and whenever I can.  Using all of these methods of communications is not necessarily for me to just spout project management doctrine.  I look to share ideas to better myself and hopefully make life a little easier for others. It doesn't matter if it's a lifehack, a web app, or discovering a blog.  There is a lot of cool stuff out there and every day I find and learn something new.

Once in a while something does rub me the wrong way.  It might be someone trying to pick a fight in the blog comments or maybe it's someone flooding my Twitter stream with noise.  This weekend it was too little sleep in combination with too much Twitter noise.

As many Twitter users know, the more followers you get, the louder your megaphone.  To counter that, the more people you follow, the louder the noise.  The noise can sometimes be deafening.

I usually see the same topic cycle through my Twitter stream 4 or 5 times before I finally click on it.  What I like about this process is that it's organic.  The link seems to increase in value the more people I listen to tweet about it.  Once it hits critical mass in my head, I check it out.

So, what's the rub?

This weekend, I had over half a dozen people tweet the exact same thing at the same time.  My Twitter feed was momentarily flooded by people who subscribed to a website.  Rather than having people I follow retweeting the link organically, the site sent out the tweet.  That feature deprecated the value rather than increasing it.  Though we all may be fighting for positions in the stream, hoping someone will hear us, I like to follow a few simple rules.

My Twitter Retweet Rules

  1. If you read something notable and it provides value, retweet it
  2. If you read something that is not notable or does not provide value, do not retweet it
  3. If someone I trust and respect tweets something, I see value
  4. If more people I trust and respect retweet the link, I see even more value
  5. If several people tweet the exact same thing at the exact same time, all value is deprecated

Graphic: Pictofigo