Some Chat Gems

From talking to J:

Me: Think of the computer as more a toy and less of a tool. Toys you explore all the parts and see what they can do. Tools you expect to be reliable.

J: i bet if you were here – you could solve this problem lickedy split
Me: probably. only cause I think like a computer.
Me: maybe that is why women are vexed by me? I need to find someone that can think like a computer and reach me at my level.

Improperly Placed Insects

My mother found a bug in her salad while at a restaurant a couple weeks ago. The manager was horrified, gave us a free desert, and apologized profusely. Mom was not disgusted because this is the first bug she has found in perhaps 200-250 salads she has had from this place. Maybe more…. We go once a week to this place and have done so for maybe 5-6 years. There are some weeks we do not go, but it has to be 40-50 times a year that we go there. That was the first bug.

Mom buys heads of lettuce from a grocery store every week to make salads to eat at home. She reported to the manager that she can understand because she has occasionally found bugs in the heads she buys way down in the center.

Last night, she called me to tell me that she found a inch long moth while chopping up the lettuce for her salad. Apparently she decapitated it in cutting up the lettuce.

Ew?

Hidden Project Pitfalls

Project management materials always discuss things in the problem-solving methodology:

  1. Define successful criteria, constraints, and release criteria. (Define and understand the problem.)
  2. Write a plan, define tasks, identify risks, and estimate costs. (Develop a plan.)
  3. (Try the plan.)
  4. Record actuals and estimates. (Collect data.)
  5. Evaluate at milestones. (Evaluate data to determine if plan succeeded.)

This is all pretty good stuff, but I think it leaves out some pretty basic stuff which no one really quite cares is involved in any major software implementation project.

  1. Adequately staff the project. You are more likely to underestimate the amount of resources needed not overestimate. It would be better to overestimate as those resources can be applied elsewhere.
  2. Buy-in of the affected. The people who are going to be affected by changing software are the ones who most need to approve the decision to change and provide the information about what it will need to do. A high level manager in Finance probably does not know what the day-to-day needs are in Marketing. Yet all too often, someone without any understanding of what the business processes are makes the decision to go with one product or another because it fits his or her vision.

    This is asking for causing a massive amount of complaints, retro-fitting later, or even abandonment of the implemented product. The more objective and detailed view the decision makers have regarding the actual needs of everyone affected, the better match that can be made between prioritized needs and solution. No, not everyone’s problems can be solved. However, making no effort will result in the decision makers shrugging their shoulders in confusion as to why so many people are upset. They have no strong justification for why they picked on solution or another.

  3. Pilot tesing allows those truly masochistic souls to experience the learning curve and bleeding edge while the normal people are safe. Nothing will create more havok than a roll-out full of bugs and problems no one knows how to resolve.
  4. Transparency in the decision making process may not eliminate all complaints, but it sucks the wind out of rumor. The more people who know the hows and whys decisions were made, the less finger pointing there will be. When decisions are made in secret meetings and never disclosed to the affected parties, rumor mills have the fuel to burn down a project.
  5. Some people need a long exposure to something new to get used to the experience. Not everyone can “get it” the first time. The more complicated and difficult a program is to use, the longer people need to work with the program.
  6. Train, train, train, and train some more. Some people are going to need to attend training (more than once). Some people are going to want to just play with it. Some people are going to refuse to learn the new program. There needs to be available assistance with every aspect of a process in a formal instructor to class setting, one-on-one setting, and self-help materials.
  7. Every individual understands each nuance differently. The more diverse the affected users, the more diverse the approaches to helping them understand what it does and how it works. Users ultimately want to know, “How does this affects me? I just want to do my job and not get yelled at by my boss or anyone else.” Using Economics jagon in talking to a Graphic Designer may be the least effective approach. Essentially consider every individual as… an individual.

NADD Free Electron Completionist

Rands in Repose has been on my mind lately and re-read. This gem of a web site contains descriptions of techie and management personalities that I recognize.

Okay, several personality description are of me. NADD? My laptop connected to blogs and other web sites, a blaring TV, and desktop playing music, say “Totally!” I am a Completionist, dead to rights. At one time, I was a Free Electron.

I think ultimately I wish that I was still a Free Electron.

Strange projects were put on my plate so that I could bear the brunt of my indomitable will on them to create, develop, alter, or destroy every problem. Somewhere along the line, through promotions and reassignment of duties I no longer to research or development; I administrate. Two to three apprentices seek my guidance; meetings; policy; conferences. This perhaps marks the start of my decline in job satisfaction. In order to stay happy, I first thought I will have to change my job back into research first and development second. Perhaps if I read enough of this stuff as what I should be doing instead of what my boss does not do, then I can get back that job satisfaction?