Rob Enderle’s article, Why Linux may never be a true desktop OS raises some interesting points that apply to a lot more than just Linux.  The entire doing what is necessary section highlights a mistake we’re all guilty of making at various times.

When it comes to competition, typically you have the folks who are willing to do what is necessary to win and the folks who aren’t. In my personal experience, I’ve seen again and again scenarios where a team would lay out a plan for what they deemed was needed in order to be successful in a market and then they’d watch as the executive in charge cherry picked the things he/she wanted to do. As a result, the project failed, often disastrously.

This statement paints a common problem in a new light for me.  I’ve seen (and committed) this error many times, but hadn’t ever thought of it in terms of “cherry picking“, and that being the ultimate downfall of a project.  We like to think that life is full of gray areas and nothing is truly ever an all-or-nothing proposition.  Perhaps it’s the ability to see things in black and white that separates the winner from second place?

Have a purpose before you get together. The group should not be trying to develop terms of reference for periodic meeting from a completely blank slate after they’ve met. Groups should have a purpose that is separate and distinct from other groups - you don’t want to be discussing the same issues over and over again in different forums.

Set an agenda, and stick to it. Be as specific as possible on the agenda, it helps define the purpose of this specific meeting. Where possible ask people to submit presentations and reports in advance. Circulate the agenda ahead of the meeting with enough time that participants can come prepared to discuss the specific topics. During the meeting avoid letting discussions drift to issues the group isn’t able to address unless they directly affect the ability of this group to function (and then assign to someone, and move on).

Have the right number of people involved. Involving more people is good for information sharing meetings where status updates, presentations and reports are made to keep others informed. Fewer people should be invited to working meetings at which decisions are to be made. Avoid having $1000 meetings to solve $10 problems.

Although replying to a message is easier than starting a new message, it creates additional work for the receiver since they must sort out your issue from the issues originally being discussed in a thread.

Another form of this problem occurs when someone introduces a new but similar problem in the middle of the thread for working on a problem.

In both cases the best outcome is that the receivers are confused by the two issues, at worst your problem gets completely lost. If you’re introducing a new subject, start a new thread.

Our Megalink service went out today the hospital - all calls into the centre were ringing busy. I called in to the Bell Business Repair Centre and gave them our information, and when they pulled our account up I was told “oh, you are on Megalink, you need to call the Data Repair Centre”. No problem, and I did just that.

The Data Repair Centre asked me for a circuit ID, which seemed a reasonable enough request except that I was in the phone room, and the file was in my office. I asked if they could look up the account by address, phone number, account number, or any other information. No, they could only use the circuit ID.

After a short sprint back to my office to pull the file I return to the phone, and discover that none of the information on the invoice is of any use to the service desk person I’m speaking with. They can only help if I have one particular number (that’s probably written on the wall someplace among the hundreds of other IDs).

I ended up calling the billing office to get my circuit number so I could get the service call logged. The billing office was helpful and had all the information at their fingertips.

This is a prime example of a poorly designed customer interface. A system should be able to lookup a customer based on whatever information the caller might have, and not be limited to requiring a particular piece of information. More so, you regular communication with the customer should include relevant information that they might need in order to obtain service from you. In this case, a circuit ID on the invoice would help. Allowing multiple departments use different identifiers for a customer is a bad idea.