Showing posts with label information technology. Show all posts
Showing posts with label information technology. Show all posts

Monday, December 31, 2012

The year that was 2012

For the year that the world is supposed to end, 2012 will bring a lot of memories. These will stand out to this white hair chronicler.

1. Prudential Plans Inc. closed shop early this year. Just three months before my son would have availed of his educational plan. When the other pre-need plan companies first experienced difficulties paying off claims, Prudential assured the more than 300,000 planholders that the company is stable.Then more than three years ago, they offered to buy back policies at cost. I opted not to sell, thinking that the company could actually rehabilitate itself. Today, I am one of the victims of the pre-need plans fiasco.

2. Habagat brought torrential floods ala Ondoy. But unlike Ondoy, which came and left, Habagat came, left, came back, left again, and threatened to come back again, all in a span of five days. But this time the local governments and the citizens were prepared.

3. In the IT front, nameless hackers, well, hacked into government websites exposing not just the vulnerabilities of websites but the lack of preparation to recover from such incidents. I've posted before that getting hacked is almost inevitable so the next challenge is how soon one can restore one's site.

In the social networking scene, some offices are still afraid of social networks. But there is reason to believe that those who are seemingly afraid will not be so afraid if top management will think that it is their idea and initiative.

4. Sources say frozen shoulder occurs in about 2% of the population. I belong to that 2% now. I realized how painful and inconvenient it could be. It is also said that it occurs to 10-20% of diabetics. I am not diabetic but my mother and grandmas are so it could be that I am pre-diabetic.

5. While Les Miserables will make its way to the big screen next year yet, I am again reminded this year that Javert and his types abound in the workplace. The Javerts are rigid, process-bound, and steadfast in their pursuit of ill-perceived goals. In short, typical bureaucrats.

In a less personal note, aren't we glad Pnoy is our president? The man has shown tremendous political will. He has booted GMA's Chief Justice, quixotically lashed at China, pushed for the sin tax, and signed the RH law. He has deftly maneuvered through fragile alliances in congress to get his pet laws enacted, unmindful of political and religious backlash. He is on his way to becoming the greatest Philippine president by just doing the right thing.

And for 2013, we all must do as Pnoy does.

We must. Just do it.

Tuesday, October 18, 2011

White hair chronicles - Dennis M. Ritchie, RIP

Dennis M. Ritchie passed away just a week after Steve Jobs died. In a week's span, the world lost two giants of the computing world. But Ritchie's death almost came unnoticed. Maybe the world was still mourning for Steve. But most likely, the world hasn't heard of Dennis M. Ritchie. Who is he anyway? To the non-techie, the low-profile Ritchie is the creator (along with Ken Thomson) of Unix and the C programming language (with Brian W. Kernighan). Unix, of course, is the precursor of Linux and MacOS (there's the connection to Steve); while C is the language which is perhaps the most widely used programming language.

I tried to learn C back in the old days, when the world has not yet heard of Linux. I had the C Programming book which was cheap, thin and printed on newsprint unlike today's expensive, thick, glossy computer books. It was simple, but elegant. I also had the similarly printed C-Answer book.

I originally thought that Kernighan was the father of C, since he got top billing in the book (K&R C). Through wikipedia, we later learn that Kernighan actually attributes the design of C entirely to Ritchie.

No doubt Dennis Ritchie was low-profile, as indicated in the billing of their book. Despite his legendary contributions, few knew about him. I read somewhere that if Gates or Jobs are the Buzz Aldrins of IT, then Dennis Ritchie is a Michael Collins. His role was equally important even if he stayed away from the limelight. Now, the young ones will ask who the heck are Michael Collins and Buzz Aldrin? But that's another story.

Saturday, October 1, 2011

The Ten Most Hated Jobs

A recent article at CNBC draws on a survey of hundreds of thousands of employees which determined the 10 most hated jobs. Despite the hard job put in by teachers and nurses, it may be surprising that they didn’t make the list. The jobs in the list are not the low level jobs. The survey found that limited growth opportunities and lack of reward caused more dissatisfaction than the low pay, long hours, and thankless tasks.

The pain then, is psychological. It’s the lack of direction and meaning in what they do that is the problem. People know that they are capable of contributing more but the hierarchical bureaucracy prevents them from doing it.

The Ten Most Hated Jobs:
  1. Director of Information Technology 
  2. Director of Sales and Marketing 
  3. Product Manager 
  4. Senior Web Developer 
  5. Technical Specialist 
  6. Electronics Technician 
  7. Law Clerk 
  8. Technical Support Analyst 
  9. CNC (computer numerical control machines, e.g., lathes) Machinist 
  10. Marketing Manager
I know a friend who though not from an IT department, performs IT tasks for his group. He can claim to perform four (maybe more) of the jobs listed above. He must hate his job, I thought. When asked about it, he said the respect of his peers and co-workers keep him going. The top heavy bureaucracy bears down on the staff and only the deep camaraderie and the common desire to contribute make the employees function. Wow, their director of IT must be hating his/her job more, I assumed. On the contrary, my friend says the managers love their jobs as much as the staff hate them. The clueless supervisors/managers can go on leave full time and it won't make a difference. My friend hopes they give it a try.

Wednesday, September 8, 2010

Easy does IT

My Tacloban trip went smoothly. I was able to install the programs and configure the computers much more quickly than in other trips. That always happen when everyone does their jobs as they're supposed to. Easy does IT.

So I had more time to tour the city. After almost twenty years since my first trip here, I notice that urbanization (as indicated by the numerous fastfood chains and other restaurants), has slowly crept in.

I also surmise that Tacloban folks love their medicine well. There must be more Mercury drugstores here per square kilometer than any other city in the Philippines. Counting the other drugstores as well, there are more drugstores here than elsewhere. I also noticed that there are a few from out-of-town med reps that stay in my hotel.

Tacloban is almost as clean as Palawan and Legazpi. This city has pride just like Cebu. They strictly implement the no jaywalking rule and other traffic rules. Tricycle drivers are also careful not to pick up fare in restricted zones. I tried crossing a not so busy street, and I was reminded by traffic aides to please observe the no-crossing signs. I gladly complied. I wish Metro Manila does the same.

 

Thursday, August 12, 2010

Five tips for improving your team's productivity

his post by John McKee originally appeared on August 9, 2010 at TechRepublic.com.
------------------------------------------------------------------------------------------------
“There is nothing so useless as doing efficiently that which should not be done at all.”
That comment was made by the great management guru, Peter F. Drucker. I shared it with a client a few weeks ago as we discussed his team’s performance and the differences between being efficient and being effective. The last is all about making a genuine difference to outcomes — something particularly important in these times when layoffs abound.

Keeping team members motivated and performing at the top of their game is especially difficult right now. If you’re feeling overwhelmed, or it seems as though the job just keeps getting harder, think how some of your team members are probably feeling. If they’re worried about their own job, paying bills, or the fate of a loved one, it’s unlikely they are doing their best work. That reduced effectiveness could, ironically, create a worse situation for them if it results in fewer jobs or reduced pay.

It’s to the benefit of all concerned that you help them keep working at full steam. Here are a few best practices we’ve seen used successfully by strong leaders across a wide swath of industries and organizations. If you or your team could use some new approaches, I suggest you add some of these to your own management toolbox:

Note: These tips are based on an entry in our IT Leadership blog.

1: Lead by example

You send messages to your team members with every action and statement. If you’re seen to be giving extra, it will inspire and energize others to do the same. The same holds true for the opposite: Showing fear or frustration will only fuel similar results within the team.

2: Focus on communicating objectives rather than defining roles

With fewer human resources, now’s the time to reassess your key deliverables. Which of them make an immediate impact and what can be punted for now? Engage as many of the team as possible on the most important goals; even if that move takes them outside their old job definitions.

3: Maintain a sense of urgency

Keep goals, both individual and team, front and center to ensure focus. Broadcast and talk about results and achievements. Especially if you’ve had to reduce headcount, you want each individual performing at optimal levels. Note I say “optimal” and not “maximum.” The former is good management practice; the latter results in burnout and negativity.

4: Celebrate individual contributions

Sports teams are clear about the fact that certain players make a bigger difference, so they recognize those people appropriately. For high performers, hearing only about the “team’s performance” can actually demotivate them and cause them to slow down to the “norm.”

5: Provide guidelines to reduce uncertainty

Trusting your team to do the right thing is well and good; but in uncertain times, even your best team members can make improper decisions. Help them with frequent reviews of goals, new or successful past approaches, and preferred outcomes during regular team meetings.

Tuesday, December 8, 2009

The recipe for a successful new systems installation

My experience in installing information systems brought me to many places. I've installed systems to rural barangays, mid-level bureaus, and high level administrators. Sometimes not all users readily embrace change. More often it is the younger set that are more willing to absorb new things.

Monday, November 23, 2009

Pinoy online power produces CNN hero of the year

A week after Manny Pacquiao's heroic feat, another Filipino is heralded a hero in the world stage. Efren Peñaflorida, who started a "pushcart classroom" in the Philippines to bring education to poor children as an alternative to gang membership, has been named the 2009 CNN Hero of the Year. He fully deserves the award but he definitely cinched it with a lot of help from his fellow Filipinos' online power.

Thursday, September 24, 2009

White Hair Chronicles IX - COBOL is 50

We mark this month the 50th year of the COBOL language. COBOL (COmmon Business Oriented Language) is one of the oldest programming language. It is also the first computer language I learned. I had to study it back in college. We used punched cards then for our programs that run on big-double-cabinet sized computers at the university.

According to Wikipedia, a specification for COBOL was initially designed by Grace Hopper. Committees were set up to recommend an approach to a common business language. On September 18, 1959, they decided on COBOL for the name.

I also used COBOL in my job as an Operations Research analyst, though I didn't use punch cards anymore, I typed directly on to dumb terminals of a ref-sized mainframe. That mainframe, which had a 90 MB hard disk (yes that's right 90 megabytes) that took half-day to format. There were no defragment tools then. But it also had a BASIC (BASIC itself is 45 years old) version that can do matrix algebra. COBOL is still very much around, though largely unseen.

Those were the days. Life was so much simpler.

"Ah, but I was so much older then, I’m younger than that now" - (My Back Pages-Bob Dylan)

Thursday, August 13, 2009

6 tactics to improve the team's productivity

I came upon an on leadership and management from TechRepublic. In the article, leadership coach John M McKee provides tactics for leaders looking to ensure their team remains focused and positive. Here are excerpts. The article in full can be found here.


“There is nothing so useless as doing efficiently that which should not be done at all.”
- Peter F. Drucker.

Keeping team members motivated and performing at the top of their game is especially difficult right now. It’s to the benefit of all concerned that you help them to keep working at full steam. Here are a few “best practices” we’ve seen used successfully by strong leaders:

1. Lead by example - You send messages to your team members with every action and statement. If you’re seen to be giving extra, it will inspire and energize others to do the same. The same holds true for the opposite: showing fear or frustration will only fuel similar results within the team.

2. Focus on communicating objectives rather than defining roles - With fewer human resources, we have to re-assess the key deliverables. Which of them make an immediate impact, and what can be postponed? Engage as many of the team as possible on the most important goals; even if that move takes them outside their old job definitions.

3. Sense of urgency - Keep goals, both individual and team, front and center to ensure focus. Broadcast and talk about results and achievements. You want each individual performing at optimal levels. Note that it's “optimal” and not “maximum”. The former is good management practice, the latter results in burnout and negativity.

4. Celebrate individual contributions - Sports teams are clear about the fact that certain players make a bigger difference, so they recognize those people appropriately. For high performers, hearing only about the “team’s performance” can actually demotivate and cause them to slow down to the “norm”.

5. Provide guidelines to reduce uncertainty - Trusting your team to do the right thing is well and good; but with uncertainties, team members can make improper decisions. Help them with frequent reviews of goals, new or successful past approaches, and preferred outcomes during regular team meetings.

6. Recognize that your emotions affect outcomes - Keeping one's cool in difficult periods serves to help the team maintain their balance and performance. People are de-motivated by constantly cranky or negative bosses. If you have a disappointment, or a major goal was missed, it’s fine and appropriate to say so; but don’t make it personal.

Being a leader is more than being a manager. It requires empathy, attitude, and skill. The effort is worth it.

Thursday, July 30, 2009

Some things that drive your users crazy

Although I'm not from the IT department, I work in a unit that can be called 'embedded' IT. As such, we provide IT support within the department. Our unit deals with users and their systems more than the actual IT department itself, whose dealings with users are limited to hardware issues. 

Here is one of the lists found at a top IT resource center, summarized for easy reading and infused with some personal experiences.



Users also have certain buttons that should not be pushed. It's a good idea to learn to recognize and avoid as many potential annoyances as possible. Here are 10 of the more common user buttons we should be aware of.

1. Being talked down to - Many users cannot cope with the rapid change in computer technology. Do not make them think that you think they're idiots too lazy to learn.

2. Being talked up to - On the other hand, don't overwhelm them with technical information. Maybe all they really want to know is how long it will be before they can get going again. Anything else, even if important in solving the problem or preventing its recurrence, is secondary. Saying less may be better.

3. Hearing that what they want can't be done - Don't make them think you don't know how to do it or you're just too lazy to do it, qualify your response and give them one or two plausible reasons why what they want might be prohibitively expensive or difficult. This way, they will not think you're ignoring them and gives you time to work out the reasons. The key nos. 1-3 is communications. Try to sort out the kind of user you are dealing with. That will determine the communicating style you need for them.

4. Dealing with people they can't understand - Users are not as experienced in IT as we are. We don't speak the same jargon. If you don't understand the user, or the user does not understand you, do what you can to lessen the problem. If there's someone available who might be a better linguistic match for the user, get them. In my personal experience, I try to nurture or mentor someone from the users' group who is more technically savvy than the rest. That person can be a great help in implementing changes. And more often than not, he is willing to take up the challenge.

5. Having their input ignored - A little patient and nonjudgmental listening can help you tease out (a) what actually happened and (b) what they actually want from the tangle of frustration, misunderstanding, and exaggeration that often greets you.

6. Being treated arbitrarily - Some users can be particularly sensitive to it when they have a computer problem because they already feel like they're being treated arbitrarily—by the computer. Day after day, their computers do incredibly complicated tasks routinely and flawlessly until—for no apparent reason and with little if any warning—they don't. Although, we know there's almost always a reason, and often some warning, users don't see that and may vent their frustration to you. Give reasons for your actions or instructions and explain why the thing you're suggesting will help fix their problem.

7. Being told the problem is "incompatibility"- Blaming incompatibility for the user's problem might be the right answer, but explain more, for example, that it's like the two programs speak different languages. Without translation, it's never going to work. You still mean it's the incompatibility but the user might understand it better.

8. Being asked to change without adequate input, warning, or explanation - IT people are frequently agents of change. And change can be bothersome. Users may be too much in a comfort zone already that changing procedures might be painful for them. The only good reason for them to change is anticipation of future benefits. If you can, try to solicit their input and give them plenty of warning.  Connect the dots for them - show them how the change will benefit them. If you can't, reconsider the change.

9. Being scolded for how they use their computer - Let their boss do the scolding for this.

10. IT people messing with their stuff - Ask permission to open users e-mail or look at their folders or files. Show respect for other people's privacy. Users have that proprietary feeling about "their" computer and "their" stuff (see #9).

As I've said above, communication is the key. Couple that with the honest desire to serve the users, then you will notice that they will come to you more for technical support than the others in your group. That will make you the star and better noticed.