Wikis have arrived on campus. Academic classes are using them to collaborate. Committees are using them to communicate. Tech teams are using them to document.
CIO magazine touts the use of wikis for project and process management, and offers some advice on building and managing your own wiki in an article titled How to Build Your Own Wikipedia.
Do you teach a class, manage a project or chair a committee that could benefit from a wiki?
My high school basketball coach often scolded us for making bad passes. To him, a bad pass was any pass that wasn’t caught. As a point guard, I often shouldered the blamed for making a bad pass when I felt like a teammate should have been held responsible for fumbling the catch.
For a while, I was frustrated by the unfair criticism. But gradually I came to understand and appreciate what coach Opitz was saying. It was my responsibility not just to throw a good pass, but to recognize that my teammate was ready to catch the pass before I threw it. I learned, for instance, that I shouldn’t throw a pass to our gangly center when he was running at break-neck speed on a fast break. Chances were good that he wouldn’t catch the ball no matter how perfectly I delivered it to him. And my team would suffer from my decision.
What I learned about passing from coach Opitz applies to my job as a communicator. Communication—like a basketball pass—is only complete when both delivered and received. It’s my responsibility not just to deliver effective communication, but to make sure the person on the other end gets it.
When misunderstandings occur—when messages get lost in translation—it’s easy to blame the other person. My communication was perfectly clear. It was the other guy who didn’t listen, didn’t pay attention, didn’t care. Seth Godin’s blog post today reminded me of what coach Opitz taught me so many years ago: It’s my responsibility.
Recently in the Missoulian, an article told of a woman in a small Western Montana town who discovered that her Yahoo account had been compromised. While this may seem benign on the surface, what ensued made me sit up and want to shout: “Protect your passwords!”
Her Yahoo account had been hacked by someone in, guess what, Nigeria. This hacker had figured out her password (which was probably very simple) and changed it. He then proceeded to send e-mail to her contacts. The e-mails were pleas for money : “I am in a terrible and tight situation here, I don’t even have money to feed myself for a day, which means I have been starving,” read the e-mails, which asked people to wire her money in Africa. The e-mails were signed it with her usual signature of ”Thanx, Mickie”, so that people thought they were legit.
The e-mails also said that she had forgotten the bag with all her money, credit cards, return airline ticket and passport in a taxi, owed the hotel $1000 and needed $1500 to return home.
Her relatives and friends, fearing for her life and safety, started calling to ask how she could have gotten herself into such a mess. One friend actually wired $100 and said he was sorry he couldn’t send her more but he had recently lost his job.
Some of her contacts also knew that she had been to Africa at least once adding to the legitimacy.
Luckily she was home at the time, but it took her almost 8 hours of contacting authorities, Yahoo and her friends to let them know about the hacking and to change her password.
She was lucky in that only one person sent money and not that much. I think she learned her lesson that she needed to have a secure password and to keep it updated on a regular basis.
So remember, when you make a password easy to remember, it is also easy to hack. Even the smallest chink in the armor can be a big crack through which money can flow, usually away from you.
I often begin my day with a plan. I like plans. I like to know what I need to get done, when it has to be done by, and what will come next after it is done. I like to think of my plan as a piece of music, composed with moments of crescendo, needed rests, and a melodic flow to move along the workday. Unfortunately my plan usually is discarded before 9am. The day shapes itself in ways which do not conform to the plan in my mind.
Yesterday was the perfect example of a derailment of my planned day. I had an operating plan to complete, budget numbers to crunch, and podcasts to produce. No problem I thought! I will tackle each task one at a time, pull all the information together, and before I know it my work will be done. Well not quite… Right outside of my office door sits a fairly new copier/printer. Either by luck or location, I have become responsible for the operation of this unit. I have been dubbed “Mr. Printer Guy“! I must know the ‘ins and outs’, the ‘whys and the how’s’, and the reasoning behind menus and options which are far from logical. While I love a new challenge, and I seek ways to use technology to enhance the lives of my coworkers, students, and faculty; I often question how I went from being a video/IT guy, to the Maytag repairman of the TSS copier/printer.
Yesterday morning the printer decides to jam, not only a paper jam, but a stapler jam too. Between the clicking of the copier’s stapler unit and the disruption of print jobs, my plan took a turn for the worse. Crunched numbers turned into a mass of crinkled paper, my operating plan went from theory into practice as I examined the stapler unit. I was no longer thinking about FY09, I had to figure out what was causing the unit to not staple and print properly.
At the end of the day the stapler unit was free of mangled staples, the print jobs completed, and my operating plan on the boss’ desk. The work was finished, but not in the order I had imagined. We often think of these little tasks has distractions from the “real work” of the day. But to those who rely on printer, the little tasks of my day are just as important as my larger plan for FY09. When it is all said and done, I find satisfaction in being “Mr. Printer Guy” just as much as being an IT manager. The little tasks do make the day, and often make someone’s day as well.
IT people have valuable knowledge and expertise that others want and need.
How do you react when someone asks you for help? Do you sit up and smile, or roll your eyes and grumble? Do you listen patiently and try to solve the problem, or do you ignore, feign ignorance or deflect the problem to someone else?
Granted, most of us face expectations that exceed our available time and resources. People asking us for help are a burden. People expecting us to solve their problems keep us from doing our jobs. At least that’s one way to look at it.
Another way is to consider the opportunity that is presented when someone asks for your help.
It’s an opportunity to:
What other opportunities does a call for help present?
Thanks to Dan Burke in Disability Services, Dan Bowling in Enrollment Services, Nick Shontz and Janet Sedgley in IT for putting on today’s web accessibility workshop. And thanks to all of you who came to learn. There were about 20 participants in the workshop.
The presentation and resource links are available at http://connect.umt.edu/accessibility. This URL will evolve over time to become a more complete web accessibility resource for campus.
Daily Blog Tips provides this nice primer on building tutorials: 11 Essential Tips to Writing the Ultimate Tutorial.
Four experienced campus HTML experts will discuss best practices for coding web pages to meet accessibility requirments on Thursday, January 10 at 9 a.m. The session will be in Social Sciences 127.
Even if you don’t create web pages yourself, the workshop will help you understand UM policy and expectations for creating accessible web content.
