I saw this ad on gizmodo last week & I giggle … And it’s from 1977s … I giggle more. It’s because I was imagining if I was in that era & I heard the term ‘Electronic Mail’, that’s probably would imagine the same thing. (Since most people could only dream of having a computer on their desk)

As a person who use e-mail everyday, I was thinking how could anyone thought was like that … But for a second I did imagine that. When thought more about it, I was looking at this as a expert & a novice. 

When you, the ‘expert‘, are talking about your passion to someone new, the audience sometimes seems clueless. The image above can probably represent is what your audience is imaging about what your ideas/goods/services looks like.

When you think: ‘It’s so simple … why don’t they get it?’; IT might be because they all ready know how it works …. while everyone else have no clue.

In a smaller scale, this happens a lot day to day in many jobs. When an e-mail out goes solving a issue at work…it ends up getting worse and people got confused.

This is happening because the knowledge we take for grants is actually news to others. Next time, when something similar happens, try to mediate & make sure everyone is on the same page before it gets more confusing.

I caught a show called ‘Family Restaurant’ at 5am yesterdays, it was just one of those day that you can’t fall back to sleep.  It was showcasing the son of a chinese family restaurant trying to change handwritten ordering system with an computer solution.

The dad didn’t want this change, while the son was ecstatic while computer arrived.  The son setup up the touchscreen system so that it is initiative (beef dishes was colored with brown, rice was white …).  When he tries to train his dad & mom to use the system; the mom picked it up pretty quickly, but the dad just couldn’t use the system & excused himself by saying be can’t use computers.

It just seems so familiar… It can be the easiest & most intuitive system to use, but if the user is not interest in change, there is nothing the system can have that can persuade user to use or learn it.  

This just reminds me if the an implementation fails, it might not be the technology or design, it just might be user or business preferring the original processes or systems.

Anita Bruzzese tag me on this meme a few days ago. It was fun to play along, until I was thinking too much about it, which was still fun.

Here are the 7 facts left after 20 that I have thought of:

- Started Learning english from the 80s Transformers when I was 8 years old.

- I have been in a on & off Hamburger Hunt since 2001 when My college burger joint got close down. The closest I got to in Toronto is hero burger, but it’s not even close

- I love listening to podcasts (including interviews,speeches & keynotes), I just learn a lot from them. I started just about the time the term podcast got coin. By now, I have listened over 2000 of them.  For example, I learned Texas hold’em from listening to 2 dozen podcasts in 3 days.

- Unless it’s for work, I don’t IM, I always think too much before I response, then 15 minutes has passed by.

- I tend to accidentially drop electronics alot. It’s cause of death of all my dented cellphones. (one of them involved with soup)

- In the last few years, I have got involved in too many functions just in 2 companies.  Here is the list:
Systems analysis, Business analysis, Quality assurance, Business systems analysis, Software development, Procurement, Training, Purchasing, Receiving, Reporting, Project coordination, Customer services.

- I always wanted to travel for work.

In celebration of Barack Obama winning the US Presidency, here is a great talk with Barack Obama

This was the first Obama appearance I saw & it blew me away.
http://www.youtube.com/watch?v=m4yVlPqeZwo

This talk was at Google in 2007, where he talked about:
- Committing Science & Innovation
- Open internet & net neutrality
- Google for government
- Why he was running for 2008 presidency
- Restoring US status in the world
…

Even after going through all the craziness for a year, what he said in this talk is pretty close to his campaign by the end. This really shows how much integrity he has to his word.

Go watch this video, it’s definitely worth knowing what potential future is to come for the internet & other technologies.

Here is a insight talk from David Pogue:
http://www.ted.com/index.php/talks/david_pogue_says_simplicity_sells.html

Why the soft side matters?
David Pogue describes the issues pretty well with talk at the TED conference. It’s funny & a few 2 minute techie show tunes.

In systems I have used, there is usually a plethora of functionalities; but most of the them takes forever to find & several tries to make it work.

David takes this issue on the user side & describes day to day frustrations of everyone.

Adding function vs making it simpler to use

Your solution can be the best in the world, but if your design is not good, no one will use it. Easy is hard, and the hardest part is not deciding what to add, but what to leave out.

So What? … because Simplicity Sells.

My last post mentioned having a ITtoolbox blog & this is the URL:
  http://it.toolbox.com/blogs/soft-side-of-it

My future postings from this site will also be on IT Toolbox.
With this new affiliation, let’s update the purpose of this blog.

Soft side of IT can include:
• Soft skills
• IT uses
• Communication & Interactions
• Blindspots
• Personalities & Traits
• Meetings & Project
• Life
• …
Basically, anything besides the ‘code’.

With the interactions between project managers, administrators, developers, IT analysts & Business users (Finance, Billing, Marketing, Customer Service, Procurement, Inventory, Operations …), there are bound to be some misunderstandings somewhere, somehow … then those IT projects are delayed.

Let’s hope we shine a spotlight on some of those area & drive some discussions.

Procrastination is pretty universal & this also affects developers. I remember when I was programming in university; I would try to solve the entire problems/assignments in my head before I start typing a line of code.

This is a way of planning a solution for programmer. Although this only works until it reaches a certain limit … then it cross the line of procrastination.

I just got the go ahead last week from ITToolBox for the soft side of IT blog. I was excited at first, I started dreaming of what to post on the first post. Now I realized that I have been procrastinated on posting on this for over a week. The first 2 day, it was probably planning, but after that it slowly became procrastination. To stop this, I started to write random points to get pass being stuck.

Planning is fine, because it does save time when you can find some efficient way to doing the work; but when you think way too much, planning becomes procrastination.

When you are unsure about a solution, do you start drafting the document or coding a prototype? I will give this a try as well.

“Can we move the logo a bit higher?”

All developer & web designer probably hear something similar to this before. After days/weeks/months of work to make the system work, rather than commenting on the hard work or the brilliant way to solution a request, the user first comment was on the trivial part.
It drives developers crazy!

This is the equivalent to you prepared & cooked the whole thanksgiving dinner from scratch, and then some at the table says “the turkey is a little bit dry”.

For developers:
Remember the interface is first thing the business user sees, so view it as the warm up to the discussion.

For business analysts & business users:
When you start off with simple changes, just say “Let’s start off with the easy stuff”.

———————-
Here is a related video on product changes called: The Process
http://www.youtube.com/watch?v=jVb8EC1Y2xM

A good meeting must lead to one objective: Actionable

My last post showed how wasteful it can be. On the other hand, I had been & hosted meetings that ended in 20-30 min with an action plan to implement by the decisions made.

There is recent one to solve an ongoing bug in the system. The goal was to close the issue with an permanent IT solution, even though we ended up with an implement-able action plan that requires minimal human/manual work required.

Original Intent
The original intent of meetings is gets to gather to solve a problem. Although many this we forget to state the purpose of the meeting, then it get side tracked, then 1/2 of the people in the meeting wasted their time.

At the Meetings
As the host, I :
1. Give a brief of what people are coming in for (Otherwise you might use up half the time with misunderstandings)
2. List out the issue & figure out best approach that fit all parties/departments (Followed agenda)
3. List out action to take
…
4. Follow-up to close open items

Of course, the follow-up of actionable is to take action.

I don’t know about you, I have been in more than my share of meetings that was a waste of time. My most useless one happened a couple years back; It was a meeting with 30+ developer & a project manager that got side-track for 40 minutes figuring out the 3 colors of the header for the main menu, which involved a discussion 2 1/2 people & decided to talk about it later. How crazy is that?

After that, I decided I will try not to waste other people’s time in meetings by:

1. Only invite the personnels that can contribute & call the people that you might need expertise (Let them know ahead of time)

2. Prepare for the meeting & sending purpose & agenda.

3. Follow the agenda & prevent sidetracking
- Check the time & revise
- Ask about the necessity of the particular discussion

4. Summarize of the meeting
- Quick header for discussed topics
- Decision & Change
- Action log

This can be useful for any detail/solution focused meetings.
Next time I will discuss the good part of meetings.

 
Last post, I brought up the a basic problem with confusions that come up for anyone that has dealt with IT.

So what can we do to make sure IT understand what we want?

Meetings
Yes, I said it … Meetings has some value. IT people think differently than operations & they think differently than finance … Actually they all have different languages with millions of acronyms.

The meetings can visualize the problem or at least picturing the solutions. Just make sure the details, confusions & decisions are writen down, so it can apply to …

Requirements & Specifications
Here is why we split out requirements & specification.

• Requirements is to describe what users needs, wants & limitations.
• Specifications are the list of to dos & the details of the design (It’s similar assignment sheet that we got in college for project, just longer & more details.)

Many times we forget about this & annoyed that we have to write 2 documents … Then we setup to be upset on a result.

Change Request
When application can be seen, tons of suggestions start flowing in. This is where IT would put all the suggestion into one bucket & put into a change request, while ask for more $$$ & approval for the unexpected work.

If anyone has use other ways to handle of the issue.
Please reply through e-mail or comments.

Have you ever order some food & have a image of what it would be … but you got completely different?   For example: If you order a medium-well burger and imagined a juicy burger with steak like texture; When it arrives, you got a hybrid of sloppy joes & a burger from a big fast-food chain.

You essentially kind of got what you ordered, because it was up to spec, although it was not what you were hoping for. This happens quite a bit in IT; When a user request for an addition part/enhancement to a system.

Here is a common scenario for an enhancement process:
1. use request a change
2. user describe the change
3. Business/system analyst change those description into specifications list
4. Develop get list & figure what the user wants
5. Developer code to spec
6. User gets the change & say that’s not what I was looking for
7. Sent back with a ton of changes to the developer
… everyone is pissed off & think the other people are idiots

What might of went wrong?

• User could describe what they were looking for in word
• User described a solution, not the problem
• Business system analyst didn’t know what the user really wanted
• Business analyst didn’t emphesize which specs was important/key
• Developer didn’t know the business need or the reason for the enhancement
• Developer literally follow the specs word by word
• With good intentions, the developer added what they think might help the user

Any of this is a very common reason that a IT project often gets delayed & why outsourcing failed for so many. 

As I’m writing this, I ordered a spaghetti bolognese & I got one that smelled & kind of tased like old rags … irk & yet how timely?  =P

I saw this web surfing Cookie Monster comic strip from a Gizmodo post a while back and I still giggle every time I see it. I kept imagining cookie monster thinking: “What do you mean delete cookies? “

Another classic example is the any key from 20 years ago:
“Press ANY Key” … “Where is the ANY key?“.

So many times, when we communicate what is clear to us, can be confusing to others.

That’s not what I meant
One of clearest realization of this was when a friend of mine was contemplating on a choice. As a guy who was studying computer science, I talked about trees as in decision trees. When she listened, she imagined walking towards 2 trees in a split path & picking which to go towards.

And I clicked, realizing she has no idea what I was talking, but listened as much as she could understand.

Take away
Next time, when you want to explain anything, take a conservative assumption on what you think they know & start from there.

Make sure you are communicating to their understanding, not just yours.

I am sitting in a local Starbucks and the coffee table has been wobbling as I’m typing this. The lure of fixing the stupid table was too strong for me to ignore, then I realized it’s ITs nature to fix things.

Here what I did:
Wobbling table (Problem) 
-> I just slide the table with a folded newspaper (Fixed)
-> The paper is ticking out on the pathway (Problem)
-> Rotate the wobble leg of the table towards the wall (Fixed)
-> The metal leg & the floor is making loud annoying sound when rotating (Problem)
-> May be it might be better use an extra coffee lid (Alternative)
-> Lift up the slightly heavy table with rotate (Fixed)
-> Check if its still wobble? (Test)
-> Nope, good … What am I going to write? (Problem)
…

If you multiple that by a ten & all done in your mind; then you would know how an usual developer think when given a bug.

Developers mind spins 100 mph to find solutions & bugs, that’s why IT are very solution oriented & our nature to fix things.

http://www.itbusiness.ca/it/client/en/Home/News.asp?id=42663

“There is no such thing as an ‘IT project.’ There are only business projects with an IT component“.

This is one of my favorite insight was this article was the first point out of the 20. My interpretation is any IT initiative has a business reason that drives & pays it. If the business reason can’t fund the project, then it’s a No-Go.

Reasons, not excuse
Business reason is driven by value & ROI (retun on investment) from a problem that needs solving, while excuse is solution driven & the explaination is an after-though.

A common example now-a-days installing is Vista & MS Office 2007:
Vista: Vista is the latest version of windows that has improved their interface to be smoother, this is a excuse since the value of improvement can’t be found. There is almost no business reason to switch Vista when XP is perfectly fine to use.

MS Office 2007: Excel always had a limit of 65536 rows & many report/data exceeds that limit. This causes a lot of report generation issues for standards. 2007 has taken out the limit & many are upgrade for this functionality.

People know the difference between a business excuse & a business reason. So next time when a No is giving, make sure it’s business sound & it’s presented as solving a existing pain/problem … It’s the basic requirement.

This blog talks about soft sides of Information Technology.

The Soft Side is:
- Day-to-day technology use
- People side
- Processes in using, designing, customizing & maintaining business systems
- Any technology implosion

The bulk of my career revolves around IT. Even though the deep end of IT is code, many forget the reason for the code is helping business & people.  So I want to share end of the different perspective involved in IT, their challenges & the lessons learned.

Enjoy!