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."
Give estimates (Score:5, Insightful)
Leave that job (Score:3, Insightful)
Tell the truth!! (Score:5, Insightful)
Cover your arse. (Score:5, Insightful)
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
It depends on management (Score:5, Insightful)
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?
I think you're approaching your job wrong. (Score:5, Insightful)
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
Where I work (Score:5, Insightful)
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.
Re:Leave that job (Score:3, Insightful)
Itemize and timeline (Score:5, Insightful)
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.
policies? (Score:3, Insightful)
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.
Comment removed (Score:3, Insightful)
This is a team skill (Score:3, Insightful)
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).
Keeping on task (Score:5, Insightful)
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.
Re:Document! (Score:1, Insightful)
Admittedly it can only improve you so far, and one person can only do a finite amount; but you may as well have that amount the best it can be.
Re:Give estimates (Score:2, Insightful)
Re:Where I work (Score:1, Insightful)
Everyone thinks that their task is "urgent", but in reality they could probably find something else to do in the meantime.
Say Yes (Score:3, Insightful)
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!
Become a Bum in One Easy Step (Score:5, Insightful)
Paper Trail (Score:5, Insightful)
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 [stokely.com]. 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
A wise man once told me... (Score:3, Insightful)
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.
Re:Itemize and timeline (Score:3, Insightful)
They do appreciate the pretty pictures though.
I have the answer and used it, it works. (Score:5, Insightful)
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.
Prioritize! (Score:3, Insightful)
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.
Re:I think you're approaching your job wrong. (Score:5, Insightful)
This is the absolute truth. I'm the sole Network/Network Security person for a company of about 1000 associates, spread across four sites in North America. Production down emergencies come first, but after that everything is prioritized.
I keep a list of every outstanding task I have, and regularly ask my supervisor to look at the list to see if priorities need to be changed. That way, when people come to me with what they consider to be emergencies, I can decide where I think it should go on my list. If they find that unacceptable, they can talk to my supervisor.
I think it also helps to explain risks when I push back on requests. When poor planning results in someone wanting a network change during the day, I explain to them that if they change they request doesn't work, it could affect all 1000 people in the company and ask if it is really that important. Anything that is actually that important usually gets support from my supervisor, his supervisor, etc.
Trying to manage people's expectations will also help. If people know that task X takes Y days, it helps them plan and also gives you better ground to stand on when you have to push back. One of the best things I did was to put in place a policy that non-emergency changes would only occur Wednesday and Sunday nights. It fits my schedule and forces people to plan.
A good phrase is, "Poor planning on your part does not constitue an emergency on mine." If you can figure out a nice way to say that, let me know.
Keep a visible task list (Score:5, Insightful)
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.
Re:I see this kind of problem in general (Score:5, Insightful)
Simple: Lawyers, Plumbers, and Car mechanics are viewed as professionals. They charge an exorbinant rate for fixing things. In business and at school IT is freely given out like candy. When folks aren't used to paying for something, they assume that it in fact costs nothing.
It also doesn't help that we (myself included) are often all to eager to volunteer our help. If we as an industry were populated by cynical and legalistic mercinaries we wouldn't have these problems.
List the tasks and have management decide (Score:2, Insightful)
It sounds like you have a lot of people who think you have nothing to do and they are really important.
Re:Real World?! (Score:3, Insightful)
Re:Give estimates (Score:5, Insightful)
the best "no" is a qualified "yes". of course, for this to work - and to avoid the bad blood that a "sure, but it'll be ten weeks and $9000" will generate - you must get everything in writing!
i can't stress this enough. a lot of clients don't really understand what they are dealing with and thus forget what exactly it was they requested. for your benefit and theirs make sure you get it all in writing! take minutes. do as much via email as possible. get a written specification before you start. that way you can always remind the client of what they originally spec'd and the changes they have made and how it is affecting time and money.
Build A Rep So That They Listen... (Score:3, Insightful)
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.
Re:I think you're approaching your job wrong. (Score:5, Insightful)
If you make sure that everything you are given is allocated a priority, though, then you'll be getting well ahead in the game. The key thing is to define in black and white what those priorities mean
Once you have agreement on a set of PUBLISHED priority definitions, almost nobody will argue with you when you tell them that their request will be performed AFTER some other request. What's more, if they complain you can simply direct them to your manager for an exception (raise the priority based on an ad-hoc decision).
For example:
Critical = More than one employee/system unable to perform their primary business tasks. No workaround is available.
Very High = One employee/system is unable to perform their primary business tasks; OR More than one employee/system unable to perform their primary business tasks but a workaround is available.
High = One employee/system is unable to perform their primary business tasks but a workaround is available; OR More than one employee/system unable to perform their day-to-day business tasks and no workaround is available.
Medium = Employees or systems are unable to perform their day-to-day business tasks.
etc.
Re:Leave that job (Score:5, Insightful)
Entry level jobs on the other hand are very scarce. I would not want to be a college grad right now.
Now amount of stability is going to save you from burnout. You have to be your best advocate of your interests, health, and safety. Employers often rely on you to let them know when enough is too much. Great employers never let things get that far. Places to leave are the ones that ignore your needs.
And I don't buy for a minute that the economy is that bad. Especially for network admins. Just pick up the want ads.
And then... (Score:1, Insightful)
Re:Where I work (Score:2, Insightful)
For most tasks this is way too bureaucratic approach. Of course, as you are on the "right" side of the "counter", it is easy and good for you but your lusers and the techie boss hates it.
The right way is to allow all people to request your time and at the same time allow you to turn down all requests. This way the secretaries don't need to waste time by going through the techie boss in order to get the monitor cable changed and those who really need your time can escalate it to the techie boss or even her boss.
What comes to the original question: prioritize and estimate! You decide how much a task takes and in which order they should be executed. Your superiors naturally may change the order as they please.
Cover your arse even more.. (Score:1, Insightful)
Re:I think you're approaching your job wrong. (Score:2, Insightful)
Don't Say "No", Just Prioritize (Score:2, Insightful)
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.
Underpromise, Overdeliver (Score:5, Insightful)
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.
Outline risk (Score:5, Insightful)
There is no "No" in the workplace. (Score:4, Insightful)
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
Never say "No" (Score:4, Insightful)
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.
Depends on management (Score:2, Insightful)
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.
Re:Leave that job (Score:4, Insightful)
Second, before you start worrying about saying "no" to clients, I would worry about saying "no" to your boss. Tell him or her that the conditions are intolerable, and if they won't do anything about it, maybe you should start refusing to work overtime. You'd be surprised how much leverage you can have, especially being the only one in your company that can do your job.
Here's another thing I've learned in my experience: they almost certainly have the money to pay for extra staff or whatever. They know it, and they don't want you to know it. They have it because they've made a practice out of overworking people and underpaying them, and if you press them, make them realize that's not a real possibility any longer, they'll bend. I routinely convince my supervisor into paying me nearly twice what I make per hour for an overtime shift. I get away with it because I'm valuable, because they have made it a practice of stretching staffing so thin that when one person calls in sick, they are absolutely desperate to fill the place, and because they realize that even with giving me bonus pay they're paying less than they would to bring in someone from an agency.
I would guess you actually have some similar power in your job, if for no other reason than the cost of bringing someone in to replace you is probably high. I'd recommend going to your boss and telling him or her, "These are the things that need to get done, and there is no possible way for me to do all of this alone. If I can't get another 1 or 2 staff members to help me, then these things simply will not get done."
Learning to say no to your boss is, in my experience, more important than learning to say no to the people you work with. If your boss were doing his or her job, you wouldn't need to tell clients no.
In the meantime though, I agree for the most part with what's been said, especially about requiring requests to go through office supervisors. That can help immensely.
The 90% rule (Score:4, Insightful)
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?
Prioritize (Score:2, Insightful)
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.
Re:don't "underestimate" this advice! (Score:1, Insightful)
1. Monday morning meeting to planify, priorize projects WITH the representant of users for each department (1 per dept.).
2. Respect the planning (never do an extra job "for free", that would mean you have way too much time). If a project takes less time than estimated to be deployed, use that extra time to do some recurent tasks (ie: administration).
3. Never accept direct requests from users (that comes with point 2). Every request must have been planified at the monday morning meeting.
4. Do your job and let others KNOW that you do it. It means you have to report to your boss AND the representant of users what you did. That can be the task list, or more impressive, the number of hours you spend for each dept.
What helps me is (Score:5, Insightful)
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
Re:Become a Bum in One Easy Step (Score:3, Insightful)
Say no, lose your job (Score:4, Insightful)
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
Re:Leave that job (Score:4, Insightful)
Bad time to get into a bad job market? Yes, absolutely, although signs of recovery are around. For the first month or so, I only applied for jobs in my county (which, due to population distribution, effectively meant jobs within 30 miles of my parents' home, where I'm crashing on the computer room floor while I search for work). Things were tough. No calls, no interviews. Not many places even send form rejection notices anymore.
About that time, I decided to broaden my search to include all major job markets in Southern California. While I didn't really want to move, I didn't want to stay unemployed, either. As a result of that broadened search, I've had two interviews in the last three weeks. The second one, just last week, was a waste of my time. The company I interviewed with first made me an offer today, and I've accepted it. I start in two weeks, as soon as my boss gets back from vacation.
I have to move about 100 miles away, and I'm not getting the kind of money I would have seen in SoCal a few years ago, but I'm now employed and the money will get better down the line as the economy does.
In closing, to respond directly to the comment to which you replied, it's true that there are certainly ads out there for sysadmins and network engineers. The problem is the ratio of positions to those seeking positions. There are a lot of unemployed sysadmins, underemployed sysadmins, and poorly paid sysadmins out there who are all applying for those jobs. The competition is truly intense. In my entire life, I have (before this job search) only rarely failed to get an interview anytime I applied for a job, and was subsequently hired in almost every case. My overall success ratio was about 80%. I've never experienced anything like the current job market. Since mid-June I've applied for over 50 jobs and only had two calls. Granted, one of those two hired me, but the ratio of applications to calls was still terrible. That's more jobs (by far) than I've applied for in my entire life previously. I have a job now, but my success ratio is shot
Documents! (Score:3, Insightful)
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.
Re:Give estimates (Score:4, Insightful)
If the demand really is absurd, you have grounds to take the employer to court should he fire you. Obvious example: asking you to do something illegal. Your contract should state something about how much overtime you may be expected to work; eg "in emergencies", but if it's a permanent emergency, that can't be reasonable.
I once worked for a complete asshole who piled on the work to an absurd extent. He would call me a couple of times a week to tell me to start immediately on some new project that would take a few weeks' work. When I pointed out that I could only do so by dropping the last thing he had told me to do, he just shouted at me. I finally quit when my salary was months late and sued him for severance. Since then, he's had several replacements bu none lasted moe than a few months. So the relevance to this is that sometimes you can never win, no matter how hard you work. Just document what you do in case it comes to a dispute and they want to fire you for poor performance in not reaching impossible goals.
Re:Sexual Harrassment (Score:3, Insightful)
If you get in trouble for saying 'No', it will not be because of what you said or didn't say in your interview.
OSS is different (Score:3, Insightful)
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.)
Re:don't "underestimate" this advice! (Score:5, Insightful)
The problem is that there is not enough money to pay for the people that are actually necessary to get the job done. It's not that the things are unimportant, they are all important, and there should be more employees on the job handling the requests, but there are not because people can't afford them. I think in this situation it sounds like the company knows that they need to hire more IT staff, but they are not doing it because they can't afford it.
I don't know if there is really any good way to deal with this problem other than get another job - depending on how much you care about your sanity. It's amazing how it all tends to get done at the end of the day!
My greatest concern with this kind of thing is that when being short-staffed is a modus operandi, the employee is never able to excel - the employee is never able to really do their best, it's like being "set up" or something. This might leave you with references that are not 100% of what they could be, and it certainly may lead you to a situation where you are not leaving the positive impression on others that you are capable of leaving on others.
A long time ago, I worked at a limousine company, and we got a new manager (the drivers made more money than the managers) who was fairly overzealous when it came to taking orders. We got to a point after a few days of this guy working for us where we were about 25 minutes behind on every order. 25 minutes late for a pickup, you can forget about a tip. You can't do that. You take as many orders as you can, and then you don't take any more. Sorry, we are booked up. That way, everything you do is done on time and done properly and done well. Overbooking yourself is pointless, you try to do too much, and none of it ends up getting done on time, or being done well. It's not worth it!
A hairdresser is another good example. How many hairdressing appointments can you schedule? Only so many. After that, forget it. Booked up. And the nature of how hairdressers get paid means they get paid more if they work more. More appointments equals more money for them. In many of these new dot com jobs and jobs like the one in this article, there is no "appointment book" and an employee's time is easily misunderstood. Right now, in jobs like this, it's learning who you can blow off and who you can't, who you can string along and who you can't - lots of people will just not say anything, and some people will bitch all the time. Those are the ones that get their stuff taken care of. It's the only way to do it. In this case, the timid get blown off. It's a horrible thing to do, some of the nicest people being ignored because they are not being difficult.
Companies have been doing this recently, and it is very irritating. It's almost to the point where going independent, selling some gadget on Ebay, or landscaping, or some other self-employment kind of thing is going to be easier than it is to work that hard for someone else. If you are going to do the job of three employees then why not open up your own small business?
This issue is really about the proper management of your own human resources. You have to be your own agent, and make sure you are not getting taken advantage of. How do you 1) pay your bills and 2) not get taken advantage of at the same time? Much harder than walking and chewing gum, especially in this time of economic hardships and crappy economies.
Even if you did document how much time you spend doing this or that to prove that you need assistants, the company knows this already, but they won't hire someone. Makes you wonder why we have these blackouts. It's irresponsible from the employer's side.
Combine with Priotities (Score:3, Insightful)
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.
Re:Sexual Harrassment (Score:3, Insightful)
You seem to be viewing this legalistically, when it seems that the parent was talking in terms of human relations at a lower-level; i.e. if you demonstrate you are willing to take any level of crap early on, it is harder to reverse that perception later- in addition to the fact that when you start a new job, you haven't yet got into a work-routine which you (yourself) will find harder to change at a later date.
Of course, life is never that simple, or easy, but that seems the most reasonable interpretation of the original post.
OT: WHAT A GREAT STORY (Score:5, Insightful)
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.
Doesn't really apply to medicine (Score:3, Insightful)
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.
Documenting your time (Score:1, Insightful)
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.
YOU shouldnt tell them ANYTHING (Score:4, Insightful)
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!
Re:Sexual Harrassment (Score:5, Insightful)
If you get in trouble for saying "No" to unreasonable requests, maybe it's time to find a new job. If you can't do something you have to flat-out say it can't be done, and why. If you can't do something under a clear conscience, then you have to tell them no, and why you can't do it.
The crappy economy forced me to essentially become an IT contractor, which, let me assure you, beats the hell out of "would you like fries with that?" I worked at small organizations that had a max of 2 servers and maybe 10 workstations, all running a version of Windows. The longest I had stayed in one place was 3 weeks, and that was due to numerous problems left by the IT guy they recently fired. At several points in time, I was told to make all the administrator level passwords the name of the company because that was easier, and that I should do the same on the server, which holds all their client billing information, basically everything important. They also wanted the server accessible from the outside easily, so they wanted me to install a remote desktop server on this ancient NT server. When I started there, I basically told them they were wide open to an attack and to secure the computers with the name of the company as the password is asking for problems. This wasn't what they hired me for, but I could not, in good conscience, leave things the way they were, and they were glad to pay me to fix the problems they didn't know they had.
There were also several things they wanted fixed that I just could not fix. They wanted me to fix printing problems their custom software was having, and make it stop constantly crashing. Not having the source code, and being a not-too-great programmer anyway, I could not fix coding problems and told them flat-out, "There's nothing I can do to fix that problem, I can tell you why it's not working, but there's not a thing I can do about custom software." They understood this and contacted the guy who wrote it, end of problem for me and the company.
Many times (let's be realistic, 99% of the time) people requesting different IT related things have no idea what they're talking about or how to use what they're requesting should you tell them they can have what they want. In my scenario I suppose I had it easy at a couple organizations since they were contractors too, and basically understood that when you don't know how to do something, you pay someone that does. It took several days to get them to accept that they'd have to remember 8 different characters if they wanted to be secure.
That was just one problem though, I pointed out they had no backup plan and that a fire, or a malicious 12 year old on the other side of the world, could essentially shut their business down in a matter of minutes. This was what convinced them it was something to take seriously, and they started to listen when I said "no, you can't do that, you're asking to get screwed by doing that."
If you're having a problem telling someone you can't do something, or that they have unreasonable expectations, you need to relatively quickly find a weakness in the plan and tell them why what they want is bad. If the people have no idea what you're talking about when you say "leaving protocol/program/box X open like this creates a security flaw," then tell them the same thing in terms they can understand, such as "if you leave this open and something happens, you could lose all your billing information and you wouldn't know who owes you money." or "This could put you out of business if you leave it the way it is."
What's dangerous is saying yes to every request, reasonable or unreasonable. If you adopt the attitude that "eh, it's not my problem if they get cracked" then you're potentially risking the jobs of everyone employed at that company, yourself included. If you don't see a problem with that, you must be one of the people who developed security for Microsoft.
Please excuse any poor wordings of this, I just downed a double dose of nyquil because of the damned flu.
Re:don't "underestimate" this advice! (Score:3, Insightful)
All is not lost... (Score:2, Insightful)
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...
Interesting that you bring this up (Score:3, Insightful)
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.
Re:All is not lost... (Score:2, Insightful)
For #5, an office, with a workbench and all the right tools, with storage for ALL the CD's you need makes a HUGE difference in your productivity. Having a workspace for rapid assembly/dissassembly of servers is KEY. Being able to quickly find the right software is also key. You might find yourself saying "no" less because you can do more. My office also has a few servers that are for my use only. The point is to be able to do most of your work from one spot.
For #6,you should get a feel for your users skill level. There are some users for whom you can say "sure, go ahead and do that." 0r, "I'll set it up, you config it." There are other users that make you cringe when ever they get near a mouse. Both in servicing requests and improving core services, if you are able to assign weights to the requests and the understanding behind them, you'll be better off.
Oh, and John Coltrane... lots of John Coltrane. No problems seem intractable when Coltrane is playing...
Timeline estimate guidelines. (Score:5, Insightful)
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
"Pass the Buck," dude. (Score:3, Insightful)
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.
Turn it around on them (Score:2, Insightful)
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
Simple rules of a software engineer (Score:2, Insightful)
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.
Yes, No, and Expectations (Score:2, Insightful)
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.
Documentation, Documentation, Documentation (Score:1, Insightful)
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
Re:OT: WHAT A GREAT STORY (Score:4, Insightful)
Trying to get upper management to work with us on setting priorities and sticking to them
Amen.
That introduces the corollary of the first rule, [which was to make a prioritized list of what you're working on and to make higher-ups insert the new task where they believe it should be.]
The corollary is that whenever the top priority changes, there is an associated cost associated with dropping project X like a bomb and spinning up to speed on project Y.
In OS lingo, there's a cost to swapping tasks.
Likewise, there's an similar added cost associated with multi-tasking in general.
Any manager worth his salt ought to know that when you fragment a person's effort into more than a couple of different simultaneous projects that you'll pay a price for doing so.
IOW, if my time is devoted 20% to Project X, 20% to Project Y, etc., you can bet you'll be getting 15% quality time on each project. The rest of the time I'll be swapping, worrying in the back of my mind about the other 4 tasks ongoing issues while I work on the current task.
A few pointers (Score:4, Insightful)
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."
Its not just timelines... (Score:3, Insightful)
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.
Re:Give estimates (Score:2, Insightful)
If you lie about a fuckup, and get called on it, you'll get booted. If you accept blame, nine times out of ten, unless you fuck up a lot, you'll get a stern looking at, a finger pointed at you, and life will go on and you'll fix your shit.
Some people want to know what the mistake was, how it happened, so that it can be prevented in the future. Ignoring it isn't always an option.
Index Cards (Score:2, Insightful)
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!
My Experience.. /Begin Rant (Score:1, Insightful)
speed costs money, how fast do you want to go? (Score:2, Insightful)
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)...
Let your boss be the one to say "No" (Score:2, Insightful)
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
Learning to say no -- 1st signs of end of career? (Score:3, Insightful)
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 [qnx.com] that disproves the myth [216.239.53.104] (from slashdot [slashdot.org], summary on qnx website [qnx.com]) that probably got its biggest boost as MS FUD and propaganda.
Only when enough people die wil