Tag Archives: problem solving

skin deep

Leave a reply

my firm asks people during the interview process what the difference is between a consultant and a contractor. the answer most people give: contractors get paid for a specific job—to do the work—while consultants get paid to go beyond the task at hand and do the thinking as well. but the thinking can’t just be about the problem. it has to go beyond being merely skin deep.

clients will ask for technology solutions—an “app” for this, or a database for that—but may not be sure exactly how to accomplish that goal. enter the consultant. in she comes with UML diagrams to follow the flow of information through the technology. she’ll even bring along some choice vocabulary words to show that she knows what she’s talking about. she gets it. but what she doesn’t get? her client.

it’s very easy to act like a consultant and think about ways to build a better mousetrap, but that’s not what true consultants do. true consultants don’t start with the solution, they first start with a detailed analysis of the organization. organizational structure, culture, available resources, processes, politics, and policies all will play a part in the ultimate success or failure of any solution. if you don’t do the work up front to understand what you’re getting into, what you need to change, and whom you can and can’t trust to help, then you’re merely a contractor with a higher price tag.

hunting and pecking never works (efficiently)

Leave a reply

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.

where’s the beef?!

Leave a reply

a lot of effort goes into making different types of work products. still more effort needs to be done to make those work products worthwhile for the end user. and, believe it or not, even more effort goes into making those work products easily repeatable and scalable.

it’s all about infrastructure.

but sometimes — even though you try to approach it from the right angle — people don’t care about the process, what it took to get where you’re at, or what vision you have for where you’re going to get to. sometimes people just want the beef.

and they want more of it.

so what do you do when leadership, the boardroom, the market, asks “where’s the beef?!” two things:

  1. give them the beef
  2. pray like hell it doesn’t come back to bite you in the ass

getting past the “boss battle”

Leave a reply

sometimes work is really difficult. you spend hours upon hours of time dedicated to solving yours and your client’s challenges. but — every now and then — those issues don’t seem to want to go away, no matter how hard you try.

it might be a complicated spreadsheet, or a really demanding client, or a piece of programming that the person before you built without any documentation. every time you feel like you’ve won, it comes back at you — like a final boss battle in a video game — taunting you, keeping you from getting to what you really want to accomplish.

but the thing about boss battles is that there’s always some kind of a trick.

next time that devil of a task comes back at you: survive when you need to, push back when you can, and look for the weak spots. find the critical piece of your spreadsheet (hint: it’s probably obvious), understand your client’s tendencies and tricks (hint: it takes more listening and less talking), and don’t be afraid to hit the restart button on that piece of programming code (hint: starting from scratch isn’t always a waste of time).

find the weakness, then attack. just remember to hit the ‘a’ button.