business as i see it

never assume that information you have is unwanted.

this isn’t a poker game in the wild west.  you don’t need to guard your hand from the eyes of everyone else.  it only hurts your organization.

just because someone sent you an email, or someone told you in a conversation, or you saw it on the internet — that doesn’t mean that you’re the only one who will find value in that information as well.

in this knowledge based economy the world is growing into, organizations need to manage their information better.   knowledge management seeks to answer the questions of who has the information, who needs it, and how do you bring those people together.  that’s the premise behind enterprise 2.0: collaboration is key.

at other times, the value is simply in that someone knows that you know it.  if you need help in decomposing that sentence, just think of yourself as a project manager or task lead.  quite frankly, they probably don’t care about what information you have — but it’s important to managers to know that you at least have information.  it’s there.  it’s out in the open.  it’s available.

i’m not sure why it is, but — much like the card game at the local saloon in the wild west — there is a lot of information guarding that happens in organizations.  we get split from our main team into smaller project teams with a specific focus.  then, we put our heads down and start working, looking around to share information only when asked for it.  but when we do this, we’re leaving out the knowledge, expertise, experience, and diversity of thought and opinion of a large portion of our own team, and an even larger portion of our entire organization.

the person who may be able to help break open the case might not be on your immediate team; they could be halfway across the nation (or the world).  but you may never know, because you’ve been guarding your information from the eyes of anyone who hasn’t asked for it.

business isn’t a crazy game of poker; put your cards on the table.  why?  because it may just surprise you who has the winning hand.

it’s perhaps the most basic of principles, and i partially hit on some primary ideas in my last posting, but it’s something that i just have to say:

keep it simple, stupid!

i’m from the school of thought that less is more. i believe in the cool serenity that is a simple design. simple means it’s easier; easier to understand (and explain!), easier to do, easier to manage, and — the part not many people think about — easier to maintain!

this is true for many things.

• the way you design your solutions
• the way you develop your systems
• the way you draft your documents
• and more!

Read the rest of this entry »

from the time we’re little, we’re taught 2 lessons:

1. respect your elders
2. because i told you so

that first lesson can more appropriately mean, “respect those people with more authority than you” and the second as “because you’re not in a position to oppose this.” so many people grow up — go through school, life, and everything — and adhere to those rules. they enable people to lead, not because they themselves can’t lead, but because they we’re always told to follow.

so what’s all this have to do with anything? bottom line: if you tell someone to do something, chances are they’ll do it — if they know how to or not.

as a team leader, project manager, small work manager — whatever your title is — you hold power to tell people to do things that they feel they’re not allowed to challenge. even if you say, “let me know if you have any issues” people generally won’t because that’s both, (a) an admission of a lack of competence, and (b) a waste of time because even if they had a problem, they always ask themselves “would my bringing this up really change the situation?”

when we create project documents to outline the scope, goals, etc. it is vitally important that we define exactly what needs to happen before telling someone to do it.

it sounds completely stupid because it’s rather common sense, but you’d be surprised how many people don’t do it. project documents need to be descriptive, easily understood, and all goals — both functional and technical — ought to be clearly marked out. scope documents (or sections about the scope inside an overall project plan document) are not 10th grade word problems. all the requirements for work should be expressly stated.

Read the rest of this entry »