At this point, the implementation project is close to being late from the original schedule … everyone now is aiming to for the implementation to go-live.

After going through 1-2 major redesign changes from project storming (previous post), the functionality should be close enough with actual business need that no functionality change would be allowed by the project manager & leads. All of the testing & development is done is to polish the system and getting rid of any bugs without changing functionality.

This point, it is to bring the implementation to a close and any changes will be consider in a separate individual change request or a project for collection of all the change in a service pack to better align the system with the business process.

In case of any functionality doesn’t fully fit the business process, documented processed will be needed to utilize the system with the least impact with the business process.

For the system implementation, just like the forming phase, the project team & the business units starts to take responsibility of the implementation & learn how the system will integrate with the business process. Since everyone start to notice the implementation is becoming a reality & how it halts other new project from starting … they all have a common goal & they are more willing to compromise to push for the system to go into production .

Once the system goes into production, it will slowly reach the performing stage.
(which I will talk about as I go through this process in the next few weeks)

With so many differences between the delivery and the customer expectations, the team eventually figures out, they need a few large change requests to open up requirements & system’s capabilities. Thus, the project team will need to collaborate to derived process & functions that fit both the client’s needs & the system.

To succeed into the implementation, this step is an necessity to refine the system to fit the key business needs. Due to limitation of the interface/API, existing limits/functionalities of other systems or just plain regulations; it does take more effort by the team to define the appropriate changes.

Without carefully monitoring the type of changes being made, the scope can easily get out of control leading to project failure. Hence formal packages of change requests are needed to be signed-off to prevent scope creeps out of hand.

Similarities between Tuckman’s storming stage & the storming phase of system implementation. Tuckman’s team storming stage is define as follows:

“The team addresses issues such as what problems they are really supposed to solve … Team members open up to each other and confront each other’s ideas and perspectives … The storming stage is necessary to the growth of the team. It can be contentious, unpleasant and even painful to members of the team who are averse to conflict.”

If we equate the conflict in a team as changes in a system implementation, we will find many similarities a team development process and the implement projects’s lifecycle.

Just like the progression during this period, the planned expectations & actual results are similar between a growth in teams and projects. Most team growth, this part is underestimated or even missed by management during planning. Although output of the team relies on how well the conflict is managed & utilized. This is the same in system implementation projects, the project plan would complete correctness in the requirement & specification process, which underestimate this correction piece of the implementation piece of the project. Although the output of this piece is critical on how well the system will adapt to business needs & future processes.

By the end of this phase, deliverable/system has bugs & defect left … the overall system functionality would fit the client’s business needs. The project is near the original project deadline due to the unexpected difference & delays, although the progress of the system is similar to end of development phase in SDLC. There is still a long way to go, which is why most IT project doesn’t meet their deadline is because this phase of work is missed in early planning.

Even though the overall system work as clients needs it, there are some major functionality delivered that mismatch what the client had in mind. At this point, the client will realize the original requirement doesn’t fit some of the business scenario, the integration with the other system or what the business needs.

At this point either the project is restarted or requirement/specification redesigns are required for the various sections. In either case, a cycle of SDLC from requirement to validation of delivery is implemented in the form of a few large change request.

When the system just doesn’t fit business needs, some changes are needed. Although this phase of change is usually missed in project planning, because the project manager wouldn’t have account the requirements needs to be redone. Most would expect that period of code fix is needed, but not a redesign.

Since it needs a simplified instance of SDLC for system implementations, this means more work is needed and … pushes the project scope, cost & time to increase quite a bit.

The first stage in the Tuckman’s model is the ‘forming’ phase. The 1st half of the IT project can be classified as the ‘forming’ phase. This is when the client defines the requirements & specification is developed & all items are formally signed off. All the requirements is developed between the vendor & client. Even though the client only have the slightest of clue what the system would look like.

The vendor tries the best to fit the requirement into a specification that fits the vendor’s product, meanwhile the client tries to refine the requirements to make sure it’s more less right. At this stage, there is just too many unknowns to have a clear picture what could be missing in the requirements.

Unbeknownst to both parties, both already have their own kind of miscommunication.

Unfortunately this is unavoidable when dealing with so many unknowns & miscommunication.

As the result, many thing does seem to work right for the client when the code is first delivered. After a few weeks of fine tuning, the client will be able to test out the product … at this point the client will realize the code is missing some major functionality that is missed in the requirement, but critical to business.

After the first round of client testing, the project have passed the mid-point of their timeline; Since under the SDLC-waterfall model, they have arrived at the testing phase, which is one step away from acceptance.

This is where we will end the ‘forming’ phase … next up storming.

This is a general reason why SDLC might seem to work in theory, but never fully work in practice. That doesn’t mean we should not use the SDLC, it just mean that it will take more time to craft the systems using the various steps in the SDLC. Like the agile method, any software development project will require a few iteration of similar process to make sure the product is fine-tune to what the clients need.

From the Robbins-Gioia Survey (2001):
    “51% viewed their ERP implementation as unsuccessful”

With complexity of large IT/ERP systems implementation, various misunderstanding & miscommunications are unavoidable … This disrupts the SDLC model by making each phase to be revisited at many points of the project. This usually generate unaccounted delays to the project, which could cause the result you see in quotes above.

After going through several module implementation, I have seen a pattern. After the 1st code delivery … there is almost a guarantee a massive change request or redesign document. After that is done, the regular defect appears for fixes.

The traditional waterfall model and most major project planning expects people get the solution right in one shot. But of course this never really happens, it takes several tries developing & refining to get to an acceptable solution. That’s why many all IT project ends up different from the original requirement.

From observation, it seems it naturally goes into a few core iteration of code implementation before the solution is ready to go-live.

After studying project management & learning about Tuckman’s stages of team development. I notice that developing an IT solution from start to go-live ready is similar to a team going from forming to working productively. Although each iteration seems to go through a simplified version of SDLC. (Feasibility, Analysis, Design, Implementation, Testing)

In all of these phases, QA & programmers are needed for on going development & validation before the solution is usable for the client.

Unless you a building a off-shelf solution with zero customization, project planning would go off track. Instead of viewing a IT implementation as one long SDLC, plan better by anticipating mismatch in spec & refinement in deliverable.

Next few posts, we will go in depth of the phases.

That’s why I’m not surprise at WorkAwesome’s post about the #1 way of staying motivated. They said the #1 way of staying motivated is Making Progress (at 76%); While Collaboration is second with 53%. It had been a bit frustrating during the summer months when we were not seeing any major progress.

Project seems to be very similar to riding in a ship to cross the sea … it keeps rocking back & forth; When deliverables arrives, it seems like it was 1 step forward & 2 steps back, where a new fix breaks something else. This really demotivate the team, since we get were excited able the deliverable the day before after a long wait.

Here are some ways we tried to maintain team motivation:

Keep Track of the Changes & the Why
Since the project is slowing down, the first you need to do is to determine the cause. It could be due to the vendor process, our internal process, a just person in the team (internal or external member) or just some expected obstacle. No matter what it is, you or the project coordinator need to determine the cause & figure out if it’s under your control or not. If it is then do whatever you need to move it forward.

Follow-up
Always follow-up, to make sure you not waiting for nothing

Write on the Wall
Have some kind list of completion in the project. It will show everyone that progress is being made. This does remind everyone that we are moving forward, which does seem affect other positively.

Focusing on the Low Urgency Important Work
When things seems slow, create or review the list of important tasks. A lot of times some of those item gets lost, so it would be a good time to go back & close some of the issue. It’s unfortunate, but most of the time at work: urgency > importance (unfortunate) … since urgency drive stress, while importance doesn’t always.

Finding Little Victories
After identifying the important task, create some smaller goals to push forward of the important pieces of the project. This will move the project forward & the team can claim these as smaller victories. For example, we preparation work & detailing step for future testing of the implementations; even though it might not seem urgency, it will become important when to time tightens when the deliverable arrives.

As long as we push forward we are making process, that means we will be motivated to push forward … it’s an momentum thing.

After talking to the consultant, we found out they were surprised that we were expecting to include the account key … It was a completely missed.

The miscommunication started from requirement definition due to the complexity of various scenarios. Although when the specification/design document arrived, all of the business & IT staff reviewed it & still missed the scenario … when we reviewed the document, we missed what was not in the design on the particular scenario.

Honestly in general, the code was correct expect for that missed item … so this missed requirement will be seperately managed by a change request.

As much we try to prevent it, miscommunication/misunderstanding/mistakes happen. We need to accept it, fix it & move forward.

1. Acknowledge the Problem (Don’t Blame):

2. Analyze the Impact:

3. Re-Determine the Specification/Conditions/Scenarios:

4. Collaborate on Solution:

5. Document it:

6. Let the Vendor Handle it:

I always had trouble with executing plans & ideas, not until my job required me to coordinate project tasks. It took me a while to find ways to make sure things get done by others & me. These are some of the little things I find helpful to keep organize & stay focus .

1. Write it down/type it up
Sometimes big insight, idea or solution during a meeting/drive/lunch … then I forget about it the next day. To prevent this, please go & find a space to stop & just write it down … that’s I like Evernote on my smartphone & plain white paper

2. 2-minutes rule (5 min for me)
If something take less than 2 min (or 5 min), do it immediately. By freeing your mind from smaller tasks (such as answering an e-mail), you can focus on the task at hand; Otherwise you might waste more time & energy trying to remember do it later.

3. Written To do list
After working for while, you will realize more & more tasks to do. When you have to keep the things you need to do, you would just get a cluttered mind & cause future distractions … So keep a to-do list. Personally I use the medium size posted notes & stick it on the desk; I tried multiple web solution, there is nothing better than paper.

Honestly, programmer are require to consider multiple facets of the code to make sure nothing breaks. This really make us think faster & have thoughts jumping around. Any improvement in organizational skill does help any of us being more productive.

Trust me, this might seem trivial … it really help to clear the mind & maximize our mental efficiency.

At SXSWi, I was afraid of to just ask questions or talk to the author. While in the cozier environment at NXNEi, you get to talk to great authors without intimation of a big conference.

I don’t know about you, ideas & solution come to me everyday, but it seems hard to implement any of those ideas. Which is why i’m learning project management.

One idea i found fascinating was a just simple formula:

Creativity x Organization = Impact

     Zero x 50 = Zero
     50 x Zero = Zero
     20 x 5 = 100

Basically you can do the work or create a lot ideas, but if you can’t implement effectively, you can’t get results. We have seen this a lot … we have seen many great idea in IT startups, but not a lot become a successful startup.

At a day-to-day scale, we can generate projects/solutions (idea) everyday/week/month.
If we can’t tracking or implement the solution, you won’t have results.

You don’t have the biggest ideas person, if you have good level of organizational skill … then you can get larger result.

Just got the Making Ideas Happen audiobook, can’t wait to learn from & share it.

Half the time, I find that other priority is overwritten by other priority, I also found this is true for most of the people I work with. With each e-mail, each meeting & each day passes by … more & more tasks goes on our queue.

Here’s the Problem: A ‘Medium’ priority can easily becomes ‘Low’ after a few new requests.

In IT, we rely on completed task of others to close or even to start other of our own task. In basic development process, Development is need before Testing & that is dependant on Design. To prevent from bottleneck, we need to be organized & follow-up.

Incoming Tasks: Organizing & To Do
Using some Get It Done techniques, here are some task that has been helpful for me

Write It Down:
Rather than remember tasking, I write down a list to handle the tasks to be done with the next 1-2 days

2 Minute Rule:
If there are a task/e-mail that can be done in 2-minutes, then do it immediately. I usually set it 5 minutes instead of 2 to be more effective.

Long Term To Do:
For the tasks to follow-up on & meetings to-do, use a digital to-do list (google task) to track & follow-up

Outgoing Tasks: Follow-up
Nowadays, everyone has dependency task where someone have to finish a task or 2 before you can start on your task.
To make sure your request don’t get lost in priorities, here are 3 simple thing you can do:

1. Don’t Assume
Don’t assume a task would get done … we all are busy on some/most days, we can miss some task if we are not organized.
So don’t assume, just follow-up.

2. Follow-Up
Use a light toned follow-up by asking for an update in a short e-mail (you can also offer to help or any clarification)
… don’t follow-up too much, it would just get annoying & they would help you next time.

3. Be Understanding
Everyone (including you) have missed a request once or twice due to other priorities. So if someone missed it after a day or two, just ask for updates, don’t guilting them for missing it. (Guilting them won’t help, but ruining relationships)

Many company has their own task management systems but don’t just rely on it … create your own system. It took me a lot of trial & error to find something that I can used as some kind of task organization

By end of that day, it felt great to close some of those task that could of been a bottleneck if left not done.

To provide various solutions, I’m sure we have all use the following:

1. e-Mails
2. Lists for Specifications & Requirements
3. Creating ER-Diagrams, Workflow & Use cases
4. Drawing on the whiteboard to work through issues

From experience which one is most effective? which is the least?

One of the best ways to discuss in-depth IT problems are to discuss visually through diagram. That’s why you can find more whiteboards with arrows & shape in IT than in most department.

He gave a great scenario to shows how much better to use visuals rather than words. Scenario: Ways of Giving Directions

1. Using Words
    • Explaining the directiono Turn left & walk for 2 block then turn right …
2. Listing Steps
    • Bullet pointing each direction … Turn left & walk for 2 block … then turn right …
3. Drawing
    • Draw the path on the map
4. Showing it (Using visual, words & motion)
    • Point: Point to the CN Tower & tell they to follow it to reach the convention center

I’m sure most of us have either ask for directions or been asked by someone else.
Which one is the most effective? To me, the latter 2 methods are faster & more effective.

Why?
We all learn to draw before we learn to write e-mails. It’s actually second nature for us to understand visuals than essays. Unfortunately along the ways from kindergarten to work, we grew away from drawing to express our idea & creativity.

When you are stuck at explaining an issue/solution, use the whiteboard/piece of paper & draw. It’s easier than you think … all you need is to be able to draw boxes, stick figures & arrow.

Next time, to get your point across … Draw it out!

Productivity really gets impacted on a bad day, while it feels like you can do anything on a good day.

On the 2 good days, I was able juggle a dozen tasks at once. Then navigate & troubleshoot issues left and right. Then coordinate some fixes, while guiding a intern through the project.

On the bad day, I just couldn’t connect my words & sentences with my thoughts. I was stuck in a 1.5hr status meeting, then I keep on making mistakes on testing for a fix for 30 minutes …

Eventually, it balanced out between the few day to become a better than average week.

This is as true in IT as in anywhere else. On a good day, programmer’s mind was able to ski around the codes; While on the bad ones, they would keep on hitting red lights when trying to fix a bug with a mysterious error message.

If you are having an really unproductive day, don’t stay behind for that day … You are not doing any favors to anyone, because it might take you working in an unproductive hour on something that can be done in 10-15 minutes. In such an scenario, just cut you losses for the day & be better prepare for tomorrow with some … zzz …

That’s my 2 cents

Really? There are soft skills that IT folks are naturally good at?

Root Cause Analysis:
To Debug code is to find the root of the issue and then fix it; To do this, the person need to search the cause with multiple perspectives & some trail & error. This forces IT to always look for the key reasons to solve problem, so the issue stay dead. This constant application of such skills really fine tunes it. That’s why root cause analysis is second nature to IT folks.

Adapting to Change:
When starting to code in the real world, you are working with codes & application made by others. This could be new system integration to your code/system, new functionality added, change in process, fix/patch in bugs or anything amongst these will require to the IT person to adapt their work/system with constant new changes.

Identifying Risks/Potential Issues:
To be good/great at identifying risk, you need some intangible skills at searching for issues. The aim of most coder is to have no bugs in their code; so they at looking for flaws in planning, designing, coding, debugging … supporting the code. When you are debugging all the time, you gain the ability to identify issue anywhere.

Problem Solving Skills:
One thing that attract people to computer science is having opportunity for a solving complex problem. Nothing beats solving problems by coming up with an elegant complete solution.

You are in an constant problem solving mode when you are programming. Also when you find a bug or big issue, you got find a way to fix it. Both of these task really build problem solving skills in handling issue that are big, small or risky.

Recovering from Failure/Errors:
One thing that IT support & coding, is that you learn by trying … trying an application, hardware, gadget, new language, troubleshooting … we have to try out solutions to see it works. When things doesn’t work rather than dwelling on it, they then move on to try the next approach. That’s why silicon valley is famous for embracing failures.

Techies might not be the best communicator most of the time, but they do have valuable soft skill sets behind all of those technical knowledge & IT certificates, especially analytical skills.

Try having a chat with a techie about a problem you have, they will start debugging your problem & give you an solution before you finish your sentence.

So what are others soft skills might IT folks are naturally good at?

This is definitely not the first time I have overheard someone defining specification like that … Heck, I have done similar meeting with a friend of mine to figure out some kind of application. While overhearing, I was thinking … where is the user? Why assume when you can ask?

With specification decided the developer without the user:

• The user might already have a efficient/easy solution. (non-issue for the user)
• End-user will not use it, if your systems is not much more easier to learn & use …
• Solving the wrong problem, it creates more work & new problems for users to fix
• Unsatisfied customer, since the system doesn’t do what they need
• …
Remember the users have to deal with it at the end, so go ask the user/client

As a recovering-developer, I know the seductiveness of look for solution first. If you don’t have a defined list of the problem, you are going cause a different set of problems that the customer has to deal with at the end.

By defining the specification first, you are:

• Making uninformed decisions that causes the end users numerous problems
• Unnecessarily limiting possible functionality & design
• Making bad assumption about the resources & users
• Mistaken with what the real problem the customers are having

The point is: By setting specs first, you are making decisions/requirements for the client/user.

Sorry for going on the soapbox, maybe because I spent a year planning with a friend for a web business that didn’t go anywhere. Also I seen too many failing startup site that seems to design by imagining the user rather than asking user’s feedback.

Honestly, I don’t know the detail & I wish them success.

Like all soft skills, project management can’t just be learnt on an manual. It must be nurtured through experience to gain the skill sets.

The goal of project management is to balance between scope, time & cost.
In layman’s terms, project management is to complete a specified result on the time you set before the money runs out.

To do this, an project manager will need to:

• Communicate effectively
• Organize & coordinate activities
• Track & the progress of the plan & financials
• Negotiate with other about resource
• Analyze & manage risk
• Prioritization
• Lead & manage the team

Most of these would be classified as communication, interpersonal or leadership skills … all of which are classic soft skills.

Essentially a project manager needs a good set of soft skills for accomplish a successful project. That’s why even though the project manager don’t physically work on the project, they play a critical role in projects (Especially in IT).

It a good reminder that project management derived from a set of soft skill and the importance of gainings such skill.

Learning/Adapting:
There is always something new added into the system that you don’t of; you will need to learn & adapt the changes & then code along with it.

Drawing Diagrams:
Drawing how data flows is much easier than saying if … then … except … else …

Separating Problems & Solutions:
Knowing the difference between the issue/problem your internal customer or clients
    - Problems lead to Requirement
    - Solutions lead to Specifications
If the user is providing the how the tables should manipulated … you’ve got a problem. (Pun)

Project Management:
A lot works in IT are project-esque, including adding a functionality, modifying reports(2 day project). IT can show business/management that plans & processes in place.

Task/Time Estimating:
Time estimation shouldn’t just be pure coding/configuring … remember you take time to check e-mail, bugs that comes out, look-up functions/data structure, SQLing, question that you are waiting for confirmation …. All of this is the time you need to complete the task. It might take 2 hours to do the code only if we exclude …, but that’s still time used that delays your work.

Patience:
Patience is need when explaining a few times … others need time to understand, because they are not the expert, you are.

Follow-up:
Tons of work rely on other tasks, you will need to follow-up; because something with higher priority always comes-up … if you just wait, you might be waiting forever.

What are some other non-technical skills needed to be better in IT?

New Mission:
    ”Soft Side of IT: Bettering Soft Skills in Information Technology“

Honestly I’m not changing my content, instead by looking at the what, with what,
by whom, to whom, what next; I now know that what’s the intention for this blog.

I’m really looking forward to this focus & I hope you will too!

Content Strategy is important, Shouldn’t this be obvious for any website? why is it still bad? That’s what Kristina Halvorson spoke about at the Content Strategy FTW session.

Content Strategy, so what?

Who owns the Content?: Marketing? Corporate Communication? IT? Sales? … Who?
- Projects are focusing on wireframes & functionalities … content can be filled in later by a fresh-grad copywriter in a week. There is a huge gap in the industry where Content is an After-Thought … currently, it just web content is a mess.
Problem: Copywriting != Content strategy
- Content is not just about the What … but it’s also about the
What, Why, How, When, Where, Whom, By whom, how often, What next.
- Content-side needs to be involved from the start (at least, much early than now)

Example of Focusing manage content:

HRBlock.com: (Sell, Sell, SELL – Session used former Quicktax.com)
- Just list prices & just pushing to sell, sell, sell? (Obviously done by sales)
- The content would then link to a list of prices & packages … It’s just a digital salesman … that’s not really content that help
Mint.com: (How can we help)
- Shows readers why are they there? Showing rather than listing benefits?
- Audience matters

Developing content strategically:

Audit: Figure out what your corporate site/personal blog/tweets are about & know why people are looking at it
Ask: What, Why, How, For whom, By whom, With what, When, Where, How often & What next
Analyze: Review values & quality of content & how your audience absorb content?
Align: The strategy & process in content creation … create, deliver, govern (repeat…)
Assume Responsibility: As you put content online, you are publisher … so take care of your content

Content is why they are coming to the site, not because you design is cool …

Oh yeah, if you want more details …. she has a book called “Content Strategy for the Web“

This session was for web design, but it definitely apply for any IT solution implementation
Problem: All of us are too defensive on deliverable/solution/process we provide

Solution: Collaboration, Not Confrontation

The session showed us the nightmare scenario about how a IT project goes downhill when the client start to micro-managed your project & ending up with you & your client in fights & ending up no communication situation.

What the client is looking for:

- They wants re-assurance that he is making the right decision
- They feel in control of the process, since they end up living with the decision
- They needs to be confident on the result, allowing him to justify his sponsors & others
- They personally like the deliverable

6 Steps of Collaboration:

Let clients understand their role
- Make sure your clients are defining the problem & not suggesting the solution
(Since that’s what they hired you for)
- If clients are suggesting a solution, ask deeper questions to understand why they want that solution … hence defining the problems

Have a strong methodology/process
- Clients understand your process & the work being done
- Allow the client is reassure the decisions being made are educated & reasonable

Include the client early & often
- Don’t go away after you got the requirement
- Understanding the client & their preference
- Allow the client feel in control of defining the problem & shaping the result of the deliverable

Educate the client about decision being made
- Guide them the decision through educating them
- Give them confidence in you, your process & your deliverable

Ask specific feedback
- Not just ‘What do you think?’, such as ‘How does this meet your business objective’
- Let them understand why the deliverable meets their needs

Avoid say NO!
Not to make the decision for them & minimize conflicts
- Make sure you provide the reasons on parts of the design & let the client say yes
- Make sure you provide the consequences (cost & work) on adding for this & that
… Then, let the client say No

This way clients are more inclusive on decisions, when the deliverable arrives, clients are less likely to flip.

For any one that’s interested, here is the session: boagworld.com/random/pain-free

---

Somethings are just not a decision for you to make … even though you know what’s is the best choice/solution; You need to bring it up with the client or manager & provide a case to allow them to make the right decision. After the session I realize that it was not that I provided a bad solution, but it was because I didn’t get the decision maker involved in the process.

Be collaborative, not confrontational.

Filed under: Manage up ]]> http://softsideofit.wordpress.com/2010/03/29/pain-free-client-relationship-managing-up/feed/ 1 Ian Tang rockrobots http://softsideofit.wordpress.com/2010/03/21/lessons-learned-days-after-sxsw-interactive/ http://softsideofit.wordpress.com/2010/03/21/lessons-learned-days-after-sxsw-interactive/#comments Sun, 21 Mar 2010 18:11:08 +0000 Ian Tang http://softsideofit.wordpress.com/?p=433 ]]>

It’s been a few few day since SXSWi, I’m still buzzing on from the energy & amazing ideas from it. Honestly, I forgot how much can happen one day to the next.
I found myself keep on changing everyday to fully experience SXSW.

Day 1: Lost … Wow
Day 2: Making notes & Just taking it in
Day 3: Participate & meet the person next to me
Day 4: Walk up & meet the panelist
Day 5: Interact on the hallway

By the end, I have decided to commit into the world of social media

---

General Lessons Learned from the trip:

• Try & try again to find your passion, you probably won’t find it in 1-2 shots
• Time is short, if something is not worth it, then leave
• Take action into your own hand
• If you are having second thoughts, kick that thought out & just do it (otherwise you are wasting your own time)
• Put you time in social media & network with similar interest, don’t do it half ass-ish
• Read up on people you want to meet, so there’s something to talk about when you meet them
• Be inclusive

---

Got to Apply the lessons learned, otherwise the trip = wasted.
Here are my To Do:

My blog need to be rework for better content strategy

- I’m going to find a way to apply the Content Strategy session
- There is still a lot of notes, I don’t know how I will publish it … I guess that will depend on what kind of strategy to use.

Participate in social media & reach out:

- Participate in sites with similar interest
- Try podcasting
- Check out the Toronto social media community

---

Every other person either are personality in Social media or working at a startup.
My target is to be a worth participant at SXSWi next year !

Filed under: Lessons Learned, SXSW ]]> http://softsideofit.wordpress.com/2010/03/21/lessons-learned-days-after-sxsw-interactive/feed/ 0 Ian Tang SXSW-leaving http://softsideofit.wordpress.com/2010/03/17/my-sxswi-day-4-5-experience/ http://softsideofit.wordpress.com/2010/03/17/my-sxswi-day-4-5-experience/#comments Thu, 18 Mar 2010 04:26:50 +0000 Ian Tang http://softsideofit.wordpress.com/?p=392 ]]>

Day 4 & 5 was just as great of a learning experience as day 3 or any days before at SXSWi.
Day 4 Sessions:

• Gary Vaynerchuk Presentation: be authentic, own your brand, don’t waist other people’s time, find your passion & work your ass off on it. I know we heard it before, but he is the prove that it works (Above was from session)
• Result Oriented Work-Environment: A new work culture where time is not important, only measure results. No gossip/sludge about people not doing their 9-5, as long as you are getting results + meetings would be optional
• Gen Y Want to Work ‘With’ You, Not ‘For’ You: Most Gen Y is looking for empowerment, not entitlement & every generations has bad lemons, find out if you need to fire them or is it just a bad fit.
• Passionate People – Key to Success: Figure out your passion & find people who have similar interest & share/build your community

Day 5 in the Hallway:

• How to Keep Your Blog from Sucking from Josh Holmes: Be consistent, Act professional online & Don’t bad mouth others
• Alexandra Levit’s Advice: Put yourself out there & work hard at being persistent (for free if you need to), that’s how she got to continue to be a author of multiple book & joining Wall Street Journal.

---

The last 2 days at SXSW interactive was just as great as before, I got to:
- Meet a session speaker who is a fellow person from Toronto, Meghan Warby … found out there is a social media community in Toronto.
- Meet Ryan Paugh from Brazen Careerist and talked about the site’s growth (a gen Y career networking site)
- Talk to Cali Ressler, author of the book Why Work Sucks and How to Fix it, about what happens when new management enters into the ROWE environment
- Experience Gary Vaynerchuk talk live, the whole exhibit hall was filled with energy … pure awesomeness. GaryVee also shaked everyone’s hand when we enter the exhibition hall (Me include), it was very humbling
- Had dinner with people we meet on the street from SXSW (surprisingly mostly canadians)
- Got recognized (that’s a first for me) 2 times from the day 3 previous session as the guy that participated in the design workshop; Once at hotel shuttle to SXSW on Day 4 and the other when boarding the plane on Day 5.
- Have a one-to-one presentation with Microsoft blogger, Josh Holmes, on blogging etiquettes
My last memorable event was a walk & talk with Alexandra Levit, where we talked about how she got started to be a successful author & also recognized me from commenting at her blog.

---

Thank You Austin & SXSW interactive!
The sessions & the experience surpass any expectation I had. My goal is to be a worthy attendee for SXSWi2011.

Thank you to everyone being so friendly at SXSWi2010!

Filed under: Lessons Learned, SXSW ]]> http://softsideofit.wordpress.com/2010/03/17/my-sxswi-day-4-5-experience/feed/ 1 Ian Tang Gray Vaynerchuk at Sxsw 2010