Slashdot Mirror
Learning to Say No in the Workplace?
Ummagumma asks: "I'm trying to find out how those of you who work in the IT service industry, tell customers 'no', when the requests are unreasonable for whatever reason. There is a culture here of 'piling-on' work with regards to IT - and, unfortunately, I've never learned the proper way to tell people 'no'. It may sound simple, but in this economy, where jobs are tough to come by, I don't want to be seen as the impediment to getting things done Any suggestions on telling people that their work request can wait? Especially in a way that won't jeopardize my future here? I've searched the web, but most of the sites that supposedly have information of this type just want you to sign up for their seminars. I'm looking for actual, real-world experiences, and how the people of Slashdot deal with this issue on a day-to-day basis."
"Here is my dilemma: I'm a relatively new employee (~2 months) at a software engineering shop. I am the sole IT person for a 100+ person company, with 50+ remote VPN users, 40+ developers, 30+ servers, firewalls, etc. I do it all, from desktop and application support, to security, to servers. In the past, the IT department has been seriously under-funded, and there is an absolute ton of catch-up work that needs to get done. At this point, I could work 70+ hour work weeks for a year, and still not be caught up, between project work, upgrade, documentation and day-to-day stuff.
I've inquired about more IT budgeting (staff, equipment, etc.), and that just is not going to happen for quite a while."
Tell them "No means no!"
Don't say no. Give estimates. Show your time table. Put the onus on someone else to fit it in, so they are clear on what the tradeoffs are going to be. In my line of work, things got complex enough that maintaining a Microsoft Project document was worth my time. The visual output was well received with management.
Sounds like you're being taken advantage of. Tell them they need to provide the resources if they want the support. If they won't staff the department properly, you need to be vocal about it or else they're just going to blame you when things inevitably start deteriorating.
I'm looking for actual, real-world experiences, and how the people of Slashdot deal with this issue on a day-to-day basis.
:)
See, you are suggesting that people reading slashdot actually have a life, or know how to deal with it
I've told customers in the past that we're not taking on any new clients until our production system has been upgraded to handle increased workloads, and in almost all cases they were willing hold until we were ready. They appreciated the fact that we weren't spreading ourselves too thin, risking long term failure for the sake of padding our short term coffers, so just tell the truth.
Is simply lay out the time. Say, "Yes i will do it, once i have this done as well as this" No need to say no, just show them that for you to say yes will require them to wait for it to get done an unreasonable amount of time. They complain? Then you may get staffed correctly soon enough:-p
The BOFH will show you the way to happiness and funds whenever possible.
My experience has always been to tell customers both internal and external what the constraints are. Meaning you what will slip because of your latest requests and how bad do you want it. If you are not willing to pay an outsider for this service it is probably not valuable enough to interrupt other work. In other words put up or shut up!
Be very polite. Thats the biggest thing. Tell the person that their request just isnt feasible at this point in time. If they are persistant, recomend a temporary solution to thier problem. If they still arent satisfied, get technical with why you cant help them. They will get confused and then leave you alone. If that still doesnt work, they probably have a reputation for being whiny, so just tell them its impossible and leave it at that.
You are selling your work and job.
Make sure you have a list of priorities from your boss.
Follow the list.
When someone asks for a low priority task, let them know that your boss has chosen your priorities and you have three months work before you will get to their task.
Try to help them to get their task done themselves quicker than you doing it.
Of course you will probably not be thanked for this. Peter
If you can get support from management, you can do anything. Unfortunately that means you end up at their mercy if they still want you to do EVERYTHING. Not much to do about it there.
At my last job I would often be asked at 5:20pm to do dumbshit stuff like get a full OS reinstall done on a half dozen machines in a department that needed an upgrade. No amount of explaining that this is not just an extra half hours work would mean a thing to those above me. If it were a one off I'd be fine with it, but from day one my job consisted of staying back insane amounts of time to get these things done, when the people who used the machines had set hours that never varied. No overtime either.
I ended up quitting, and while you might not consider that an option, if it comes down to working yourself dry and being used/abused then it's an option. Get on management until they relent, to get another IT person if you need. If you don't do it now changing later is all the harder. Hell, you're new at this job - do you know if the last person quit because of insane expectations like this?
Just tell them 'no', and explain to them the reason why the request is unreasonable.
I'm a relatively new employee (~2 months) at a software engineering shop. I am the sole IT person for a 100+ person company, with 50+ remote VPN users, 40+ developers, 30+ servers, firewalls, etc. I do it all, from desktop and application support, to security, to servers.
...oh and find out where the closest supply of Jolt is. You're gonna need it.
Only one thing to do...pray!
You're using her as bait, Master!
In almost every type of employment, your job is to make sure your supervisor is satisfied with your work. Their job is to oversee you and make sure you're doing a good job for the company.
Now, if you drop that into the guise of any client-oriented job - be it law, medicine, IT, or even a lowly customer service job - satisfying customers is not your primary and sole responsibility. You have to balance each client's interests against those of the company, other clients, and the priorities of your boss.
If a client is expecting too much, your mission is not to do everything they say - that's a great way to throw your priorities out of order. You're letting them detract from your other responsibilities. If you don't feel right telling them that they're not your only client, then apologize, tell them that you have other duties as well, and refer them to your boss. Let him deal with it. That's why he makes more than you do.
Really - I can't stress this enough. Keep your boss up-to-date on what you're doing, and let him guide your priorities. If anything or anyone is straining those priorities, let him deal with it.
It's really that simple.
- David Stein
Computer over. Virus = very yes.
We avoid this problem with a simple rule: Any work for "the techie" for has to be passed by "the techie's boss." Really, for anything not sopmewhat urgently needed, only management-level personnel should be able to assign longterm tasks.
After all, your manager is supposed to, well, manage. And if not him/her, then a project manager of some sort. Any decent sized corp I've worked for had one of those. If you're getting snowballed with lots of work, then at least those above will be aware of it, and more can be done to manage your time.
It was called Fight Club, I think.
I am a viral sig. Please copy me and help me spread. Thank you.
I will share with you a tidbit of wisdom from those of us in design: keep track of how you're spending your time. Keep a detailed record of what you are spending your time doing and who is asking you to do it. Show this document to your manager and have them prioritize your time so that there are some rules in place. Managers are there to make sure you can do your job, make them work for a change.
I'm reminded why I bill hourly now.
The right way is to propose and alternative.
Scenario 2
PHB says - "I want X done asap".
overworked IT engineer - "No problem, which one of A,B,C,D, .... W would you like me to hold off on while I do X ?"
PHB ... goes away and does not come back until it's more important that A...W
Scenario 2
Customer - "I have this way out idea that will really be cool to do !"
Overworked engineer saya - "Fantastic, you know, we have a procedure for new projects, go fill in the form and we'll prioritize it".
Customer goes away and forgets the crazy idea.
Most of the ways to deal with anyone it to give them your problem. If you do this then you filter most of the nonsense. The golden rule is to never say no but to "Prioritize"! No-one will ever complain that you don't do your job if you are "prioritizing!".
You'll need to speak management speak (and that means Powerpoint and Project) to get your point across.
Make a list of all the existing items. Put them into some form of project timeline (Mr Project, MS Project). Show the dependencies, requirements, funding estimates and man-hour estimates.
Make management assign priorities to tasks. I don't mean broad categories like "high" and "low", but actual numerical order. No equal priorities.
Generate a nice GANTT chart that shows you'll finish sometime around 2015, if and only if no new projects crop up.
You need nice pretty charts and graphs with lots of primary colors and some nice page-transition effects to catch the attention of most management types.
Learning HOW to think is more important than learning WHAT to think.
How about you offer to explain exactly what you have to get done now, what you will have to get done later, and why their work doesn't matter as much. If needed, start going into technical details about everything, true or false, in the hopes that the jargon makes them go away.
(\(\
(=_=) Bani!
(")")
I'm with you there. Having support from management is absolutely necessary. Let your managers and those of the groups you need to deal with know that you're human and only have so much time; You'll hopefully then only need to convince 5-10 people what's needed. Spreading out the filtering of IT work requests to that many extras gives you rest, and puts the onus on deciding what a department needs on the managers, not some shitkicker who wants an upgrade to a machine just cos his intarweb is slow and he's a numbercruncher.
I think what you're looking for are policies. You want something endorsed by whoever is above you that details what you are and aren't supposed to be working on as well as what work gets priority. Maybe from 8-noon you handle new requests and 1-quitting you're on project stuff? Make it known that helpdesk stuff isn't the bulk of your job.
Also -- consider talking to people in each of those groups you outlined earlier. Maybe a couple of developers could be roped in to screening questions from their fellow developers before passing them up to you. It sounds like you're with an IT heavy company - the individual user groups can probably take some responsibility for their own actions.
Implement LDAP or AD and give a user from each group power to manage users within that group. That way you don't get called for password changes etc.
There's lots of things that you could work on to take load off of you. People do need to understand that you can't do everything. If you can get a work priority policy past the boss, at least you can start keeping track of the piles and whe a user says "why isn't X done" you say -- management says it's not a priority so it will be done when P D and Q are finished. ("when will that be" -- "6 months to a year") The users will go to their bosses and ask about the policy -- either the policy will get changed by your management, or they'll stick to it and back you on following it.
'Hey Abbott, hey Abbott! I think the recession is over!'
'Why is that Lou?'
'I just heard an IT guy say he's not available for overtime.'
(Okay, to avoid downmodding, it was originally 'I think the war is over (wwii)' 'why' 'I just heard the woman next door talking back to her maid'. The idea was that if someone gave a maid a bunch of shit, she could go be a Rosy the Riveter. Sorry, google no help. Go find some old time radio mp3s. Or tapes. Or CDs.)
Jesus was all right but his disciples were thick and ordinary. -John Lennon
Instead of telling them "it can't be done," or "it's beyond my abilities," why not simply tell them the truth. "It will cost you (the client) an ADDITIONAL [large amount] thousand dollars above the current budget to implement what you (the client) wish. If you supply the necessary fundage, your additional requests and changes to your initial design documents will be implemented." This way, the more obscene the request, the more the customer will be deterred.
and not just in jobs.
What I mean is my friends will ask me to fix their computer or install a new hard drive but they would never think of asking their lawyer friends to write them a contract. What's up with that?
The first thing you need to realise is that going to your boss and saying "I'm really overworked, I need more staff" will never be successful.
You need to start recording and queueing all work that comes in to you in some sort of helpdesk type system. You can then produce some statistics for how much time you're spending on things, how long people have to wait for their support calls to be closed.
If you can present a case showing that each user suffers say 2 hours of downtime a week you can cost that out and if it comes to less than the cost of more staff you stand a much better chance of convincing your boss that hiring you some help will actually be a cost saving.
If you really want to reduce the workload rahter that increase your staff you could try implementing a re-charging model for IT services. This works well where the company has different contracts or cost centres. You can sell it as being more fair "each contract only pays for the support it needs, not that of the others". Price up your time (including your overhead) and re-charge those costs to each cost centre.
I guarantee people will become more reluctant to call when they know it's going to take $50 off their profit this month for you to walk over to their desk. Plus you can show your boss that if he hires another IT guy he can bill his fellow managers an extre $4000/month!
I've recently become development manager for one of our company's products. As such, it has taken a while to find my feet, both when interacting with sales & consulting internally, and when interacting with customers. I certainly erred on the side of saying yes too often, because I wasn't sure about saying no.
Not anymore. For me, it took mistakes, stress, and all sorts of complaints directed at myself or the company, whether or not it was my responsibility. It is this realisation that sometimes, I need to say no. People do get pissed off at you when you say no. But your job isn't to please people, it's to get a product out the door (well, for me it is, anyway).
So, you learn to say no when from the experience of getting a yes thrown back in your face.
dominionrd.blogspot.com - Restaurants on
This is an incredibly important skill in the IT industry.
The only good way I've ever found to do this is as a team. You have to know that your teammates and team leader will back you up. Your manager is not part of this as the request may come from them but hopefully they'll learn to trust your 'no' statements and start backing you up on these too.
If you are on your own then it's more difficult but generally that requires showing the requesting party why you are saying no. This may include asking them to seek approval from someone else to drop what you are doing, sign off on the risk, etc.
And if you are a contractor or similar then you need to supply your reasons and if they still insist then do what they want after making sure they are fully aware of the consequences (and you have a written communication to them including your objections).
- a designated project manager who is the one point of contact with the customer, and is ultimately responsible for customer management
- a change control process. if the customer asks for a change, we say "okay, we'll analyse that". then we get back to them to communicate the impact. "we can do the change, but we need $x, or y more people, or z more days."
So there's no need to actually say "No". You just have to point them to reality: there's only a certain amount of things a given number of people can do in a given time.Get all your customers together with their wish lists once a month and prioritize what needs to be done. Managers love meetings and they will love hashing this stuff out and fighting each other for your time. The only drawback is you have to sit through it and listen.
'Same speed C but faster'
this is what I can't believe about slashdot. the 50000th beowulf cluster, "but does it run linux", "in soviet russia" joke will get modded +4 or +5 funny, and this gets modded -1 redundant. there is far more redundant stuff on slashdot with far higher scores. yes, i am bitter
Instead of taking the full weight of the decision, why don't you tell your manager that clients want A, but you already have B, C, D in the queue, and ask the manager to prioritize these items for you. Something will have to be delayed, maybe it will be client's current request, or maybe one of the things that were previously in the queue, but you won't be the one deciding what gets delayed.
.02c.
If you are in the position of power, then you should have enough power to make a decision without fear. If you are shaking in your boots, then shift the burden to the client by letting the client prioritize things for you. Obviously this is complicated if you have more than one client. Then you'd have to get them all in a room and have them talk it out.
The rule of thumb for power is that power should match your responsibility. That means, if you are, say, responsible for cleaning the floor, then you must be empowered to move things off the floor, to access cleaning supplies and so on. If you are a manager and it is your job to prioritize items and yet you are not empowered to say "NO", then something is terribly wrong, and perhaps, your project is going down the tubes anyway, and you should look for another job. Alternatively, you can just shut up and sort of roll with the punches and hope that clients will drown in the endless bureaucracy (let the thing that's holding you down hold your clients down as well) and eventually run out of steam. It really depends on the environment you work in.
The only diplomatic way I could find around this was in a prioritization scheme based on adverse impact. For instance, network issues supersede server issues, server issues supersede workstation issues, workstation issues supersede printer jams.
My initial problem was in trusting my clients to be understanding enough to "get it". To my surprise, when I laid it out, they were amazingly receptive, as most of them knew when it was their turn to have a network or server problem, they'd be at the top of the list.
I'm not sure how well that will play out in a corporate environment, but like my customers, your users may be more understanding than you are willing to give them credit for. You are one IT person. Everyone in the company can count to 1, I'm almost sure. They're also keenly aware of how out-of-whack the user/nerd ratio is. Conservative (read:CHEAP) companies will let it get to 70:1, users:nerd. Good companies will go 40:1. Exceptional companies will go 20:1.
I don't envy you your job, you've got to focus on efficiency. Good luck to you, it'll probably be either highly rewarding or we'll all see you on the 6 o'clock news pinning down your coworkers with an assault rifle. Let's hope for the former.
We all get along together like tornadoes and trailer parks.
Sheesh, evil *and* a jerk. -- Jade
I can't do that.
Substitute "Dave" with appropriate moniker, of course.
Doubt it will work, but it may give your boss/client the impression that you're sufficiently weird enough to leave alone.
I had a similar problem very recently - more and more projects heaped on me, all with similar end dates and certainly not enough hours in the day to complete them.
In the end, I created a spreadsheet for my boss, that detailed the different stuff I'm working on, and the importance, time required and other details for each project.
At the end of the day, your boss is payed more, _precisely_ to make these sort of decisions. If you put the onus on them to make the decisions, they can't criticise if they've already had prior warning that you've got too much work on.
tom-george.comBecause geeks rate higher t
Take the nature of your employers into consideration before saying 'no' to them.
You might just end up being found "dead in the woods".
My solution? I've become intimately familiar with the "transfer" button on my phone. Customer is a fsckwit? "Let me let you talk to Don." Don't feel like handling this problem? "I think Mac is probably more familiar with your network than I am." Hell, I haven't done any real work since I started! I love my job!
Moderate drunk! It's more fun that way!
You say you are the sole IT person in a 100 person company where over HALF of the employees are SOFTWARE DEVELOPERS? That is seriously wacked. I don't believe a bit of it. I could believe it if you said data entry or something but GEEZ.
It's scary to think what kind of software you guys are dishing out if the company has 1) software developers too incompetent to fix their own little problems and 2) management too incompetent to realize how to effectively support their own internal infrastructure.
Anyway, It sounds to me like you have done too many favors beyond your normal job duties and now you are almost expected to do them (ie you are a big pushover) It is really remarkable how people stop having so many problems when you stop doing things for them that they should be perfectly capable of doing. Show them how to fix it themselves and the next time it comes up, then even if they can't remember exactly how clear their browser cache or whatever, they might just give it a stab and succeed without immediately calling you in to babysit.
From the words of a relatively experienced consultant:
Don't say no, say yes, and explain how long it will take (3 months) and when you can get started (in 6 months). Of course you must be very polite and empathise with them. Tell them that you understand how annoying their current problem might be.
Write a list of jobs, prioritise them, and then stick to the damn thing like superglue. If anyone has a request, listen to them, write it done, forward it onto your boss. Or alternatively if your boss is useless, stick the item at the bottom of the list. (my boss was so useless I ended up writing a small web-app to do this for me, and then for other people, and then for other people in different projects). But most importantly if you stick to your prioritised tasks you'll actually get some work done instead of constantly task switching, which wastes everybodies time.
Alternatively, if the request is just stupid, don't say "No, that's dumb", say "Maybe we could also (instead) do this, which would result in also having these positives, on top of what you've already said.". Diplomacy is the key!
Another important thing is to not let these users prioritise your tasks. They will all end up "super high" or something equally useless. Just use your own numbering scale from 1-10.
The alternative is to piss off all of your users, say yes to everything, look like you never get anything done, stress yourself into a heart attack by 40, write crappy buggy code and to hate your job. It's your choice.
Welcome to the real world!
Leaving a job in this economy is a fatal error. You won't get unemployment insurance (or food stamps) and you won't find another job. Nobody will care that the expectations were unfair or the working conditions intolerable. Put up with it somehow or become a bum. Your choice. I speak from experience.
Most of the comments in this thread are entirely accurate. Do not say no, but rather, document exactly what tasks you're doing, ask your manager to prioritize, and have customers go through him/her to get to you.
If your manager is unreasonable, you will have to do the prioritization yourself. Most important, though, is that you very clearly document the time estimated and actual hours spent on fulfilling a task.
What I have also found to be extremely useful (consultant, yeah yeah...) is, before starting a task, outline the actual task deliverables. When finished, do a quick writeup on what you did, who it was for, how long it took, etc. Doesn't have to be long, just look reasonably nice
This takes a bit of getting used to and initially may seem like a waste of half an hour per task, but I have yet to speak to anyone in any level of management who didn't appreciate that sort of thing. It gives them concrete proof of what you're doing, it gives you a paper trail to fall back on when people claim you don't have enough to do, and it makes your boss look good, because they have something tangible in their hands to present to their management.
Also, though I know it's not entirely relevant, it helps me to occasionally look at Stokely's Golden Rules of Consulting. It's more geared towards independent contractors, but contains some very wise principles.
Whatever happens, don't get frustrated. I guarantee you, eventually your customers will begin to understand that everyone and their mom wants you to do things for them, and will learn to stand in line. And my experience has been that when something is truly truly earthshatteringly urgent, they become even more appreciative if you can bend the rules a bit. That's how we kept a fairly extensive bar stocked during my last operations role
Cole's Law: Thinly sliced cabbage
One employer I had told me never to say I could not... let them know under what circumstances I could.
I have lived by that ever since. I am a supervisor that is responsible for not only my time but the time of others. I never say no, I just let people know, without whinning, where there project stands... and what possible delays there may be. I have neen known to tell someone that I was planning to shelve their job for a week, and if they want they can give me materials now, or wait until I am ready to start. I usually let people know that I am just trying to be honest with them and not lend them false hope.
In my small firm I keep my schedule posted as well as the tasks of my subordinates (I don't put their exact shedules... can of worms I won't open). Most of the time people can tell where on the totem pole their project falls and will often hold the job themselves seeing that something more important is in front of them. Ultimatly communication is the key, not bitching. If people see things getting done and you working hard and working snart, they will rarely (I won't say never) get upset at how long something is taking.
Say "I'm inserting that into my prioritized queue of tasks to be done in slot #98, right behind fixing the mail server virus filters..." Your problem is you're letting people's new requests take too high a priority.
"Freedom means freedom for everybody" -- Dick Cheney
I once worked with a man-hating lesbo (not a stereotype - she really was) who was the director of sales. That position, at that corporation, held as much power as the general manager.
:)
:)
She was a Cornell grad, and certainly nowhere near stupid, but her personality was best suited for a drill instructor, not a manager.
We had three different business areas under one very, very large roof so one day she calls me in and asks me to "consolidate all 3 databases."
One db was dBase, another was MS-SQL, and the third, so help me, was an ANCIENT db written for PICK!
She wanted this ASAP. So I explained to her that ASAP was 6 months, bare ass minimum. She (and her ilk) have NO IDEA the amount of work that goes into these projects.
She didn't like that answer, but told me to do it anyway. 2 months later I had a semi-functional interface written in Access. About that same time I reported the general manager to the owner for stealing company property. (He told me to authorize the purchase of a laptop for his girlfriend)
After that, things got very ugly, so I simply left before they had a chance to fire me. I was sleeping with a girl in HR at the time and she told me I beat them to the punch by about a week.
Not sure if this tale gives you any insight, I think I just wanted to get it off my chest
Anyway, the bright side is that a month later I found a job that paid 33% more, and which I absolutely *love* and it is what I'm still doing today.
In retrospect, I not only would have told her "no", I would have told her to jam it up her fat ass
Tal
"Study your math, kids. Key to the universe." -The Archangel Gabriel
As far as the customer is concerned there are three elements that concern them. Time, Quality, and Money.
On any product they can't have all three. Example: If they want it quick (time) and the want it cheap (money), it will be lacking in quantity. Or If they want it cheap, and they want qulity, the delivery time will be long.
Saying "No" is not always the answer. But if you explain how their request will affect the one of the three elements (time, money, quality) they will either:
A) Give you more money.
B) Give you more time.
C) Expect less at delivery(cut-corners)
D) Withdraw their request.
And everyone wins.
You don't say 'No' to customers, they pay your bills.
:-)
:
:-)
However, it sounds from your question that you are an employee not a customer. This is a different thing entirely.
What you need to do is manage your boss. This is a skill that needs to be learnt. Some bosses don't need managing, some do, and some are in between.
Here is an approach that may be suitable for your workplace. What you want is an approach that is transparent, shows you are busy, lets other people make decisions about what you work on, and doesn't get you involved in politics.
Every time a work request comes in, or you become aware of a work request, log it. You can log things simply in a spreadsheet. Draw up a simple form for other people to fill our for work requests they give you.
The two things you need to glean from this list are a Priority and a job size.
Put the jobs for the next 4 weeks or so in a grid on a whiteboard. Put the priority against each job, and when you expect to start it.
Your boss gets a more detailed report showing him/her all the jobs you have in the request list and which decade you expect to get to the end
Now, people can look at your whiteboard and see at a glance
- what you are doing now
- if their job is in the next 4 weeks
- if so, when you'll get to it
If they don't like the priority of their job, they can complain to you or your boss and get it bumped up, bumping someone else down.
When an area complains that their job has been bumped down, you tell them who told you to bump it down and let them fight it out.
When every job on your board becomes Priority 1 because people have got your boss to bump up their priority, introduce a new category "super-priority" in a new column, as in "yes I know your job is Priority 1, but my boss said it was only Super-Priority C, which means you get done after super-priority A and B.
I find that by the time you get to Super-Super-Priority people usually realise how dumb they are being, real priorities get allocated, and the cycle starts again
Really, this is basic time scheduling. Everyone has to learn it. When you start a job fresh out of uni or whatever, where you only ever had to work by yourself, there are a lot of skills you have to learn about managing other people.
Even if you are prepared to work 70 hour weeks you are still going to need a schedule and priority list.
HTH,
JC
Management: You described your predicament well to us. Just say the same thing to your management. List your duties with rough estimates, and your manager will understand more resources are require, or tasks will not get done. It will then be your management's responsibility to buffer get more resources and/or buffer the IT requests of the company. Help Desk: Also, try setting-up a help desk to put a system between you and the hordes of requestors. Here is a good, free, web-based system: http://www.liberum.org/
Remember the 80/20 rule while you're slaving away. 80% of your users are serviced by 20% of your work. Since each Slashdotters work environment varies, what specific task you should be working on will vary too. From what background information you've provided, I think it would be a good start to prioritize security because it would affect everyone on the company LAN and those connecting on the VPN. Find/resolve security problems, implement user documentation for smart password maintainence, standardize software used for secure tunnels, etc...
Once that is resolved, you should move on towards the next immediate problem that affects the most users. Maybe it's upgrading/fixing the server(s). You'll probably have to upgrade hardware or install new patches to keep the developers happily developing on a fast machine while the administrative staff can wait for the MS Office update, etc...
Good luck.
Rangers Lead the Way!
You probably already understand one of its key points (or will very soon): it's not sustainable for you or anyone else to work more than about 40 hours, week in, week out, without turning crispy. Work is different from time in front of keyboard or slumped in your chair. You can rack up a lot of hours north of 40/week, but in the long run will have almost nothing to show for them. Additionally, the book will tell you how to say no, as you requested.
One more thing. If you are supporting 100 people, then your days are unquestionably one series of interruptions crashing into each other. There's strong practical advice here about how to minimize interruptions, and work toward having an environment in which you can actually get something done without having to use "hiding" tricks. One of the stories in the book is about a developer who was so bugged by interruptions in his cubicle that he took to working in a toilet in the men's room for an hour at a time. I hope you aren't near that point yet.
Here's the book at Amazon: but you can get at the library, and probably faster.
Myself and my co-worker work for an educational services company. We manage a smallish network of ~150 UNIX machines and are responsible for maintaining them, the network gear, and network security. We also solve every problem that the applications developers can't figure out (which amounts to a lot). On top of that, we're continually striving to improve our network infrastructure. We're often dragged into meetings to plan and develop infrastructure upgrade projects.
Management's priorities are all over the map, and priorities can change every hour. This makes life incredibly difficult for us.
Our solution was to grab a big-ass whiteboard (you know, 4 feet tall, and 16-feet wide) and write down all of our tasks. No real detail... just enough to indicate what the task is. We mark which task we're currently working on. Whenever management comes by to give us more work, we take them to the whiteboard, write down the task(s), and insist they prioritize what's on there.
The amount of incoming work was enough to keep four people busy. We spent 2 hours daily discussing priorities with management. All tasks were important enough to keep on the board, and our Ops Manager maintained the priority list.
Then one day, the whiteboard filled up.
Management got the hint when we insisted on a second whiteboard. Instead of providing us with a second whiteboard, there's now whitespace available on the first board.
Just keep a list of tasks at hand, and make sure your manager knows what you've got on your plate. If you're given a new task, insist that he looks over your current list and assigns some priority.
I had an insane boss once, each day as business started he'd roam around the office for his morning ritual, he made each employee look him straight in the eyes and say "No" three times in a firm but neutral voice. If he didn't like how you did it, he'd make you do it again. Yep, he was totally nuts.
I've heard that a great (yet simple) way to manage requests is to give the customer write access to a spreadsheet that stores a prioritized list of work requests. You always work on whatever is at the top of the list.
This allows customers / bosses to assign new tasks as they see fit, but helps to make clear the fact that prioritization is necessary, and that a new request may be neglected or may push out other necessary tasks.
- Once management has decided make a big poster with the priority list and post it on a wall near you. Identifing that the priority came from Management.
- For every new request write it on the bottom of the list
- When a task is finished mark it off on the poster. (to show your progress)
- Now everyone will see your list and see the priority of their request.
The key is to get management to decide and display it for all to see.It sounds like you have a lot of people who think you have nothing to do and they are really important.
-- Andy
What is your Job title, and who do you report to? Are you the sole IT person, or the sole technical person? These items are important; because when you are going to try and change something you have to know who you are and to whom you are talking.
IT exists to serve the business. For an IT project to be approved, it has to be shown how it will benefit the business. If you are the manager and the tech, then I would audit the business, and create projects for cleaning it up. Show how cleaning it up would benefit the business, and how not cleaning it up hurts the business. Talk to the staff and find out about downtime before you were there; how often it occurred and who was affected. Quantify this with hard numbers (i.e. actual outages, and how they affected the business from a monetary perspective.) In that environment you can be sure that there have been issues. It should be relatively easy to come up with a project that involves either more staff, or outside contractors that will show a positive return on investment.
You are still fresh there and all the state of IT there cannot be blamed on you. If you take a proactive (sorry for the buzzword) role now you can make a difference and make the place somewhere worth working. You just have to make sure you are speaking the same language as the people you are presenting these things to.
If you are not the IT manager, then I would talk to my IT manager about doing the above. The IT manager is ultimately responsible for your department and would likely look favourably on this. Worst-case scenario, you get turned down, but get some valuable experience. Best case, you get to play a primary role in making your IT department function properly.
Good Luck!
CB
When they come to you with requests, always get their username!
Then you can provide them with the full user experience they so richly deserve.
MUH, HA, HA, HA!
Show me on the doll where his noodly appendage touched you.
Seriously, though, it's tough. In the corporate IT world your best bet is to hide behind some clearly define procedures or policies (yes, those things are useful). In the situations I'm familiar with (as a user putting in requests to systems support), what happens is this: I submit a request for enhancement or a trouble report; support opens a ticket and gives me a ticket number which I can use to track progress; after a couple of hours or days; I get an email telling me that the ticket is closed with a certain status; often the status is `rejected' followed by an explanation, like what I asked for is difficult to do and would only benefit a small group of people. That's usually fair enough for me, since I can often work around the issue, and if my workarounds create problems for other users, then support will be more willing to help out. I've never felt anything resembling outrage or anger if a request got rejected, at most I felt irritated (more work for me). But the key is that my requests have been in the queue, have gone through the system in a standard fashion, have been reviewed by one or more people (if I requested escalation etc.), and typically get rejected because there's a policy on what requests are urgent, standard, minor, or ignorable. Similarly, I hope that the support people don't get outraged or angry at yet another request to install an interpreter for an obscure scripting language when they are busy with more urgent things, because it's just another ticket in the queue that will be dealt with according to standard procedures.
In sum: documented business processes. And communication.
if it can't be done, or the strech is just to much work to be feasable, tell them. If they tell you they want it done any way, let them know about "don't say I didn't warn you". then leave. IE F*CK 'EM! They pay you to run the network and if they don't want to listen to the one person that knows something, thats not your proplem.
yes, i will get a million geeks on my neck for saying this, and heck, before i became a corporate whore i was against this. But now i've seen the usefullness of this.
make up a system which includes procedures for change managment and incident managment. Everytime someone asks for something, ask them wether it is an incident or a change (or decide yourself), if its an incident (in which case you have break/fix situation), you know its a valid/urgent request and you can work on it. If its a change, you put it into a change managment system, together with the rest of the work you already have. Make this work visible (give out ticket numbers and such), so next time they want an update, you can refer them to your change managment webpage and they can see which project(s) are still to be fixed before theirs is started. This way, you dont come off as a sluggish worker AND you keep your customer happy.
ITSM, love it or hate it, but it sure is usefull.
immediately thought of Milton in Office Space upon seeing the title of this topic?
"... I kept my Swingline stapler because it didn't bind up as much, and I kept the staples for the Swingline stapler and its not okay because if they take my stapler then I'll set the building on fire. "
Seriously, this is basically all there is to it. Use whatever calendaring software you have to break down what you're doing on a daily or weekly basis, if not hourly. Even a recurring to-do list is good. The idea is to show that your time is not an infinite resource.
If you can sit down and say something like "I can make time for this project this month, but it will require moving back those security updates for a week, and the database migration for a few days. Also, we're running low on shared drive space and there's no budget to augment the servers, so to add this in, I'll have to put everyone on a harsher quota for the next few days (and delete your mp3s off your shared drive)," and show how your time is mapped, they will see why they can't reasonably expect you to take on more work.
You'll also be able to get more actual work done, because the mere act of organizing your regular activities will let you see ways to cluster them for more efficiency ("oh, while this disk image is copying, I can hit that next item on the list, replace the video cable on that secretary's computer so she'll stop holding my mail hostage"), etc.
Also, at the end of six months or a year, maybe you can use the resulting log as evidence that you need an assistant or a pay raise or both. It's also good for remembering what to put on your resume, if your small company decides to lay you off and replace you with two kids who just graduated and also happen to be related to the VPs...
Get off my launchpad!
Give lists of projects with estimated times.
Tell them they can pick projects (in order of priority) up to your available working days.
"I can spend next month installing Minesweeper on your laptop, but I'll send a time summary up the line saying I did that instead of patching for Blaster"
Xix.
"Everything is adjustable, provided you have the right tools"
Thank god! I thought this was another gender sensitivity discussion, whew!
It's not a 100% solution, and it raises some chicken-and-egg challenges, but the only way I've been able to say "no" (and have them listen instead of overruling me) is to establish a really good rep with them first. Sometimes this does mean doing the impossible and sucking it up and plowing through some impossible workloads at first, simply to establish that you're a force to be reckoned with, you know your shit, and you're not afriad of "putting in the hours". The last one is perhaps the most important; if you say "no, it can't be done" often their first thought is, "he just doesn't want to do the work" so you have to establish yourself well enough to push that thought out of their heads.
Of course, this course of action can also have the opposite effect if done wrong... if you meekly take on superhuman workloads without a whimper you might establish yourself as a doormat and then you're never gonna be able to say "no". So you need to stay very assertive and communicative (not combatitive!) during the whole process- you're willing to bust ass for the company, but you're not a doormat either.
Also, don't just say "no"... have REASONS for what you've said, as well as alternate solutions. If you offer constructive solutions they will respect that and even if they disagree they'll see you're trying to work WITH them and not AGAINST them.
Of course, if your bosses are just especially cruel, exploitative, and/or clueless they might never have the sense to hear the word "no". But... they're just out to make money. They're willing to listen to almost anything that will make them money. You have to convince them that the occaisional "no" is necessary, because the alternative is often a burned and angry client whose unrealistic deadlines you agreed to meet, but failed. Burned and angry clients don't stick around very long, unless it's to file lawsuits.
OtakuBooty.com: Smart, funny, sexy nerds.
All in title. Dont miss to consider day to day work too in your estimation. If they think things are too slow, they need to get another IT to help you.
-- Laurent Pointal
As was mentioned previously, if you believe there is an alternative which at least as good but can be completed in a shorter time, bring this up with your superior. Hopefully, either he or she will clarify the task further indicating why your proposed alternative is not an adequate substitute, or your alternative will be accepted.
If no such alternative exists (as it often does not), you still should not say "No".
First, you must appear organized, that you have an up to date and concise listing of tasks, timeframes, and priorities, and that you are making and documenting satisfactory progress on each of these tasks.
You can run this by your superior, update him or her of your status, as well as recall priorities given to existing tasks.
You do not need to say, "No." Instead you can say, "Should we make this a priority over task x?" Put the broad directional decisions in your superior's court if that is appropriate in your relationship/position.
Give a timeframe for its completion based upon the priority assigned to it. If your superior later requests that you change priorities of tasks, document this.
Give the impression that you are making progress on what is on the mind of your superior, and if asked, be prepared on the spot to report the priority and status of all tasks currently in progress.
.sig Realistic fines for copyright in
Get up at 2 AM. Work like hell. Get home at 9 PM. Don't forget to f**k your wife. Also, feed the dog.
That's 19 hours a day. Do so every day.
That's 133 hours per week.
Now, do this enable you to catch up or not?
The simple solution to problems of this nature is to step out of the developer role and put the situation in business terms:
"I'm afraid that is going to run you way over budget in programming hours"
This comment is fully compliant with RFC 527.
seriously.
If you're that underfunded and understaffed, a large part of your job description is "scapegoat".
In the meantime, become the most disciplined and effective employee they've ever seen, do a bang-up job on everything you have time and funding for, keep written records of what you did when etc, all that good stuff. No personal email, no slashdot, no cnn.com with your coffee first thing in the morning. Use your coffee time to plan everything you do, write it down, write down how you will do it, write down how you're doing it, write down how you did it, write down how you'd do it next time.
Constantly negotiate priorities. Find a way to track tasks and priorities: a Palm organizer can be a godsend.
Work hard and cover your ass, so the hammer doesn't fall before you find another job.
But start looking now, because that hammer will eventually knock you on your ass.
There is a common misconception that IT folk can do a simple 1 hour task just because someone sends an email saying, "Please do this simple 1 hour task (and put it at the top of your stack)"
When 50 people send an IT person an email about a simple 1 hour task that needs to be done today or tomorrow, you've got a problem.
None of these tasks may be unreasonable. None of the users may be overbearing or unreasonable (although, it's more common that users consider their task to be the only priority)
Here's what to do:
- always assume that it will take 5 times as long to do something as you think. For a 1-2 hour job, tell your customer it will take a day. That way, when you get 3 emergencies and you don't get to that one hour job until 4pm, your user won't be upset. If you happen to finish this by noon, your user will be *THRILLED* that you're ahead of schedule. If you get 5 or 10 clear emergencies that push a task back, immediately notify said user that there is an emergency and you will not be able to get to their job until tommorw.
- Use your own judgement to prioritize requests to start with - everyone knows what is inherently important and what can wait
- When your stack overflows, and your "day's work" turns into a week's work, list the things that need to get done and what you think their priority is and talk with your manager to ensure that they agree. Discuss what tasks will have to be dropped or slipped and by how much with your manager first and then with your users. In the event of a tie or question or indecisive manager, talk with users and let them know that the only way you can do "x" is if they get user2 to agree to let "y" slip. Once you get users trying to convince other users about how important their demands on your time are, they are now negotiating for your time and realize that something has to give.
- Know when to say that you're so busy that you won't be able to get to anything additional for another week unless your manager approves you dropping a project
- Keep a record of what you do for your manager and constantly build the case for additional headcount (assuming it will take forever...)
- be efficient - look for trends to problems and solve the root cause by scripting or automating instead of fixing the symptoms over and over
- Don't get suckered into working 16 hours a day - you won't be effecive and you'll be bitter. Learn to put in you 8-12 hours and leave work behind. meditate. Exercise. Chop wood (it's very theraputic!)
- Be effective - don't waste all day on slashdot - while you might actually read something useful here, your job description probably doesn't inclde surfing slashdot. Work is called WORK for a reason...
So, on behalf of your manager, GET BACK TO WORK!
It is especially hard when people put a lot of pressure on you and take an advantage. One polite way of saying no is to mention the US Labor laws, a lawyer, or both, and how the laws regulate number of hours per week and overtime pay.
I think a fair pay would involve a 300% pay increase for 70 hours a week. Don't let them tell you that it's your problem that it takes 70 hours. It is THEIR problem. Don't let them tell you that this is your company and your mission critical project. This is THEIR company and THEIR mission critical project. You are there to get paid for what you are worth and put in what you are comfortable with. Not less, not more.
The biggest problem is that they may try to disgruntle you and make it look like it's your fault. You have rights. Document all abuses. Put in a 2 weeks notice or just take a leave if that's the best. You can threaten to complain to a proper government agencies for workers' rights, and should actually do so if the company makes any retaliatory moves.
but gently remind them that they need you, more than you need them, as you are a very busy person, with a lot on your plate. Point out, gently and politely, that YOU are the one in control, not someone who is coming to you, for a service rendered. Of course, this does not work all the time, but I have and very good luck with this approach. Hell, sometimes I'm not even all that polite about it...
... the customer goes over your head to your point-haired boss who of course says 'no problem' and leaves you with the work having no comprehension of how long it'll take.
Try reading this: www.dilbert.com
Our CEO has this unique way of prioritising stuff that he wants us to do.
When he says "don't worry, it's not urgent", he means "Drop everything now and do it." When he says "Do it now, it's urgent" he actually means "I want it done three weeks ago!". Inevitably, whatever he wants "must only be a five minute job" but actually takes us a couple of hours which delays other software projects.
Despite the fact he prides himself on being a straight-talker with everyone, he can't seem to do it with our department. Gee, we must be special....
In my opinion most IT programmers have the problem that the marketing department makes promises on products and if they eventually are sold then the IT staff has to sort things out, possible or (nearly) impossible. Most times marketing is more powerful than IT (at least here in austria), because they control most of the company's money, and saying "We can't implement this feature" after THEY already advertised it makes you look either like a "non - team player" or just a lazy bastard. Saying no is not sooooo easy sometimes if you want to stay in your job. I prefer "sublte downgrading", meaning i implement something that feels like the requested function but is downgraded and less powerful. they almost never realize it :)
It would be more reasonable to ask the IT Staff what they actually can do in advance instead of telling them they must do it... this could save a lot of time and coffee
".Sig Stealer" was here
Also keep every memo email and piece of paper you're given, and if your boss or the customer tries to give you a new task/system change verbally, make sure they put it down on paper, so if something does to askew, you've damn well got a paper trail to deal with any recriminations.
It sounds like you are worth your resume and money, leave the job. You will not become a bum if you leave the job, but you just might if you keep it and burn out.
However, someone who is not worth the resume or the money, can't burn out when he is not doing much while sitting around for 70 hours a week. But he might just become a bum if he leaves.
I always ask if said software is in the building, next how critical it is versus the current workload, and then the all important question, is there cash in *MY* budget to do this job. Nothings sends em packing like asking for cash to get it done. Start talking about overtime, and they go running.
I am. A Digital Monk.
In computers, all things are possible, but the time they take may vary.... :)
I find that by repeating this whenever I'm asked if something is possible, I come across both as willing and responsible. And no-one's asked me to get a computer to make the tea... yet
I see a lot of suggestions that you may take but a lot of scheduling is being left out. If you, as many are saying, "simply" respond by saying blah, you will find you are spending your entire day replying to people, telling them these clever answers, and no time doing actual work. Instead there needs to be a system on how people contact you and then create a daily scheduled time when you can schedule when you will respond to their requests. Don't spend more than an hour a day working on your schedule but not that much less. It seems counterproductive to spend an hour not doing work when you have so much to do and so much coming in. But it will keep you sane.
There will be those who will see you as unreasonable. Those who will call you up and say "hey, I'm not asking you to do this now just to take 5 minutes and tell me when you can do it." You have to be brutal and say that you can't tell them anything and they must send you their problem through your implemented system and within a day you will give them an answer on when you can work on their problem if at all. It will seem unreasonable to them that you can't give them 5 minutes now but what they don't understand is it is just 5 minutes to them but 5 minutes times 100 people ends up being your entire day.
The short answer is don't tell anyone 'no' immedeatly but don't tell them anything else either. And remember that any answer that tells you that your problem is "simple" has never been in a situation where they are trying to organize tasks coming in from so many directions. Finding and implementing a working system is going to be hard and require some experimentation. The trick is to have a system, make your system transparent to your bosses, and not to be thrown off by people who aren't your boss telling you that you are being unreasonable.
When you interview, you should be well aware of the economics of your future position. Employers expect the potential employee to have thought out a plan of action for both the interview and their career.
So when the potential employer asks, "do you have any questions?" one of the first things that you should be asking about is, "may I ask, how much do you budget a year for the IT dept., more specifically upgrades?"
The answer will tell you everything you need to know. If the budget is small (less than half a million USD per year), you will be hardpressed at this working place. You will have a tough time, just as you are now.
Another tell-tale of a potentially less than ideal workplace is seeing what kind of servers and equipment they run. If the shop is stack full with Windows machines, they have incompetent IT staff, and you'll be stuck fixing someone else's crap. If they're big on Linux, it means they have no money for the real equipment and upgrades, which in turn means you'll be stuck again, this time with a low budget and probably a low salary, for which you will be overworked to boot. Again, less than ideal. These are important details not to miss when interviewing. If possible, ask for the tour of the IT facilities, that should also be a good indicator of what the place is like to work at.
Next time, then, knowing what the tell-tale signs are, you won't be stuck trying to figure out how to say "no". Good luck!
cost.
You said that the requests are unreasonable. From that I'm guessing you mean you couldn't plan for them. If this is true, they probably weren't in the original contract. Just tell them how much extra it's going to cost them.
Money is universal. Once you put something in terms of dollars and cents (or Euros, or Yen, or whatever), both your management and the customer will understand. Most of the time the phrase "This isn't in the contract" or "It'll cost extra" will be enough to scare a customer away for awhile.
...as an "IT Professional" in this economy:
NO: I don't believe (you|your recruiting firm) are actually (interested in my resume|shopping my resume to "prospective employers").
NO: I don't know all of the following: AIX/Assembler/GIS/Java Server Pages/Win32/C#/PeopleSoft/Ancient Swahili Healing Techniques/SuSe/Coal Mining/PowerBuilder/Rational Rose/Embedded Software/Web Design/Windows 3.1/95/98/2000/XP/Every Known Linux Distro/Did I mention AIX?/HIPAA/C/C++/Shit No One's Ever Heard Of/Tantra/Other Shit I Can't Think of Right Now Because I'm Too Drunk/ADA/Smalltalk/Networking/Your Proprietary System
NO: I can't build a system for you using all the above technologies for $15/hr.
NO: On a 10 hour fixed bid.
NO: Fries don't come with that.
NO: You can't speak to the manager.
In Soviet Russia, Chuck Norris will still kick your ass.
1. If you don't have an immediate response tell them you'll think about it. "I have to check my shedule." or "let me make sure that's ok"
2. A second approach would be to counter with a suggestion that would save you time and benefit the company. "or we could.." or "what if...."
Those 2 usually get the job done.
Put together a quick, simple web-thingy that you can administer, and give permission to your boss to assign priorities to items you get.
Somebody puts in a request? Great! Post it on your web-thingy, and notify your boss to assign priorities for the request(s).
Then, when user NNN sees their priority bumped to position #37 (ETA==never) they can take it up with your boss... while you just appear to be clean, professional, and attentive.
This is the kind of thing you could hack together with Linux/Apache/PHP/Perl in a matter of a few hours, if you really are any good.
Heck, put in a submission form so that you don't even need to type it in!
I have no problem with your religion until you decide it's reason to deprive others of the truth.
This is the classic dilemma in any activity that involves limited resources applied to competing tasks. At some point you'll have to drop some tasks to work on others since there just isn't enough time in the day to do your job. The problem you are having is that you are probably not setting up a controlled resolution process that everyone involved understands. If you have a way of prioritizing people's requests and keeping them updated on their status, then they are usually more reasonable about delays. It also helps you build up enough data to show to management that you need extra people.
With that in mind, here is what I almost always do:
1. Setup a request tracking system and get management to tell everyone that they need to use it. This is actually the hardest part and could take months to get everyone to use it. Don't be a slave to it though, just use the system to keep things organized and coordinate everyone's needs. I recommend RequestTracker2 (yes, it's free).
2. Rather than telling people, "No, I won't do that." Tell them, "Great, I've put your request in the Request Tracker. You can track the status of your request online. I'll prioritize requests based on need." You can tell them "No" by simply giving them a low priority. If it isn't really important then they'll forget about it. If it is really important, then they'll bug you and you can escalate. Be careful though because if you're in an organization where political power rules supreme and your boss has no balls, then you'll get dragged around like a rag doll servicing the requests of people who will further your boss's carrier. In this case, you're better off just not bothering, or finding a champion who has more rank than your boss to keep watch over the whole project.
3. Keep in mind that 80% of your problems are probably caused by 20% of your users (and also by management decisions). Once you have data on what requests you are servicing and who bugs you the most, you can bring reports to management showing who the top "offenders" are. If management is truly interested in saving money, they will identify the causes of these people's problems (most likely poor training and lack of controls over what they do to their computers) and try to fix them permanently. If you are like everyone else, then management won't be interested, but they will probably be interested if you have a "problem child" who eats up half your time a month (it's happened to me). In these extreme cases (which I call "IT Stalking") management will usually talk to the offender and they'll quit. If not, then beating then with a rubber hose in the parking lot is your only other option (I'm kidding on that of course).
4. The final thing you can do is to use the data you're collecting to try and improve your administration techniques. The key is to use run charts to identify causes which can be elliminated. Read books on Statistical Process Controll if you're really serious. This is the super advanced level, and if you're doing this, you're kicking ass. In my experience this is usually how you identify areas where you can most effectively use automation and identify recurring themes that need squashing.
It's not possible to cover everything in just a message, but I'm hoping this will get you going. The big thing to keep in mind is that all of this will take a long time and you'll need management support to really get it done. There's a lot you can do without their support though, and it might be a better place to start. For example: How much of your work have you automated? If you are logging in to each machine you admin and editing text files by hand, then you're not doing your job right. Check out PIKT or CFengine for help in this area. I think that if you can automate most of your job and try to setup controls so that common problems are prevented, then you'll go a long way to easing your schedule pain. But, for any real long lasting effect, you'll have to change the way this part of the company works. That's a pain.
The best way to say no is to say yes and bill by the hour.
Invoicing, Time Tracking, Reporting
But you have a lot of projects that your boss is hot on right now, so you'll want to consult the boss to make sure he doesn't mind you doing this "little thing" "real quick".
:)
Then you're sort of playing good cop/bad cop, using your boss as the bad guy
You can't do this on everything, or you'll really get on other employees' bad sides.
.sigs are for post^Hers.
There really is no answer, as this sort of thing is a naturally occurring force "in this economy"...you probably meant by that your attitude of laxity as being caused by the recent crisis (recession), although in reality it is due to the economy as a whole, in all periods.
But anyhow, usually when I start a job I generally take on all work initially, so that people's first impression will be that I'm not a "slacker". Then as stuff starts piling up I start being selective. For example, currently two people in a department give me things to do - one always goes the extra mile before handing it off, gives me all the information beforehand and so forth, the other will escalate anything immediately, gives me crappy information and so forth. So what I do is the first guy I always do what he wants right away, and the second guy I blow off or tell him I'm busy or tell him to do the groundwork himself. I also prioritize what I do - usually what the boss asks for, and what will keep me from getting headaches get first priority. Also, if something looks like a lot of work, I tell them, and since fires come up I give a longer estimate than it would be.
The ITAA helped cancel overtime pay for IT workers so this has sure helped out in them paying less and more IT people being unemployed. Now you can have 2 overworked, 60 hours a week programmers instead of 3 40 hour a week programmers. Hooray for capitalism, it's doing such a wonderful job - that's why the average inflation-adjusted hourly wage in the US is below what it was thirty years ago. As hours per year has risen by a three digit number. And so forth - the long-term trend doesn't look good. The only solution really is to check out Washtech/CWA or the Progammers Guild and fight it out with the ITAA.
I work in classroom IT at my university, fixing laptops, delivering computer equipment, etc. This week my boss went on vacation and left me to fill her shoes.
It's a lot different on the other side of the desk.
Just today, I had at least three or four professors call in and expect free tech support for personal computers. Others called and wanted free equipment usage for non-university related affairs. Two machines needed reformats and software installation. And the list goes on and on. Many were things that are not part of my department's responsibilities.
I had to say "no" a lot today, something I don't normally have / want to do when I'm not filling in for my boss. I like to help these people, and I have the feeling that most techs feel the same way. However, other work took priority. I can somewhat see what my boss goes through every day. That's why she majored in Socialogy and I'm majoring in Computer Engineering. Leave the the red tape to the management, and the computers to us!
given an appropriate allocation of time, money and resources.
:
There are a number of things that are key
1) agree with senior management on broad priorities
2) draw up a list of what needs to be done
3) re-order the list in terms of the agreed priorities
4) present the prioritised list to management, and have them agree to the priority
5) Give an honest indication of how far down the list you'll be able to get
Go off and do stuff, and report progress on the list and re-prioritise the list say once a week, with their input.
IF they are half way decent as a manager, they will rapidly understand to either accept the level of capability they have, OR accept the need to increase that level of capability to meet their performance expectations. If they can't arrive at conclusions similar to these, in general you should be looking to work elsewhere.
If they want X to be done, explain what is really needed to achieve X. If some or all of the pre-requisites, give a honest estimate of how that will impact their timelines.
Oh - and plan on, and only commit to, 35-40 hours of real work per week per person, otherwise you'll burn people out, AND have no spare capacity to surge to meet the occasional urgent deadlines.
Another thing that can help, is to help filter the crap out, by getting agreement from management for allocation of resources to issues.
No system is perfect, but if you can demonstrate an understanding of the businesses needs and priorities, and be up front, but constructive, about the implications of meeting those, you can often say no without really saying no.
I always work with a strict feature schedule. I'm (amongst other things) responsible for a number of applications running in this organisation I work for. For all these applications there exists a *huge* wishlist. So what I basically have done is decide which features go in which version. Every feature gets a timeline attached to it (cost aren't really a big option here, but time is) and these timelines combined get a releasedate per version. Now, new features (as opposed to bugs!!) get pushed in behind in the queue and are versioned. And just stick fanatically to this versionlist. This helps me a lot (and has also helped me a lot when I used to work for a webdev company)
You could work 70 hours/week until you have an ulcer. I've worked in those kinda environments.
First thing: STOP ACTING LIKE YOU'RE THE ONLY PERSON RESPONSIBLE FOR THIS PROBLEM. Break it down into clear responsibilities and assume the ones that are resonable for you. Stuff the rest up your Boss' throat.
Start with the servers. Make a maintenance schedule. Shut them down every 4 or 8 weeks to Patch, review backups (!!!) and reboot to test "get back up" ability. Make *NO* exceptions.
Whoever is in charge of that asylum might understand that. Once you've got control of 'em servers -- then focus on whatever the end users want/need insofar as support goes.
Remember. The corporate jewels are in/on those servers and you *MUST* back them up reliably. Heck, you have to prove to yourself that you can restore them!
It's time to put the brakes on that shop, dude(ette). Get the cardboard out and put the big "flame" on one or two machines. Shut them off. ("firedrill")
Look, you can't rationalize this with these people. Either DO IT better or sit down with your boss and get it in writing that you're not responsible for loss of data. Heck, get that in writing anyhow unless you're in charge or entirely satisfied with the scheme.
Good luck. icq 338-262-309 anytime.
Second Thing: Developers are insane with change/control proceedures, in my experience. They'll drop tables, insert 1 million rows, update DB schemas, etc.. on a whim. GET THOSE BACKUPS DONE!!
I was in your situation about 10 years ago with my first ever IT job. I agree with posts recommending a project plan, keeping your boss informed of what you're doing, and also escalating impossible work requests to your boss to manage so that you do not look like you are being overly obstructive (just busy!).
:) This CAN backfire if you do it too consistently, as people will start to think you don't have enough work to do, or that you are pretty poor at managing your time... but if you have 100 users, you can try it at least once on all of them :)
At the end of the day I tend to forget what I just spent 12 hours doing, so write everything down as you go along, and mail this to your manager at the end of the week, so they are aware just how busy you are.
BUT - my main area of expertise is DEFINITELY the route of underpromise and overdeliver. This is a technique for making yourself look more efficient than you really are. So - a user asks you to come and troubleshoot - say a missing share they used to have set up on their workstation. You know you can get round to them in 1 hour. Tell the user you will definitely come to see them in 2 hours time. Turn up in 3 hours and the users unhappy. Turn up in 2 hours and you've met expectations. Turn up in ONE hour, and hey - you're an hour early - RESULT! The user is v pleased that he is important enough for you to see quickly! User is happy. Now you knew all along you'd be one hour... but you've managed the perception of the user effectively, and he's a lot happier because, at the end of the day, you've psychologically out-manoeuvred him
Couple more things - when you helldesk phone rings, smile when you answer. You can hear it in your voice, and you will come across as a happy + confident employee, even if you're the opposite. This gives people confidance in your abilities, and they will enjoy dealing with you - and this costs you no time or effort. The more highly people think of you, the better your life will be.
Remember people. This is easy for you - I work with 5000 people, you only have 100. Bear in mind that at the end of the day, everyone wants to be adored *no, really they do!*, so you can use this to your advantage in a smaller way - treat users nicely, ie: as if you like them, and they will generally like you back. People who like you generally will let you get away with more... how much more quickly would you forgive your best mate letting you down, compared to a stranger?
I know none of these are super-practical tips, but you've already had tons of them - I promise they'll all make your job more enjoyable!
Good Luck.
I was in the same boat you are in a few years ago. I was hired as the sole IT person to support 100+ users runnind Windows and Macs. The amount of work to be done was overwhelming. I was woring from 8am till 8pm, 6 days per week trying to keep up with the workload.
Turns out they fired my tail because someone in the company didn't like my attitude, and replaced me with a staff of three. My suggestion to you is to set your work hours and do as much as possible within them, but make sure you go home on time, unless they pay you overtime. You shouldn't sacrifice your personal life to compensate to their inadaquate staffing levels since it's unlikely they will appreciate it.
Not only does management speak/graphs help get your point across, it is CYA. Then, laterl, when the manager tries to make it look like you are a slacker and haven't been doing what you said you could, you can back yourself up by presenting the document you showed him.
If you have a good documentation of your time spent, it is hard to argue that you ought to be fired for laziness since you have proof of what you've been doing.
It also helps with managers who like to tell you one thing, and customers another. For example they priortise getting the network upgraded as #1, but then tell a customer that you will be more than happy to help them install a new photo software whenever they like. YOu can then whip out the document, point out the priorites that THEY gave to you, and ask tehm if they want to revise it.
The idea here is putting the impetus for time management on your manager (they are supposed to manage) and having the documnetiation to back it up.
Tell them: What part of the "NO" is the one you don't understand? The "N" or the "O"?
They will get it. Sure.
Half Time
Although my experience is slightly different because we are customer-based and not internal, our approach is to say "it will cost you". Then, if they insist it can be done faster you outline the risks. If there's money at risk they usually capitulate, but if they make unreasonable demands, the only thing you can do is go along with it making it clear you're not comfortable. At the end of the day it's 'their' money and 'their' responsibility. If the problem is that they expect you to do more hours than you think is reasonable and won't hire help then the problem is not how to say no - it's your unreasonable employers.
...keep a schedule of everything
it may help using project or, better IMHO, an issue-tracking system so that requests can come in via the web or email, and users can see the status of their request anytime and its level of importance related to other requests.
A very good issue tracking system is roundup http://roundup.sf.net it runs as a cgi or as a standalone app.
Once you have such a system in place, send out weekly status reports on everything accomplished during the week, pending issues, etc.
Visibility is one of the most important things in organizations.
Oh and when you have difficult situations, ask your boss showing him the pending issues in relative order of importance, their timeline etc.
Yeah, charting and budgeting time is swell, but it still leaves the problem about *what* to prioritize. i.e. - Create perl scripts to help generate the new report about project X? Or reconfigure all machines to avoid big new worm 0 that's shutting down systems acroos the internet? Or reconstruct email system to deal with recent joejob? Or implement new tool Y which will increase productivity 50%?
Sometimes you can't put off what doesn't look important. Decisions, decisions...
There is no America. There is no democracy. There is only IBM and AT&T and DuPont, Dow, General Electric, and Exxon
Well as long as we're looking to the movies for wisdom, don't leave out Office Space, or American Beauty. I know, the DVD keeps jumping to and freezing on Thora's ample gifts, but if you can manage to find the scene where Spacey tells off his boss.... Falling Down would be a poor choice to consult in this instance, considering the less than ideal ending.
There is no "No" in the workplace. But there is a lot of other things.
... and will not stall us with the current project."
For example, there is the current list of your tasks, with a timeline and priorities. If your management comes with new projects, have them look at that schedule and ask them to reorder priorities and timelines, if necessary. That will give them an idea of what the new project will cost them in terms of delay of other projects, messed dependencies and other consequences.
For example, there is the simple question of money. If an external customer comes to you with a new project or a new idea that will mess up the current project, show them the consequences of their doing, and attach a price to this. "Your new idea will fit into the current project here, here and here. It will use up to x mandays of work, costing $$$ each, and will delay the first shipment of the deliverables by y days. Also, the new things will need adjustments to the project documentation, the handbooks, the testing procedures, costing another $$$. That comes down to a total of $$$$$$ for you at this point in time. Another alternative would be a separate project adding your features to the finished product. That might be slightly cheaper because of
The basic idea behind all these techniques is to make the internal structure of your projects and your schedule as transparent as necessary for the person asking you. It enables them to understand that their idea may be good (it probably even is), but that it is not suitable at this point in time. It also makes transparent for them the ressources they allocate and probably waste, if they insist on it now.
Which is much more effective as a plain "no" anyway.
Kristian
Nobody likes to be told "no" when they request something, especially from someone (like yourself) who is seen as a resource within the organization that is supposed to respond to requests.
I'm going to echo what others have said, and that is essentially, communicate, communicate, and communicate some more. Don't whine, just explain the facts:
Fact 1. You are a human being, and you have a limited amount of time to accomplish tasks, just as any other human being does.
Fact 2. When you have responsibilities, those responsibilities take time. Additional responsibilities will require more time.
Fact 3. If tasks are expected to be accomplished at a higher rate of speed, management must either allocate more resources to accomplish those tasks, or must properly prioritize.
Fact 4. You should not be expected to work 70 hour weeks to keep up with the basic demands of your organization. This, it seems to me, is the most important one in the situation described- it points to a failure on the part of the organization to recognize that in order to accomplish their goals, they must be willing to allocate the proper resources to those goals.
Speak to your boss/manager, and explain the situtaion in simple, concrete terms. Don't be afraid to say "It is not reasonable to expect a single FTE to accomplish the tasks allocated." Document what you're doing, explain why (in simple terms) it takes the amount of time it does to do things, and be prepared to explain your reasoning. You are the subject matter expert, not management.
What it comes down to is that when the rubber meets the road, an organization that wishes to have tasks accomplished in a timely manner by any division, IT or not, must be prepared to support that goal with resources. If the organization cannot or will not provide those resources, you MUST explain (politely) that it is not possible to accomplish what is expected in the timeframe alloted.
I realize that not everyone is in the position to say "give me the resources I need or find someone else to tell you what you want to hear", but the alternative is to eventually fail; in a case where you simply cannot make management see the facts, it would be prudent to seek employment elsewhere if possible.
I speak from experience here- I tried to be Superman and Scotty all in one to a number of organizations. I suceeded for a while, but only by totally destroying anything I had resembling a life outside of work, and that led to long-term health problems, both physical and emotional.
Trust me, you'll burn out long before anyone takes any notice of your plight, unless you make it perfectly clear what you bring to the table, and what you do not- 70 hour work weeks shouldn't be in that package.
For all the bitching we tend to do about managers, having a good one is critical in this sort of situation. Just about the only way to come through such a problem intact is to ensure that your boss guards your time jealously. Being able to say "your request will take me two days, but it'll be two days a month from now unless you can convince $BOSS to downgrade one of my other priorities" is really the key here. If it's a project you agree is important, but just don't have time for, you might suggest some ways that your boss might be convinced to agree. On the other hand, if it seems meaningless, you can probably avoid an argument by listing some specific items on your to-do list that everyone in the company will recognize as being sacred. But either way it's not your job to do the convincing.
Don't, no matter what you do, work 70 hour weeks without extra compensation. I've been caught in that trap, and I can assure you that what feels to you like dedication to quality looks to them like prime evidence that you're a sucker. (In the worst case, if they fire you for not working unpaid overtime, you still get unemployment benefits. But if you burn yourself out to the point where you either quit or become so unproductive during your regular day that they can call you incompetent, you get nothing.)
If/when your own boss comes to you with more work, my suggested response would be along the lines of "I'm afraid I can't do Y right now, because I'm having to spend all my time on X in order to get it done by when you said you needed it...or is Y more important than X?"
But overall, the best thing to do is to remember that an "order" from someone who doesn't personally control whether or not you still have a job is actually only a suggestion. Keeping all the users happy is a good thing, but not at the expense of either your manager's pet projects or your own sanity.
I am a contractor doing freelance tech support, sound design, and web app programming. I've found that the best way to keep clients from taking advantage of me is to charge a lot.
Seriously! When clients have to feel their pocketbook getting lighter, they stop asking for piddling things and keep requests to important items.
Jory
...NO: I don't have an H1-B
and NO: The guy who replaced me at 1/10th the salary can't speak the friggin' Queen's English.
Fuck it...stick 'em in there somewhere. Is this funny or pathetic? I don't care, mod it as you will.
In Soviet Russia, Chuck Norris will still kick your ass.
As the parent poster implied, use MS Project (or whatever project planning software you've got) and put everything you've got to do on the plan.
... hours per week. Either you'll get lots of overtime (if that's what you want), or they'll hire you an assistant.
;->
**Keep it maintained at all times** - it only takes a few minutes to maintain it once you've got it set up.
**Be realistic with your time estimates** - if you don't know how to build a firewall, then allow a lot of time to do it.
**Remember that you aren't productive 40 hours a week** - depending on your role, you'll probably only do productive work 30-80% of the time, and if you're the only techo guy in the shop I'm betting you'd be somewhere below 80% productive. Reading email, going to meetings, cigarette breaks - they all chew into your 40 hours per week. Once you decide how productive you truly are, factor it into the project plan by saying the resource (you!) is only e.g. 60% available.
Then, when someone comes up and asks you to manually install virus checkers on these 43 new PCs, put it in your project plan, show how every other task you've got blows out by 2 weeks and see if your boss is prepared to accept the delay.
If you're at a place where they pay for overtime, enter all your time estimates in hours and do a few "what if" scenarios on your resource allocation (i.e. you!) to show how long things will take if you work 30, 40, 50, 60,
Without a doubt, the best/only way to get out of a situation where you're overworked is to be extremely organised and able to show anyone at a moment's notice exactly how busy you are. Once your boss can see the true impact of giving you "just one more" task, in terms of the slippage that will impact other projects, you'll be amazed how that extra work will no longer be as important
PS If anyone knows an OSS MS Project replacement that can do all this stuff, please speak up. I've been dying to replace it for ages, but it's a really good fit for this particular problem space
if you want me to work on B then I can not work on A, do you have the authorisation to stop me working on A if so I will work on B otherwise seek approval.
They then usualy can not get approval and I work on A until it is completed or not a priority.
ERR 411[Max number of witty sigs reached]
Okay as much as I agree with a lot of the prioritisation advice that has been given so far, I'm going to offer some different advice.
:-)
Wild guess... you're a perfectionist?
Me too.
It's a problem.
Seriously, aiming for perfection is a genuine personality problem in a work environment. Why? Because perfectionists can never achieve their goal but they'll spend twice as long as everyone else trying.
Here's the solution, tried and tested.
Follow the 90% rule.
Know exactly what you instinctively want to do to complete any task, and then aim for 90% of it.
Do this once.
Then ask yourself, honestly, have I really done a bad job here? The answer will be no, you've done a job that is the same as you'd have achieved if you'd aimed for perfection. But it took you half the time.
Perfectionists waste so much time aiming for that extra 10% and they never achieve it because it's a form of psychological self-punishment.
Get one thing absolutely clear in your mind -- you are NOT aiming to cut corners or be lazy. You're going to achieve exactly what you would normally, you're just freeing yourself from that nagging burden of an impossible goal.
Finally, consider this...
When you wonder about "how to say no" to people, are you worried about letting them down or letting yourself down?
See what I mean?
It's called Negotiation and is one of the hardest things to get right in business.
:-
If it's a client, you have to politely inform them that while you may not be able to get the job done for the time they are requesting, you can certainly aim for 'x time' - never mention other projects that you are working on for a client as you always want them to get the impression that they are the most important.
Never say No to a client - if you no you can't do it, then outsource it.
If it's your boss, you have to negotiate more heavily, as the boss is certain to 'pull rank' to get his/her way. Again, you need to request more time, however at this point you can indicate all the other project that you are working on and set a priority list
Ok boss, if this job is so urgent, I'm afraid I'm going to have to put X job on the back-burner to get it done.
Finally, if it's a marketing person who said to the client "Sure, we can get that done by next week Tuesday easy !", you have to hunt that marketing person down and kill them - after all, marketing types are a dozen a dime and really have little use except for blood-sport...
A slashdotting - you get the stick first and then the carrot !
Mr Burns: I see it all, now. You're just a bunch of yes-men. I was making the wrong moves and you were too gutless to tell me! Isn't that right??
Yes-men: Oh, yes, sure, etc.
Smithers: Right on, sir.
"I assumed blithely that there were no elves out there in the darkness"
My solution to this was to make a "to do" application.
If my colleague wants something done I tell him to put it on the to-do list with a priority rating.
I then work top down. That way he knows what I have / haven't done and what he's going to delay by wanting new things.
Managers should manage. I let him choose which work I'm doing next.
And I can't stress enough how well that appraoch works in a bigger company. Bump requests up to your manager and let him choose which you do next. It reduces your stress because you aren't trying to juggle a bunch of peoples feelings and with luck, if you are overworked, they will do something about it because they can see the situation rather than people bitching about you never doing their tasks when they think that their tasks are the only ones you have outstanding.
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
I am in a similar situation, in that I've only been on for a few months now and one other person and I are doing all of the web programming for out site (asp .NET stuff). We've recently changed all of our services, billing procedure, web interfaces, etc... so that there is alot of work left to do to complete the transition as well as a whole bunch of work in fixing bugs that pop up in the new system.
I get requests for features from the higher ups, and maintence requests from my peers who need certain things to work in order for their software to interact with our site. In any case, I work as hard as I damned well can, but I basically prioritze what needs to be done and what can wait (at least for awhile). And the people working with me realize that is what I am doing and treat me pretty well even if I am a bit slower in getting their next feature done than they would like.
I would say that if you are in an evironment where the people around you expect you to do more with less when you are already working (and I mean seriously working) a full 8-10 hour shift, then you need to look for a new job. Obviously the current economy will make this hard (I've had to pass up on a move because of the economy), but working in a place where they want 5 people worth of work from just 1 person because they are too stingy-stupid-whatever to hire more people is just plain masochistic.
- I love animals. I try to eat at least one a day.
Today's excuse : Solar winds.
Yeah, yeah, it sounds sleazy, but it's the only way to ease the workload without coming off as a difficult person.
Everything written so far about having some sort of *list* that everyone can look at and understand is crucial.
This works not just for support, but for any multiple-human endeavor. Why - because a written list is what keeps humans sane, who knows why?
The whole thing is to have some sort of reasonable way of doing things, otherwise you get to go back 50000 years into PANIC. And you don't get to take your club with you.
If you got a $100 bill, put your hands up...
If you see a reply from someone during the day, they're reading reading Slashdot at work and taking the time to reply at work or they're unemployed.
"I was going to write this bitchin' Hello World program; so I made my boss, like, write a specification, and then I charted out the timeline from focus groups all the way through QA. I got laid off a month before I could finish it, though. What a bummer. All that work for nothin'. I'm really bored now at home, but I've become an expert at Microsoft Project."
Karma - Troll (cover your webcam, you're hideous!)
Theres no way in _HELL_ we can build a site for 10,000 hits / hour with ONE microsoft 2000 license!
Simple.
Keep a list of all assigned projects, whether on a web page for all to see, or on a whiteboard, and make damn sure everybody knows where it is. Get priorities assigned, not as in TOP but as in position on the list.
... body bags, medicine, ammunition, combat rations, fuel .... and the ensign got all huffy and backed down.
...
Here's a little story you might find enlightening, the importance of priorities in keeping requests under control. This is relevant, very relevant.
I worked with a guy who was an air force loadmaster in Vietnam, early 60s. He had some scut job at the main Saigon airbase. They used to extract carriage fees from shipments of steak and whiskey going up to the officers club at Cam Ranh Bay. One day, some ensign showed up, fresh as a daisy, said there were pallets going up to the club, and he was in charge of making sure they arrived intact, and demanded they be sent up on the next available plane. My friend had been in too long to give a shit about some wet behind the ears ensign, and furthermore, had the distinct attitude of What Are You Going To Do, Send Me To Vietnam? So he slapped a bunch of clipboards up on the counter, said fine, you tell me what cargo you want to take off, sir, and we'll see that your steak and whiskey gets up there right away sir. Now what will it be
That's the end of the relevant part of the story. Remember, make the job assigner decide not TOP priority, but where exactly on the list, so when other people complain, you can point to new jobs added above theirs. The goal is to get the suits hassling each other, not you. Don't argue with them. If they berate you, just say you need to know whose jobs to bump down the list. Be quiet and form, you need to know the positional priority.
OK, the rest of the story is more fun, not as relevant, but may help you to remember this trick.
The ensign demanded that someone stand guard over the pallets of steak and whiskey. My friend just sneered at him, Sir, you have a sidearm, why don't you use it? And the ensign did, he stood gaurd over the precious pallets for some time, until some crusty old chief, who had spit more sea water than the ensign had ever seen, showed up with a case of whiskey under one arm and a case of steaks under the other, slapped them down on the counter, and the pallets went out on the next flight.
There's a moral to that story to, but it's probably not a good idea to start taking bribes to shuffle your boss's priorities
Infuriate left and right
>>I've searched the web, but most of the sites that supposedly have information of this type just want you to sign up for their seminars.
There's a great book "Rapid Developemnt" by Steve McConnel, I recomment every developer/project manager to read it. I remember reading a good section on how to say 'No' in a professionl way.
He has a bunch of exerpts and articles here:
http://www.stevemcconnell.com/
Offtopic, Inflammatory, Inappropriate, Illegal, or Offensive comments might be moderated up.
In the world of Show Production ( I'm a lighting designer for clubs, concerts and the likes) we have the show triangle.
Fast
Good
Cheap
You can have it good and fast.. but it wont be cheap
You can have it cheap and fast.. but it wont be good
You can have it good and cheap.. but it wont be fast
This is most likely not a good idea, and not primarily because of the current job market. Chances are high that you will find the same situation elsewhere, too. So moving to a different job (if you can do it at all) will most likely not improve your situation. If you can't manage your customers in your current job, you probably won't manage them anywhere.
There are reasons why customers behave in an insane way sometimes. The most common one is: they think you work for free. Not literally, but in a large organization few people have to pay directly for the work of the IT staff. So to them your work is free as in beer. And if you hand out beer for free, people have an incentive to get drunk. Of course overload will cause headache (as in beer), but the incentive is still there.
The solution is to make them pay for your work. If you can't do this in dollars and cents, make them work. Force them to go through your boss. Make them take the blame if a top banana at your organization can't use powerpoint for a day because you are busy fixing minesweeper installations.
When they propose a task tell them how much it will cost them and ask about prioritization of existing tasks.
"God fights on the side with the best artillery." - Napoleon, Marshal of France - speaking truth to power
This applies to "professionals", too. My parents are boths accountants (a CMA & CA) and used to do taxes for family members and friends in exchange for (in my mom's case one year) a dozen jars of home-made jam and (for my dad) a box of meat. They don't do that anymore, though -- the firms they work at have policies against their accountants doing side business.
There's actually a north-american tradition of this. In "To Kill A Mockingbird", either Jem or Scout (I can't remember who) asks their father why people leave food on the back porch. His reply is along the lines of 'these people are friends, and they can't afford to pay cash'. For those who forgot (or never read the book), Atticus Finch was a lawyer who would frequently provide services for people in the town who could not pay (many of whom were black - not a popular move in 1950's small-town Alabama). Exellent book, BTW.
A man who can't pronouce "nuclear arsenal" shouldn't have one -sig ends here.
This is a very valid point, i work as a data warehouse designer, part of my duties is to use various reporting tools (Business Objects and Siebel Analytics) to design and build report to return the data that the customer wants to see. Since i work in the UK and the client is a v large company reporting to a regulatory body these reports are the basis for fines, timetables and the like, however the client comes accross as a very half assed designer. If they want something i spend some time going through there requirements trying to steer them away from going over the top.
Example..
'great if we have a report that shows me a,b,c and d as a % of C then why not have it show r,t,y,g,h as well.'
'We show those in another report there is no need'for them in this one.' i usually spake thusly
The need for fast accurate reports goes over there heads and the need for a No!! often comes in at the point, you really have to weigh the almost childish i want! i want! i want! with the actual design and specs.
I fully believe in the word no, its not just about scaring them with quotes and timescales but also about professional pride in a good job
S
Kingdom of Loathing (www.kingdomofloathing.com) Addicted is me
Two months at a software engineering shop? C'mon, half of the staff there can probably do a large chunk of what you do. They're either knowingly taking advatage or they're fucking with the new guy. Either way, get some backbone and tell them you either get an additional helper, or cancel some of the non-essential jobs you've got to do. Let them make the choice between more moeny or less work... Or quit and let someone else do it...
Forget thrust, drag, lift and weight. Airplanes fly because of money.
This paper : "How to be a programmer, a short, comprehensive and personal summary" (PDF) is a good start to answer your question. After debugging techniques, there are wonderful chapters like "how to talk to non engineers", "how to deal with difficult people", how to tell people what they don't want to hear". The author has a very sound view of dev work (more than net/sysadmin) and his concise advice is worth the read.
WHat you're dealing with is only mis-communication. One interesting point is to try to understand how non-techs see us, especially when they ask us something impossible or overcostly. We cherish this nerd culture, but it makes our interaction with the rest of the world somehow diffucult. Our individual value increases if we are also able to implement the NormalPerson interface.
I mean it. Never say "no". Just tell them how long it will take, how many hours of your time it will take, what resources you will need, how much it will cost, and then let them decide whether it's worth proceeding.
Here are some hints:
Keep a job sheet. Prioritise your jobs. Put hourly estimates next to each job. Amend the sheet as each job progresses. When adding any job to your sheet, give the user an estimate of when you'll start and how long it will take. Keep users well informed of any progress on the job: a 20-second phone call will consume very little of your time but makes the user VERY happy. Give monthly job reports to your boss showing total time incurred on each type of job, etc.
Now you've got the job sheet, everything becomes easy. If users complain about delays in starting, point to the sheet. If they argue that's far too long to wait, point to the sheet. If they demand that they be given higher priority, tell them to get permission from the boss to reprioritise. If the boss asks why you're taking so long to get around to fixing Mary's computer, point to the sheet. If the boss wants to know where all the money's going, point to the sheet. The sheet is wonderful.
If you want to be super-nerdy, put the job sheet on the intranet. A simple spreadsheet is all you need. Don't get fancy. Rotate the sheet once per week, carrying unfinished jobs forward. Now users can easily see what you're working on and who is wasting all your time. Office politics will soon put pressure on the problem users (and you will always have at least one problem user) to leave you alone, and you don't have to do a thing.
Whatever you do, never say "no".
These are the guidelines that help me achieve my goals, and my boss' goals, without going nuts in the process.
I can't stress this one enough. ALL requests for work should come through your trouble ticket system. Mid and Long-term projects don't need this as they should *only* come from your immediate boss.
Having everything in writing allows you to keep track of who requested what and when. It also leaves a paper trail should the user/client claim you did not meet their request on time/to spec. Last but not least, it enables you to justify your time management.
I know this sounds like a verbal wank, but it's true. If a task is not important, don't prioritise it above those that are. Keep in mind that your priorities are not those of your boss, and your boss' opinion of your work is really all that matters as far as doing well goes.
To be happy and successful in your job, you need to meet the priorities of your boss. If there's something that needs doing and it's not your boss' priority, make it one. Do this by explaining what it is, why it needs to be done, the impact on the organisation/yourself/your department/whatever if it's not done, the urgency and why it's so urgent.
When you're working on very important tasks under ultratight deadline, put your phone on "do not disturb" and ignore email. This helps your concentration greatly and, bottom line, if it's important enough people will walk into your office to see you. This is doubly effective if you're trained your users to do everything via TTS or email; they'll be reluctant to ask you in person, knowing you usually tell them to repeat it all in an email. Thus they'll only come to you when it really is important.
Following the above point, your prioritised list of tasks is sacrosanct - stick to it! The *only* tasks you should even consider inserting into the priority list you and your boss have previously agreed on, are those that can be classed as "DoMeNowOrElse". Before you class something in this way, ask yourself "would i be willing to do major (>2hrs) overtime to get this done ASAP?" If they answer is yes (e.g. downed email server), then it's worthy of insertion into the priority list. Also keep in mind these insertions should always go above existing priorities - it'll help dissuade you from arbitarily adding tasks because someone other than your immediate manager says they're urgent.
Meet once a week with your boss and ensure your priority list is still relevant with his needs. He or she usually knows much more about whats going on and what's important at a strategic level, so while you may think disabling that ex-employee's account isn't more important than upgrading a mailserver, your boss may know different.
This may sound silly in a discussion about workload management, but it's core to everything you do as a sysadmin. Remember that the only time most people see what you do is when they come to you with a request. They dont have the vaguest clue what your job entails - the difficulty, the hours, the stress, none of it. All they'll remember is the grumpy way you dismissed them with a "no" and went back to working on your "DoMeNowOrElse" task. Which to them of course looks like you're just goofing off at your workstation. While this seems the easiest, I find this point by far the hardest to stick to.
And, last but not least, remember this phrase: "A lack of planning on your part does not constitute an emergency on my part". But don't ever say that to your users unless you can figure a nicer way of putting it
Janie took my gun...
This ain't a problem you can solve yourself. It all depends on your boss.
If you have a good boss, you can talk to him about work overload, and he will help you put priorities on the projects and fight off people who want to hassle you.
In short: A good boss will make sure that you can put as much of your time into actually working, and he will be the one saying "no" for you. That's his job. You're there for technical skills, not for corporate politics.
If your boss sucks, he'll leave everything to you and then blame you if things go wrong. One surefire sign I've found for this kind of boss is that if you complain to him that you can't get all the work done, he replies with something like "well, then stay longer".
If you have a boss of that kind, my advise is to get the hell out.
Talking to people will generally help (as in "ok, I've written down your problem, so I won't forget it, but I have x other tasks right now and it will take y hours/days before I can work on it.").
However, for most people if they do have a serious problem, that is the most important thing in the company and you will probably spend way too much time arguing with them - time you could have spent fixing the problem.
What you can do here is to work on getting an image of reliability. If everyone in the company knows that you will remember their problem, for example, they are less likely to call in to "remind" you.
A "todo" list really is your best friend. It makes sure that when the shit hits the fan, you have some documentation to fall back to, and you can show everyone that you would have gotten to the printer right after the CEOs secretaries mouse problem and the network outage on floor 3.
Assorted stuff I do sometimes: Lemuria.org
If I had the experience you are asking for I would be holding a seminar and get you to sign up.
Especially if you are a programmer. At least a sys admin can get away witih saying no maybe 10% of the time. The second a programmer says no he has attitude and teamwork issues and eventually becomes Fredo's Kiss of Death.
... but if we do it this way we can get the same result."
There was a time when it was possible for us programmers to hide behind a project manager whenever the requests were unreasonable or just did not make common sense, but that is no more. When the mass layoffs started the first thing that happened was at least half of these project managers got the axe and many programmers got stuck in PM duties. This is why to many of us this job is turning us into politicians, because it is the only way to survive.
Of course, one could get high and mighty, but the only thing one would get out of this is a pink slip or a bad performance review (like it just happened to me).
The only possible escape is instead of just plain saying no, to deflect the issue with alternative approaches to the problem. What sounds better? "Can't be done.", or "This is not going to work because of
Pedro
----
The Insomniac Coder
This is a test of your management, not you. That is what management is for, for heavens sake.
You should have a line manager to whom you report. Yes, of course you provide a service to a zillion different departments, but there should be one person to whome you report. Possibly the guy who hired you. Or the guy who says you can't have any more budget. This is his problem.
If that guy is totally pointy-haired, then there is nothing you can do. Start looking for another job. Because even if you solve this problem, another will come along, and another, and another... Better to jump early that to drop out from exhaustion.
But assuming your boss is not totally pointy haired, then all you need to do is to dump the stuff on his desk. When people come and make the excessive demands, package the whole lot up, take it to him and say "this represents 200% of what I can possibly do - please choose the half you want me to do, and prioritise it, the tell the other half they cannot have what they want", It is his job, not yours to palacate the enraged user. There may be a few iterations, as different users use their different powewrs to escalate their requests (or drop them because they weren't that important, or there is another way to do them).
Obviously, your boss will try to get a bit more out of you - ask for 110% of that 200%. Don't give in to this. Make that 100% honest, then stick to it. If your boss fires you for an honest statement of what you can do, then he is too pointy haired to work for. And don't let him squeeze your estimates - if you say four days for a job, it is four days, not three. You are the techy, it is your job to make those estimates - and to get them more or less right. He is the manager, it is his job to use those estimates to get the best value for the company from your skills. Respect his skills - do the things he prioritises, not the ones you would like to do. But demand that he respect your skills and doesn't override your technical judgement.
To summarise: you need to learn to say no to only one person: your manager. If you cannot set up a decent relationship with him/her, the job has no long term prospects: head for the lifeboats fast. If you can set up such a relationship (and it is a core function of technical management to have such relationships), then you can simply pass the buck upwards.
Consciousness is an illusion caused by an excess of self consciousness.
I read Peopleware at a software house. Good book. Then the s/w house went bankrupt so I had to follow the work to BLCMP. Then after I'd put in a year's faithful service I had a schizophrenic episode so they made me redundant.
Moral of this story: you can be in a Kobayashi Maru (no win) situation, do everything right and still everything will coe down in flames. Hope you work things out ok.
It's the difference between software engineering and hacking. They want a new feature? Fine, ask them for requirements and use cases. Hard copies. Signed. Put a positive spin on it by asking them they'd rather you did it right, or did it twice. Document everything, confirm every conversation by email, attach your schedule to every document, actually move your completion dates every time a piece of new work hits you, and never, ever tolerate the scam that you're only scheduled for (e.g.) 80% of your time, and you can fit in the extra work (along with holidays, training (hah!), sickness and meetings) into that other 20%. It's bullshit, and management need to be called out on it.
If you were blocking sigs, you wouldn't have to read this.
The best solution is accept the work, but explain how over-burdened you are.
Work 8 hour days, and walk at the end of your shift. Because the previous guy was willing to give up his life to meet the demands to the company, they expect you to as well.
You need to reset their expectations. After they've seen that they're going to have to wait for things, they probably will reconsider letting you hire someone to help. (or fire you, but we shouldn't have to accept abuse just because of the market)
hmmm, sounds like my old job.....
a decent whiteboard, project planner, job priority
list and making sure that the end users only
submit jobs through their supervisors or
team leader is your path to happiness and
being able to do the tasks.
personally, i'd be more worried that you are the sole person...so how will you holiday?
In this kind of situation, I think the best is not to say no. But, when you say no and you can give them a reasonable answer, then you will be able to satisfy them without insulting them.
Somemore, just work there for another 6 months, and you can use that experience to find a better job in the future. I guess you know that experience is more important, hey...
What others think of my opinion?
Speaking as someone who was worked 12 years in IT, and has been very successful, I would suggest that it's irrelevant whether or not you find out how to say "no." That's because IT is in the midst of a sea-change, a change that I suspect will ultimately destroy the traditional IT department. You see, it will never be possible to run IT the way you know it could be run; the business won't cooperate enough to let that happen. If you do learn to say "no," vendors, consultants, and suppliers will be right there to tell your customers "yes, yes" no matter what the request is. IT products and services every year are better and better at replacing real, live humans, even developers. You're just one, committed employee; you can't compete against companies that make money off of providing IT services to businesses.
My suggestion? Get out of corprate IT. Go find a supplier, and work for them. Find a way to do what you do but as a contractor, not a full time employee. Create a great product that will destroy the IT departments you currently work for; you'll make a fortune.
The queue list was the first page anyone saw. From that page, you could 'Enter a new problem request', which let users fill out a small form that has:
- A one line description of the problem
- An elabortate free form description
- A priority chooser for hi/med/low/whatever
- An email 'cc list' for the problem
The tasks would all show up in the queue, sorted by priority and status, or you could click on the headings to resort by name, date, etc.Sysadmins could reprioritize, and add comments, which would be mailed to the user, and anyone else in the cclist.
The important thing:
- *** Make the queue publically viewable ***
This way everyone sees what issues are afoot, without having to ask, or walk over to the sysadmin department. For a large company, this is important, as systems can easily become a 'hang out area' where people would bottle neck and commiserate, preventing the admins from getting work done.By letting everyone see right away how busy things are, they can prioritize on the fly. You can browbeat people who make everything unreasonably 'high priority', and prioritize them down. Go to their managers if they're being persistent, so you can find out if things are really as important as the user makes it sound.
As the report grows longer than humanly manageable, which is inevitable, use it as documentation to the supervisors as proof you need more staff. It can also be used to show how many issues you (or your department) resolve per day.
This way, everything goes through the queue; data is entered by the users (so you don't have to do the paperwork for them, ie. a white board), and people can record problems as soon as they're encountered, complete with email feedback. Everyone at the company can see the queue at all times. Even remote users can file requests.
Prevents unnecessary confrontations, phone calls, and 'hanging out' near the sysadmin offices, letting the admins keep busy, and prevents things from falling through cracks.
When items are resolved, they go into an archive, which can be searchable via a simple regex search form.
I implemented this all back in 1996 with a few perl scripts for the systems department (of which I was not a member; I was a systems programmer), and ascii only files (one file per request) which were key:value files, and were easily grepable and fixable, and were part of the daily backups, so nothing could get lost, and database problems could be fixed easily.
I believe the system is still in use today at that company (though I've long since left), with the same name I gave the tool (the 'ASAP' system).
It worked well.. so well, other departments wanted me to make them one too, which I did for them easily enough. As it turns out, many departments have similar needs for such a system, where they are basically a 'problems in/solutions out' based department.
HTH.
As far as my experience is concerned, it's pretty easy to tell the client 'hey, I'm going to be "x amount of time" late.'
The hard part comes when it's your boss wanting you to write some sql to falsify client records, thus falsely billing the client about 80k/mo.
I told my boss no and I got fired. But the client still loves me.
Take what you can get, I guess....
More on topic, the client should always realise that you work under a certain schedule -- a development schedule. This is the schedule you should have submitted to them previously. It includes about two weeks extra to finish the project. Even with this, you won't finish on time -- you'll still be finding bugs, assuming you test your app properly. Make your finish date two weeks earlier and I'll gaurantee you'll find fewer bugs (doesn't mean they won't be there....)
No boss could make me work this long, with such little pay. I doubt I'll ever learn to tell myself "no" at 4am a terminal in front of me.
40 hours a week!? Productive for 30% of that!? You panzy. I have worked 40 hours in two days on many occasions. (Yes, I also have a "real" job.)
You can't judge a book by the way it wears its hair.
When asked to help, reply, "Sure, let me give you my card." Hand them business cards with twice the hourly rate you would want printed on them (say $50/hr). To stay the good guy, mention that you give friends and relatives and relatives of friends half off.
Then, if you get work, you are at least getting a decent rate. Also, you might accidently establish a nice profitable side business.
If you still get more work than you want, subcontract with some unemployed computer science graduates. (Or tech savvy high school students, after all, most home computer problems are pretty simple.)
I've read a lot of interesting answers here about what you should do. I'd say go fot it. Anyway some software could help you. I tried MS Project for this but it was not exactly what I wanted. Now I'm using: Request Tracker
It allows requests by mail and keeps customers updated of changed jobs. Separate jobs per areas, change priorities, assign jobs to people, and many other features.RT is an enterprise-grade ticketing system which enables a group of people to intelligently and efficiently manage tasks, issues, and requests submitted by a community of users.RT manages key tasks such as the identification, prioritization, assignment, resolution and notification required by enterprise-critical applications including project management, help desk, NOC ticketing, CRM and software development.
I've been using this in a small shop with 5 workers and it helped us a lot. It also is used in way big places and Fortune500s. And I think it could be used in one-man places.
A thing a like a lot is it allows the customers send you the requests by mail. If you manage to make them get used to it you have a lot of work done.
It took me a weekend to install it and test it and it was worth it.
don't "underestimate" this advice!
Yes; this is good advice.
Saying no is usually a bad idea and practically impossible irl with more senior personnel,managers, directors. No, creates bad feeling on the part of the rejected requester. It is much better to help them understand their request in context. You should seek to priorities this workload into what is Urgent and what is Important. Many things that are urgent, are not important, and many things that are important are not urgent. Understand the distiction and work it, Always address the Important tasks first. Distribute the prioties, more often than not people can understand why their task is lower priority. If not let the two competing requesters battle it out themselves, it also keeps you out of the politics, and conserves your energy for the task in hand.
Years behind schedules and overworked?
:-)
Demand funds to hire more people, join an labor union, or quit. Or just work your quota, that is what you're paid for. If they're not paying you to do miracles, then don't.
It's common to slave-drive admins. Where I work at they absolutely don't pay for overtime, yet they expect all system upgrade to be done at nights. No, we can't come to work at nights, we have to be at office all office hours and help the computer illiterate use their computers
I only tolerate it because I like the work. (luckily most people either know how to use unix or don't use unix, so I'm not terribly bogged down during the days.. viva linux/unix..)
Don't tell people "no" -- it's not what they want to hear, and even if they accept it, they're going to be far less than impressed with you.
Rather, if there are tradeoffs involved, then tell your boss what the options are. Often, PHB's don't understand that software development/ IT/ etc isn't like digging a hole: you can always dig a hole faster, given sufficient incentive (a levelled gun, for instance). But computing doesn't work way. There are whole branches of software engineering devoted to just that principle.
For instance: in a five-day period, you may be able to:
Do your research. Find out what resources are required for x, y and z. How long does an upgrade take? How much time is spent configuring new routers? Tabulate your findings, and present them to management -- and let them work out how to say 'no' to their bosses.
And best of all -- if you do that, you're the good guy who had the initiative to do the research in the first place.
At the .com where my wife works, she says the sysadmin schedules everything methodically. I understand he is up to about 2009.
What part of NO don't you understand???
We had this problem at work ourselves. What we did was simple - we installed bugzilla.
Every person can then just submit a bug-report of what they want you to do, and you can decide for yourself in what priority this comes. It will also visualize quite well for the other staff what kind of stuff you are working on, and they will also receive an confirmation when you're done or have rescheduled your plans. It's been my experience that people will generally show alot more patience when they receive written confirmations instead of a yes and no.
All you need to do is give them a crash course in writing good bug-reports so that you don't end up in having "fix my computer" filling your screen.
=-kiOwA-> EOF
As soon as someone comes in to add more work to your queue and you know you can't do it. Just do this... List off all of your on-going projects sorted by priority. Then ask them which one they want you to bumb so that their request can be done. You can only do so much in one day without burning out.
I'm a PHB and I can tell you from experience that not all of us PHB's don't want to hear 'no'. I make it quite clear to everyone who works for me that they should communicate to me when things start to get out of hand with respect to workloads. Employees get far less productive when faced with a seemingly impossible mountain of things to do - because it gets discouraging.
The thing to do is have a frank conversation with your PHB and explain the facts surrounding the status of your department. Do not approach the problem in terms of how it affects you, per se, but rather about how it affects the company. It is perfectly okay to tell your PHB that you need help - even if only temporary - to get caught up.
I've often times hired a temp or a contractor for a few weeks to get things under control.
On the other side of the coin, I really hate it when employees bite off more than they can chew. Your PHB will not be impressed by you taking on a load of work that he KNOWS you cannot complete on your own. This is a common flaw in "new" employees - they desire to impress so much that they often times fall flat on their faces.
Most PHB's, myself included, are impressed by employees who know the limits of what they're capable of doing and know when to ask for help. It's better for the company and better for the employees.
The most important thing is to simply be honest. Don't try to snow anybody and you'll be just fine.
Maybe a little offtopic, but it may be illustrative to view it from a consulting (read expensive hourly) perspective.
I used to work in consulting doing enterprise implimentations of supply chain software systems as both consultant (programmer) and project manager.
Two of the huge issues were always budget (not spending too much (working too much as we were hourly)) and time (getting everything done on time).
If the clients (boss) asked us to provide extra functionality or wanted to change the design of something after it was complete, it would cause both time and budget delays. At the time of request for a change we would actually provide a quote with the cost in both time and money and have them (literally) sign off on it. This way after 6 months of overruns, we could point to their decisions along the way. My company would actually provide "combat pay" to consultants who billed a lot so there actually would be compensation for those that worked the insane hours (and put in the extra time to come in at 5AM to check the cron jobs).
Getting back to the point, I think the important thing is to tie or limit your employer to the amount of overtime that you put in and to begin to keep track of your hours. You could maybe look to 'industry standard' numbers for how much you should be expected to work. Of course, if your boss is a true a**hole, this may not be too easy. At a minimum though, you can demonstrate how they are not living up to their commitments or you can show how you are going the extra mile. The alternative is to leave, which as people pointed out, makes sense to do *after* finding a different job.
BTW, I definitely don't recommend the consulting job I mentioned above. 5 days a week on the road is no long term lifestyle that I would recommend to anyone and you will (and should) eventually burn out.
Hunger is the best sauce.
In this industry, everybody knows one another, one way or another. There simply is no room for doing a bad job - it will stick to you and your reputation.
With that in mind, I stick to doing things really well, or not doing them at all. I never take on so much that I don't have time to do a good or great job at my tasks. The fascinating thing is that people respect that reason for me to say no - at first they question why I can't do something, but when I say that I wouldn't be able to do other things well and that I take pride in delivering excellence and won't deliver at all short of that, then they understand.
And you know what? I'm not known for saying no, I'm known for delivering with consistently high quality. That's how I hope to keep it, and that's why I take the pain of saying no sometimes.
Take a tip from the medical world: When everything is an emergency, nothing is an emergency. Get some books on time management, read a few and get an idea of the processes. Then have a chat with your boss about how you can create a schedule and set project priorities to make the most of your time for the benefit of the company. There will be times when you have to leave a couple of people bleeding in the waiting room, shrieking loudly, in order to keep a larger number of people alive. So what.
First of all, you need the authority to say "no, that was denied" or "not now, but you are on the schedule after ___", and they need to back you up in your decisions. If you are constantly being pulled off important project "A" to take care of a minor thing for someone else, it's not efficient. If people learn they can go over your head to get their pet project done, it's not efficient.
You also need to make a list of undone tasks and prioritize them: what is "mission critical" and has to be done real soon before the wheels fall off, what must be done at regular intervals to keep things running smoothly, and what are the "we would like this" projects that can be postponed. Also track the number of "emergency" fixes you are doing ... if they have a pattern, go upstream and prevent them with a training class, an upgrade, or whatever it takes.
You need a couple of "superusers" ... people who are willing to help out their department with the minor stuff. The definition of "minor" varies, but usually these people reboot servers, install software, and are the first point of contact for problems with software used in the department. You might need to have a couple of training classes to teach people to take care of the repeated minor problems (and post the how-to's and FAQs on the company website).
You need to have a meeting, with everyone, explaining the situation, the priorities, and how things are going to be handled. If you lay the problem out, show the project list, and explain that there is a plan to take care of the business-critical stuff, then the rest, in a rational order, most people will act rationally about it (those that don't should be referred up the line to whoever outranks them for a whack upside the chops). Follow up with a publically available list of the projects (a spreadsheet on the web works well) and a running total of your progress and interruptions. When people can SEE your workload, they take it more seriously.
Set up a formal way to submit and answer work requests: there are some free ones available. Make it a policy that people have to formally get themselves on the list, or submit a request on the spot before you do the fix ... that "while you are here" stuff chews up resources.
Set aside one block of time a week for the "nuisance" stuff, like tweaks to user machines, ... If people see you working on it regularly they will be more patient.
Consider outsourcing some projects if your load of true emergency fixes is so high you won't get to them, and if they are really needed.
Clients do not like to hear "No" *From me* because it takes the power out of their hands and puts it in the hands of a nobody like me. It's all about who is boss and it's a ridiculous game.
My solution: never say no.
What I do is say, "it'll take "X" number of man hours and will cost you "X". If they want to pay for it, then we're better off and making money, if they balk at the time or price involved, they're essentially telling themselves "No" and I'm not the bad guy.
I think this is the standard way of dealing with it. Frankly the more programming work I do the more I realize that anything can be done, so "No that can't be done" is a lie.
The only true "No" is if you have to tell the client that you can't realistically build "X" in 4 weeks. Either way though, the ball is back in the client's court.
Of course there is one more important factor in this equation. Stupid idiot managers who say "yes" to ANYTHING.
"Can you build the jupiter lander's software by tomorrow?" "YES! of course we can!".
Stupid managers do this because they are stupid and have no idea that it's a shot in the head. They think that developers say "No" just for fun or something. They never realize that developers are intelligent and have experience in creating realistic deadlines.
whew... end of rant.
So in order for you to dissuade a client from giving you more work, you need a client who is tight with time or money and a manager who understands the development process and is willing to back up the opinions of his expert staff.
The price we pay for immortality... is death. Narnia The Great Fall
When working for a customer, you're job is not to say no (unless the request is unethical). You're pay to provides options and then a chosen solution. That said, you have a heavy obligation up front to ensure that you've expressed you 'professional' opinion on the problem, given a set of possible solutions, but in the end you only (and should only )get paid by the customer for doing what they requested.
It's a little different to say "no" when your job duties are not clearly defined. The boss can always say, "well, someone has to do it, and you're the only one here who knows how... that's what we pay you for!" Well, fact is, there are places that will pay *more* for that kinda work, and they should be made aware of that. If the work you're doing is really above & beyond your salary/etc., it should be easy to find a job that either pays what you're worth, or only gives you a set of assignments you're comfortable with (i.e. at a bigger company, where people are more careful about such things).
stuff |
Not that I'm always as successful as I'd like to be on this... but...
:) The suggestion of a regular problem tracking tool is good, just make sure it's low maintainance itself (there's a whole rant fighting to get out about that topic, but I think I'll defer that for Usenix hallway discussions...).
First, get a handle on what you're doing and for who. Then, keep the people you're juggling informed when they're being juggled... that way they own the scheduling problem instead of you.
To: CEO
Cc: Project Manager, Quality Manager, Other Manager
Subject: Upgrading Laptop
FYI: I won't be able to get your laptop upgrade done until Thursday, I've run into a problem with the network in the Project Bunnyslippers offices and 3 developers are twiddling their thumbs until it's fixed, and Other Manager's printing problem is holding up the ISO9000 reports...
[etc]
Let me know if I should defer something else instead.
Thanks in advance...
-- Peon.
Just make sure you really DO have a handle on what's going on.
Get yourself a computerised help desk for submitting requests, enforce its use such that all requests must be submitted through this form, and make sure that there is a clear understanding of the priorities that a user can assign, along with expected resolution times.
Mark down any "unreasonable" and other geniunely non-urgent requests to the lowest priority. If they are truly urgent, there will be some haggling to raise the priority. It should be understood that low priority calls will not be resolved until such time as the queue for P1 and P2 calls is either empty or under control. Alternatively, the SLA could indicate that P3 call closure is of the order of days rather than hours.
This shakes down the real priorities, and also sets user expectations. One can further mandate that raising a call's priority requires managerial approval.
So it's not a question of saying no, but of establishing the priority of the call per a recognised Service Level Agreement.
Try not to explicitly say "no" or "i'm not doing that" if possible. If it's something that wouldn't make sense to do or would end up in more work later, explain that to them, but try not to make it sound like arguing.
All project requests in our company are required to have a payback value, this is a dollar amount that the user believes will be saved by the project. This way we can point to other projects we are looking at and give the user a reason why we are saying yes or no to them.
We use the payback not only for rating what project we will be working on next but also for validating the work we are performing. It's nice to be able to add up those paybacks and say the IT department saved the company $XXX last year.
We also use project tracking sheets that show a time line of everything we are doing, this makes a great visual tool that a non-techie can understand.
While i was far from the only IT person, I was the only IT person to support one product at a LARGE world wide company, and for the whole state that the main office was at, I used remote control heavily. :)
I had so much work to do when I started i thought it would never end, but when I started remoting the machine (either that or ALOT of footwork) I got everything so caught up a year after i started i was able to come in at 10am and leave at 2pm for the day
remote the servers, remote the users, VNC would work, but we used a package I was also able to push software and updates to the users. I got to where I Was playing more games than I was working.
but then clinton happened and the job world started to suck.
We have seen that living things are too improbable and too beautifully "designed" to have come into existence by chance.
Personally, I equate IT professionals with doctors and lawyers- we're all professionals who deal with complex systems that everybody needs but few understand.
Put yourself in a customer's shoes. If you went to a doctor or lawyer with a problem, under what circumstances would it be OK to hear "No"?
Thanks for the great story, and dead on to boot. Upper management types are usually not planners per-se, they are *negotiators*, and unless you find a way to push back you're going to get fsck'd.
stirring the pot since nineteen mumblty mumble...
Working with customers in IT is like parenting teenagers. The parallels are striking --- having never had to do the work you do they are experts at it; they have a sense of entitlement; they will still cry to momma occasionally. The list could go on and on...
So go to the library and get books on parenting teenagers.
One other tip: re-direction is a powerful ally. When in-hourse customer comes up with a request -- redirect them to something which fits your time budget and still somewhat meets their needs. Explain it to them like a company car; all the sales people want Jag's, Boxsters etc -- the company bean counters want used Yugo's -- that's why the sales folks drive mid-line Ford and GM. IT support is the same way --try not to say "NO" but instead "No, but how about ____________".
The first time a dumb-ass sales guy asked me for something stupid, I told him, "There's no way in hell that you are getting that from me, and if you have YOUR boss ask me, I'll tell him the same damn thing." Well, he had his boss ask me, I told him the same damn thing, and then my boss visited my office.
He asked why I was being "difficult," and I explained to him that there are plenty of printers that are shared, and every sales guy doesn't need his own fucking printer.
It's amazing to me that this approach doesn't work for you. Just tell them "NO."
-- "Bother," said Pooh, as he chambered another round.
My experience has been that making your software package flexible and extensible by the user themselves is the best way to say "no".
Rather than arguing with users about whether a given report should be added to the feature list, simply allow users to write their own reports. That way, when they propose a crazy idea that would waste a ton of time and be of no benefit to anyone else, simply tell them that it is a wonderful idea and here is how they could implement it.
When that isn't an option, I've found the best way to scare off internal clients is to be eager to take on the project, because it presents "unique challenges" unlike the "boring simple stuff" that is already behind schedule.
Jus say that when someone says something you can't/don't want to do. Most people in the company will probably be bowled over or be sick of hearing you tell them that for the tenth time and you'll eventually get caught up on work.
Or you could just totally confuse them with a bunch of jargon technobabble that makes things sound even worse than they are.
Trolls lurk everywhere. Mod them down.
If you want to give them an answer they will accept, you have to listen to your answer from their point of view.
I've lost count of the number of people that suggested to list off all the other things you have to do. Do your customers REALLY care what you're doing for someone else? Of course not. Don't do that. For most of them, it won't help, and may make them think you're doing work for everyone except them. They may leave you alone, but you'll leave them with a sour taste in their mouth.
Next look at who the people are that are making the requests. If you are working for a large company, then you should only be recieving requests from department heads. If Cindy over in accounting is calling you because her mouse cord is tangled, this is #1 wasting your time and #2 is hiding her incompetance from her manager. If the managers realized all the frivilous requests being made of the I.T. department, most of them would put a stop to it on their end, and this really helps. Managers care not just because their people are wasting your time, but also because their people are probably being less productive until the request is completed because they have an excuse.
For requests that will take time to complete, you need to work up a request form. Give a master copy to all the department heads and tell them that if they need something from I.T. then they have to fill out the form. It won't be well-received initially, but they will get used to it after a week or two. Place lines for requestor, department, and description of request. DO NOT place a line for "urgency", because they'll all get marked "emergency". Instead, put a selection of why the request is there. Example: "Client Jepardy", "Client request", "Internal Request". That of course translates to urgency: high, medium, low. They know it, but there's no way to hide Jeff's inability to figure out his Start menu from losing a paying customer. This will help you prioritize your time, AND lets you show your managers that you are taking care of the things that matter most first. Don't do client requests until client jepardy stack is empty, etc. If your managers complain, you have an airtight case for hiring additional staff.
When (not if) people complain about their requests not getting completed, simply tell them that you have 7 "client jepardy" requests you are working on currently, and that you will take care of their request when those are handled. (and possibly when the "client requests" are handled too) Here you are not telling them that a specific someone else is getting service first, but instead that you are saving clients. No one will be able to hold that against you. Be sure you keep it "faceless" - don't tell them who the requests are for. If they still complain, (and they will) then be prepared to immediately forward them to your manager. One of his jobs is to run interferance for you when people from other departments are making unreasonable requests. Most of the time he will tell them to go take a hike. Sometimes he might call you and "escallate" an issue, but keep careful written account of these escallations for later in case he wants to know why a client request took so long or why a client jepardy issue just barely got done by deadline.
I work for the Department of Redundancy Department.
You practically answered your own question -- re-read the last line.
Anytime someone asks you to do something, say you're willing to do it if it can be fit within the budget, or if you can obtain more budget. Internal business customers will bug you to no end if you don't bill them -- they start thinking about whether they really need something when you charge them.
If you can't directly charge them for your services, figure out a way around that. You can't take on any more projects until you get more budget for it -- and that budget might include salary for a new hire, new equipment, new software... etc.
You see? You see? Your stupid minds! Stupid! Stupid!
My sole responsibility is to my patients, first and foremost. Some corporate management types have attempted to apply a customer service model to medicine, but it's not a good fit. The patient is my customer, and my supervisor (that would be my department director) is there to resolve problems and put out fires. Customer satisfaction is A goal, but it's not THE goal...
I have the luxury of being in a profession where I am not beholden to any corporate masters... my license to practice medicine is MINE, and hard-won it was. I practice good medicine, guided by my ethics and professional obligations to follow the standard of care. My patients come to me for that and NOTHING ELSE, and by God, they get it (though sometimes that's not exactly what they wanted... read on)
That doesn't mean everyone leaves satisfied. As a point of fact, some are very DISsatisfied. Many patients, either from having an unspoken agenda, unrealistic expectations, or fancy some illicit narcotic diversion, DO NOT leave satisified. The first two types of patients are best dealt with by thorough, insightful history-taking, and education. The latter, however, are often angry, belligerent, and threatening (can't count the number of times I've been threatened)... but that's what happens when manipulative narcotic-seekers don't get their fix. Want an even better example? Try giving one some Narcan (extremely effective narcotic antidote) when they come in OD'd with respiratory depression... they're on their feet in a matter of minutes screaming at you for taking their high away... there's gratitude for you.
It's worth remembering that some customers will NEVER be satisfied, no matter what you do. Learn to spot these types and AVOID THEM... don't waste your time. Fulfill the letter of your obligation to them and move on... either that or charge them enough to make it worth the hassle.
Also, on the topic of saying "No," I've had to do it myself. I used to work at a place where the ER was not sufficiently staffed (ie. not enough docs). Those of us that were there were running our asses off, and seeing way too many patients. Now, the sweet spot, according to our college, is about 2.5 patients per hour. Now, that number will go up or down depending on how sick the patients are... I've seen six or more per hour when they are not sick... I've spent more than an hour with a single patient when profoundly critically ill. I had to stop working at that hospital... they kept calling me, and I had to tell the director no, because I felt like I was practicing outside my margin of safety. No is important... particularly when it's the right thing to do.
Anyway, good luck with your job... saying No is a major step, but you need to be able to do it. You owe it to your mental health.
Even if a man chops off your hand with a sword, you still have two nice, sharp bones to stick in his eyes.
Basically all the advice given so far is bang on.
I have found that the best way of refusing more work is to do 4 things:
1) The best method is just speak to your boss who should be aware of what you are already doing and get him to refuse anything you don't want to do.
2) Failing that do your best to force the person requesting the work to describe exactly what they want doing down to the smallest detail. This should cause them to do a lot of work and make sure they understand exactly what they are asking for. Often they will decide it's not quite so urgent as soon as it looks like they might have to do something themselves.
3) Give a timescale for the work but be sure to give a figure at least 2 or 3 times longer than you really think it will take.
4) Show the requester your timetable of work and ask them to speak to everyone else in the queue before them if they want the work done faster or urgently, you will need an agreement from all of them that it is OK to fasttrack this persons project.
To summarise simply make it as hard as possible for anyone to get anything out of you and make them jump through as many hoops and navigate as much red tape as you can invent before you tie yourself down to a definate yes or no.
This isn't just bloody minded vindictiveness because your work is your responsibility and you will always need to make sure everything you are doing is justified and be able to back up your decisions with evidence so all you need to do is make sure people provide you with good written reasons why there project should take priority over someone elses and have written agreements from the owners of all the other projects.
First, talk to your boss. Tell him that you're overtasked, and that he has one month to hire a lower-level admin for you to dump on. In the meanwhile, start interviewing elsewhere, and make sure that your boss knows you are doing so. Accept a job offer just before the big day. If there isn't someone else hired by that date, resign. There will be a peon working under you shortly.
But if you don't have the balls to do that, then just say no. If you lose your job for saying no, it probably wasn't a good job anyway.
My examples (All true):
- No, I won't fix your Outlook configuration because you were being an idiot an fucked it up. Why not? What would be a better use of my time- fixing your Outlook problems, or going to Monster and getting a job where I don't have to deal with them.
- No, I won't build any more Active Directory networks. It's too complicated, too stressful, and I'm not going to waste a ton of time learning AD when I know how to manage Windows systems using Samba without all the headaches.
- No, I can't get the email system working any faster, because you were being a prick and bought a crappy firewall/proxy appliance instead of letting me set up a linux box, and it's fucking up the ESMTP sessions.
- No, I won't come in this weekend to work on this project. I'm not management, and the managers are the idiots who let it get a year behind schedule, and nothing is worth giving up weekends to spend more time working on these computers.
- No, I won't help you with Project Y, because I still have an eight-page to-do list for Project X.
You're a sysadmin, not a carpet. Don't be such a pussy, and if your job sucks, leave.
Remember, your in the 'service' industry now, not the IT industry. (Do you think that kid selling you a cheeseburger is in the 'culinary' business?) Your real job is to keep your customers from whining at management. The last thing you want is your customers complaining that you've made them unahppy.
Your job is to keep the customers happy and off the backs of management. That's not exactly the same thing as catching up on all those lingering IT issues. In all likelihood, your customers won't notice any of that, but they'll still be ticked off because you haven't responded to their request to fix their own little annoyance.
If a customer's request can't be handled without dealing with a larger IT issue, explain that to your customer. If there's a workaround, use it. If not, move on. If the fix requires more money, let the customer do the asking. After all, if they can't do their job because management won't spend money, it's their problem. If it turns out that they're asking you for something that's not job related, your boss ought to be happy you said 'no'.
Never, ever, tell a customer 'no' and walk away without providing an explanation. It's part of your job to explain things in a way that non-techies can understand, but, even id they don't, you've protected yourslef from being labelled 'arbitrary' and 'rude'.
-- Slashdot: When Public Access TV Says "No"
I totally agree about having processes, what I said was "project management software does not do it for me".
What we do in our company is to move to an 'operational' model (in which planning is easy) as fast as possible. But it's only possible in a mature game, where estimates make some kind of sense.
E.g. if installing a new PC takes 2 hours, it is totally OK to plan an installation of 100 PCs. But if fixing one bug takes 2 hours, no way can you schedule fixing 100 bugs on that basis.
Software development (as compared to operational maintenance) is inherently chaotic not because of the lack of process but because small unmeasured factors (such as the relative skill of perhaps just one person) can have huge impacts on the cost and time.
In my company, a software development firm, our processes are almost entirely driven by the need to manage this uncertainty and reduce it to the bare minimum.
Ceci n'est pas une signature
I've had to lean to tell the boss "no".
As in, NO, I'm not going to work until 2AM then show up at 8:30 the next morning.
NO, I'm not going to work 50 hours a week, including Saturday, when you won't give me any vacation time.
So much of that wears you down. This company I work for has continued to pile on contract comittments (meaning lots of routine user crap to do), AND continues to try to find other billable hours, with half the staff of before (two techs when there were four last year).
This means every day my task list is piled with stuff to do that I don't have a prayer of getting done in 10 hours, much less 8, even if I don't take a lunch break. And that's assuming a crisis doesn't arise for me to deal with.
Corporatism != Free Market
Just ask the users to prioritize all their requests into High, Medium, and Low so you know what to work on first.
They of course then give every request a priority of High, except for two requests they give Low which only will take 5 minutes to do anyway. And most of the requests are 'minor' (i.e. 'not so minor') changes to a project that is going live next week.
I just love that Waterfall Method, don't you? I just love being hit with several tons of water and being washed into the river of 'Time to go insane again!".
ask them to prioritize. One phrase that's saved me from insanity quite a bit is "There are only so many keystrokes in a day." This way they realize there really is an upper limit.
"It's here, but no one wants it." - The Sugar Speaker
I do it all the time. I'm on the boomerang. My bosses are too cautious as to how much work to give me. I work 40 hour weeks, and read every Slashdot article. Believe me, there are a ton of requests needed that get shot down around here.
Play God, and concentrate on getting as much done with high quality as possible. You'd be suprised at what a few hundred Unit Tests will do for you in terms of assuring quality, in the face of adverse conditions. I command a way higher salary because in the early days, I cut my teeth on never saying no. I am God!
You really are capable of doing so much more than you really think.
Also, it's a great excure for getting additional "boxen" at your desk. Okay, but I'll need the latest PC with 2 million Gigs of RAM, etc. (And a DVD burner.)
1. Depending on your manager, you might not be able to say 'no'. If that is the case, try to get the users to help themselves by setting up some contingencies. Set up some spare computers if someone pooches their workstation. It'll depend on what you have for your budget, but the general idea is to not have them orbiting your desk with nothing to do.
2. Seriously ask your boss how he/she intends to fit in your vacation time into your schedule. If you don't get an answer, you'll never have a vacation. If the boss has to "think about it", that equates to the boss thinking "maybe the problem will go away if I ignore it".
3. Also ask your boss about getting another person in. It is not unreasonable in a high IT maintenance environment to have a minimum of 2 persons for 100 employees, plus 1 IT person per each additional 100.
I hope you have some luck into getting some of these points covered. Otherwise, you'll be burnt out in less than a year.
Dear Ummagumma,
....
.... ....
.... Okay, now go make something up for them. Remember good management/bosses like presentations with bullets ... keep all the paragraphs to yourself (well) until you have a company policy statement the bosses/CIO/CTO want to sign-on for good business reasons.
... [the end]
The first six (below example) clearly support the users and enterprise. The enterprise requires the first three (1, 2, 3) the users/bosses frequently do not notice; Therefor, in the offices (bosses and worker-bees') 4, 5, and 6 will win more friends and influence people. Expect IT/IM/IS/TA folks that exclusively support the top priorities (1, 2, 3) for an enterprise to be invisible to bosses/management until there is a crippling problem and/or financial problems that require cutbacks (payrole) in the business.
Also, as implied, there is a high probability that an X-Helpdesk all-knowing guru will be your boss, because they made friends in the offices that could influence promotions.
Build a Support Priority-List (SPL):
Priority-1: Critical Services Systems Crash/Lockup/Outage/....
Example: External/Internal Enterprise Communications and Process Systems
Priority-2: Critical Systems Software a/o Hardware presenting anomalies
Example: H.323 VTC Application (Voice, No Video) a/o Thrashing Ethernet card.
Priority-3: Critical Systems Security (Internal/External) for folks and things.
Example: Business/Network Access Control, IDS, Forensic, HW/SW Config/Update.
Priority-4: Nice to have, but not needed, required, critical,
Example: Desktop media player problems, MSOS killed blue-gun in the CRT,
Priority-5: All office administrators, Whoever hires/fires or is their pet-rock.
Example: Secretary, Admin Assistant, Their Boss, The Boss's gopher(yes-head).
Priority-6: Setup automated "Helpdesk" ticket system for enterprise support.
Example: None Needed, This should already be a fact.
Priority-7: Always collaborate with company folks on initial creation of an SPL, keep it current stuff always changes, include management in setting priorities, have them sign-off as if/on company policy now controls your actions. This allows you to say (?no?) yes for when it fits within the company priorities, mission, policy,
Present SPL to management/CIO/CTO for edit/recommendations of what systems, devices, services, items should be at which priority. Sometimes IT/TA is not aware of the critical business relationships of everything involved for the enterprise. An enterprise subordinate (internal) "Helpdesk" [present to local director/boss] has a much more narrow focus to the office/division local users and services, no control/responsibility of external communications and/or enterprise systems/services.
Rather than bore y'all further
OldHawk777
Reality is a self-induced hallucination.
Unaccountable leaders are masters, and unrepresented people are slaves. How do US and EU fare?
Many of the replies are good. One tiny detail that appears not to have been mentioned is that the departmental budget is usually calculated ones a year. Changing a budget implies that the person that created that budget did not know what they where doing.
Find out who is responsible for your departmental budget and when the budgets are made. Make a detailed budget of your own including cost/benefit ratios with accents on the areas where costs can be cut (If any). Forward this to the person responsable for your departmental budget. Wait and see what happens.
If the person responsible for your departmental budget is not reasonable, then I recommend you start looking for a new job. It is better to resign over budget difficulties than to get fired because of sloppy work due to an excessive work load. This can prevent you from getting a new job later on.
Watch out for companies where the IT department is the responsability of the financial department.
A little bit of knowledge can be a dangerous thing, especially at budgetting time.
If you are in a windows shop, you are way understaffed for what you do. If you are in a unix shop, you are still understaffed.
What I try to do is:
Fix broken things that cause the most problem for the most people (or will cause the most monitary loss) first
Fix "quickie" problems next
New things for the most people
One day a week (or a half day) do those routine things that affect everyone, virus updates, IDS updates, patches, yada yada yada.
Try to keep reserve time in the morning and afternoon for high priority things that aren't schedueled, but don't tell people that's what you are doing or it will become the catchall time everyone ratpacks you.
Seriously consider that you've gotten an impossible mission here. Sounds like your employer isn't serious about taking care of the IT workload because they see it as an expense with no return. Point out that while you don't normally make or break any one thing, the IT department makes every one else more effeciant and that by properly funding and staffing IT they will save money or gain effeciency everywhere else, thus saving money everywhere else. Have situations where you can show them with in their own shop that what you've done saved money, or allowed something to be done faster. One good way to do this is to enlist others on your side.
Pick out a person who is not too good with computers, but does something that has very concrete and positive results for the company. Adopt that person, and make sure they get what they need. Ask them to help you make your case to management after a while.
Remember, it's only a job. While IT people as a class normally will do insane things to make sure everything works, take care of yourself too. After all, you were looking for a job when you found this one, and I bet the last person quit/was fired due to burnout.
Necessity is the plea for every infringement of human freedom. It is the argument of tyrants; it is the creed of slaves.
There are more than a few readers of slashdot who are students who may not have much real world work experience, so lets' just say that this is REALLY good advice.
Keeping a written record consists not just of keeping any written documents that come your way, but also keeping good notes on any conversation, etc. Remember, you may not be able to prove certain conversations, but they are useful in many ways besides that: You have a good chronological record for your own purposes; an outside party judging a situation may, all other factors equal, be more impressed with somebody who can explain well a series of events.
When you've judged a situation, you may want to gain a few allies. If your boss is an asshole, he's made other enemies and these people MAY back you up if it comes to it, but remember that these people have their own agendas, so don't get too roped up in them.
Another good thing is to know your bosses weaknesses. Be careful how you handle that... I'm not suggesting blackmail or anything illegal or that would screw up your career. I'm just saying if your boss realizes he's in a vulnerable situation, he can be the one walking on eggshells, not you.
Make sure you realize the dynamics of any job. In my case, I was working on a project involving taxpayer money. That's not the same as working in a private office environment.
Also, if you complain about your job, know which of your friends can't keep their mouth shut. Few people can keep a secret.
And remember, offense is not always a good defense. You have to protect yourself but you don't always have to do more than that.
unless youre a CTO, Director, or someone that manages lots of people/projects, you should be turning to your boss for shielding for this.
you simply tell them their request will end up on the list and make them go away, then you make your boss prioritize your workload and/or tell these people that their request isnt worth anyone's time and effort and doesnt fit into the budget.
IF your boss is not fulfilling this role, then he is a crappy boss (cowardly) and shouldnt be managing things like this. I would begin looking for other work if I were you, since this situation wont get any better and you will stay miserable
if your boss IS capable of handling this, then maybe you are not conveying to him that you feel your workload is getting to be overbearing because of these kinds of requests. maybe he thinks you are just a go-getter workaholic type.
this is really a major function of bosses, try to use it!
A year spent in artificial intelligence is enough to make one believe in God.
The reason you're in this fix is I gather that your company has no policy on IT response. This means your boss is probably spending a lot of what little money you have on things that are making nimrods happy and doing nothing else to get the company where it needs to be.
Get a policy written, in place, published, and live by it.
It should define what is critical to the companys' success as a critical system (payroll and accounting, for example). These become your priority responses. It should also designate a chargeback to the department that asks for projects. If a salesmans' manager wants a color laserprinter in each office instead of sharing a single inkjet on the net, that managers' budget should pay for it, not yours (when he sees the projected bill it'll wake up even a PHB). It sounds like the departments in your company are using you for a "candy store" to raid for stuff that won't be held against them in their budgetary reviews. Your budget should only be for non-departmental items like network items.
In addition, you should be using a system that tracks work by user and department, write one in access or buy one (I like TRACKIT!, but it ain't cheap). Charge each item to each department, repair parts, new systems, your salary portion in hours it took to fix the problem (that IS a cost to the company). At budgeting time pull up the reports by department and user and find out who your problem children are. Your companies president SHOULD want to know who's draining off the dough, (or he's just staying long enough to sell his options and run before the deck falls).
Write the document you live by, document the work you did, charge the people that want it.
Your priorities should be the companies success, which I hope is your managers' priority. HE needs to make that clear to the rest of the company or HE will look bad when you work your butt off and get nowhere.
It doesn't matter what you wrap your emotions around, Reality is a brick wall specifically designed to scramble eggs
Having worked as both system administrator and as a developer my experience has been that most IT departments I've worked with are way on the other side of this problem. I've seen IT consistantly give our group computers with old 2 gig hard drives over a number of years despite the fact that our project didn't fit on a 2 gig hard drive (we told them this every time and every time we got a 2 gig anyway), a firewall where outgoing ftp was let through but not outgoing ssh (this is in a company that does a large amount of UNIX work, I might add), a password policy where we were under strict orders to not share our password (Good) and the root password for practically every machine was required to be enter (bad). I've even seen a technology college's campus where the students were not allowed to connect to any campus code development machines from outside of the computer labs themselves! This on a campus with not only a large commuter population, but also a large online learning program!
I am, as a result, proud to be a system administrator that says yes and makes it happen even if it means a lot of work. So be careful to strike a balance. (cue rattling chains) bewaaare it could be yooooou.....
Where is your manager in all of this? Why should you be the one saying "No"? That should be the job of the person you report to. If you have to say "No" or negotiate something, it shouldn't be with just anyone in the company who has a demand of you, it should be your boss, and your boss should be the one telling others "No".
If your manager is allowing or has allowed the situation to develop whereby anyone in the company can dump on you, then he or she is doing a very poor job. Likewise if the manager just dumps on you continually.
Dilbert and PBH aside, there are good managers in this world and they don't just dump work on their subordinates, they push back at the levels above them.
You don't have to be "regular army" and do only what you are told, but business organizations are arranged hierarchically for a reason. If people in your company aren't observing the hierarchy, they should be made to. If people are constantly coming to you with demands, unless they are your manager, you should be referring them to your manager.
totally agree
Set up a web site that contains your current work load and project list with estimated times. Allow people to see just how loaded you are and have a priority ranking system for all new work.
So, someone comes to you with a new assignment/request/demand. Review it with them and discuss the priority assignment. When they agree on the priority then you put it into the queue and give them a start date and an estimated end date. If you can do a good job of keeping to those dates then you'll have mostly happy customers.
The biggest problem/challenge in the support world is when things seem to "disappear into the black hole" and nothing happens. Sometimes it's because you forgot the request (someone stopped you in the hall to request something and you're busy on something else...) or just simply haven't been able to get to it yet. You'll also want to have a way to publicize emergency work (like patching for MS Blast and what not).
You may want to invest in some help desk software for tracking and scheduling as well. (This can also be used to build up FAQ's for your customers to do some self-help.)
--- I wish I could hear the soundtrack to my life. That way I'd know when to duck.
The most important thing you can do is make a detailed record of REAL man-hours worked. If you're hourly, do NOT lie on your time-card. If you're salary, turn in a weekly work report. Prove to your bosses that you are over-worked and need some help.
The unfortunante thing about salaried workers is that companies do not track exactly how much time they work. A lot of it is legal reasons -- they don't want a paper trail to prove they've been working their salaried, $25,000/year desktop techs 80 hours a week. Mostly, though, its just something that they don't want to deal with. So, it's your responsbility.
Of course, remember, while the squeaky wheel gets the oil, the squeaky wheel sometimes just gets replaced with a cheaper wheel. You need to weigh how much its worth to you to make a stand, and how likely it is for you to be replaced. Is your boss the kind of guy that would fire you at the drop of a hat and hire on someone else who's willing to work for $20k salary at 120 hrs a week?
Also, are you hourly? Are you lying on your timesheet? If you are, stop. If you do, you have no way of being able to prove the man-hours involved. Plus, you can be in just as much trouble from labor law violations as your employer. And, if they can you for it, you'll be a rich man.
Most of the advice in the responses have been sound:
- (Try to) document the cost of the new request (in actual time and money, opportunity cost, risk, etc.)
- Make sure management and/or the client acknowledges the cost and signs on to the choices.
The second tier problems I have encountered are:
1) Cost projections are estimates, and (especially in development environments) subjective. Your cost estimates will be challenged, and there will always be somebody around willing to ingratiate themselves by offering a lower estimate. Whether they are misguided or mistaken (or right!) is not always clear, but managers and/or clients generally pick the most optimistic answer from each column.
2) There are always overhead costs that can't be projected exactly in MS Office: time lost to unexpected events (server crashes, illnesses, screwups, whatever). You can make an informed guess, but people will be suspicious of a "fudge factor" and will discount it.
At the end of the day, people will string together the most optimistic assumptions (often mutually exclusive) and ask you to commit to it.
This is what got NASA to where it is today.
[Sorry for the pessimism; I guess I read this too early in the morning; I'm still on my first cup of coffee.]
Say yes. Give them a realistic time frame (length to complete) A realistic cost estimate A realistic start date Before you agree to do it, have this in writing, and make them sign off on it before work begins. Better yet, make them sign off on it X days/weeks BEFORE work begins.. and have that as a stipulation in the document they're signing. When they call back later asking when it will be done, refer them to their copy of this document. If you're running behind, let them know before the due date, they will be much more likely to understand than you calling them on the due date and telling them it'll be more time. last of all, manage your time! Here's a useful free (as in beer) tool to help: TaskPerfect
If you don't have a manager or people run roughshod over cost/resource allocation then start looking for a better place to work or adopt the attitude that you'll put in the hours your paid to work and no more. Don't kill yourself to make someone else's goals, especially if there's no benefit to you directly or indirectly (i.e. getting a bigwig's project done gets a favorable nod toward increased IT funding, thus adding resources to the dept.)
A feeling of having made the same mistake before: Deja Foobar
I never say no to a customer.
It's always:
This will affect the delivery of the project.
This will affect the project itself (decrease functionality).
This will require more resources (money, hardware, time).
Put it in some sort of writing and get a direct acknowledgement.
I have a special email folder for just this topic.
when you boss tells you "oh. keep your existing timetable untouched.. you can work on this project over the weekends..." :)
PS. I'm pointing this out because its happened to me.
- Tempestdata
.... is Mr Project. OSS for the Gnome environment.
We always take the approach of "Yes, but it will cost you". In other words, we explain the costs and difficulty associated with their requests. We never respond to the emotional tantrums of tough consumers, but instead, step back and look at what they are asking and figure out how to show them the difficulty (even impossibility) of the request. It works every time. We don't have to say no. A bad request will die on its own. Hope this helps.
Spec negotiation is another key. /.
Going from point A to point Z may take 60 hours but going from point A to point Y takes 2 hours the person making the request really only needs Y but does not realize the difference. Budget the 60 hours, negotiate point Y and surf
Tell them no, and then start on it and try to get it done before the person goes over your head and management, wanting to be everyones friend, says yes to it despite overwhelming odds (ie. so what if it involves interstellar travel - our department needs to look good) or without hearing your reasons for saying no (because that Mac software technically won't run on our Windows network).
That way you look like you can get things done in a hurry. Looks good come evaluation time.
You don't say "no" to the customer. You simply tell the customer how much the request will cost them. In your situation, you tell them how much their department will have to contribute to your budget.
In the rare cases where the task is not just difficult but in actual fact impossible, you simply alter the description until its merely hard and then tell them how much that will cost.
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
In all seriousness, it is perfectly ok to say no to the suits. I have found that saying "NO we won't do that and here's why" followed by a dumbed down explanation that is understandable given the individuals level of expertise or lack thereof, not only works but adds to your credibility. Also if the reason is budgetary don't be afraid to say so, you might end up with a few more shekels in your IT budget. "I told you so's" are also ok if done tactfully. Good Luck
Of all the things I've lost, I miss my mind the most. Or do I?
Service Level Agreement.
The SLA should specify how and when things are done. It should also classify work request priorities.
Put an SLA in place and have management sign off on it. When a request comes in, prioritize according to this. When the users come back and start bugging you, point them to the SLA and tell them that things are done in order according to the SLA. If they don't like it and complain to their manager or yours, inform management that they signed off on the SLA and that you're simply following the official policies already in place.
This would also allow you to get the most important issues resolved first, without having to worry about Sally in Accounting beyotching about her screensaver while you're trying to fix a server.
Cruising the internet on my TI-99/4A @ a whopping 300 baud!
"Here is my dilemma: I'm a relatively new employee (~2 months) at a software engineering shop. I am the sole IT person for a 100+ person company, with 50+ remote VPN users, 40+ developers, 30+ servers, firewalls, etc. I do it all, from desktop and application support, to security, to servers. In the past, the IT department has been seriously under-funded, and there is an absolute ton of catch-up work that needs to get done. At this point, I could work 70+ hour work weeks for a year, and still not be caught up, between project work, upgrade, documentation and day-to-day stuff.
I'm in nearly the same position. I'm an sys/net admin for a research lab at a university. I approach the issue in several ways. 1) a weekly 'open-items' meeting with my boss. 2) a clear statement of purpose 3) often detailed justifications for saying no and/or suggested alternatives.And 4) I keep track of requests that are made of me; if you find patterns or duplications then you might be able to centralize services.
for #1, it's been helpful for my boss to see what I go through. When I've been late with deliverables it's almost always because of exigent circumstances (for instance, 'blaster' has kept me quite busy...)
For #2, it's helpful, when faced with a request, to answer the question "how does it further research at the lab?" If it doesn't, then I just look at them until they go away...
For #3, when faced with a request for some service, I might say "no way, too insecure" or "here's what it costs. Here's why it isn't the solution for you. And here's the problems that other admins have run into." Usually, I'm able to suggest alternatives. For instance a user wanted to run an NFS server from his desktop linux box so that he could mount a share from his home (off-campus) linux machine. The issue was keeping his files in order: He wanted to keep one version of his files and one only and found that burning a zip drive or CD was causing trouble with revisions and such. I said no. Gave him all the technical reasons why it wasn't a good idea and suggested rsync + SSH. And he could do it all himself. Big win. Another user wanted a dual boot machine Windows and Linux. I said no. Told him why and suggested vmware. Another win and he did it himself. Be mindful that you are paid to be the expert and that your users will MORE OFTEN THAN NOT come to you with a solution they don't fully understand ill-fitted to a problem they don't full comprehend. If they understood both the problem space and the solution space well enough, you'd be out of a job.
For #4, I often have different people come and ask me for the same thing. Noticing patterns and eliminating duplications of effort will make your life, and theirs, immeasurably more satisfying.It can also serve to consolidate your base services and scope.
For your particular situation, I would also add that, in my experience, there is no such thing as an "underfunded IT shop". That is to say, if you have 30+ servers and 50+ VPN, etc, somebody has been footing the bill. It just hasn't been centralized in any meaningful way. I would undertake some sort of review to discover what surely must be rampant duplication of efforts and inefficient implementations...
Just do what you do best
Arnold "Red" Auerbach.
Force them to make the decision as to the use of your time. Simply, make them prioritize their own requests.
Ask things like, "is this more important than this other thing you asked me to work on? Which would you like me to work on first?" Say things like, "you understand, this will delay that other item, right?"
When they want both done simultaneously, against all laws of time and space, you must reason calmly for them. Because, chances are, they haven't reasoned out the impact of the request themselves. You must make it clear how this request will change the status of other outstanding request. You should make them tell you precisely what to do and gently tell them the downside of it.
If the person making the request fully understands the gain and loss of putting further strain on a resource, they can make the decision that will make them happiest.
Judging from the posts, the majority of posters on slashdot are modeled after Wally and not Dilbert...
From excellent karma to terible karma with a single +5 funny post...
"A) Give you more money.
B) Give you more time.
C) Expect less at delivery(cut-corners)
D) Withdraw their request"
The executive decision to "expect less" is generally forgotten within a few weeks. Whatever corner-cutting was acceptable when the request was on the table will result in (1) lengthy "bug-fixes" where we spend the time & money that was not supposed to be spent, or (2) new requests to build what was not delivered the first time.
Whenever I talk about option C, I explain that it is mostly management fantasy. In the long run, A,B, & D are the only real choices.
The only time option C comes into play is when you need to use the world of management fantasy to get a project off the ground. Getting a project launched takes an act of God, but the sky is the limit for finishing (or tweaking) a project that is already in progress.
One option that was not on the list is the concept of twisting the customer's request into something that is more feasible or can be combined with other similar requests so as to fit better into the big picture. Sure, it all comes back to options A, B, & D, but most oddball customer requests are simply one of many possible approaches to a problem. Drill down into the problem, and there is usually a reasonable solution to be found. If this is done poorly, the results are indistinguishable from corner-cutting. If done properly, the end result is better than anyone expected at a fraction of the cost.
Here's what happened to me at a well-known multi-billion dollar healthcare company.
:-)
:-)
I was asked to lead the development of a major application re-write that involved linking together multiple complex back-end systems, but was ordered to do so with my hands tied. I was given strict deadlines before any requirements analysis was started. About 6 months were allotted for requirements analysis, 3 months for coding, and 3 months for testing. My newly hired boss's boss (just under the CIO), dictated that strict SEI guidelines (setup by people totally unfamiliar with software development and new to the SEI process) had to be followed. Everything had to be written in Java. I (the most experienced programmer on the project) was not allowed to write any code. Absolutely no code could be written prior to the completion of all detailed (down to the function level) SEI documentation. Prototyping to find unknowns was considered unnecessary, a waste of time, and strictly forbidden.
The team consisted of a young inexperienced manager, her seasoned manager, two experienced programmers that had never programmed in java before, and a few inexperienced programmers. Even though I was the "technical architect" for the project, I was forced to take my technical direction from my Business Systems Architect (BSA). We called them bull sh** artists.
After the BSA wasted about 8 months spinning his wheels on technical decisions, the team's management was desperate to show some progress. I tried to negotiate with my management and the team's management to allow for some prototyping to get the project moving by discovering unknowns (best UI for the work, estimating best case performance, making sure that the glue layers would work, etc.). Management strongly believed that documenting everything first was the only way to go. My requests to be reassigned to another project were denied. Eventually I was reassigned to the unemployment lines.
About 1.5 years later, the young manager contacted me for a consulting position on release two of the same project (cleanup the mess and add more functionality). During the interview I was told that release one of the project was:
- about one year late into production
- even though the UI met the user's written requirements, the user's realized what they had asked for was not an efficient way to perform their work
- most of the technical documentation (about 3, three inch binders worth) was worthless, as major parts of the system required redesign and implementation after the system went into production, because the documented design did not work in the real world
- the system performance and stability was horrible and most of the team's time was now relegated to daily bug-fixing
Finally, she stated that they should have listened to me in the first place and that she was hoping I would take the consulting assignment to lead the next release. I quoted her an hourly rate. She told me that rates had plummeted due to the glut of IT workers now in the workplace and suggested that I match the rates of foreigners. I asked her to give me a rate she was comfortable with and that I would try to accommodate her request. I never heard from her again. All of my attempts to followup with her went unanswered.
This well-known healthcare company was in the news this past year. It lost over one billion dollars. Much of the loss was attributed to the many failed new systems it tried to hastily put in place. This company also recently announced that they planned to outsource much of their IT work to India to cut costs. Maybe they should consider outsourcing their management instead?
So the moral of the story is you can say no and actually be correct about your decision, but with today's clueless management, it may cost you your job. (Of course nowadays IT jobs often pay less than manual labor jobs, so maybe that's not a bad thing.) And now you know one of the reasons your healthcare costs are sky-rocketing.
Sorry buddy, I dont have time to respod your question right now on how to say No, I am too busy working on other things.
VBJonC
I'm a technology consultant with over 5 years of experience, this experience is split between work for companies owned by the same umbrella corporation, and companies that are entirely outside of our corporate infrastructure.
Don't assume that your boss, or the people giving you the work, know your situation. Never say no; that's not what you're paid for. But point out technology and resource limitations that make requests unreasonable. Phrase it in terms of impact. If someone asks you to do something, "Ok, I can do that... but requests x, y, and z have priority over that, so it'll be n [days|weeks|months] before I can get to it" Or suggest an alternative like "Sure, I could take that word document from HR and convert it to HTML... but did you know that Office can automatically save to HTML format now?"
The short of it is, it's their money and their time; they can choose to do what they want with you while you're on the clock. Just make sure that the decision makers are aware of your situation, and how their decisions impact the work that you do.
I am disrespectful to dirt! Can you see that I am serious?!
Our users are supposed to call the helpdesk first and get a call logged for them. In this way, it can be assigned even if their preferred service tech isn't around. Users have the annoying habit of calling techs (me and others) directly and asking for solutions to a problem. Well, I put a nice message on my Audix that reminds the users that they must call the helpdesk before I can even consider their issue. It actually tells them to 'hang up and call the helpdesk at x####.' This works nicely for me, and even if I do accidentally pick up a call like this, I tell them, "I'm sorry I can't help you until you place a helpdesk call. There is no guaruntee that I will be the one to whom the call is assigned. We have 1400 users to consider, and I can't put all of them on hold for one individual." At first, when I started doing this people thought I was rude, but now they've accepted it and I don't get user 'phone spammed' anymore. (At least not very often.) Users don't even leave me messages, they know they have to go through the 'desk.
Every now and then, we get some who think that they are the most important people in the company, and they usually try and give me a line like, "since you were the one who helped me last time, I thought I'd just call you." I always tell them no. Everytime. The helpdesk is meant to evenly distribute calls, and letting them call me directly doesn't work with the system. If they have to wait in line, that's their tough shit, there are lots of users who are just as anxious to get their issues resolved.
This sort of thing makes me feel like a pimp at times, although I know those feelings are unwarranted. My goal really is to help the users, even though they annoy the hell out of me at times.
Speak for yourself.
I have an almost identical situation here at work. I found a way to deal with the issue though. Hire a prviate investigator and get pictures of one of the higher-ups cheating on his wife.
;)
Then whenever you need to say no, do so, and tell the user if they have an issue they can take it up with that guy. He will defend you and your decision like a champ
-Sternn
Here is how I say 'no':
:)
Requester: I need you to load x on my y today.
Me: No.
With a variation of these to follow:
- poor planning on your part does not equate to an emergency on my part
- take a number (then I point to the handgrenade with the 'number 1' number attached to the pin)
- I am doing x, y, and z today - there is no time to accomplish your request until (searching through calendar), December 2003...
Now, if the request is a bonafide emergency (mailserver down, voicemail down, etc...something alot of people depend upon), then I will shuffle the priorities to make it happen. In all cases, something doesn't get done as a result - which I make quite clear to the requester:
Requester: The flux capacitor just went down and we don't know how to fix it! Help!
Me: Yes - the FC takes priority. However, this is going to delay that script you wanted to generate sales data by a day - is that acceptable to you?
Requester: Yes-yes! Just get the flux capacitor back on line!
Me: I need to have that in writing...
Lodragan Draoidh
The more you explain it, the more I don't understand it. - Mark Twain
I work in theater, as a designer, and one of the things that you never do is tell a client (director) "NO". However you do tell them what the particular idea will cost in terms of time and money and then let them try and convince the Producer to give us more money. That way, they understand what it will take to get the work done and they become insturmental the process of acomplishing the work.
I once worked for a company who had as the primary owner a man who believed nothing was impossible. Religious convictions notwithstanding (Yes, I believe with God all things are possible, but I also believe He often merely shows us the open door; we have to enter and find what we need.), the company motto was "Don't worry about why it happened, or why it didn't happen, Make It Happen." This being said, he would often tell clients 'Sure, no problem, we can do that.', when the reality was that we had no clue. He would then point to the motto and berate us at meetings because we didn't 'Make It Happen'.
Consequently, after a bit more than a few months, I grew weary of the 'Make It Happen' speeches (note: many things we were doing were along the lines of things like SNA connections to AS/400 boxes with NT Servers, or programming routers without instruction/training/knowledge). I found a job with a larger entity, and found that they, too, suffered from the 'we never say no' policy. Saying 'No' in a corporate environment is career suicide sometimes; other times it makes management take a step back.
I agree with most of the posters about documenting your time; it's absolutely vital, both from a standpoint of showing just why projects are behind, but also at review time, to prove you are a worthy asset. Documentation will often save your bacon.
In America today you can murder land for private profit. You can leave the corpse for all to see, and nobody calls the c
As other posters have alluded to, the most constructive answer is: "Sure we can do that, but it will take this much time and this much money". I was in your situation once and I dealt with it in a number of ways:
1, I had a white board, with days of the week and hours of the day in a matrix. I filled in available spots when people wanted work done. If someone complained, I invited them to find a free spot in the matrix and write their name in.
2, Make appointments with your users. That is, try and schedule the time required. I used to leave a bit of "fat" in there in case emergencies came up.
3, If somebody gives you a job that you think will take more time/effort than they think, send them and their boss an estimate and see if they still want to do it.
4, Try and put some sort of ticketing system in, where you can track who has been asking you what and how much time it took. The worst thing is to have no proof against people who complain about the service they are getting.
5, Try and build an infrastructure that requires next to no babysitting (easier said than done), which will free up more of your time to deal with one-off end user issues.
6, Send reports about what you have been up to to your boss and/or the big boss. It might get them on your side.
It's not really a matter of saying no, but more a case of managing expectations
Who is your supervisor. Does that person have any sway within the company? If yes, then have that person set your priorities. Go to that person with a list of projects and time frames, and ask them to set them.
If you are getting requests from 2 different groups, especially people who are at or above the level of your supervisor you will probably have to do it differently. Whether you or your supervisor do the following is dependant upon your relationship with him/her. I will assume that you can do the following.
Find an org chart. Find all of the people in the company that are requesting things from you. Go up that org chart until you hit a common supervisor for all of them. If that is the President/Owner so be it. Present your current list of projects, along with expected time frames. Have that person decide your priorities.
If you can't determine who in upper management should be doing this. Or they won't help you. Then there comes the final attempt. Get the various people to decide amongst themselves. State clearly that you are working an such and such an item for so and so. If the new person wants to get in line before the project you are on, then you will need approval from so and so.
Bottom line: It really isn't IT's responsibility to set company priority. Is the marketing project more important than the development project? It is inappropiate for an IT person to be deciding these things. Especially for someone as new on the job as you.
IT people make the mistake of trying to set company priority, and that is one of the reasons we are frequently viewed poorly outside the department.
Ok, I give up, why you?
the best way to say no is to say no
As the sole IT person, you're going to run into a lot of problems unless you make your work clearly visible and have it adequately scheduled.
First thing, confer with your boss, and try to schedule at least two weeks of where you're not implementing new things, but just doing maintenance.
During these two weeks, you should have meetings scheduled with every department to see what they have planned for IT needs for the next, say, four months. Check to see if they have any money budgeted to address these concerns as well.
Then get a meeting together with your boss, and then with the department heads to schedule and set priority for these tasks. Make a very clear schedule, and be sure to get some wiggle room in there.
When that's signed off, make sure you document everything that gets done, get it signed off when done, and document anything that impedes your completion of schedule. File weekly reports and make sure that every department head gets those.
The key is to make sure that they know what's going on. If they know that you're concretely busy doing work they've agreed on, they're less likely to come and try to change things. When things go wrong, they're likely to understand more, and maybe consider the IT budget more over time.
Anyway, enough rants from the Admin turned Project Manager.
The power of accurate observation is commonly called cynicism by those who have not got it. - G.B. Shaw
http://www.business2.com/articles/mag/0,1640,51816 ,00.html
Keep documentation on everything you do -- you want a detailed to-do list, and a log of what you've done already. When asked to do something new, send them the to-do list, and have them decide on the priority of this new item. Then it will be obvious what will get put on hold while doing this new task. Basically, just remove yourself from the prioritization decisions and let management manage your time. Then there will be no surprises when some things don't get done, and everything is documented, to cover your ass.
:P. And I suddenly had a lot of time to work on important things.
It will let your boss/client guage how busy you are, and after some time, get a feel for how long things take. Plus it makes them feel special - management likes to manage. They like to delegate responsibilities, and if you don't keep them informed of the delegations they've made already, and their consequences, they won't have to accept the management responsibilities that go along with delegation of tasks.
When I took this approach, management decided that nobody was allowed to make IT requests without clearing it with them first. They were quivering with power
Good luck!
"I am the sole IT person for a 100+ person company, with 50+ remote VPN users, 40+ developers, 30+ servers, firewalls, etc. I do it all, from desktop and application support, to security, to servers." Hmmmm, YOU are in charge of this department, hell you ARE the department. Set standards that make sense, and demand compliance. Your role as an IT manager should be to enforce reasonable standards compliance, for the good of the company, as well as for protection of its data. Understandably this can be a sticky situation when dealing with Upper management, owners, people with more weight to throw around than you, HOWEVER, they hired you to do a job, SO DO IT!!!
"Sheep just follow the easiest path and run from scary noises and intimidating creatures." - Me
Not possible without extra contract/money/time/younameit::
"That's an interessting problem. I'd say one would have to keep an eye on A, B and C, and probably redo D completely, but with an extra 4 weeks of time it shouldn't be to difficult. We could talk about that once I get this finished, or would you like me to stall the whole project and merge that requirement into it?"
Forget it/Quite impossible if we don't change your entire Appsever enviroment::
"That's a *really* good Idea. You know, there is a solution for this that [very expensive vendor] once did. I'm not shure about how and how well they managed to do it, but one would probably have to [technical detail A] and [technical detail B]. The problem is there is only [very expensive product] that claims to have an out-of-the-box solution for [technical detail C]. A real world solution for that is actually quite compley...[small pause]... But,you know, if we could manage to do that, that would actually be a marketable product. I mean, really. I would be totally unique."
We suffer more in our imagination than in reality. - Seneca
Saying no is not something easy, you can't really say 'no' point blank.
You need to be able to convey the idea of saying no, without really saying the word. Most of the time projects are denied in my IT world because of money. Yeah it's stupid, but with enough money you probably would be able to do just about anything, unless it's a really crazy idea.
Technology also needs to be able to come forward in order for certain projects to come through. My advice to you is simply to explain the situation and how their project cannot be done with the current budget/technology. Try to relate to another project that didn't go through because of the current projects. A project is never denied, rather always delayed to a later time.. like next year when a new budget will be available.
-my 2 cents
Put it on your todo list. Keep your todo list open and accessible. When people bark about something, move it up in priority on the list. If they never ask about it again, it'll stay at the bottom of the list and not get done.
Secession is the right of all sentient beings.
Everything they want you to do can be considered as a project. So treat it as a project. You need to require Scope, Resources, and Schedule for everything that you do. This will get your PHB's to start making choices on what to do based on the value to the business (or costs.)
Also, if you aren't using a system to document your work like Track-It, Vantive, Remedy, etc... you should get something. It will quantify how you spend your time and will make whomever can tell you want to do on your job realize they have to make choices. This will eventually take the load off you.
Once you start tracking your hours spent working on a particular type of problem whomever you report to will be much more receptive to the "Scope, Resource, Schedule" argument.
Success is the ability to go from failure to failure without losing your enthusiasm.........
Require it.
Require it to be well written.
Maintain consistency with it. Don't ever EVER let "because I said so" or "I've worked here longer than you" be a sufficient answer... EVER. (Even with the big boss, don't be afraid to push back a little bit, pointing out what other projects his request would be bumping.)
You'll find that about 25-35% of your requests will go away because people won't work for that peice that they really "need", and they'll survive just fine without it.
You then filter for noise ("DVD drive for travel purposes") saying "No" to the really easy ones.
What remains gets a dollar amount applied and passed on to your manager for approval.
Works for me.
Ask your boss: "You want me to deprioritize my current reports, until you advise a status upgrade?" and hope he doesn't always answer: "Make these your primary action items.".
Also, "You're not your job. You're not how much money you have in the bank. You're not the car you drive. You're not the contents of your wallet. You're not your fucking khakis. You're the all-singing, all-dancing crap of the world.".
I'd tell you more, but I'm not allowed to...
Graduate school is always an option.
This is what I'm planning on doing - I'm starting part-time classes next week, and likely going fulltime next semester.
retrorocket.o not found, launch anyway?
First, make them tell you what they really want, not what they want you to do. Getting an accurate description of the goal, rather than the process as they envision it, will let you suggest alternate methods to achieve the goal.
Second, don't tell them "no", tell them what it will take (or cost) to meet their goal. Break it down in terms of cost and benefit. Find ways to say "yes".
If you tell them that what they want will cost $40K, require about 200 hours of overtime over 4 months, and cost $15K per year to maintain, they may change their minds about whether they really need it. If you can show them a way to get what they really need (or progress in that direction), they may be willing to accept alternatives.
http://drteknikal.blogspot.com/
...and make sure you're paid hourly.
In my previous organisation they had a serious problem in that they were a small org that grw overnight (3 man to 25 strong). It then became difficult to support the 600 odd users in the same way as before. We were always running from one job to the next. couldn't say no. The way we worked it was to create an SLA (Service Level Agreement) with the company (each dept head) for our standard response to common events (and uncommon too). this way, once published we had a guarantee sticker that said, we dont have to do it now, but it will be done in XX hours.
"They locked up a man who wanted to rule the world, the fools, they locked up the wrong man! L.Cohen
Time estimage guidelines:
... 1.2^10 = about 6, so 10 x (1.2^10) = roughly 60 days = 12 weeks = 3 months.
New programmer fresh out of college: Take his estimate and multiply by 8x. Yes he could get it done in 1 day, assuming he got so cranked up on caffeine his eyes stopped blinking and he worked on that (and nothing else) for 24 hours straight. In the real world a newbie can dedicate about 2 real hours doing a particular task each day, the rest is spent coming up to speed on corporate coding standards and libraries, email, breaks, and not 'in the groove'.
Veteran programmer of average skill, single person project : multiply his estimate by 3x. A third of his day is spent hand-holding the newbie, and another third is spent hand-holding management. The other third is spent programming, but luckily he knows to pad the schedule some (not enough, but some.)
Veteran programmer of uber skill, single person project : multiply his estimate by 2x. This is as good as it gets. A uber veteran programmer knows to leave his email client closed and his door closed so he can stay in the zone. He knows to pad the schedule more than he really thinks he should. And it still takes him twice as long as he expected.
Multiple people working on the same project : increase the timeline by a factor of 1.2 per additional person. If two people ought to be able to do it in 10 days it will take 12. If 11 people (10 additional) ought to be able to do it in 10 days it will take
Glonoinha the MebiByte Slayer
You don't just need to be able to give good esitmates and keep a good central list of all help requests/projects, you need the tools to make your job manageable.
Listen, If your a Windows desktop shop, one of the things you can do to make your job more manageable is to deploy Novell Zenworks. Whether you are a Novell shop or not. (Future version will even support Linux desktops.)
Remote Control
Remote Diagnostics
Inventory
"Push/Pull" Software installations. (WOL support)
Workstation cloning with PXE support
I mean imagine deploying an application to all of your computer by creating a snapshot and telling it to deploy to all of them. Getting a report that it didn't deploy on one workstation and fixing that one remotely from your desk. Deploying new computers with by imaging them and pushing the necessary applications to them.
All of that frees your time for more complicated projects and creating the structure/documentation necessary to continue the process.
Good luck.
Just give everybody admin privileges and your job will be much easier.
word.
I have worked in similar conditions for the past 2.5 years.
I manage a network of 120 people, 14 servers, 2 VPNs to banks, 4000 external pop/smtp users... from firewalling to networking to helping an executive change his background picture... I do it all ALONE.
I have tried MANY times before to explain them the work I do can't be done by only one person... but after 2.5 years I realize that if they are stupid enuff for thinking 1 person can do that, they will be stupid enuff for not understanding my reasons.
That kind of employers are so, but SO dumb in nature, that it doesn't matter how u try to put 'em the situation, they will just say "I don't care, do it, it can't be that hard, u are lying to us".
Unfortunately I work in an underdeveloped country, and I have to feed my son, so... right now I can't quit, but if you can, do it now that u have a life and u don't work M-S 12 hours a day.
k.panik
Keep a webpage with one of these tables. In each quadrant, just keep an ordered list of tasks to be done, person who requested task, and date task must be completed by. I'd put a line at the top like "I exist to serve the business of the organization. Choose the place your request fits best. If uncertain, call people and negotiate until you are certain. You can figure out where it goes better than I".
Keep an org chart on a portion of the same page, and tell them that they can put their task anywhere in front of anyone at their level in the heirarchy or lower, or in front of their own boss. If they need to get past someone's request, all they have to do is go to someone high enough in the organization and convince them to send you an email.
Then spend 6 hours a day on urgent important things, 1/2 hour on urgent unimportant things, 2 hours on non-urgent, important things, and 1/2 hour on unimportant, urgent things, or some other mix you find appropriate.
You will slowly see that you are told the important things far in advance, because people find out they get done quite early and very reliably if they give you notice (because you always make time for important things). People also see they shouldn't ask you to do things that aren't important, and by keeping things public, they won't ask the silliest of things that you get now. You'll also see your users start to use the proper terms for things as the list is public and they will otherwise appear unintelligent. Rather then seeing "My computer is broke. u fix it" you'll see "Configure Eudora on My Desktop to Send Email"
As you complete a task, move them off into a permanent record of tasks completed.
And keep an extra computer by the door in your lab/office. If someone walks in with a request, just have them file it appropriately right at that terminal.
Want to see every step I took to start my company? http://www.rowdylabs.com/blogs/pitchtothegods
This budget problem is not because there isn't enough money but because the budgeting system you use isn't sophisticated enough. The way you do it now: IT department is assigned $x per month or year and that's it. No, this is wrong. Take an internal customer approach instead. Your "customers" are really all the other departments. When someone in the marketing department wants a new computer or program or a service call then the IT department should bill the marketing department's budget. See? This way, IT always has enough money because in order to get any IT work the requesting department has to pay for it. Doing this adds some overhead to the budgeting process but it more than makes up for the trouble. The way you're currently doing things, the IT department is purely a cost center which is always the first thing under the axe for budget cuts. Turn it in to a revenue center that pays its own way with the system I've described and you can easily justify hiring an assistant.
I contract with the government. It's me and one other guy handling all the network support, he does the switches and routers, I do the server maintence and network security.
We get a ton of requests that are outside of the scope of what we're supposed to handle. Technically we're level three and level four support when it comes to any issues, regardless of network or VoIP.
Many of the things we say no to are against department policy, so those are the easiest. There's no way I'm going to violate our security plan just to make the life of one customer happier. I'd lose my job, and I'd rather my direct government supervisors be happy that I didn't violate that than have a customer be happy that something was easier.
I get requests all the time to unblock instant messaging, but that's not going to happen. Our switches already know to bit bucket all authentication servers for icq, aim, yahoo and msn. That's by far my favourite thing to say no to presently. Just waiting for them to start complaining about the lack of yahoo! mail. *g*
-maz
<happiness>beer</happiness>
I told someone no, I wouldn't create a system that used a Social Security # for a login, and a badge number for a password... no no no. Had to do a sit down with my boss, their boss, and their boss... and I explained that 1) that information is definitely NOT secret, and 2) it was unethical to use information like that... it could compromise other aspects of the employees lives.
and I got fired... for "breach of ethics". apparently "pandering to a customer's silly whims and tantrums" is an article of ethics in that crowd.
meh
It's simple. I've moved to project management and it works like this. Tell the customer, "You know, let me look into that." Go ask around, listen to the answers, come back and tell the client, "It's not feasible if you want to stay within your budget."
You said it yourself: the economy sucks right now and money isn't thrown around anymore. As soon as someone hears "overbudget", they'll shut up quickly.
blog |
Go to the register.com, and read some of the BOFH diaries. I base my career on the teachings of Simon.
--PFY
You say you were underfunded in the past, but not the present. You contradict yourself and then say you asked for more resources. It seems to me you can utilize those around you. Have the developers support their applications. Have ghost images of standard setups and tell everyone to use common storage because you WILL blow installations away to support them. Subcontract out to interns the MBWA work. You are looking for excuses and not solving the problem. You need to change how you work. Go to lunch and think about it - you are not efficient or are choosing the wrong stuff. Your standard configurations should have standard self updating virus software for instance. People get into the habit of doing work that is not important and yet is fun. Or you can go to lunch - think about it - and just say "I am an IT person, I will do what I can supporting the most productive members first and I am really busy. Can we reschedule to talk at about 3 hours past the end of the day, I should be too tired to continue working by then and can spare the time as my reliability will have decreased to a point I should stop working or I might accidentally destroy the share space by not being aware of the details necessary to perform my job. I haven't had lunch - can you go pick me up something?"
just observe this tutorial :
...
(user) : I was looking on the web the other day, and I found this package that would let me-
(admin - me ) : no.
(user) : but I think it would help me...
(admin) : no.
(user walks off in a huff)
later that day :
(manager) : (user) tells me that you refused to install (stupid plugin totally unrelated to work) for him.
(admin) : no.
(manager) : no, what? No, you didn't say that, or no, you won't?
(admin) : no.
(manager) : no, WHAT!?!
(admin pauses quake3, SSHes to file server, runs find, a minute passess, opens files in ee)
(admin) : no, as translated into sysadmin, means fuck off you boring cunt. Do I have to explain it again?
(manager) : I'll have your job for this!
(admin) : Only if you can explain why 68 MBs of JPEGs all starting w/ asian_sluts_hcore are sitting in your projects/network_switch_refresh/ folder...
PC moderators can suck my White pierced, tattooed dick. If you think pride == hate, s/dick/Aryan meat mallet/g.
Be the Bastard.
-Looking for a job as a materials chemist or multivariat
High demands and never-ending work have always been an issue in the IT profession. One man wrote the seminal work years ago on how to handle these issues efficiently and effectively:
http://members.iinet.net.au/~bofh/
The best way to tell a customer "I can't do that" is to SHOW the customer "You can't afford that".
When we're handed an unreasonable software rollout on antequated equipment, the simple solution is to say, "Sure, we'll need 500 new machines, licenses to upgrade all of their copies of Office and Oracle, and we can have it done for you only a month if you authorize time and a half payment of overtime for the staffing requirements."
They do the mental math, come up with an unreasonable number and come back to us with a more reasonable effort.
Actually once last year, they said "sure, go ahead" and we got 500 brand new machines and the cash to hire a few more employees to help with the migration.
Sounds like a win-win to me.
Stewed
~~~
Squirrel
There are 10 kinds of people in the world. Those who understand binary and those who don't.
Part of the job of an IT person is to make it clear to their bosses how difficult a job is and do some kind of cost-benefit analysis. You may add some nifty new feature to a product but if it results in making the product much harder to maintain and may introduce uneccessary bugs because of the added complexity, it is actually a losing proposition for the company. Saying that something is difficult to do requires you to have some confidence in your abilities but it is sometimes good for both you and the company.
When I started to work as a junior software engineer at one of the dot coms, everybody wanted me to add complicated tasks to my programs. Finally, when I was buried under piles and piles of requests and functional specifications, I asked one of my superiors what to do. His answer was simple: I had to learn basic principles of software engineering:
a. Some tasks can never be sold with software
b. A good software engineer comes up with new code, an excellent software engineer learns how to re-use already existing code
c. Assumption is a mother of all fuck-ups
I have learned how to say "no" very quickly and here is what I how. Before you write the first line of code, make sure that you have requirements and specifications. There is an excellent book written by Michael Jackson (no, not the pop-star) on how to do that. If you are confident that you cannot meet the requirements, tell it to your boss/customer; chances are that if you cannot write robust and error proof code to do something, then either nobody else can do it or you are not well prepared for the task. If what they ask for is truly ridiculous, every decent software engineer will give them the same answer and anybody who takes the assignment will screw it up. Either way you are off the hook. Its better to be honest up front then being a scape goat.
I'll try not to sound too much like a therapist.
Basically, no one has the right for any reason to violate your emotional and mental boundaries. Given this information, any employer who would expect you, the only IT employee, to work miracles on a budget with 70+ hour work weeks would either be insane, satan, or taking advantage of you.
In any of these cases in it not right. I assume you are salary which means you work whatever they tell you too. They can fire you because they feel like it. And basically, you owe them for giving you a job in such difficult financial and job market times.
Therefore, here is a practical solution. Explain to your customers, clients, employer and co-workers that you are one person doing the job of several. You are more than happy to get to their requests (which I can assume are typically easy user account resets, PC checks, LAN crawls) but to please be patient. And if you must tell them "No, I cannot do that." Be sure to add, "No, I cannot do that right now. I have too much work to do. Perhaps we can revisit this at a later date."
Keep in mind you do not want to upset them. So yelling "NO!!! GO AWAY!!!" as the BOFH would, while quite humurous, and honestly quite theraputic, would probably get you fired. You want them to be considerate of your time and your work so please be considerate of theirs (and it sounds like you are, otherwise you wouldn't be so willing to do the work and find it so hard to say "No.")
I hope this helps.
Rivendahl
... there is nothing that has not already been thought
I have read through a few threads here that indicate a "yes, if..." (aka qualified yes) is the best method to say "no." From personal experience, I think this is a bad idea because it fails to properly manage the expectations of the person you are telling "no". More often than not, the listener shuts off their ears after hearing "yes", and assumes that the task can be accomplished.
I think a better approach is to give a "qualified no"; i.e. "No, this can't be done now unless this, this, and/or this gets done first." The shock of hearing "no" often moves the focus from the original task to the issues needed to be dealt with first.
A response of "no" is also more likely to be challenged than a response of "yes". Be ready to back it up with solid fact. And if you find out you were wrong, admit it, and point out that they now have a solid foundation for the "yes" instead of a quick, uninformed answer.
While it might be unpopular, and possibly job suicide in a highly unpopular political environment; give them the straight, candid answer. Don't sugar-coat, make empty promises you can't back up, or mislead to save your butt or burn someone else's.
It is called character and integrity; try some, its good for you.
Fools ignore complexity; pragmatists suffer it; experts avoid it; geniuses remove it. ~A. Perlis
Put the onus on someone else to fit it in, so they are clear on what the tradeoffs are going to be. Exactly. I have found that emphasizing the increased risk associated with one or more of (decreasing alloted time/resources, increasing project scope, decreasing project cost/funds) is the most effective way of communicating to your customers (internal or external) the impact of their demands. It's not that "It can't be done." It's that "If we constain it thus, the risks are very high, and here's what those risks are ..."
Business customers are typically highly risk averse, and they usually respond to this very well.
This is my experience as a Project Manager (PMP).
-- L
I don't ever say 'No'. I say How Long. They usually drop the request if it's not going to work for them. If they want me to squeeze the request in, I usually tell them that I could have if they'd made the request X days ago before the rest came in. Then, they'll usually accept MY timetable and I don't end up wandering the office with a shotgun lookin' for coworkers.
Easy! Put together a detailed schedule of what you do. You know something is gonna take you a week to do - put it in there. Another thing takes 3 days - put it in there, too. Talk to your manager, adjust priorities. If you do these two things saying "no" becomes much easier. Basically someone comes to your office and asks you to do something - you point a finger to your schedule and say "I have no time for this right now, let's go talk to my manager to adjust my schedule". Your manager will have to either drop stuff from your plate or deny the request - it's "mechanical".
I do contract IT work with a company. They have their own IT department, but the people there are either busy keeping the Exchange server from breaking, or are futzing with the Database (the contents of which, they know nothing about). All together, they dont seem very helpful. That is why I was hired, to directly apply technology to some of the different projects a parts distributing company has. As a result, I have several different project managers coming to me for major help on several different projects. Thus far, I have kept all my TODOs on stickies attached to my desk above my computer. When someone asks me to do a new thing, I write it on a stickie and append it to the end of the list: FIFO. Occasionally higher-ups request things, which jump straight to the top. But luckily, they can recognize the importance of some of the other projects I am doing, and when I tell them about it they demote themselves to the back of the queue. The biggest issue is one person in particular who knows a great deal more about IT than the others. He wants automation. When I have to tell him no, I generally point out what would be neccesary, and why its different from what I could do for him already, and he understands. Maybe Im just blessed with project managers who are willing to listen- it is a smallish company after all.
"Sorry Im not more user-friendly."
Show management how much time various jobs take, and build that into your time estimates. If they don't like it, ask for help. If they don't want to provide you with help, *shrug* and say well, with all these other projects, this new request will take x hours. Just don't agree to put in over time, because then it'll become expected. Basically, don't let them walk all over you, it's very hard to get out of that kind of situation once it begins. Realize that anything special you do now, to deal with these unreasonable demands will become the norm. And I don't think you are looking to become an IT slave.
Based on my experience, a characteristic of a good manager is the ability to say no. Others posters have said you should not say "no" itself, but express it differently, in terms of scheduling and preferences: communication skill, scheduling and planning are what managers are paid to do.
I've seen the problems when managers were too spineless to say no. As you say, it might annoy the customer (who might be an 'internal' customer) in the short term, but that is nothing compared to the long-terms problems. In the long term, you need to have a good working relationship with your customers. That means mutual respect, including respect for the limitations under which you operate. Saying yes only seems like the easy option. It inevitably leads to an excessive workload, which means that somethings will not be done, or done late, or quality will suffer. The customer will then perceive you as being untrustworthy, for failing to deliver what was promised (perhaps implicitly). Aware that you have failed them, the customer will make even more demands, which you will be tempted to accept, to make up for it. A few cycles of this and your relationship will be entirely dysfunctional; they will make outrageous shrill demands, hoping to bully you into doing some of what they really want, and you will forever be in conflict. Don't go there.
If a techie is being placed in a position where he feels he has to say no, there has been a management failure: the techie is either being asked to also be a manager without having been formally made a manager, or a manager has not done their job.
If the techie is being asked to act as a manager, it might be useful if this was explicitly indicated in someway, so everyone is clear that he has the right to demand particular information (priority) and the right to bluntly say no (as a last resort).
Ne mæg werig mod wyrde wiðstondan, ne se hreo hyge helpe gefremman.
You have my "impossible" mission beat. 20 more workstations/users, so I will justify my depression today by repeating, "It could be worse." I will stop using my usual mantra, "It could be worse, I could be on roofs."
You are embarking on an impossible mission. Respond positive, work long hours, receive the crappy treatment you will learn to loathe, burn out in 1 to 2 years, and move on to the next sorry-ass IT assignment.
We should all create a registry of our thankless IT Manager positions, and put a warning buoy outside, for others to avoid.
I'm sorry, man.
You prioritize and if they don't like their place on the list, tough shit. The 80/20 rule will tell you that most of the shit you do is pretty much useless anyway. Only the 20% really matters. Concentrate on that and nothing else.
Tell them no. What? They're going to fire you? Go ahead. Let them hire some out of work scumbag that hasn't had a job in a year and see how far that gets them. If you're that replaceable, it's just a matter of time before your job is outsourced anyway.
What would Brian Boitano do?
Here's how I do it.
"I'm sorry, but, you want what? Ahhhhhh yes well you need to submit a written request with your departmental authorization, signed by your manager and giving the charge code for your department/project. I'll get back to you with an estimate of manpower/material costs for your request and an estimated start and compleation date based on current scheduling requirements and manning levels. You let me know, once you have received it, if that's appropriate and you want me to procede and I'll send the appropriate budget transfer forms to your department/project manager for signature. Just as soon as that's accomplished I/we will place your project on the scheduling calender.
No I can't just take care of it right now, I'd really love to but it's policy/rules and I really can't change it. Zero-cost accounting you know, Total quality and ISO 9000 process must be observed."
My hard learned lesson from the Military and Government sector is that paperwork is a weapon two can use! And remember, they can't fire you, who the hell would do the work then?
Or you can start reading the BOFH material and learn how to REALLY say NO!
If you know there's no way to complete everything on time and no-one is listening, then prioritize brutally. Use the Stephen Covey approach of dividing your work into 4 categories:
1) Urgent and Important (i.e. a crisis)
2) Important but not Urgent (i.e. a long term need)
3) Not important but urgent (i.e. things you can safely ignore even though someone is screaming at you to do it *now*)
4) Not important and not urgent (i.e. time wasters like reading news in the middle of the day) (NOTE: taking a break when you're exhausted is *not* #4. It's #1.)
Give all your tasks one of these numbers and then commit only to #1 and #2. You may get a lot of flack for skipping out on #3 (e.g. not being at a useless meeting that "everyone" goes to), but it's only short term because people accept it after a few times. Do whatever you can to never get stuck doing #4.
Make sure that you don't forget #2, no matter how much #1 is pressing you. You can't forget long term and mid term needs. Often taking care of #2 gets rid of #1 problems. For instance, if you get tired in the middle of the day, resting now is important and urgent (#1). However, if you dedicated a little time to keeping in shape (important but not urgent -- #2), you'll find that you can last a 13 hour day without getting tired. If you have a customer that regularly bugs you with huge important last minute requests (important and urgent -- #1), you can get out of crisis mode by keeping in touch with that customer so that you know what's going on and can thus plan for their requests before they know them themselves (important but not urgent -- #2).
I've worked in several very large organizations. Here's a short list of tacticts to use to thwart ever-increasing boosts in workloads:
/.
:-)
- Use program management. Program management is different than project management, in where you prioritize projects based on needs by the business, and effort is directed to the ones that provide the most bang for the buck to the business.
- Competing interests. If you have unreasonable requests from non-revenue generating departments, put these people in front of the executives (call an emergency meeting) who are running the revenue-generating part of the business and have them explain why you have to work 200 on some boss's Crystal report versus fixing a production problem that is affecting sales. Works everytime.
- Be more visible. The more people know what you are working on and what your backlog is, the requests that come in will be thought-out a lot more often if the business thing all you do is eat pizza and read
- Use cost-analysis studies. Spending 6 hours to write up a white paper exploring your users' idea and the pros and cons may save you hundreds of hours of work having to do the request (especially if the business decides it's a bad idea later on). The thicker the document is, the more the business is inclined to think that you have approached the idea and its implications than if you merely shot off an email saying "we're too busy to do that" or, "that's a bad idea."
- Face time. Meetings suck, but you should at least go to one to two of them a day and stay involved, especially the meetings where the businesses cook up new ideas that impact the I/T department. Meetings are usually were the business cooks up these requests, so you can snub them out at the source, or redirect their brainstorms into better projects that will be more useful to the organization.
- Use the business process against itself. Larger organizations typically have a project management process they use. A lot of projects die while still in the design stage. Typically this is because the business gets distracted with another pressing matter and the project seems much less urgent after enough time passes. If you need a lot of time to work on construction on some other effort, you can usually effectively delay the construction on a new project by stretching out the design phase (call lots of review meetings). It looks like you are working on the project, but you aren't actually building anything.
There are a lot of other options for tanking projects, I've used various techniques to get rid of some really bad ones... but these are the ones I use most often and have served me well.
Good luck.
Any time someone asks you to do something, sigh loudly, rub your brow, and shake your head, and repeat, "Great... Just Great...."
One of the coolest books I have read:
First, Break All The Rules - from Gallup Publications. I highly recommend it to everyone when we start talking about stuff like this at work, or staff picnic, etc...
What's happening here is that the focus is shifting away from being a good sysadmin, or a good computer programmer, salesperson, etc. and the focus is shifted towards something else, something along the lines of multi-tasking and balancing tasks and having the social engineering skills to deal with all the stuff on your plate. Those are two different kinds of skills.
The chain of command that you reference applies most generally to residency/academic programs... and for one reason only: supervision of trainees.
A resident may have some training, but he is often not able to practice his discipline independently... at least not until he has graduated from his residency (He may or may not seek board certification after that... some hospitals require it).
In the private practice world, virtually nobody orders around an attending physician... it's his license to use or lose, and the buck stops with him. This is as it should be... the only reason a chain-of-command exists in residency programs is because the attending bears the ultimate responsibility (legally speaking) for the actions of his/her subordinates. Now, mechanisms DO exist for peer review, QA, impaired physicians, and removal of incompetent physicans (board-of-medicine complaints, etc), but that is not truly day-to-day supervision.
I don't let ANYONE tell me to do something improper for a patient... and in the past, I have told superiors to get bent (I'd recommend something more diplomatic, unless you are comfortable with confrontation). Then again, if it's a suggestion, and a reasonable one, from someone in a position to know (ie. similarly or better-trained/experienced than myself), I will always consider it.
The first thing you learn (or should learn) in medicine is that you can't know everything... and listen to others. It's a poor physician who routinely ignores the advice of a 20+year experienced nurse, for example.
But to readdress your initial point, I tend to take advice given by administrators regarding patient care with a grain of salt. Some of these types haven't set foot in a clinical environment in years, which in my mind makes their expert advice immediately suspect. That's not to say they may not be right, but I'd have to look at the merits of their suggestion. I'd surely evaluate for myself before taking a clinical care recommendation from such an individual.
Even if a man chops off your hand with a sword, you still have two nice, sharp bones to stick in his eyes.
...but can make your life hell if you don't qualify "can do". I think most people have said the same, but it boils down to letting the customer know your current commitments, letting them know that you can do it, but it has to be prioritised, and then letting the people who want each task done figure out the priority.
"No, I'm too busy" looks really bad. "Yes, but I'll have to squeeze you in between updating the Use Case Documentation and the deployment to the live environment" shows a willingness to do the work even though you're busy -- you're going the extra mile for them, and people like that.
James Tait, Programmer and Free Software Advocate
JID: jayteeuk@wyrddreams.org
You need to cultivate a relationship with someone in management, in order that they will say "no" for you. Do the best job you possibly can while making clear to management that you are doing the best you can. Otherwise, you're seen as an obstacle to success because work doesn't get done because it piles up. Either way you lose unless someone with authority recognizes the real problem is not you.
I've heard that whiskey and ensign story a few times in my life. I've always thought of it as urban myth to prove a point.
riding round the world on an old motorcycle
We solved that problem here by building documentation for every project.
We start with business requirements (what do they want, how should it work)
functional requirements (exactly what do they want, exactly how will it work, content gets written up in word documents... they sign off on the details)
technical spec (how are we going to program it, what are the interface definitions, where will it live, what systems will it be connecting to)
time cards (what did the programmers do today, and how long did it take)
All of this paperwork is done, preferably by a project manager, with us in on the details. We fill out our own timecards.
The entire project is prioritized with the rest of the projects and placed on "the big list in the sky", by the business. A project timeline is established, which starts when we get to it on the list. The project is locked in stone until completed. All documents get password protected (people are sneaky).
All additional enhancements and "oh yeah, I forgot about this" go into another project which is, you guessed it, documented and put on the big list in the sky. Otherwise the first one will never get finished, and you end up with the 4 year old project that will never be finished. If you don't do this, you have "scope creep", also known as "your worst freaking enemy".
You can see the disadvantages that scope creep offers when you get no raise and they guy who is good at managing his paperwork, but does little actual work, gets 11% for "finishing lots of projects". When people get laid off, the ones that finish their projects are the last to go.
When you start doing this, the VPs will see which business people have their act together and which don't, IE who is causing IT to cost so much. All of a sudden you stop getting blamed for not getting work done. You have evidence that the idiots that ordered the project could not make up their mind on what they wanted and it cost the company $xxxxx.xx
This way, the business has a list of current projects, they know where we are with each, and they can shuffle priorities all they want, but if they want stuff to get done, they leave us alone. When they pull us off of a project the timeline freezes until we can start working on it again.
After a year of doing this, the business thinks twice about what they want before ordering it. They know where we are, why we are there, and how long they have to wait for every thing that is in the list. They know how much that the stuff they forgot to mention to us will cost, when it will be added to the project.... you get the idea.
They know how long we planned for it to take, how long it is actually taking, how much time we wasted answering stupid questions on the phone, blah blah blah. You no longer hear them making snide comments about the slow lazy IT people... The amount of production support that I do (most of which is now being done by a formerly underutilized co-worker) has gone from 30 hours a week to 2 and I can actually get programming done: )
I used to be in your shoes. Post back here and I can give you some word templates: )
In a nutshell, the answer to your prayers can be found in mountains of paperwork. Unfortunate, but necessary to stop the madness. The best answer you can offer as they pile on work, is "Sure we can do this, it will add 120 days of development. Do you want to finish this project on January 1 instead of September 1, or should we finish this project as is, and start a new project for this additional stuff?"
They still have control, you still have your sanity. Let them decide how to run their madness, but tell them what it will cost and how long it will take, and make them sign off on it. You get to keep your sanity and never say no.
l8,
AC
Whenever someone asks for something inane, annoying, or otw distracting, agree do it if you politically must, but give them one or more action items every time they stop by. Be really happy to help, but request all sorts information, research, whatever it takes to keep 'em busy. Be nice about it, don't overdo it, but very firm in your request for those action items, and every time you see them, ask for updates.
/. in peace!
It makes you look like a good guy but after awhile the clueless and annoying seem to stop bugging you as often... And if they start complaining, they are not entirely blameless if you have emails.
And as a developer, keeping away those interruptions is crucial to getting work done and reading
Failing that, I'd read BOFH for more advice!
r4lv3k
First, if what is being requested is urgent and important, just do it. But when that is not the case, my standard line is:
I have also found that using a whiteboard as a to-do list to be very helpful. Let others think you do this for your own benefit. But make it a prioritized list and keep it as a "public document" of what you are working on and what your priorities are.
A) In a small firm, get a little service ticket tracker and make sure everyone can access the prioritized queue report. That way they can see what is on your plate short term. Also make sure you put out a monthly email that lets people know what's up in IT land including *and this is critical* a summary of tickets closed, project status and so on so people know you are working your ass off. You are a stud if you can include downtime and causes on the report.
B) Self-Service Rules. If you work with 40 developers, focus on providing resources so they can solve their own problems. Make sure things are documented and available so people can find things. Make it so users can self-install software and so on. Don't be a control freak. With programmers and sales/marketing departments it wont work.
C) Become a horse trader for budget. When someone's got something that needs done, and it requires an upgrade or new purchase THAT IS AN OPPORTUNITY to get another department to fund you. Let people buy priority with budget dollars. I've diverted funds from advertising or sales training to buy servers because I NEEDED ECOMMERCE ONLINE NEXT MONTH!
D) Don't be a no guy or a yes guy. Ask questions like "How will this help make your department more efficient?" , "Will this change enable us to increase capacity?", "Explain how this will help the bottom line?", "What alternatives have you considered... why did you settle on this decision?", "This will have impact on ______. Have you discussed the impact with ______ in ______?", "This looks like a really good idea - what drove you to consider doing this?" A lot of times people will talk themselves OUT OF DOING ANYTHING or put the project on the back burner.
E) Don't be heavy handed with end users. Don't ever say to anyone that they or what they do are not important! When you have to say no, just be honest: "Accounting is down right now, can I get to this later?" "Do you need access to something you don't have to fix the problem?" "I think this is a great idea, but before I'm comfortable signing off on it, I'd you to discuss the idea with _______ and ______." And finally, you can always say, "No, I can't do it."
-- $G
It's a difficult job, often times dirty as well, but someone has to do it.
You're naiively lumping "management speak" and graphs and diagrams and other charts and powerpoint presentations together as if that's the only way management relate to problems. If I was your manager and you came to me with a presentation with slides, a gantt chart showing project dependencies, a "best-fit" graph of peak workloads of time, and a 50 page report, my first question to you would be
..."
Manager:"Great, thanks. Did you make these yourself? In your own time?"
Network Guy:"Ummm, yeah, mostly."
Manager:"Well by coincidence, I'm just having a meeting about staff costs in relation to workloads, and this will help my put my point across no end
"It's not your information. It's information about you" - John Ford, Vice President, Equifax
My tactic whenever my boss (past, present, or future) or client or whatever simply refuses to listen to the logic coming out of my mouth is to give a good hearty laugh, slap them playfully on the back or shoulder, and then walk away, shaking my head and still chuckling as if they had said the funniest thing ever. I don't know about IT, but it usually seemed to work whenever a former boss o' mine repeatedly asked me to risk my life to do menial shit like change light bulbs on the ceiling of the garage. Boss: "No, Andrew, we don't have one of those light-bulb changing sticks. We want you to climb up the 30-ft ladder... AND THEN STAND ON THE VERY TOP TO REACH THE LIGHT BULB!" Me: "Hahahahahahhaahhaaaahaaha!!! WHACK! , heh, aheh, heh, haaahaa!"
Voodoo Girl is the bomb!
10 years of experience in IT says: If you're working in IT right now, thank your lucky stars. Don't rock the boat. Realize that you could be replaced in a heartbeat. However, take whatever support you can get. If you're working for a good company then you're set. If you're working at the typical company that's shooting themselves in the foot because they don't get IT... you're screwed. If that's the case, then your only protection is your boss. As a company employee, your job is to follow orders. Anything else will amount to painting a bull's eye on your forehead. When you get hired as a regular employee you instantly lose your voice. You aren't a decision maker. You have no "juice" to make the decisions stick. Never say "no." You can't afford the grief. Don't try to change a broken company. Keep your head down and fly under the radar. Let your micromanaging boss dictate EXACTLY how he wants the job done. Then follow it to the letter, putting the responsiblity back on his shoulders, not yours. Don't fall into the trap of having 50 bosses because you've become the company's IT whipping boy/slave. Never volunteer for something outside the scope of your job description and training. Don't use work to learn. Set up a testbed environment at home and learn there. You'll have more freedom to do it right. Don't use free software for solutions. Make your company pay for it. It's good fiscal training for them. They need to learn the real cost of IT. Beige boxes are not servers. Never use Linux without a support contract for every installation. Learn what a properly deployed Data Center looks like: clean cabling, everything's racked, no beige boxes, only servers, UPS, dedicated air conditioning, physical security/cipher locks on the door, etc. Make the company PAY for training/certifications before attempting to work on the related project. That said, if you want a voice, be a consultant. Consultants come from the outside and are hired for their expert opinion. It's a fundamentally different experience. You design it, implement it, and train SOMEONE ELSE to run it. Or you could run it yourself on a part-time, outsourced basis. If you can't be a consultant, keep your head down. Create a priority list and get your boss' agreement. Make the priority list fit what's important to the company as a whole. Create a task list and task submission procedure/website/database/whatever. Don't get sucked in when someone says it will take a second and it ends up taking 3 hours. Spend 5 minutes on their request if they won't submit a task request. If it takes longer than that, tell them you will submit the request for them since you know what the details are now. Always try to offer workarounds until you can officially get around to working on it. NEVER GIVE A PROMISE OF WHEN IT WILL BE DONE. Let the user specify the priority level of their request. HOWEVER, TREAT THAT PRIORITY LEVEL AS SEPARATE FROM THE COMPANY-WIDE PRIORITY LEVEL THAT YOU WILL ASSIGN YOURSELF. This is CRITICAL. This lets the user know you will respect the priority of their request WITH RESPECT TO THE OTHER TASKS THEY HAVE SUBMITTED. It might be the top thing on his plate but if the server's down, nobody can work. YOUR BOSS IS YOUR ONLY PROTECTION. He's the only one you can't avoid completely if necessary. If he's out to get you, look for another job immediately. If he's good, you can rely on him to defend you and not undercut your decisions. He travels in policical circles you don't. Take advantage of his unique perspective. You're in the trenches. He can see poliitical things coming you won't. Don't stay too long at a bad company. Don't get burned out. There is a right way to do IT. Most companies don't get it. Be aware of the many traps IT people walk into. Be aware that the fear of technology people have will probably be the main thing people will use against you (sometimes knowingly, sometimes unknowingly). EVALUATE YOUR COMPANY'S LEVEL OF IT QUALITY. Assess the company you're at right now and compare it against any company you want to get hired at. I've found that the information you can get before you get hired gives you just as accurate of a picture of a company's IT quality as the dirt you get after you get hired. Contact me if you want help doing this. I made a spreadsheet to do just that.
I just told my employer that I wouldn't cancel my vacation when the person I was supposed to hand my project off to quit. They wanted me to stick around until final QA was complete (another 4-5 days),while I had family flying in from all over the country to visit. I told them no, they told me goodbye. Oh well, it isn't hard to leave a job like that, it's just hard to find a better one. :/
Just junk food for thought...
Actually, the sticking point was that we said "unconditional surrender" and they said "Nooooo! Negotiate with us!". Then we said, "unconditional surrender or we're going to vaporize a city." They repeated their refusal. We blew Hiroshima up. We repeated, "unconditional surrender or we're going to vaporize another city." They repeated their refusal. We blew Nagasaki up. Then, we said, "unconditional surrender or the next city we vaporize will be Tokyo." They said, "Ahh shit! Unconditional surrender sounds ok now!" We wrote them a consitution, and Douglas MacArthur got to pretend he was God over there for a while. Truman had already told Stalin all about the bomb as far as its power and such based on the test in the desert.
There's probably a program to do this somewhere, I just haven't looked it up yet.
What you need is a program where people requesting your time must submit it to a queue. A priority queue is probably best, as you don't want to be saying "I'm working on ticket #3341, and that server that's on fire there will be ticket #3382," although you should be the one to assign priority, not the user.
Most important though, is to make the status of this queue visible to those that submit requests. They must know that you are Very Busy, and that it will be a while before you can get around to them. If they don't like it, they can talk to your boss, and add creedence to your requests for more staff.
"No problem. I have the capacity to do infinite work so long as you don't mind that my quality approaches zero."-Dilbert
I would rather have killed everyone in Japan then lose a single American soldier.
Here is a lesson for you. If you might not like the outcome, don't start a war.
between the greater and lesser infinities sleep the dreams undreamt
Pretty much most of the good tips I've already seen here. It sounds cliche, but remember Scotty from Star Trek? Don't be 100% honest about schedule estimates. You don't know when something will go wrong, you don't know when you have to do some other small job in the middle of a larger project. With any luck, you might SOMETIMES even go under your scheduled time estimate and be the miracle worker of the day.
;).
I had a colleague at my previous workplace, an older female programmer(rare enough, but obviously the best programmer in the house). She always remembered to keep saying "work won't get finished by doing it". The point was that no matter how long days and weeks you work, there will ALWAYS be more work to be done in the IT field(probably elsewhere too?).
This leads to priorising and more than anything else, respecting what you do. You have to realize that in the long run, jobs come and go, but there's only one you.
Personally, I also find it important to being in good communications contact with the boss. Being able to just stop and talk, cell phones turned off, and discuss ideas as well as the current work situation.
Oh, and the old saying I mentioned above... it also means that no matter how many people there are, ALL work never gets done. Obviously, sometimes you need more staff, but there's usually a good way to compromise. Some things are priorities, some things aren't. Some things are worth spending a few days on, some things aren't.
As for the last tips, flexible work hours do miracles for work productivity. I've seen it myself and in my current staff. Good eating habits at work can also do wonders (don't worry, you can party at weekends
I worked with a guy who was in development and managing the IT end of things. he was always overworked and underfunded (not as much as what you're talking about, but...). his solution to the problem was to have someone else prioritize the workload on a project-by-project basis (NOT day-to-day or hour-to-hour).
basically he was leaving it up to the management to be the bad guy for whose work wasnt accomplished. let the guys who are dumping the work onto you be the bad guy for the customer.
sTc
Most things worth doing are worth doing twice. -- me I think or was that my boss' methodology?
I hate being a project manager. It is a difficult and thankless job. You have to answer for things that are not finished on time or on budget. Being a 'techie' who is trying to do 'real work' in addition to manageing my own projects makes it even worse. But, if you don't want to be 'herding cats', you really do need to implement a standardized project management methodology throughout your entire organization. Otherwise, the entire organization is likely to fail.
I'm the head developer of a totally small time specialized systems company. (And cook, janitor, bottle washer too, small time translates to: just me) Now i'm not an IT guy really, but I have a similar situatuion: Enough requests to keep 12 of me busy.
One must condition one's customers. There are several ways of conditioning: I don't recommend the piss-poor way that some large software companies condition their users to expect little if any help. In your case, you'd probably get fired.
I do some small things, which basically cost little in resources and time. While not in your exact situation, there's enough similarity to warrant a reply. Anyways, this is what I do. There are guys out there far better at this than I am, but I have a lot of bottles to wash. (:
My customers each run a linux server, and a pile of diskless terminals in their stores. The software is specific to the type of store. I do all coding, upgrades, troubleshooting, most over the phone or via modem, as most of these systems are > 500 miles away. Luckily I get about 1 service call every two months, the system and software's pretty reliable. Most phone time is about upgrades, or ideas for features, steering, etc.
My strategy for having some time outside of the business:
1> Prepare the customer. Make sure the customer understands there are a lot of moving parts under the hood.. and yes, while it might be nice to have a new version of 'right hand', you might also need to backport changes to 'right wrist' else 'right arm' turns purple, and falls off. Make the customer aware of both the complexities, and the time it takes to balance a complex system after a change is made. Once the customer understands this, you can be more choosy about what you sink time into. You can even get away with things like 'i don't think it works with the existing architecture, but lemee look at the code to see if it's possible.' Always leave them with the notion that it 'Might' be possible, but temper it with the notion that it 'Might' be painful, or next quarter.
2> Having scared the customer with #1 above, I *ENCOURAGE* them to request new features, suggest changes, etc. You really have to hammer folks about this. Whether or not they have a clue or not, they all want input. Give it an outlet, whether or not you can deliver. Listen carefully. Best to talk in person/phone than via e-mail. The customer will likely respect a 'No.' if he feels like he's been heard.
2a> Amongst all the chaff you'll get from 2 above, there will be some gems. You'll also spend a fair amount of time talking to customers, developing a more personal relationship, which is crucial in being able to say NO. There's a wide spectrum of requests and types of folks that make the requests for features. At one end of the spectrum, requests are utterly impossible / impractical given the existing architecture, or sometimes just poorly scaled to a computer. In the middle of the spectrum are the comical.. ('can you make the computer beat my employees with a stick when they ignore store policy? Yes, I've gotten this request. (: I took it to mean that I was doing *something* right in the PR dept. for a customer to actually ask this.) At the other end of the spectrum are things you can do which take little time, but make somebody else's life a lot easier. Often times users are afraid to ask for these features because 'they don't want to be a bother, think it'd be too hard.. etc' Shoot for these in the lulls. You'll get a reputation for delivering. Yes, you still have to take on the 'BIG' projects, but it's always ALWAYS 'bang for the buck'.
3> Keep todo lists, one version called 'short term' and another version called 'Long Term'. Make absolutely sure your customers KNOW you have a todo list, and that they are on it. Make SURE that customers are informed as to just how much time is involved, and that it's probably a conservative estimate. Even if you know you can't deliver something, tell them you'll put
Another thing to consider with the unpaid overtime trap is that it can significantly lower your salary.
Think about it. If your salary is $60K/year, you're getting $29/hr for an 8 hr day. If you work 4 hours unpaid overtime every day, you're actually making $19.33/hr. You'd be better off taking a less stressful $40K job (not necessarily programming). If the job doesn't pay "time and a half" overtime, you'd be making $60K/year for the same number of hours. If the job pays time and a half overtime, you could work only 2.7hr overtime a day and still get $60K/year.
The next time your manager asks you to work 12 or 13 hour days, be sure to mention this to him/her/it. If your manager doesn't understand or can't use this information to do anything for you, then seriously think about moving. Your company is either on the brink of bankrupcy, or they soon will be since they treat their employees like dirt and this will indirectly affect the company's profit and viability.
In any case, if you need to say no, explain why you need to say no. Usually, users will be understanding and sympathetic if you give them an explanation instead of looking like you are just blowing them off.
Looking for a job?
Want your resume written professionally?
DON'T USE TUNAREZ!!!
When demanding something though, there may be very realistic and logical reasons for it. Ask them why... if they get defensive then that is a sign that they first of all don't know why and second of all they know they are being children. I don't like doing business with children as it hurts my reputation and profits. If however they explain their rationale then not only can you better design the entire system (i.e. add that to requirements from the start) but you can perhaps show how their choice may not be the best one for the very requirements they gave you.
On behalf of the buyer, because we all are at various times... I would like to say to avoid developers and vendors that dance around your requirements and demands instead of holding a rational discussion of what and why you have those demands. If it is something important like security and protection of sensitive information like customer credit cards, then ensure that they put down in writing (and with their signature) their choices and rationale/proof for why they made the choices they did. Any good businessman will respect this... children will be offended.
In many ways this goes along with earlier discussions about how as a consultant you can CYA. Namely, if you feel that a particular design or other decision has a high probability of causing trouble then if it is not an ethical issue... just simply have them sign off on a paper detailing your recommendations (and rationale) along with their decisions and rationale (which may be, with children, a simple "because we said so")
Don't become the victim of stupidity of others.
When I was VP of engineering for no-longer-existing dot-com company, management wouldn't take "no" for anything. "Damnit, we're on Internet time! We've got to be able to do everything now!"
No problem. It's a simple matter of supply and demand. I only have so many resources, and a lot more projects that all seem to be top priority.
So, each project became a justification for new consultants. Eventually I had more consultants than we had projects (mine was the largest department in the company- what do you expect from an Internet company!). Now everything was happening at once, just like the execs wanted.
Why the extra consultants? Because I never knew when new projects would pop up that needed to be done "today", and you know, consultants take time to find. Over-capacity was my friend. I always was able to say "We're on it!" to any new project. Managers and execs loved that, and that's how I became the VP...
So, what happened to the company? They burned through more than 100 million in funding and never did find a working business plan. Duh!
The moral: Don't fight bad management, use them to advance your own career, then bail just before the crash. I own my own company now. Zero consultants, and a very linear list of priorities. Oh, we're not perfect, but we are profitable.... http://www.RLT.com
When I last worked for a large law firm, our boss couldn't say "NO" to any request, no matter how difficult or insane. If they want it done in a short amount of time, we have to work 80+ hour work weeks for no extra pay to get it done. I couldn't do that because I have a family that needs me at home, and a son who needs a babysitter and the babysitter won't work extra hours so someone has to pick him up on time. My wife works as an LPN and has long hour days, so if I worked long hours there would be nobody to pick up our son from the babysitter.
Many tasks were just beyond my talent, like creating reoccuring dates in a calendar program which nobody else had any ideas how to do. I even asked on the Experts Exchange and got no results. But, they say, Outlook can do it, so it must be easy to do.
Also how can I get work done when every day they keep making changes to the program and the way it should look? I make all their changes, and then someone says "It is not intuitive" so they re-arrange it several more times until everyone is happy. Whatever happened to having IT making the UI and the way it should look? I would be happier if everyone got into a meeting, decicde how it should look, let me code that, and if they decide to change their minds later don't make the UI changes until the next version comes out.
What really got me is people promoted to management who have no idea how IT works, but they have final say over IT tasks and projects. I had one woman who told me to change the name of something she saw in a database to something else. I tried to tell her that it is a database column and that changing it means changing all the queries and stored procedures and triggers associated with it. She had no idea what column meant, even if she did claim to be an Excel expert. So my boss had me use "Pieces of information" instead, and then she got mad that I was "dumbing it down" for her. I told her that I can change the labels that name it, and descriptions to it, but she wanted the column name changed. So after changing anything that touched that column name, she decides to change it again! She had no idea of all the extra work she was creating for us. She also had no idea why it was taking so long to change, as she only took 15 minutes to write the email about it.
Also other departments bashed IT at every chance they got with no punishment. We couldn't say anything back, even if they cussed at us. Why do people get so emotional over computers and programs anyway? It is just a tool to use, and bashing the IT department won't get their problems solved any quicker. We're doing our best, and are overworked, and underpaid, but they treat us like sub-human creatures not human beings.
Also at first signs of a profit loss, IT people are almost always first to be laid off. Shouldn't they lay off the people who made the mistakes which lead to the profit loss? Blame accounting for not noticing the trend that sales were down. Blame marketing for not marketing the product right. Blame sales for losing customers. Blame management for not doing their jobs right. Just don't blame the people who keep on running those computers for you so you can get your jobs done.
Remember, Slashdot does not have a -1 disagree moderation, and no, troll, flamebait, and overrated are not substitutes.
Here's the thing - after working in IT for 15 years, I can tell you that all of your end users and managers are morons, incapable of peeing without getting their socks wet, much less understanding something as complex as software development.
Just put in your hours, and be sure to document who told you to do what and when so you can avoid taking the fall for managerial stupidity. Above all, don't take any of it seriously.
If they wanted you to be successful, and really understood what that meant, they'd get off your back and out of your way, but then they wouldn't be managers, would they? They're more interested in speeding home to their suburban death-mazes in their shitty SUVs to drink themselves into oblivion. God bless America!
The only problem with putting your schedule in front of management, is that there are some things they just won't see as important, even if they are to you.
Given a choice between "install security updates", or "install software updates that are 10x easier to manage" or "finish the database conversion that is half way done, awkward to work with, and unstable as hell" and "setup my new shiny toy of the week" they will take the shiney toy, because it's "Okay to put off that other things for a week or two."
This is because they really truly can't see what you are talking about as important, if they don't understand what it is. This is actually fair, since we do the same thing to them.
Unfortunatly, those things you want will keep getting put off for years if you don't fight for them.
The advice listed here is really, really good, and is the way to go. But just remember that sometimes you will have to fight for the stuff that you really need. Don't be inflexible, and don't fight over every issue. Pick your battles, and fight them when it really matters.
It's also easier to say "I just need to do this one really important thing first" than it is to say "I can't handle your shiney toy because I'm too busy".
plus-good, double-plus-good
Hmm. The answer depends on your employment situation, which you will have to try to read.
There are some employers that are dysfunctional enough that, as an organization, they cannot prioritize projects and activities. There are consulting companies and startups that will agree to any crazy customer request. I worked for one once that formalized this as a "just say Yes" campaign with their sales force.
If you are working for an outfit like this, the best thing you can do is set firm boundaries between your work life and your personal life and then stick to them. Some people deliberately put hard stops at the end of the day -- having to pick up the kids at day care before 6pm, or having to leave in time for a tennis match or choir practice or whatever. Then, while you're at work, acknowledge to yourself that some balls are going to hit the floor, and try to do what is expected within the time constraints you've set for yourself.
When at a company that does not plan well, it is best not to allow yourself to be pressured into making estimates and time commitments. Instead, do what work is assigned, and if you're taken off one unfinished thing to work on another, do so with a smile. You, after all, are a professional, and an individual contributor, and you work on stuff at the company's convenience.
If this leads to stress or criticism, you will have to decide whether the job you're in is worth saving and how far you're willing to compromise to keep it. As a rule such employers don't improve.
On the other hand, if you're working at a fairly reasonable, well-managed outfit that has effective management capable of making decisions and sticking with them, you can try to negotiate, and prioritize, and get some sort of process in place.
One thing that won't work is keeping a log or list of what you've done. It's extra work and nobody will care once it's done, because they already know full well that you have more to do than you can possibly get done.
o MrProject- info/applications-project-management
o TaskJuggler
o TUTOS
o ToutDoux
o OPT (Outreach Project Tool)
o Phprojekt
o OpenOffice.org
o dotproject
o Double Choco Latte
o PMtool
o EPIware and EPIware LITE
o OPENSCHED
o Achievo
o FUTURe
o KPlato
o QtGantt
o XPlan
o Intellisys Project Desktop
o Intellisys Project Enterprise
o AMS REALTIME
o Novient (was WebProject)
o PyGantt
o proManager
o Projector
o BSCW
o AutoPLAN Enterprise
o mySAP Product Lifecycle Management
http://www.linuxmafia.com/~rick/linux
"Yes sir, I can certianly do that. It will be finished in early 2009. If it is very important, it can be done next week, but *you* will be responsible for telling Big Boss that his task will be the one completed in 2009."
"Your superior intellect is no match for our puny weapons!"
I've found that the best way to deal with user or staff requests is to ask for a written business justification for the work. Usually the person making the request never follows up or cannot justify the staff time or resources needed to complete the project. If they do write something up, pass it on to management (someone higher up might put a stop to it).
I did this a year ago when management decided to upgrade all the Windows 2000 machines to Windows XP and Office XP. I asked them to write down the reasons for the upgrade and what new business functionality would be gained by the new version that is not currently available.
We are still on Windows 2000 and Office 2000.
First off, the market is a real bitch right now, so having a job is a good thing. I've done the 300+ users/5 servers/no help thing before, and it isn't really enjoyable. I've found that if you let someone run all over you and then complain about it, you will be in a mindset that doesn't allow you to succeed at your job. Managers understand that you need help, if you explain it to them. All a CEO or VP wants to hear is that you can fix it, you have 2 or 3 options on how to, and it will take x amount of time to do so, given your other priorities. Give them options, and tell them what those options mean, both from a time standpoint and a finance standpoint (if they choose not to do it, then they know the consequences). Treat everyone the same way...you are saving the company money by making good decisions. You are not going to make it if you just react to a bunch of technical problems, because nobody gives a shit about your having to stay late to patch IIS. You also have to balance typical BOFH draconian policies with effective workflow. Don't create problems for yourself by making a bunch of changes to your security policy all at once. Instead, implement the changes one step at a time, starting with strong authentication and GET BUY IN from the higher ups on why it is important. If you fear talking to the CEO or President, then you won't get much respect from them. Teach them why you are competent and explain what they get out of you. You might be surprised when they recommend to your manager that you should hire some consultants to do some of the grunt work while you implement a more strategic project. Of course, you have to be able to provide a fiscally responsible solution, with a readable and understandable discussion of what the technology will do for them and put it in layman's terms. It requires writing, yes, but in writing you have both your proof of concept, ROI evaluation and Ass-Covering documentation for when the shit hits the fan and people are pointing fingers. Good luck.
man rtfm
Always multiply the actual time it will take you by four when providing estimates. For example, a job will actually take you 2 days - tell your customer it will take no more than 8 days.
"According to the Turtle" www.paperbackreader.com
http://www.trinet.com/HR_resources/HR_Library/HR_l ibrary.htm
California only recently recognized certain computer professionals as being exempt from overtime pay. In September 2000, California created an overtime exemption for computer professionals, one which is more stringent than the federal standard-and, accordingly, California employers must follow the state standard. Many states do not have such a standard, despite the nation-wide explosion in technology positions!
In California, a computer professional is exempt from overtime pay if he/she is primarily engaged in work that is intellectual or creative, requires the exercise of discretion and independent judgment, and is highly skilled and proficient in the theoretical and practical application of highly specialized information/computer systems analysis, programming, and software engineering. The primary duties of the employee must consist of at least one of the following
* The application of systems analysis techniques and procedures including consulting with users to determine hardware, software, or system specifications.
* The design, development, documentation, analysis, creation, testing, or modification of computer systems or programs, including prototypes, based on and related to user or system design specifications.
* The documentation, testing, creation, or modification of computer programs related to the design of software or hardware for computer operating systems.
* Lastly, the employee must be paid at least $41 per hour. This does not translate to a corresponding annual or monthly salary; exempt computer professionals must be paid hourly. For example, if the employee works ten hours in a day, he/she must be paid at least $41 for those ten hours-but the employer doesn't have to pay overtime for the "additional" two hours.
I browse at +5 Flamebait- moderation for all or moderation for none.
you're screwed...
.txt file. what ever format you are comformatable with. make sure you keep track of when you are asked to start working on it (you get notified of the work), your estimate of start and stop dates, and what the task is. when you bosses come to seee you about task ____ you can pull that up saying this is everyhing in the queue before and after it. After a few times that your bosses have to come see you about the work load/tasks not getting done, then they will realize that you need more help.
do this. Tell everyone that you will be more than happy to work on their problem/issue/project/task. But based on your current workload, that will will be done by _______. Make sure you are an extra week for every 4 weeks it is away (need the buffer time in there for all the accidentals that popup). Keep a list somewhere.. like a word doc or excel spreadsheet or
Also make sure you document what you do each day.
been there done that... good luck..
Scott
janitor
sdn website family
email: scott at sboss dot net
Can you suggest a good time-management trouble-ticket system that runs on FreeBSD, Linux, OS X, and Solaris?
now we need to go OSS in diesel cars
In Tyler we trust
I've enjoyed some success using index cards for this. I tried whiteboards, spreadsheets, and web pages, but index cards worked best. I think it's because they're physical. They're visceral.
Here's how it worked for my boss and I:
For each task, write it on an index card. Scribble an estimate in the corner (ie, "3 days"). If the estimate is uncertain, write it in uncertain terms ("2 to 10 days"). If you don't know, write that.
Don't skip the estimates -- they're important! Without them, your boss has no idea what the cost of a task is, and can't make good decisions.
Now hand the cards back to your boss and let him sort them. I suspect that being able to handle them and sort them is important -- the boss I did this with really seemed to enjoy seeing the tasks and ordering them by priority.
Now is a good time to discuss scheduling issues. "Ok, I like that order. If I add up the estimates, I see that the integration task won't even be started until 2 weeks from now, but I heard Jerry say it needs to actually be done by then. Should we rearrange some tasks to make that happen?"
Bring done cards to your boss and explain anything interesting that he needs to know. "That one took a day extra, but good news -- that other card that ought to have took 5 days took 3. Our lucky week! And we need to talk about my estimate on the database thingie, it's going to take longer. Is it still important even if it costs longer?"
Your boss will periodically come to you an insert cards into your stack.
The beauty of this is that it's your boss deciding what doesn't get done, not you. And bosses really like making decisions like that... it's what they're made for!
Anything can be done, but only given infinite resources. All you have to do is put it in terms of cost.
"I can do X, but if I do X, I won't be able to do Y or Z and these things are more important."
Usually, as long as you are compentent, being overworked is not a crime. I got fired once from a place where they believed I wasn't competent because I didn't spend all my time pointing out all the things I did. They found out afterward that it was impossible to hire a replacement (because no one else in town had the combination of my skill set and my willingness to work for practically nothing), and that, without someone doing my job, they couldn't support 3 of their largest clients, who accounted for the vast majority of their revinue. A little instant karma for them, bastards.
ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
The key is to not set specific expectations. Generally they will just get really upset if you tell them the truth. In my experience the truth is often along these lines:
1) They need a fix **ASAP** because they've waited the last minute or,
2) Something broke down before a critical presentation/meeting/deadline/visit/etc. or,
3) Your IT staffing level is 25% - 50% lower than it should be or,
4) There are 20 new viruses out in 10 days, 5 of which are unusually effective or,
5) The person assigned to do it will get to it as soon as they can finish their 5th cigarette break or,
6) The budget to accomplish what they wants to do has been slashed to shreds or,
7) 80% of the work has been farmed outside of the US and there are communication (ie language) difficulties or,
8) They JUST AREN'T IMPORTANT ENOUGH.
How do you deal with that? NEVER lie, just skillfully mislead. Sure you will "get on it" and "see what you can do" and "page someone" and "be glad to escalate it" and "glad to call back when I have an answer". Wait 3 hours. Call them back. Tell them you've paged/emailed/IM'ed/met with 15 people and you are trying to get it done but can't make guarantees. YMMV
Yes.
Keystone (http://www.stonekeep.com/keystone.html)
Its based on PHP/MySQL and works great!
JD
I find myself re-acting almost instantly to requests by locking up inside, and wanting to refuse... but i have trained myself to carefully listen to what they want and why they want it. And to review whther or not it is truly a bad request. I think you'll find that many times it isn't such a bad deal. And that it may be totaly reasonable.
however when you can't rightly justify the request, then the first step is to calmly explain in a detail they can comprehend why you feel the idea would be bad for the organization. Most of the time user requests are very small, but have larger implications to the company as a whole. If you tell them that while it may not seem much just to let them do it, it would pose a greater problem/risk to the entirity of your company.
Most people will relate and understand, there are a brazen few who will still disagree vehemently with you... these you must be carefull with. If they are adament, tell them, "ok, i see your point, and i think it may be possible, however i am concerened about certain implications such a change may incur... let me research it as soon as im done with this current project, and see how feasible it is."
Such a statement has gotten me out of more sticky siuations than i can count, an important thing to note during ANY of these conversations is to always be up-beat, and to even make them smile and/or laugh .... you know be kind about it. When youve gotten away from that person.... DO YOUR RESEARCH.... it doesnt necesarily have to be extensive.... but you do need to back yourself up if it is a problem.
allow them to breach the subject again, if it is truly pertinant they will return, but youll find many forget about it... in which case it never was all that important. If they return, present them with your case ... if you found that their request was un-reasonable. If they still disagree.... which should be rare.... tell them you must speak with someone else to see about how to go forward with changes(boss, co-workers, whoeever).... then you'll need to do the beurocracy thing.
while it may suck to ask or tell your boss about these issues.... you'll find that his word relieves you of the pressure.... and if your the boss.... then it is a matter of agreeing on policy with the rest of your executive staff.
The greatest trick to saying "no", is to be social... anti-social IT guys piss off users just by being there... if your company likes you, you'll find your job much easier... and "no" a tremendously easier thing to say.
my personal number one line.... "i know, i hate having to do that too, but it just isn't secure to leave it open, fucking windows."
--VISION
--Idiots, Every single one of YOU, A flaming mass of conglomerated morons, hey wait a second, isnt that how RAID works?
Instead of saying "no", try telling this to the customer/boss/whoever:
:-)
"Think of a number, any number and write it down here. Now keep adding zeroes to the right hand side. When I say 'Stop', that's how much it will cost you for me to do that for you."
-SurturZ
I've seen a few stories on here from people, so I'll add mine...
:) )
Guy works IT and holds tiny 30-person startup together for litterally 3-4 years... workload is getting tougher and tougher and he says that they really need more IT help.
Finally after 6-8 months the boss' agree...
They hire a guy to be his boss, making nearly 3x what he makes...
Then they hire a helper for the boss making 50% more then the first guy...
Finally after about a year they lay off the poor bastard. The new boss and new helper keep their jobs and salaries of course...
Did this guy do a bad job? No, he kept the place running for over 3 years... was he making too much? Nope, he making the LEAST out of everyone in the company (myself included and I was CO-OP at this place!)
They just screwed him and screwed him and screwed him... it's been a good 2-3 years and I joke with him now that they literally did him a favor by laying him off because he makes nearly $20k/yr more at his new job, with regular raises and a normal work load. If they really had it in for him they would have kept him on till the bitter end (they went under about 8 months after they laid him off... hmm... I wonder...
Always say yes!
Say yes, we can do that it will cost this much $xx,xxx.xx
When you start to get ridiculous Project Creep, tell the customer, "We can create a fleet of satellites to monitor and collect the data, then an army of robots to verify data and interface with the client's customers, followed by an implantable cerebral cortex data retrieval system.
With these changes in place the client will not have to DO anything. Our new system will do the client's work for them, the client just has to sit back and collect the profits.
Oh yes, the new system will cost you 17 ba-gillion dollars and take 453 years to complete, but you really want these changes don't you?
Everyone, particularly 'the management types' respond to cost. The cost can be in hard numbers or in trade-offs as mentioned previously in the Vietnam case.
Once they understand the cost of their decision they can properly make it.
If you say "I'll do it as soon as I have time," or something like that, you'll come off as having an attitude. People will soon be saying you're unresponsive and uncaring.
What you need to do is say, "I would love to help you, but I'll need to have my manager prioritize that task into my list." Then get your manager to do just that for you. Every time you go to him, he'll realize that you're not enough resources.
If he suggests that everything is a priority and it all has to be done, stand firm and say, "I can only do eight hours of work in an eight hour day." If he asks for more and you're salaried but not making a respectable amount, you could say, "I would be willing to some extra hours, but I do not feel the pay I am receiving fairly compensates me for that amount of time."
It's a dangerous ploy, sure, but a co-worker of mine had to play that card recently when the boss told him 'Half your time is for outside clients, If you bill more than 20 hours a week externally and put in more than 40 hours for the week, THEN you'll get overtime.' And then went on to ask why on earth so many things in the office weren't getting done. I know he was putting in 40+ hour weeks constantly. He stopped doing it. No more working on weekends unless it was an emergency.
-V
... "I read part of it all the way through." -- Movie Mogul Sam Goldwyn (and some slashdot readers)
1. Say "No!"
2. Get fired.
3. Sue.
4. Write a book about it.
5. Profit!!!
Well it's nice to see that the Americans are willing to vaporize entire cities
That's a were. Our leaders no longer have the backbone for such things, despite the fact that we have the technology to vaporize small nations now.
simply for the sake of humiliating their opponents
No, it's not about humiliation. It's about, we won the war, and we demanded an unconditional surrender. It's kindof like how you say, "we don't negotiate with terrorists." We don't negotiate with people who attack us on Sunday morning when it should be damned well obvious that there isn't a translator working that day in DC to read your declaration of war. What gets me is that we gave them a second chance to surrender before Nagasaki, and THEY STILL REFUSED. I'm sorry, but if they're that fucking stupid, they deserved it. Hirohito should've stepped down and surrendered instead of sacrificing his people's lives to try to keep himself in power.
What a great value for human life!
It was either kill a bunch of them, or let them kill a bunch of our people invading to achieve the same goal. I, quite frankly, think that if you're fighting a war where you're not even the aggressor, you should worry about saving the ass of your own citizens who are fighting to defend/avenge your country instead of some random civilian in the offending country.
The most user-friendly project management tool I have found is a Microsoft Excel add-in called Projex. It is on the web in a file called Projex.zip and it's free for the download at http://www.pcworld.com/downloads/file_description/ 0,fid,16600,00.asp.
Enjoy (and ask for a raise because you saved the company a bundle of money.)
I have had this problem in the past. I was working 80 hour weeks trying to catch up and the reward for doing a good job is more work. The answer is strong management support. I worked with my boss to define my responsibilities and what was expected (SLAs for network and server uptime, maintenance windows for changes, a patch management process, help desk duties, important projects or initiatives, etc). I then tracked time against those and reported status regularly. When a new assignment comes up or work comes over the wall, I assign it a priority (with the help of the requester) and I take it to my manager and ask him what work I shouldn't do in order to get this new task done.
This approach led to the hiring of two more people and the realization that not everything can be done at once. Management appreciated it because it showed them where their IT costs were and helped them prioritize.
My whiteboard helps a lot with this. I keep a list of projects on the board. It changes frequently but it's always full. When I get a new request, I point to it and say, "sure, I'll put it on the list."
Then I ask when they need it done by... If they give me a date that's in the near future, I let them know what else is on the list for that period of time, and ask them to decide where this project falls in priority in regards to those projects. Now they'll always feel that their project is more important than that for another business unit or department. So then you simply say: well, why don't you go check with "Director of that Business Unit/Department" and/or "The VP who is both of their bosses" and clear it with them that this bumps their project's schedule back, and if they're OK w/ it, then that's fine.
They rarely come back insisting on the same date.
You've got a couple other choices as well. It sounds like you are completely understaffed, so consider outsourcing, and shaking down their budgets for the cash to do so. If they want it so damn fast, then they can pay the big bucks to get it done.
Also, consider finding a new job. Any company that underfunds IT is going to have long term problems as a result, including financial stability. While the last IT guy will be one of the last to go, do you really want to be there when that happens?
In my case, I've gone from a staff of 0 to a staff of 3 full time people, and a huge backlog of work to actually getting to tackle some of the gravy projects and doing future-looking stuff. I was lucky in that the company understood the value of technology.
By the way, there are industry average stats for # of computers per support staff. I've heard of 20 Windows boxen per tech, although that seems extreme. My small company ( 150 employees) uses a total staff of 8: 1 Senior Director who is also a DBA, 3 network/server and desktop support techs, 3 programmers for external and internal Web development, and a designer.
The facts have a liberal bias. --The Daily Show
You'd be supprised how far some kind words, a bottle of single barrel scotch, and a fine cuban will get you. Reserved for the proper occasion of corse.
Well.. maybe. Or Maybe not. But Definitely not sort of.
As the Germans would say, you're spurlos versenkt which, loosely translated, means "sunk without a trace." In any event, how you deal with people depends entirely on the individuals involved. You will have to learn which people are willing to be patient, and those who just make lots of noise until they get what they want. I've found that many, if not most users, are willing to give some slack if they're treated with respect and understanding. Just saying, "I'm too busy come back later" makes you come off as unfriendly and unhelpful and alienates your user base.
Personally, it sounds to me like you are massively overloaded and that if you told everyone that comes to you to screw off you'd still be overworked.
The higher the technology, the sharper that two-edged sword.
i say no..
they laugh..
I go without sleep for 2 days trying to meet the dealine
For immediate emergencies this generally doesn't work, but if you've got, say, 20 hours a week available for long-term projects, allocate that evenly among the various departments. Invariably they will want much more than you can do, so you give them first pick. If a department is dissatisfied with the wait time for some project of theirs, figure out how much of their budget they'd need to give you for you to outsource it or hire more staff. If that goes well, set up some kind of an auction model for your time. It will then become very clear which projects need to happen now, and which ones do not.
I work for in-house tech support at my university and that person:workload ratio you've got there is just obscene. If management won't give you the budget directly, you gotta find a way of getting it out of the departments you're supporting.
WARNING: there is a trojan on your
I haven't read all 482 comments but my solution was to write a very simple html page that submitted to a simple Access database where they had to submit problems through this "trouble ticket system". It had a critical rating they could select while submitting of 1 being 'when you have time and 10 being my computer is totally dead and I can't work. Of course I had to go back and change this # but it was alot simpler than dealing with them calling me over & over. That way they could see just how far down the list they were and it actually got my boss to notice how much I do when he looked at the page & noticed over 2,000 open tickets. About 1,000 were things like 'my mouse sticks a little' and I always put them off for after the rate 10's. My little program grew more elaborate as time went on by adding things like combining tickets when a single user had more than one. They finally spent thousands on some lotus notes plugin help desk software that was more work to maintain than my own program but oh well...grin. Anyways they had the option to cancel their ticket and some of them realized asking me to replace toner cartridge in their printer could be done alot faster if they went & asked for it themselves and I found my workload decreasing on it's own.
Two roads diverged in a wood, and I - I took the one the bus load of girls just went down.
I've been an IT systems manager, an IT recruiter and now a non-tech business owner. Here's some heartfelt advice:
1. Stay in circulation. Don't let anything get in the way of networking with folks who can give you a job when this one blows up (it sounds like it will).
2. Stay technically hands-on and current. Use your autonomy to push your own limits and be thankful for that freedom. You're lucky.
3. Document risk. Make sure your supervisor(s) know and can assess the risks of their shifting priorities - shift the choices onto them and keep (to yourself) contingency plans for when things go wrong.
4. Obtain leverage. Interns, unemployed folks - whatever. Recruit help from folks who won't break your bank. Use technology to save yourself time.
5. Produce unexpected results. Want a bigger budget? Stop whining about it and find ways your department can make or save the firm money. As you propose implimentation of your brilliant scheme ask for a portion of the savings or profit for your responsibilities. Be creative.
I've been in your shoes and the outcome is partially beyond your control. Protect yourself foremost.
The CORRECT way is to ALWAYS say NO. Then, if it is a good idea, use it.
You really don't have to if you keep a good work habit of making a timeline or timetable of work-in-hand. If you work in an open environment you can keep the timeline in project names - but if your work is confidential keep a set of simple codes for projects.
You can discuss your schedule and priorities openly if you do this. You'll get two hits this way, first for being organised and second for being open to negotiation.
But when it gets tight don't hesitate to say "No" to impossible demands. You'll still be recognised for having the nous to be organised and the balls to be decisive.
I don't see the problem with your management or your customers here, the problem is that you have unreasonable expectations. Instead of whining on slashdot you should get yourself some Jolt and whip out a Perl program that will do your job for you! Be sure to post it on CPAN before you get laid off. (You will now be redundant). This way my company can use it to trim some of our costs too!
Better to say no right away and deal with a somewhat steep, but very short disappointment curve versus agreeing and not delivering which usually results in a gradually increasing, but very long disappointment curve.
"I'd rather be a lightning rod than a seismometer." -Ken Kesey
Wasn't C-130s, it was something with two radial engines, C-119? They had a mission delivering food to a village, rice at least, and a cow. One engine failed, they had to unload the cargo in a hurry, including the cow, but the cow was too smart to walk out the back door, so he fired his .45 next to it, not to hit it, just to scare it, the cow got the hint, and some farmer got a strange surprise next day. The cow also evacuated its bowels as it left ...
Infuriate left and right
Gosh. Maybe navy supplies move thru air force bases.
Infuriate left and right
Request Tracker. Google it. now if someone can find me a good, OSS request tracker that runs on IIS/ASP...
Janie took my gun...
Most of the time if you can't say no just give time and cost estimates as well as what work won't get done to if you have to change priorities. Send that off to the your manager or whoever is responcible above you for the scope of what needs to be done and let them deal with it. That's one of the few things that management is good for.
Oh are you refering to the 300,000 innocent people including korean prisoners that got incinerated by your weapons of mass destruction? Well, maybe if the Japanese hadn't been brutally occupying Korea at the time, those Koreans (and many more) wouldn't have died. Having said that, I'll leave this weird little off-topic flame war alone.
just say "hm...maybe"
-Q
Let someone else deal with it for 1/10th the price. Spend 5% of the time making sure they do twice as much work as you would have if you were working full time.
If you repeat this process at 10 jobs, like I have, you get 9x the income of one job, and only about 1/2 the work!
This issue is a bit more complicated than you think.
Exactly! I see lots of suggestions to make presentations to Management, or even just make some sort of poster/list that you can refer to.
The thing is, if you're overworked already, WHO THE FUCK HAS THE TIME TO DO ALL THAT?!?
What are you, insane? We vaporized entire cities to force a surrender and stop the destruction of innocent Americans.
Yes, but isn't it illegal to target civilians of the enemy? I don't understand how you can justify the slaughter of tens or hundreds of thousands of babies, women and old people.
Armed forces should target opposing armies, not civilians
off topic - but maybe Americans are finally learning your lesson now in Iraq.
I was hired to a company in October 1999 Pre-y2k. I was also the SOLE IT person for the company. We have about 11 offices spread throughout the state. The network I walked into was in massive shambles. I mean predominantely terminal computers. All windows boxes which well werent standardized having public IPs on the internet. Their mainstay server a SCO box which also was public on the internet. All sessions to the SCO box were in TELNET mode. (Anyone with SSH experience on SCO plZ PLZ PLZ point me out to a site so i can implement SSH on SCO). The actual wiring to the network was cat3. Their method of email system was HOTMAIL.COM. I mean I can literally go on for days or give a massive lecture on how I cleaned up the place. As I cleaned up the place people kept asking me if we can do certain things. I told them many times "No". I made it my policy to not lie to them. If it was possible I did it. If it wasnt I would explain why. I guess you just have to explain NO and why no. I know it may make you mr Unpopular with mgmt or the end-user but Just do it. I stuck to my guns. Now many years later now matter how horrible things have gotten I stuck to it. Now I have a nice tidy network (With exception to the SCO box). We have a real network w/ a standardization for doing things and how my people do their computing. Its almost like working at a real company again. They told me NO many times over but I stuck with it and now they rarely tell me no. But to reiterate.. If you have to say no just explain as to why. I know many people hate saying no and constantly live in fear of losing their jobs. I am one of them myself. Make sure that someone in mgmt can back you up. If you cant say no w/o getting backed up then maybe that might not be the right environment for you. Or you can just drag it out collect a paycheck until something else comes up. I am not sure what your environment is like.. But learn to communicate. If no one talks, no one knows whats going on and if people dont know why you said "No" then its gonna create nothing more than chaos. /end rant
There's no Freedom like UFP-dom
I worked at Sony 989 studios during the development of Everquest.
My hours were typically over eight hours a day and I was asked to work many weekends.
As soon as Everquest was complete they fired everybody and hired back only a few.
Some offered jobs back at $35k
This affected many people, advice would be nice.
I'd like to know if there is anything I can do legally.
In a poorly managed company you have to work out what the politics are simply so you can work out how to say no to various people and do your job as written. Giving proirity to things that are affecting production of whatever the company makes money from will be accepted by a lot of people - but some people bring serious personal problems into the workplace and will chase you from room to room - yelling, because they did something that they would like you to fix then and there, simply because it is the "last straw". Others will consistantly lie to you, then pretend they are joking when caught out. Others will make demands because they don't feel important enough, and they now have someone that will come when they call. I had major problems with a few of the last type of person, and it took a few tantrums on their part before I realised what I was dealing with (and by then management's opinion of me had dropped a great deal). In hindsight, they way to deal with these people is to tell them that their problem is important and to talk to them for a while (and stay back late to do the job you are paid to do), actually solving the problem of the longer telephone cord, or the printer that is three metres too far away (I am serious guys) will not solve the real problem - they will bring up another trivial demand and say it requires an instant response despite the fact that the companies customer support modems have all gone down leaving 12 people idle until you fix it.
Making demands at such a time makes such people feel powerful, so you need to tell them something that makes them feel powerful, so that you can go and do your job and they can stop raving and go back to whatever junior clerks that tell you they are second in importance to the CEO do.
Once you've identified the difficult people, NEVER take away any I.T. equipment away that is located near them - it is THEIRS, whether they use it or not. Do a switch, replace the unused printer that another department needs with a broken one that looks impressive, or just leave it and let the departments that hate each other sort it out. If you do need to take it - let absolutely every difficult person that works near it know - ring them at home if you have to, it will make them feel powerful without wasting much of your time or risking your job.
Needless to say I worked out some of these things after the fact. I'm sure it made a junior employee feel very powerful when my contract was terminated a couple of weeks early. A bad workplace can still be a good place to work if you work out how to deal with the difficult co-workers. I didn't put a very high priority on that and it probably cost me a lot of extra hours of unpaid overtime.
That said, a workplace full of educated people working on long term projects, with lots of interesting hardware is paradise in comparison.
At this point in time I am managing my time poorly. I stopped doing and actual work over an hour ago, and here I am at work after 7pm posting to slashdot! I'd better glance at a screen full of gkrellm charts for servers ( 1 second of actual work ) then turn off the lights, go home for the weekend and read slashdot there.
Here is a quick way to give yourself more time during the day. I used this at Apple, NASA and JavaSoft, and it REALLY WORKS.
Get in to work early. Seriously. If you can get in at 7:AM, then you can update your calendar and already have a LOT of work done before the teeming masses get in around 9:30.
The morning hours are absolutely the most productive of the day. It may take a week or so to get used to getting up early, but once you do, you will really find you can do a LOT more work.
Good luck!
- xtian
"What's that watermelon doing there?" - Jersey
However, if they really need it, they can ask my supervisor to do so, but it will cost.
My supervisor usually asks me how long it will take and how much will it cost, and I give him a huge number.
He tells the customer/employee, and that usually settles it. If they really want it, they'll have to pay big bucks for it,
or they can wait until I have time (which never happens)...
The day Microsoft creates a product that doesn't suck, it will be known as the Microsoft Vaccuum Cleaner!
Know why you are there.
If you do not make the decisions, never say no, or they will find someone else.
If you make decisions, you can say no.
Overall, you need to be relied upon. If people see you and know yuou will address their concerns, and when you do it is quick and it works, your "no" will actually mean sopmething to them. Ultimately, therefore, i'd say it matters on how they view you.
Have you read my journal today?
Some of these folks obviously never had or can't hold a real job. 1st thing - draw the org chart - the REAL org chart not the one they print saying who reports to whom. Anyone who makes a request follow them up the foodchain to find their boss and where he sits. Use where their *boss* is on the foodchain to decide priorities. If their boss is higher up or better able to forward your career then drop what you're doing and take on the new job. Now cover your butt by taking the time to email ,with a copy to yourself, the people whose jobs you dropped "I am sorry but I have been requested to give by priority and thus your job has [pick one](a)dropped off my to-do list (b) been delayed. if there are mitigating circumstances that could affect this decision, I encourage you to present them to for resolution. Thanks."
If they are lower on the totem pole than the job you are currently working on: "I'm sorry but I can't squeeze that in just yet as has me working on . I can see your job is really important so why don't you contact and present him with your problem. I'm sure he will be willing to allot some time from his project to yours."
Ta-da! You have offended no one and got 'em off your back. You have either acknowledged them as king of the hill and boosted their ego AND their opinion of you as a bright perceptive individual OR you've told them to take their project and take their chances with the sharks - but in a way that cannot be faulted.
This is real-world advice and covers the most common offenders. The sneaky bastards are the hardest ones to handle but essentially you drag them down to the boss's office pronto and get a verdict NOW. Do not let them slink away and slime your name because you didn't kiss their butt right away. The good news is that everyone usually knows they are weasels anyway.
Regards, BubbaJonBoy
Hey. You say that you've asked for more resources but got the answer "No!"
Right?
Well, WHO did you ask this question? Why should YOU be their messenger boy? Are you an IT Manager or their personal mouth-piece? If they already have a mouth then it sounds like one of you is redundant, huh?
First Principle: When someone gives you RESPONSIBILITY for something, they simultaneously give you the AUTHORITY to make it happen. When you accept AUTHORITY, you accept RESPONSIBILITY.
Sounds like both you and your boss are confused about this. Responsibility and Authority can NOT (EVER) be separated.
No matter what the President and his advisors say!
If your boss is the man saying "NO" then your boss is the man holding both the authority and the responsibility. Send your petitioners to him by telling them:
"Look, I'm really sorry I can't help you with that. I have this amount of budget that I am responsible for. With that budget I have the responsibility to get this amount of work done, these projects finished, etc. I do not have the authority to spend any of this money on anything other than these explicit things. I do not have the authority to spend any more than my budget, even on getting these done, let alone doing things I haven't been authorised to spend money on.
If the company really needs this stuff done then someone needs to authorise the funds to have us in IT do it."
Mix is up a bit for varieties sake, but that's about it in a nutshell.
I ALWAYS give a little speech about this in job interviews. I let every potential employer know that when they give me responsibility to do something, they're also giving me the authority to get it done. If they don't want to give up the authority, fine, they get to keep the responsibility. I tell them I LOVE being given additional responsibility. I have NEVER had an employer give me any crap about that. They have all appreciated the sense of it in the interview.
(Later, as they're holding the bag, they sometimes regret it. Sometimes I let it slide, sometimes I tell them; "Life's tough, huh? I'm glad you figured that out." It depends on the person and our working relationship.)
Second Principle: There are NO technology decisions, ONLY business decisions.
Buying a new computer, piece of software, network device, whatever: they're all just business tools. The business spends the money in the expectation it will get a return on that investment. If it can get a better return somewhere else, it should go there. If that means it buys a new widget packer instead of a new Cisco 2924 then so be it. That is the business' decision to make, not yours.
Learn to speak the language of business to business people. Educate them that I.T. exists ONLY to serve the business. Let them know that you're not the High Freaking Priest of IT sitting on some damned Mount Inscrutability, but simply a man doing a specialist job with specialist tools, just like the man who cleans the toilets is.
Let them know that you're not going to let them pretend that what you do is magic, that you can make functional IT resources out of an old newspaper and some ordinary household bleach.
Let them know that the authority to spend money on business investments comes from the people whose responsibility it is to see that the business prospers, and that you are not that person or persons. Sound familiar?
Learn how to say this DIPLOMATICALLY.
If you can't say "I'd really LOVE to help you" and mean it, then (A) don't say it, and (B) find a job where you can. The IT industry has enough pretenders and charlatans to give us a bad name, we don't need any more, and you don't need that shit in a third of your life.
But learn to SAY it. Your life WILL be hell until you do.
It's not hard. Its just simple principles that anyone can understand. You just need to apply them to your specific situation sensibly.
Share & Enjoy.
"The fool doth think he is wise, but the wise man knows himself to be a fool." -- William Shakespeare, (1564-1616) Poe
Learn about the war before you make stoopid comments like this.
The Japanese overran China levelled entire cities, raped the women then killed them, slit babies throats, then chopped off the heads of the men and put them on poles outside the city to instill fear in others. Entire cities destroyed the hard way - not just vaporized. The Nazis and the Japanese are the ones that dragged civilians into the war - not the US or the Allies. Or did you also forget places like Dachau and other death camps - mass graves in Poland where the entire village was made to dig a big hole and then were executed and buried in them?
The concept of civilians being off limits pretty much died in WWII. We can honestly say we didn't start it - but we damn well finished it! Then we made restitution by picking their sorry butts up dusting them off and offered our hand to help and in friendship.
regards, BubbaJonBoy
The first, that usually works with "reasonable" users, is the feel, felt, found method. This works very well for someone that has actually been in the users shoes at some point in their career (which may not be your case).
The other approach, which I use to this day (and I've been in this business for almost 20 years), is to create a list of all project requests (and WIP). I would also suggest formalizing the request process, if it is not already formalized. Create a User Request Form, and have them sign it. Even if it means nothing, having a user sign will get them to reconsider the priority of their request (and they should be asked to prioritize their request on the form: Critical - Effects day-to-day business and is customer visible, Medium - Effects day-to-day business and is internal, NOT customer visible, etc.). You see the way this works. You then create a master list of all requests (Priority, Date Requested, Requested by, Estimated Time required to complete the request, Description, etc.). This report, when printed, should be used when you meet with your manager/boss to prioritize your tasks. Your manager will, with one quick glance, know if there is any one employee trying to monopolize your time, know if there an employee is crying wolf, et. During your meeting with your manager, ask him/her to prioritize the list (with you). As new task requests come in, they get added to the list, and subsequently discussed with your manager the next time you meet (which as a new employee should be at least once / week, proeferably twice / week).
Hope this helps.
Sarge
You present yourself as an ignorant high schooler.
It's not what you know; It's what you can find out.
Now I'm not so naive as to think that two wrongs make a right, but I can sympathise with them as thinks that them there yellerbellies had it coming to them.
Plus, fanatical opposition on Okinawa made the US think that it would be similar on the mainland. Some conclude that nuking the cities actually saved Japenese lives - the grannies who would have made suicidal charges armed with breadknives and so on.
Oh, and why didn't the silly twats surrender after the first bomb hit?
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
Those who don't obey the Geneva Convention don't (and quite rightly so) benefit from protection of it. If I'd been in charge, I would have shot every comissioned officer and 1 in 10 of the rest of the Japanese army. And that's if I'd been in a good mood.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
One was told to do it or he'd be replaced by someone who would follow instructions
One who didn't say no ended up with a work-comp injury that the company, eventually, fired them for (illegal, but "prove it" in writing)
One who said "No. Not possible, given the constraints" was replaced by a 'yes-man' Manager wasted about 21 engineer months (15 real months) before the implantation was mathematically proven to be impossible in a public paper (due to race conditions where locks couldn't be used). Entire project was canned, manager was promoted for having the "smarts" to cancel such an ill-conceived project (no one remembered it was he who conceived it :-))
It's sorta like the saying "Easier to get forgiveness after the fact than ask for permission up front." Stoopid managers don't like to hear no, but prefer "yes" with shoddy work and bugs over all else. Knew one manager (managing a government security project) who was proud of having hidden bugs and problems and having beaten another company in competing for a contract (because they were "stupid" and were forthright and outspoken about problems or questions). This manager's motto was "it's not a bug unless the customer finds it" [so any work on "correcting" such "features" was a waste of company resources and an indication of the fixer's inability to follow orders (or so it said on reviews of his employees)].
It really depends on what type of company/manager you work for. But bottom line with global competition for your job is that those who follow orders without question rise the most quickly. Only if there are post-disaster or post-war investigations/tribunals are such ethics questioned -- otherwise, it's just "par for the course" in the battlefield of capitalism (lowest quality product that the consumer will bare for least price).
That's why the government had to create laws to stop exploitation of children, create minimum safe working conditions, minimum wages, product safety commissions, building codes (designed to be the _minimums_ necessary for a safe building, but are used by most builders as the target to shoot for -- because, again, in a capitalistic sense, shooting for anything higher than the minimum will cost more and make you less competitive than those that barely scrape over the minimums.
Of one of these 'do the minimum' managers, a government evaluator, who didn't like the manager's attitude, but had to *pass* him because he met the letter of the law on the minimums: "if you always shoot to just roll over the rim, sometimes you're going to miss".
But things are going to have to get worse before they will get better. Until such managers (and companies) are held accountable for failures, the situation won't change. Until customers stop buying buggy software, product quality will continue to decline (because if the customer is buying it, it still must be over the minimum -- let's try even lower quality the next time!). Anyone who cut their programming teeth during the dot.bomb era has been taught that software bugs are inevitable and to be expected. Software quality has been "spin doctored" to be something that is "not really possible" in real life. Everyone has been given _ALOT_ of propaganda about why software quality is impossible - to the point that most people are now believers. Though occasionally, there comes along a privately held company that disproves the myth (from slashdot, summary on qnx website) that probably got its biggest boost as MS FUD and propaganda.
Only when enough people die wil
You should hold your employer to what he agrees to, but using "the law" to screw him over based on a working relationship you had previously put up with is criminal, and is bad for society. We live in a society that's free and the attitude of "I deserve more" is what causes people to be middle class...go and create stuff by getting friends and using your mind and making it on your own, not agreeing to terms and then realizing later that you were working too hard and "deserve" more pay. You have to be very careful if you use the completely screwed up court system we have -- most of the time you're only doing evil. We'd be a lot better off if everyone realized they "deserve" nothing, but can use their ingenuity to create value.
You can't say 'no' directly. No, not ever. That would violate the idea that your providing 'customer service'.
What you can do is what software developers have done for years. Say, "yes - I'm sure we can make that deadline..." When the deadline comes and the project isn't done and everyone's asking why it's not done, tell them you've run into some problems along the way(which translates as "other, more important work"), and you'll need to push back the deadline. As long as you keep up the impression that your actually working on it, no one will be disappointed.
Once your coworkers catch on, there's nothing management can do about it.
We didn't drop the bomb to end WW2. We could have easily surounded japan and waited for them to row out to us and surrender (they didn't have any gasoline so they couldn't have driven a boat).
My understanding is that we dropped the bomb because we wanted to show the russians that we had the balls to do it. It's pretty fucked up logic, but who knows maybe it worked. Maybe the reason that the Cold War did not end in WW3 is because the russians knew that we would not hesitate to kill an entire city of innocent civilians.
"I can not bring myself to believe that if knowledge presents danger, the solution is ignorance" - Isaac Asimov