The consequences of mistakes in business have grown such that most business people I know have trouble seperating the facts in a decision from the spin that will be put on the results later on. They frame every possible decision in terms of how it may look to the press, the stockholders, the SEC, the customers, the VP down the hall, the list goes on and on. When we do this, we can’t think clearly about the issue itself. It’s even worse when you are in a meeting. Every time someone puts a possible outcome on the table, there’s a whole room full of people spinning it in every direction to find how it could come out badly, squashing the idea. Keep doing this, and you will often find that you have no good solution whatsoever. Even if you don’t, the only decision you will arrive at is the one no one can say anything bad about, which usually means no risk. No risk in business equals no innovation.

What happens is that people confuse possible fallout with substance. Put your spin away. Try leading your meeting off with something like this: “First, let’s decide what to do. We can decide how to sell it afterwards. If we don’t, we’ll spend all day selling and never have a product to sell.”

Set the stage right. First, you all need to decide what to do based on the facts and non-political risks involved. After you have done this, you can think about how to present your decision and do any political damage control. You cannot make the right decisions, the tough decisions in life, if you worry about how you’re going to sell them first. Make your decision, then sell it. This is what leadership is all about.

So it goes in IT and project management as well.  Too many times, we want the business to understand that we’re thinking ahead for them, that we’re using the right technologies, making good decisions, and sometimes the business simply does not care.  It’s not that they don’t want us to make good decisions, its that that’s our job, and they don’t need to hear about it.  They need to know when we’ll make their jobs easier.  The key is understanding when you should simplify things for the client, and when you should not.  Here’s a few example cases.

When the Sponsor/client cares about the end result:

Sometimes, people just want their problem solved.  They don’t care that you’re using web services to solve their problem.  They don’t care about the database.  They don’t care about anything except solving the specific business problem that they’ve identified.  What you should report to them is when you’ll be done, when the documentation and training will be available, and when you think they’ll be able to put the solution to use.  If this is what your client wants, then anything else other than updates to these three pieces of information likely just irritates them.  The result is everything to them.  If you talk about all the details you are wasting their time, and to them you are focusing on the process rather than getting them their result.  Stick to the basics.

When you are late on a project:

See the item before.  No matter how much the client may care about the process and the details when you’re on track, once you’re late, then they can get impatient.  Stick to the details of what you’re doing to get things back on track.  Don’t worry about the rest until you’ve solved that problem.

When your problems are not the client’s problems

The client’s problems consist of the fact that they don’t have their solution yet, what to do until it arrives, all the communication and change management around the solution implementation, training their staff, listening to their staff complain about things changing, learning how to use the new solution, providing training, and dozens of other things not related to your project/product.  The difficulties related to RPMs not compiling correctly on the linux installation are of no interest to them- that’s your problem, and that’s why you’re in charge of the project, not them.  In fact, there’s some chance that they don’t even care if you’re using linux, windows, unix, or bands of mongoose that quickly rewrite their screen every time they click on something new.  They just want their solution, and if you can tell them how you’ll make their other problems easier, that’s an added bonus.

Other times, you should share as much information as possible with the client.  Some examples are:

The solution will be delivered in phases

The client isn’t getting everything they want up front.  This complicates their lives.  Share as much as possible about what they can expect and when.

The client will be maintaining the solution after implementation

If the client has to maintain whatever it is you’re delivering, then you can’t give them enough information.  They will want and should have as much say as possible in as many decisions as possible.

All in all, understanding the right amount of information to share with the customer goes a long way towards their happiness.  Share too much, and you’re wasting their time and your own.  Keep your project reports tuned to the audience’s needs.

Let’s consider what this does for the business.

The pros:
*Abbreviations or shortened brand names enable easier communication for those in the know
*Better advertising- people ask “what is?” and you get the chance to sell them

The cons:
*If all employees are not in the know, it impedes communication. For example: everyone probably knows what the intranet is. Everyone probably knows the company has one. Everyone also goes to use it when they need to. It’s part of their jobs. Why does it need a different name in order to communicate about it effectively? Why do you need to sell it? If you need to sell it, then it isn’t doing a good job for the company at what an intranet does.

*Employees have to learn what all these terms mean. Managers have to learn what thousands of them mean. Wouldn’t the company be better off if these people were spending their time learning to do their job better instead?

That second con is a big one. Everyone has a certain amount of bandwidth for receiving, processing and understanding information. They can only truly learn so much per given day. This is what the whole “information overload” crisis is about. If you are creating product names for internal applications that don’t need one for the sake of branding, or you are creating abbrevations for things that don’t need them, are you helping the company by eating up employee bandwidth for learning?

Certainly, corporate culture can help you spread your abbreviations and internal brands. Is this what you want to use your corporate culture for? Wouldn’t your company better profit from the corporate culture spreading values and knowledge instead?

The bottom line is this: Abbreviations are for things you already know. Brands are for selling things for a profit. Use them in the right places, and at the right times.

1) All leaders in the project give the appearance of being of one mind and that the project is in good hands. This inspires confidence from the team

2) It insures that new issues are held on to until they can be discussed thoroughly, before public dissension is created through knee-jerk responses

3) If other staff in the meeting bring up important info about the decisions you have arrived at previously that should influence your decision, treat it as a new issue. Talk to that staff, gather your facts at that meeting. You can now take that info away, discuss it at length, and revise decisions as needed. You can always release your final decision at the next meeting, again with a united front.

4) All disputes are held behind closed doors with the minimum number of participants.

This may seem like you are leaving a lot of people out of decisions, but remember this: if your project is moving at a realistic pace, you are always making decisions with the minimum amount of people involved. A working meeting is six people or less for a reason. This is the absolute maximum number of people who can hold a reasonably short discussion about anything and reach a firm conclusion. Anything more than that is simply information transfer.

You give a long report about what’s going on with the project, what the current status looks like, when you expect to deliver.  After you finish, you open the room up to questions.  No one has any.  At all.  After the meeting, you check with the sponsor- it’s an important sponsor – and he says he understands and is impatient for completion of the project.  After engaging him in conversation about the deliverables you are wrapping up, he asks some odd questions, you probe more… and realize he doesn’t understand what you’re about to deliver to him at all.  He’s working off assumptions.

This is (unfortunately) not an uncommon experience in the workplace.  The part of this situation I want to illustrate is how you learned what was truly going on:  by what the person asked.  Most people believe that they understand what’s going on- otherwise, they will voluntarily ask questions.  They don’t dodge asking questions out of any insistence on not knowing what’s going on.  You must seek what they don’t know- what they do ask questions about- if you want to know what they believe is going on.  Seeking inquiries and digging into details with someone will invariably lead you to their view on things.

It’s an old mantra, but it’s true:  Judge people not by what they say, but by what they ask.  Use this to your advantage.  Never be satisfied with just what they say.  Seek them questions.

This is where things went astray.  You see, at our company, like many others, the “positive spin” bug is rampant.  Problems are referred to as Opportunities.  We don’t want to be negative here.

Where this led next is predictable and sad all at once.  My team assumed that it was a bad thing and started trying to solve the “problem”, not be excited about the opportunity.  At first, I thought that there were some terrible implications of the idea that I had not thought of, and so I started digging in, trying to figure out what the problem was.  All in all, it took us all about ten minutes to arrive at the fact that I trying to communicate something positive to them, not a problem. So what went wrong here?  Business speak.  Our company has fallen into the trap of trying to be positive about things.  That’s a nice concept, but it’s not facing reality.  Businesses has problems and should not fear them or hide them behind other words.  People here commonly say “opportunity” when they mean problem.  I’ve heard them correct each other in meetings to intentionally make the substitution.  What effect has this led to?  Has it made problems truly become opportunities?  No.  Has it made people more optimistic and positive?  No.  What it has done is changed the meaning of the word “opportunity” in our lexicon to mean “problem”, which now leaves everyone in our company with the challenge of how to communicate about real opportunity now, because we can’t use that word anymore. As humorous as this sounds, the problem is real.  When I related this story to a few of my colleagues in management and said “so what do we say when we want to talk about an opportunity now?”, no one had an answer.  We’ve successfully sabotaged our ability to relate important information within our own company.  We probably are not the only ones.  Try relating this anecdote around your own company and see what kind of conversations you end up having about it. This type of “business speak” is an honest, serious problem creeping into the business world.  The one thing that businesses cannot afford to do poorly is communicate.  Understanding jargon is important.  Don’t propogate its use. Anyone else have any similar experiences?  Better yet, anyone know a new word I can use to talk about opportunities?  :)

We fail.

A Status Report is about reporting status and progress.  It is not a report card; it is not a marketing piece.  It is not part of your resume.  It is a document intended to impart exactly where things stand currently, preferably as succinctly and in as few a words as possible.

When writing a status report, keep to the facts.  Include:

• Items completed
• Were the items completed within scope?  On schedule?  Within resource budget?
• Were any risks realized?
• Were any risks identified?
• Were any opportunities discovered or realized?
• Are any new actions required?  By who?  By what time?  What resources will be needed?
• What is your next set of actions planned?

Present a status report like this, and you will not only inform, you will impress.