Communications Archive

Conflict in Value Perception

– January 11, 2011Posted in: Agile, Project Management

This weekend I witnessed a true conflict in value perception. We’re not talking values like:

- We treat others with respect
- We are humble

Rather, it’s about what the Customer (Product Owner), the Vendor (Core Team), and the I (Facilitator) believe has value. I see direct value, like actual delivery of product, and indirect value, like mitigating risk by facilitating communications.

We started a deployment cycle that is going to take some time. The team activities are clearly defined and level-of-effort have been estimated. Dates in which potential risks could arise have been identified. This is all good. Until an activity begins, we won’t be certain if a risk will be fully realized. This is why I’m a really big proponent of daily communications. Every morning, we have a 15 minute (status) meeting. (The culture demands that we call it a status meeting so I’m good with it.) The extended team is distributed (3 locations) so this is a little challenging.

Though I stressed to everyone the importance of daily communications (at a minimum), this weekend I was a little shocked at what happened. Deployment activities were taking place over the weekend. There was a trigger point for a risk that had been identified. During the Friday status meeting, the Customer informed the team that they would not be on the status call. Though I had agreed to be on the status call, this was a bit of a paradox. I am a facilitator. Per the contract, I can not act on behalf of the customer. IF the team ran into a roadblock over the weekend, the customer would not know until Monday morning. We could potentially be delayed by two days until the customer could provide feedback and direction.

So, what happened over the weekend? The team did indeed run into a roadblock. But, they were empowered enough to get the work done. Because risks had been previously identified, a mitigation strategy was in place. The team was able to bring in team members, over the weekend, without having to consult with the customer.

I still believe if the deployment is going to be a success, all parties must be fully committed. We’re all in this together. I’ll never ask a member of my team to do something that I wouldn’t be prepared to do myself.

Something David Bland said at the APLN DC meeting really resonated with me this weekend. He said,

When dealing with distributed teams, keep the feedback loops tight.

David could not have been more right. We dodged a bullet this time around. Empowering the team allowed us to do this. But, the customer took an unnecessary risk, by intentionally lengthening the feedback loop from 24 to 72 hours.

Like the image? Find it at Pictofigo

Gingerbread Crime Scene

Derek Huether

– January 6, 2011Posted in: Project Management

After a horrific crime scene at school nearly left our son traumatized for life, I think a better stakeholder management strategy could have been used.

About a month or so ago, our son and his classmates all made little paper gingerbread men (and women). They were all so proud of their creative achievements. All was well in the world, until they returned to their classroom one day to discover the little gingerbread people were gone. Nothing was left but some glitter (gingerbread blood) on the floor.

The story they were told was a leprechaun and fox had broken into the school and captured all of the gingerbread people. I can’t remember at this point where the story came from. One of our son’s friends went so far as to say he saw the leprechaun chasing the little guys and gals. Don’t you just love the imagination of the 5-year-old?

Unfortunately, this left some of the kids very distressed. They didn’t know the big picture. We, as the parents, did. What actually happened was the gingerbread folk were mailed all over the country to friends and family.

Photos were taken and, about a week ago, there was a return of the the Gingerbreads. Our little man went to visit a family friend in California. Mr. Gingerbread made some friends, took in the sites, did a little lounging, and even wrote our son a letter.

Hello Jacob!

WOW, what a fun week I’ve had here in California!

Upon landing at the airport, I rented this really cool car and went for a nice drive around the Orange County area. This area has so many nice beaches, parks and shopping centers! The city I stayed in is called IRVINE.

I did not know that the weather could be SO nice and warm during the Fall/Winter season! I was happy to be able to enjoy some sun and get a nice tan by the pool!

The day I arrived it was 80 degrees here!

The traffic in California is very heavy, but I got to learn the roads and freeways pretty quickly!

I also got a chance to visit a city called San Juan Capistrano and toured the historical MISSIONS.

Now it’s time to go back home and see you and all my friends again!

Gingerbread Man

So what is the Project Management hook? When you’re busy planning project activities, put yourself in the shoes of the stakeholder or Product Owner. Are they going to react positively or negatively to your plan? You should have individual Stakeholder Management Strategies identified. Though our son was near tears by the idea of a leprechaun and fox breaking into his classroom and killing off Mr. Gingerbread, we were there to be supportive and convinced him the outcome wasn’t so dire.

Did you see the leprechaun killing Mr. Gingerbread and his friends?

Did you know that gingerbread people are known to be very fast…faster than foxes and leprechauns?

Though it all worked out in the end, I wouldn’t recommend trying this on a Kindergarten class. The gingerbreads could have easily left notes saying they were all going on vacations and avoided all of the drama an carnage.

Popularity: 1%

Tags: Communications, Stakeholders

Know Your Customer

Derek Huether

– December 5, 2010Posted in: Project Management

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.

Popularity: 1%

Tags: Assumption, Communications, Constraint

No, I’m Saying…

Derek Huether

– November 19, 2010Posted in: Project Management

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

Popularity: 1%

Tags: Communications, Contracts, Negotiate

(Zombie) Customer Service

Derek Huether

– November 18, 2010Posted in: Agile, Project Management

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

Deliver WOW Through Service

Embrace and Drive Change

Create Fun and A Little Weirdness

Be Adventurous, Creative, and Open-Minded

Pursue Growth and Learning

Build Open and Honest Relationships With Communication

Build a Positive Team and Family Spirit

Do More With Less

Be Passionate and Determined

Be Humble