Working with IT: 3 Basics/Essentials

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?

Here are 3 essentials to do to cope with this:

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.

NOTE: These are not best practices, these are just case where a freelancer or small business development shop would face to make sure their customer get what they want. Larger companies will have more complex & detail processes. 

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


Up to Spec, but Not What You Want

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

Delete Cookies? … Noooooo

Original image was from

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.

It’s ITs Nature to Fix Things

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.

Think Business First, Technology Second

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.

Intro: Soft Side of IT

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.