A relate-able way to look at Information Technology & Business Systems – by Ian Tang

There was a lot of notes taken on day 2 at SXSW.

The sessions were so great:

• Pain Free Design Sign-off: key point – Collaboration, Not Confrontation
• Failure Panel: My take was … own your failure early … build trust
• Trust Agent Panel: Be interesting, build community (It’s awesome seeing them in real life)
• Content Strategy FTW: There is a huge gap in content design … it’s as big as UX design
• Austin Eats 101: #1 – Breakfast Taco & There is something called chicken-fried steak

Learned a lot, I will put up my notes & experience for this when I’m back in Toronto

Also … First social media sighting, I saw Holly Hoffman from Brazen Careerist’s early today, but didn’t talked to her & much younger than I thought … that was kind of cool.

When was the last time you got stuck at work/project, because it’s dependent on others’ part? That’s a bottleneck & it happens to many of us on a daily, if not hourly basis. It even get more frustrating when you find out no work has been done it while you are waiting so you can complete your part.

In IT projects many task rely on each other but I do find that some tasks get dropped until it’s too late & impact the project. To make sure important tasks doesn’t get stuck at a bottleneck, you will need to convince other the importance of the task in their perspective.

Everyone & each role has their own priorities. In order to get someone’s attention, you got to know what’s important to them.

Here are some role specific priorities:

• Project Manager: On-Time
• Developer: Making it work as per spec
• Business/System Analyst: Make sure things doesn’t break
• Database Admin: System performance & data integrity
• IT/Project Coordinator: Clear Communication/minimize confusion

(Of course, these are not their only concerns; but it’s important to their role)

In the last post, I mention why project manager will concern about time > money in most scenarios. To get the project manager’s attention, you can focus on how your bottleneck would impact the project time, rather than just requesting to get it done.

---

Why would we need to do this, isn’t this part of their job?

Nowadays, most of us has a million things to do; as the day goes on, your request can get delay because:
- We/They don’t have enough time
- Other priority overrides
- We/They are juggling too many balls
… or any other reasons
In short, sometimes tasks does get dropped … that’s the reality. That’s why you sometimes need to explain from their point of view, so they will give it priority.

Like requesting for anything, the approach is as important as the ask; It will end up with a difference in results.

Follow-up is a basic work skill not everyone has or will learn. When you work in IT for any mid-large company, you are guarantee to work with several layers between the developer and the business users. At this point, getting a task done get troublesome.

Example: Such as getting a developer access to the server.

The task takes at most 5 minutes, the approval & the process takes a dozen days … or forever. It’s not that we need it this second, but such request taking 2 weeks is unacceptable. Although the task/request might of been dropped somewhere within the business process. To make sure things like this doesn’t happen, you got to follow-up.

---

My Follow-up Tactics:
Sometimes you can’t assume things would just get done, so you got to follow-up.
At first you can give the benefit of the doubt, request gets done.

To make sure requests/tasks gets done, here are my step to follow-up:
1st Follow-up: The request can be left hanging around. This is to make sure the request is initiated.

2nd Follow-up: It’s on someone’s list, but priority is lower. Making sure the request has an estimate completion time, at this point you should give them time to work on the request (amongst other priority)

3rd Follow-up: It on someone’s list, but priority changes & the task get forgotten
At about 50-75% time has gone, double check if the completion is delayed or not.
The purpose of this is to make sure the request is in progress & not dropped due other requests; if it’s dropped, it will them give enough time to complete the task with minimal delay.

4th Follow-up: It needs more time, but no one was notified … this is the point where the project schedule gets delay.At this point, you are annoying the person … so you got to be tactful.

---

The 1st & 2nd follow-up is need for most cases, in order to make sure the task is clarify with a specified end-time.

I usually won’t use the full tactics if it’s someone I had never worked with before; This method is used only if the colleague is unmotivated or they have too many different priorities … That’s why you follow-up with them & let them set an their end-date.

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.

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.