image by jnarin, flickr artist

you’ve seen people hunt and peck when they’re typing; those guys that use only two fingers and have no understanding of how to navigate around a qwerty keyboard. it’s incredibly inefficient, and sometimes pathetic.

sometimes it’s so bad that you actually remove the keyboard from a person’s control and type in whatever needs to be said yourself because it’s just faster than the alternative. well if you wouldn’t put up with someone’s typing that way, why would you put up with hunting and pecking in your business processes?

a lot of our tools now-a-days have become really powerful. you don’t have to wait long — if at all — to see results in your work. your elaborate spreadsheets update in real time, email and instant messaging dominate our daily communications, and hundreds and even thousands of lines of code compile in mere seconds. it’s easy to let this ‘instant-on’ functionality dictate how we approach our problems.

spreadsheet not working? tweak this formula. code not compiling? make a quick edit and try again. end users having problems with the system? run another backend data load.

what we really need to be doing, however, is assessing the problem at the core of whatever it is we’re talking about. let’s go back to basics. what is it that your spreadsheet really needs to be doing? what are all the inputs for your formulas? what’s the progression from one calculation to the other? write these things down. make a flowchart, baby! if you fully understand what you need to get done, you’ll have an easier time getting there.

it won’t give you an instant answer, but chances are you’ll save yourself a lot of aggravation (and multiple rounds of work and rework) in the long run. hunting and pecking is for rookies; it’s time to graduate to a more efficient approach.

image by syamastro, flickr artist

blog.  wiki.  ms excel file.  ms project plan.  ms sharepoint page.  basecamp project.

they’re all tools.  while people may prefer one tool over another, whichever tool it is will not take hold unless the culture there supports it.

i see a lot of proposed changes to current work streams and business processes fail because — even with support from leadership — the user base rejects those changes.  there could be a few reasons why:

• it’s not simple.  if the change is convoluted, adding extra steps to the workflow process or time to complete tasks, people are going to reject it – even if they agree in principle that the proposed new method is “right”
• they don’t understand it.  if you make a change that people don’t understand the reasoning behind, they will have a hard time accepting and implementing it.  #1 sign that you made boo-boos?  hearing employees say, “uh.. why are we doing this again?”
• it doesn’t fit.  if your changes contradict the way you do business, it’s only going to lead to confusion and frustration, and ultimately it will be abandoned.

if you’ve tried making changes to the way your team or organization does work in the past and failed, check the process again.  look at what you’re trying to do, and see what your people think about it.  when new tools don’t take hold, don’t discredit their use.

it’s the culture, stupid!

keep the tools and fix the culture.

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.

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!

when you keep things simple: (1) new employees or additions to your team will be able to more quickly adapt to the work you are doing and how you do it, (2) you reduce the number of steps in a process and therefore reduce failure points, and (3) improves your ability to answer questions regarding past work and to re-use and adapt work products for the future.

in a world of “work/life balance” where someone could be working half days, 3 days a week, have a flex day, or any of the multiple excused absences, you will have people coming and going on your work items constantly. either completely new members of the team, or even just members new to the work. the idea of “plug-and-play” should not be tethered to our electronic devices. we should strive to make all that we do plug-and-play because that is when you truly reap the benefits of efficiency in business. keep your processes and systems simple so that anyone can do the work. well, that is anyone with a little bit of coaching of course

it’s well known that the more moving parts you have in a device, the greater chance of a failure happening with that device. helicopters cost more to maintain than airplanes, not because their parts are so high-tech, but because there are so many parts. there are more flight controls on an average helicopter than on many fighter jets that have a price tag that is many millions of dollars more. the same is true for information systems. i assure you that a process that has 7 steps to complete a goal has a much higher rate of failure than a system with 3 steps in place. the proper solution would be the one that automates the complex areas to make the process simpler for the end-user, therefore reducing possible points of failure.

proper documentation is the single most important thing a person can do to help make their job easier, no matter what area you work in. say something, and you’ll probably forget it. read it, you’ll remember a fair bit of it. but if you write it then read it, you’ll remember a lot more. add that on to your actually doing the work, and you’ll retain more information yourself. so when someone asks you “a question” about “a thing” you don’t even have to refer back to the documentation because you’ve got it all up in your brain! plus, a lot of the work that we do is repetitive. query structures are used again — like finding participants “in payment” or “outstanding credits” — in multiple requests. keeping things simple in your documentation means knowing exactly what areas to look for, and being able to efficiently find the information you’re trying to find. simple documentation helps understand what went on in the past, and makes those portions that can be re-used readily available.

exercises for a simpler you!

• as an exercise to try yourself… the next time you do something in work, pick anything — perhaps the one thing you do the most — and when you’re doing it map out the process. what steps are involved. don’t ask any questions yet, go all the way through to completion. once you’re done, go back at your list of steps and ask these 2 questions of each one: “why is this here?” and “is there a way i can make this better?”

• another exercise to try… the next time you read over a document, take each section and ask the following 3 questions:

1. what is the purpose of this section?
2. does this section meet its intended purpose?
3. how well does this section meet its intended purpose, if at all?

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.

example:

True-ups: There is a known system issue where the new rate change is not used for terminations that occurred in the prior month; therefore, a query is required to identify the retiree, alternate payee and terminated vested population affected by the new rate. Any impacted retiree payments will be recalculated and adjusted to reflect the new rate for January 1, 2008 payments. A similar true-up process will be performed for DB7.

An additional true-up query is required as part of the interim process. The query will be run in DB Module to capture new rate eligible participants who retired 3/27/08 to the DB7 Live Date (5/12/08) to ensure their benefit payment was calculated based on the correct rate. (A query to identify benefit payments that commenced 1/1/08 to 3/26/08 has already been run to validate the correct rate had been used in determining their benefit payment.)

the above would be much better described in a form such as:

true-ups

to accurately capture the information needed, we are completing 2 true-up queries to identify populations affected by the rate change. because of a known system issue with the rate changes not going into effect for participants terminated in the prior month, the two queries being performed are:

1. a query to find: retiree, alternate payee and terminated vested populations affected.
   the participant’s status change must have occurred between 1 January 2008 and 26 March 2008
2. a query to find: retiree, alternate payee and terminated vested populations affected.
   the participant’s status change must have occurred between 27 March 2008 and 12 May 2008

these queries must be performed to adjust and recalculate payments to reflect the new rate.

the first query is run once approval is granted on the project plan for this work item. the second query will not be run until the migration has been made to our new DB7 system.

in this way, the queries are more clearly defined (though the technical requirements for these queries are, admittedly, not here for reasons i think you could probably understand). when defined in this fashion, you can see a definite breakdown of (1) the purpose, (2) what needs to happen, (3) why they need to happen, and (4) when those things need to happen. now, ok, i wrote this in what? 10 minutes here — so the wording, etc. is not exactly how i would present something like this to a client, but the information is all there as it was in the original version only it’s presented in a much more effective way.

well begun is half finished. if you clearly define what you’re doing ahead of time, you will save yourself many headaches due to rework or unnecessarily long e-mail conversations over what work needs to happen.

like i said, people will do what you tell them to if they understand how to or not. it’s up to you how easy or hard you make it, so make it easy and help them understand the work that needs to be done.