Handling Missed Requirement

As the deliverable arrives, we were able finally to test it out after the long await. Unfortunately, we found out that a side functionality was only using at the address instead of both the account & address.

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.

Here are the process I followed this time to reduce any potential further delays:

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

Blaming is never good, acknowledge the issue & get to work.

If a process was miscommunicated or misunderstood, the issue will trickle down into the work that is being done. It could have been caused by client miscommunication, vendor misunderstandings OR both.

It doesn’t matter anymore, it happened … state what was missed & move forward.

2. Analyze the Impact:

Once we accepted that there is an issue to fix. Figure out the impact of the issue to determine urgency/priority of the issue.

This will also become your justification for the extra time it took for the fix. For my current issue, the impact would of cause a good set of end-customer not receiving a rebate/refund … due to the monetary impact to the bunch of future customers … this would be set as a priority issue.

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

Write down the specifics of the gap/issue & what are the scenarios that needs to be covered. Don’t jump to look for a solution, you are blindsided by what you have seen.

For example, the issue we found was big enough, but after redefining the conditions.
We find we only need to update one of the key condition to include the account #, instead of just the address to solve the issue/gap

4. Collaborate on Solution:

Find an agreeable ground between the client & the vendor. This is to make sure no further misunderstanding occurs for this issue.

Oh, please write it down as well.

5. Document it:

This could be in the form of a change request or an agreement of change. Since change this is different from the original design, you better document it; otherwise when the project manager ask why extra time was used … you would be blame for misused a resource (even if you are right)

At this point, unless you want to hide the issue … just document it or setup a change request. Misunderstanding & Mistakes happen, just make the fix official (if needed, get it approved).

6. Let the Vendor Handle it:

At this point it should let to the vendor work on the deliverable, since the specification written down for the vendor.

Although makes sure you make it clear to the vendor that question & feedback are welcome … this way you will get what you need & confusion is minimized … also it will cut down on time to redevelop it again.

2010
08/16
CATEGORY
Communication
Content Management
Lessons Learned
Write comment

Organizing Our Thoughts

As discuss in the last post about organization & results. No matter how smart or skillful you are, without organizational skill it will really impact your results.

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.

2010
07/11
CATEGORY
Uncategorized
Write comment

Ideas x Organization = Impact

The first NXNE interactive was in Toronto 2 weeks ago. (it’s the canadian cousin of SXSW)
The location was at small & decent, but when compared to SXSWi, it’s like the Ontario soccer finals vs going to the World Cup. Both were great, but in completely different magnitude.

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.

One of the excellent author I was able to meet was Scott Belsky (Making Ideas Happen) to get his insights. Scott’s book & talk was about … well … making ideas happen.

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.

There were tons of detail on how to create impact through some process & skills

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

2010
06/29
CATEGORY
Uncategorized
1 comment

Requests Losing in Priorities

As I dig through my old e-mail & to-do last friday, I stayed behind again to close out some of the pending task that got lost in priorities for the week.

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.

2010
06/09
CATEGORY
Communication
Priorities
Productivity
Write comment

Problem Solving by Drawing

From a previous post on IT’s natural soft skills, we saw how years of coding & debugging changes your process of thinking. Rather than thinking in words, techies would think in groups/item/object & how it moves.

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.

The current top author on visual thinking is Dan Roam. I meet him this year at SXSW at his session: Blah Blah Blah: What to do When Words Don’t Work

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.

The above example parallels with the few listed tasks we do to solve work problems in IT
… which is more effective communicating ideas & solutions?

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!

Through visuals, Dan was also described how health care industry works on the napkin.
If you want to learn about how to communicate visually, you can check out Dan’s book:
The Back of the Napkin.

2010
05/21
CATEGORY
Communication
Soft Skills
Write comment

Good Days, Bad Days and Productivity

This week I personally had 2 good days & a bad day. I noticed the difference in results I was able to deliver between it.

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.

Some bosses expect a constant stream of productivity out of their employees every second; Unless we are robots in a factory, I don’t think that’s realistic. Everyone have good & bad days, but in the end it’s the overall results that matters.

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

2010
05/12
CATEGORY
Productivity
Write comment

Techies have Soft Skills Too

From my previous post on soft skills needed for IT, there was a comment at it.toolbox.com mention that analytical skills was missing. After thinking about it, I realized there are a few soft skills that techies & engineers are naturally good at.

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

If you are working in IT, I can assume you have done a decent amount of coding/debugging. With years of programming/technical admin experience, you will nurture some unique skills:

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.

For any techie who undermines soft skills, check and see if you use any of these skills? Is it critical to your job?

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?

2010
05/03
CATEGORY
Soft Skills
1 comment

Don’t Define Specs During Brainstorming


The table next to me at the cafe sits 2 developers planning to develop a software for a restaurant POS system. They are currently designing specification by think of what store would need & what user would do.

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.

2010
04/27
CATEGORY
Priorities
Write comment

Project Management as a Soft Skill?

From my last post on IT Soft Skills, someone asked:
 Why list project management as part of soft skills?

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.

2010
04/19
CATEGORY
Project Management
Write comment

Soft Skills to Help Information Technology Field

Even though IT is more technical than most departments, we still need to work well with others. There are a lot of soft skills required to be the best person for the job. Here are some that I found useful:

Educating/Guiding:
When meeting with business/users, IT many times need to tell how things work … you are more less educating the user

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.

These few items are just the tip of the iceberg, soft skills is way more than just talking & organizing; a lot of it is being considerate to the people in front of you.

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

2010
04/12
CATEGORY
Lessons Learned
Soft Skills
1 comment