<sarcasm>I agree that I only wanted to be a bike messenger because of my idol, Puck, on The Real World.</sarcasm> In this article, How The Internet Has Changed The Bike Messenger Business, it indicates that bike messengers are getting killed by the ubiquitousness of email. Perhaps another step forward should be taken. Technology has made it way too easy to send files to others. This allows people to infect their computers, easily send confidential documents to the wrong recipients, and other acts of poor impulse control.
UPDATE: Position filled.
Valdosta State Information Technology is hiring 2 Web Design student assistants.
Web Design student assistants are responsible for creating and maintaining several department web sites, surveys, and other projects. Individuals will be responsible for interacting with representatives to build web pages and perform basic graphic design to complete websites from existing web template designs. Additionally, individuals work with any students, staff, and faculty who require assistance in developing class or work related sites.
- Ability to learn. Candidate must show they can adapt to the rapidly changing technology landscape.
- Some experience with one or more web design or image applications:
- Photo Editing: Adobe Photoshop, GIMP, Paint Shop Pro
- Web Design: FrontPage, Netscape Composer, Dreamweaver
- Effective verbal and written communication skills and the ability to interact professionally with a diverse group of users and support staff.
- Ability to clearly document all projects.
- Desire to learn web scripting languages: Perl, ASP, PHP
Students majoring in computer science, art, public relations, or marketing preferred. Self-taught designers welcome.
Send resume and examples of previous work to me.
Project management materials always discuss things in the problem-solving methodology:
- Define successful criteria, constraints, and release criteria. (Define and understand the problem.)
- Write a plan, define tasks, identify risks, and estimate costs. (Develop a plan.)
- (Try the plan.)
- Record actuals and estimates. (Collect data.)
- Evaluate at milestones. (Evaluate data to determine if plan succeeded.)
This is all pretty good stuff, but I think it leaves out some pretty basic stuff which no one really quite cares is involved in any major software implementation project.
- Adequately staff the project. You are more likely to underestimate the amount of resources needed not overestimate. It would be better to overestimate as those resources can be applied elsewhere.
- Buy-in of the affected. The people who are going to be affected by changing software are the ones who most need to approve the decision to change and provide the information about what it will need to do. A high level manager in Finance probably does not know what the day-to-day needs are in Marketing. Yet all too often, someone without any understanding of what the business processes are makes the decision to go with one product or another because it fits his or her vision.
This is asking for causing a massive amount of complaints, retro-fitting later, or even abandonment of the implemented product. The more objective and detailed view the decision makers have regarding the actual needs of everyone affected, the better match that can be made between prioritized needs and solution. No, not everyone’s problems can be solved. However, making no effort will result in the decision makers shrugging their shoulders in confusion as to why so many people are upset. They have no strong justification for why they picked on solution or another.
- Pilot tesing allows those truly masochistic souls to experience the learning curve and bleeding edge while the normal people are safe. Nothing will create more havok than a roll-out full of bugs and problems no one knows how to resolve.
- Transparency in the decision making process may not eliminate all complaints, but it sucks the wind out of rumor. The more people who know the hows and whys decisions were made, the less finger pointing there will be. When decisions are made in secret meetings and never disclosed to the affected parties, rumor mills have the fuel to burn down a project.
- Some people need a long exposure to something new to get used to the experience. Not everyone can “get it” the first time. The more complicated and difficult a program is to use, the longer people need to work with the program.
- Train, train, train, and train some more. Some people are going to need to attend training (more than once). Some people are going to want to just play with it. Some people are going to refuse to learn the new program. There needs to be available assistance with every aspect of a process in a formal instructor to class setting, one-on-one setting, and self-help materials.
- Every individual understands each nuance differently. The more diverse the affected users, the more diverse the approaches to helping them understand what it does and how it works. Users ultimately want to know, “How does this affects me? I just want to do my job and not get yelled at by my boss or anyone else.” Using Economics jagon in talking to a Graphic Designer may be the least effective approach. Essentially consider every individual as… an individual.
Found at Software is Too Expensive to Build Cheaply…
Dear Mr. Architect:
Rands in Repose has been on my mind lately and re-read. This gem of a web site contains descriptions of techie and management personalities that I recognize.
Okay, several personality description are of me. NADD? My laptop connected to blogs and other web sites, a blaring TV, and desktop playing music, say “Totally!” I am a Completionist, dead to rights. At one time, I was a Free Electron.
I think ultimately I wish that I was still a Free Electron.
Strange projects were put on my plate so that I could bear the brunt of my indomitable will on them to create, develop, alter, or destroy every problem. Somewhere along the line, through promotions and reassignment of duties I no longer to research or development; I administrate. Two to three apprentices seek my guidance; meetings; policy; conferences. This perhaps marks the start of my decline in job satisfaction. In order to stay happy, I first thought I will have to change my job back into research first and development second. Perhaps if I read enough of this stuff as what I should be doing instead of what my boss does not do, then I can get back that job satisfaction?
Playing online Halo PC is not really fun when there are superb (professional quality) players at a game and make sure everyone else knows they can beat you at whim. I played on a server last weekend where one side was a clan. The other side on which I ended up player were obviously not very experienced playing together on a team. We were slaughtered quite badly until I was left alone for a second to calm down because I was all alone.
I snagged a car, drove full force into their Blood Gulch base, killed 2 on the way into the base, grabbed the flag, killed the same 2 on the way back to my base, took an obfuscated route back their sniper on my base did not anticipate, juked just enough to avoid getting killed by him, and scored the point.
I was very elated and still laughing less than a minute later when I was banned.
Kicking the butts of 4 on my own by picking a great, unexpected tactic is “teh win”!!