Sep 3rd, 2009 | 1 Comment

Top management techniques that most of us would love to see!!!

1: Pro Wrestling Project Management

Much like the world of professional wrestling, the world of project management can be filled with empty threats, posturing, feuds, rivalries, and unusual alliances. But what if the similarities were made an official part of project management? Let’s face it, I think we have all (at least once) dreamed of putting stubborn clients into a headlock until their faces turned purple, or maybe seeing the project manager spend 20 minutes in a steel cage with the operations manager. To really make it an authentic experience, managers would be required to enter conference rooms to music and perform a variety of poses designed to intimidate any other managers.

2: The Rolling Stones Development Model

During their extensive career, The Rolling Stones have produced a song for every occasion — and nearly everyone is familiar with their most popular tunes. So it seems like a perfectly logical jump that instead of “standard communications,” one could run an entire development project using sound clips from various Stones songs. Is the client demanding an impossible timeline? “You Can’t Always get what You Want.” Is their favorite feature impossible to code up in a way that makes them happy? “I Can’t Get No (Satisfaction).” Is the project in deep trouble? “19th Nervous Breakdown.”

#3: Bug Bounties/Penalties

Ever feel like half your day is spent cleaning up someone else’s mistakes? It’s even worse when you find out that the person who is making you feel like your job has been reduced to “clean up on aisle two” is earning as much (or more) money than you are. Imagine for a moment that any problem that could be definitively pinned on a co-worker’s poor quality of work would have a financial penalty attached to it, and that the person who fixed it would get that same amount of money. Would that co-worker’s mistakes be such a headache then? Probably not. I suspect many of us would look forward to them!

#4: Jargon-free Communications

Sometimes, listening to a manager (or worse, a salesperson) feels like you’re reading a Tom Clancy novel, with all of the acronyms, industry-specific slang, and other incomprehensible jargon. It seems like every other sentence requires more time to decipher than it took to say it. I think we can all agree that if management started using real, standard English (or your local language of choice) instead of these marketer-speak filled, incomprehensible messes, the world would be a better place. Unfortunately, we are probably more likely to see a wrestling ring put into the lunchroom (see #1) before that happens.

#5: Geek Games for Performance Reviews

Most of management’s existing techniques for measuring performance simply look at the wrong factors. Ever notice that they count the times you were late to arrive but ignore all the times you were in the office at 11 PM patching servers or writing critical pieces of code? What is really needed is a metric for overall geekiness. A much more effective review would be a pentathlon challenge, testing each employee in the following critical areas:

  • Knowledge of sci-fi and fantasy movies and books
  • Ability to stay in-character over a five-hour role playing session
  • Modern video game skills (FPS death match)
  • Classic video game skills (Super Mario Brothers speed completion)
  • Ability to identify ancient computer hardware and make it work

I think with this kind of review, it would be easy to ensure that raises and promotions went only to those who have what it takes to be top-flight technologists.

#6: Charging for Dumb Questions

Remember when you were in school, and the teacher told you, “The only dumb question is the one you don’t ask?” Well, from what I can tell, that rule goes out the window the moment you become an IT worker. Your day is now filled with giving answers to dumb questions from people who won’t understand the answers anyway. Management loves to bandy about the saying, “Time is money.” Let’s put these two ideas together. If management wants us to spend our time answering questions, that’s fine; we’ll simply charge them for it. Under this new policy, all IT employees will be given a mobile device that allows them to time any useless interactions with management and record the manager’s name. At the end of the month, their department will be charged at “standard consulting fees” (say, $250/hour), which is then put into the IT department’s budget, earmarked for perks like new PCs, raises, and other niceties.

#7: No Degree? No Problem!

Most of those who are in the know in the IT industry realize that college degrees and even many industry certifications don’t directly translate into real world IT experience, let alone the ability to do the job. Try telling that to the HR department, though. Sure, many roles within IT can benefit from formal, academic-style training (people writing compilers and device drivers come to mind), but those positions are fairly uncommon. However, for the typical IT worker, dropping the college degree or certifications from the “mandatory” list would be a wonderful thing. Not likely to happen in our lifetimes, but one can dream.

#8: Siskel & Ebert 360 Reviews

The 360 review is a model in which everyone on the team reviews everyone else. Of course, this promises that the workers get to review management. Wouldn’t it be sweet if this was done in a “thumbs up/thumbs down” format, complete with bickering over things like the manager’s handling of weekly meetings, the quality of his or her memos, and the tone in which the team is addressed? I can picture it now: “Well Bob, to be honest, Sally is really lacking in the leadership department. When she tries to give constructive criticism it sounds like she is really phoning in the performance. A thumbs down from me!”

#9: Relevant Manager Dashboards

At one job I had, I created a number of “manager dashboard” reports. I think we are all familiar with these. They’re supposed to show the manager’s world at a glance. The more it tries to look like the instrument panel of a car or airplane, the less likely it is to show any information that actually relates to the project at hand. To make matters worse, IT projects are pretty difficult to quantify, so you end up with dashboards that don’t really mean much of anything at all.

I propose that we put together some dashboards for our bosses that show what we think the bosses need to know at a glance. We could have a thermometer indicating the team’s frustration level and a tachometer for hours worked per week… with anything over 40 being the “red zone.” We could also put in some idiots lights. But instead of saying “check engine” or “change oil,” they will indicate “team nearing mutiny” and “Jim needs a vacation.”

#10: Better Project and Team Names

Okay, we’re going to violate #4 here. We recognize that management is going to insist on keeping codenames and acronyms for projects and teams. So why not have codenames that make us feel like we are part of something interesting, at the very least? In other words, if the project is about to be named “Project Happy Kitty Cats” it needs to be named something better. Like “Operation Cthulhu” or possibly “Project Thor’s Wrath.” Likewise, instead of boring team names, such as “QA” or “Network Operations,” we should have much more colorful names. I’m not suggesting that the development team be renamed “Cobra” (and the supervisor be known as “Cobra Commander”), but how about renaming Tech Support to “Really Trying to Fix Mistakes”, aka “RTFM?”

Written by Ajay Matharu

September 3rd, 2009 at 8:38 pm

Aug 31st, 2009 | No Comments

#1: Pay attention to details

“I realized that I’d been sending e-mail updates to the client and spelling the name of his company incorrectly for a month.”

It seems comparatively unimportant, but to that client, the error is a sign that you don’t recognize his corporate brand. Oversights like this will cause significant, unnecessary friction.

#2: Don’t mess up the simple stuff

“At my last company, I accidentally overwrote the data files for an online project plan, leaving me to re-create large parts of the plan from scratch. I couldn’t believe it when, later that year, I lost two people’s month-load of work because I was using an unfamiliar, source-safe revision-control package — with the wrong settings.”

The moral is to make sure to be professional even when you’re doing simple stuff like backups.

#3: Stay on top of schedules

“I simply forgot about the longstanding vacation plans of one of my crucial team members when working on the project plan. Fortunately, he managed to reschedule, but I’m still having to buy him beers just to keep the story quiet.”

See the previous advice — the same comment about professionalism applies.

#4: Don’t second-guess the right decision

“Last year, I was asked by two of my most respected developers if they could take a two-week training course. I had to refuse them, I thought, due to our departmental budgetary situation. They left the company, citing my lack of management ability as one of their main reasons.”

Maybe this manager could have handled the situation better, but you have to make decisions and live with the consequences. There’s no point agonizing about “what-ifs” after the event.

#5: Don’t pretend to know what you don’t

“When I was quite new to project management, I was embarrassed to admit my lack of experience in building embedded versions of programs, which I was pretty familiar with. I thought, ‘How hard can it be?’ It turned out that I had to work double-time just to stay in touch with what was happening on the project, and it resulted in a major cost overrun.”

Try not to get overconfident; that can often result in a major egg-on-face scenario.

#6: Don’t be afraid to admit your limitations or ask for help

“I recently found that one of my projects on behalf of a defense contractor was beginning to slide, but I was unsure what to do about it in a very macho culture where any admission of a mistake would have caused me to lose respect.”

The best way to lose respect is to allow your project to mess up. Every day you fail to communicate makes the task harder. If you have this problem, get it out in the open today.

#7: Learn to say “no”

“My CIO once goaded me into taking on another project when I was already really working at capacity. I lost focus, and a more important piece of work was compromised.”

This is such a common error because most everyone needs to learn to say “no” constructively.

#8: Don’t accept blame for another’s mistakes

“A senior manager asked me to put together a feasibility study. After I’d written a detailed plan and discussed the work with several senior developers, I discovered that the manager didn’t have an authorized budget. I was accused of wasting scarce resources.”

Carrying the can for someone else is unfair. Perhaps the manager will see this and cut you some slack the next time you need a favor.

#9: Forgive yourself and do better next time

“When I was asked for an unscheduled progress summary by my CEO, I panicked and left out a word in my e-mail response. The whole thing was misinterpreted and blown out of proportion. Even though the work was completed on time, I’m sure that my professionalism is still in question a year later.”

Don’t let personal history deflect you from making the next job your masterpiece. To err is human — even in project management.

#10: Don’t underestimate people issues

“I had a project that nearly came apart because I underestimated the impact of people issues within the project team. We had quite a few new developers, a few more experienced folks, and several contractors. The existing folks were part of a strong union and had adopted the “work to job description” mantra, whereas the contractors generally did whatever it took to get their deliverables done. This created a lot of tension within the team as the staff members felt the contractors were overstepping their bounds (and really they were, in order to get stuff done), and the contractors felt they were carrying the “slackers” (and really they were, in some areas). A complete mess. However, none of it was obvious until the tension started to come to the surface. By then, the schedule was compromised and had to be reworked a bunch.”

Keep a better handle on the personal issues within the team. Ask more questions, more frequently, to get at them.

#11: Take nothing for granted

“One project I was involved in went down the tubes because I didn’t check that the executive in charge had actually read the technical spec he had signed off. He then instructed a design agency to produce a product that the client couldn’t use.”

Check that your senior management has read and understands the project documentation.

#12: Keep the end user involved

“After three months and many labor hours, we delivered a RAD business tool the end users never used because it didn’t provide the functionality they required. The tool was trashed and we had to start again. The second time around, I kept the user and other stakeholders involved, and we delivered a business analysis tool they could use and be proud of.”

Keep the user involved from beginning to end in a development project. It’s the only way to be certain you will deliver what they want.

Learn from your mistakes to prevent bigger ones

Even though it may seem as though the high-pressure field of IT project management doesn’t tolerate slip-ups, carelessness is fundamentally different than failing while trying to do your best. If you (or that rookie project manager you’re training) can learn from your mistakes, then you might be able to prevent big projects from spiraling out of control.

Written by Ajay Matharu

August 31st, 2009 at 12:04 pm

Page 8 of 8« First45678