Search This Blog

Loading...

22 June 2010

Ignorant or Stupid?

Sometimes we get ignorant stakeholders. Not stupid, just ignorant. Many people confuse the two terms, incorrectly substituting one for the other, but they are very different terms. To illustrate, I'll turn to the dictionary:

ignorant, adj. - uneducated in general; lacking knowledge or sophistication;

stupid, adj. - lacking or marked by lack of intellectual acuity

Ignorance is a lack of knowledge that is directly related to limited exposure or experience. Stupidity is ignorance despite sufficient experience and exposure. We can work with ignorance.

Stakeholder ignorance can come in many types and flavors. Some are brand new to working on projects. Others are new to their position, or new to business in general, and don't understand their business. Its not that they don't want to help and be part of the project, its that they just don't understand what it is they have that we on the project team need.

Pre-game Scouting Report

Some time ago I had a stakeholder, who was brand new to the company I was working for but not new to the industry or his role, ask me a question about product ordering. This stakeholder was concerned about the data entry time required to process single orders with a large number of ship to addresses. The scenario was that large customers with hundreds of branch offices wanted to place a single order for replacement supplies. The replenishment would then be direct shipped to each of the customer's branch locations. Each branch would receive a very similar order, where the total amount of product shipped would be based on the sales volume of each branch.

As I dug deeper into the requirements, it became clear that the problem wasn't one that would be easy or cheap to solve programmatically. Because each location would be receiving a unique set of items, there wasn't an easy way to write a program to automatically generate a list of products and quantities and then place an order for each location. After a few minutes of discussion, I came to realize I was in for a difficult time explaining the complexity of the request to my stakeholder. I knew this would be a challenge, so I reached deep into my bag of communication tricks and went to work.

The Play by Play

I began my explanation by talking about our order entry process and what it takes to turn raw goods into a finished product. I explained how the finished product arrives at the customer's door. I explained how our customers currently placed orders and why it was so hard, given his scenario, to automate the placement of that order. The conversation went nowhere. Given his apparent lack of knowledge, he shouldn't have been a stakeholder, but as we all know, we don't get to pick our stakeholders, but they do get to pick us.

My first attempt to explain the complexity involved in his request had failed, so I decided to move away from our specific process and use a more generic example I assumed he would be familiar with to explain the concept. I used Amazon.com as an example of how an order has only one ship to address. If you want to ship to multiple addresses, you place multiple orders. Sadly, he had never shipped to anyone but himself, so the idea of purchasing something and having it shipped to someone else wasn't a concept he grasped, despite giving examples such as birthdays and holidays as why you might want to purchase something and have it shipped somewhere other than to yourself.

My stakeholder had no concept of anything that happened between him clicking Submit on the webpage and a box showing up at his front door. If he couldn't grasp how that worked with a single supplier shipping directly to a single customer, how could I explain in simple terms the significantly more complicated process he was suggesting? Method two had failed, but I wasn't yet ready to give up.

Step three was to start dazzling him with science and math. After a little digging, I found out that the average order he was describing happened for one customer per month, with a total of about 300 ship to addresses and each address would generate about $20 in sales. Over a year, that would add up to around $72,000 in additional sales. Subtract out costs of fulfilling the orders and you would probably make a profit of $4000 for the year. That doesn't sound too bad, until you consider that the company we worked for counted its sales every year in the billions of dollars.

Still, profit is profit, but we haven't discussed the costs of developing a solution to meet his needs. I explained that a project like he's suggesting, which even Amazon.com doesn't do, would probably take thousands of development hours, at an average of $100/hour for contractors, just to make the project happen. The entire yearly profit for his project would be spent hiring one person for one week. The payback just wasn't worth it. He was better off hiring a temp worker to do the data entry for him than he was trying to start a project to solve the problem.

I got blank looks. No, I'm not kidding. The math simply eluded him.

At this point, I was down to my last option. When all else fails, draw them a picture. Yes, given what I had been through already, I probably should have started with this option. I should have brought crayons. This was my first interaction with this stakeholder and most everyone else in his department would have understood the complexities without me needing to spend half an hour walking them through it.  I had made a bad assumption that he would understand as well as his colleagues, a mistake I was determined to never make with him again.

My pictures were pretty uninspired as by this point I was fairly confident he wasn't going to understand no matter what I said, did or drew. I made a few scratches on my notepad, outlining the same points I had said earlier, just with words in boxes with arrows showing how product flowed. After a few minutes of that, he still had that same blank look staring right back at me.

Post-Game Wrap-up

Frankly, I was beaten. That was the first time in many years I left a discussion without having reached the other person. I felt worn out and defeated. As I walked away, one of his coworkers, who happened to be one of the best stakeholders I have ever had the privilege to work with, pulled me aside and let me in on a little secret... I had done better with the stupid stakeholder than anyone else on their team. It didn't matter what the subject was, the guy never got the concepts people tried to explain to him.

So, at the end of the day, I had not failed, or at least had not failed any worse than anyone else. It was all at once a feeling of relief and of dread. While I knew I was far from alone in not being able to get through to this stakeholder, I also knew that his boss wanted to groom him for a more active role in their department, meaning I would be working with him more and more. Sometimes, for some people, ignorance, even stupidity, really does seem to be bliss.
At the end of the day, we really can not cure stupidity in others, but we can provide them all the necessary information for them to cure their ignorance. If we do that, then we have succeeded in our role, even if the conversation is ultimately unresolved.