This discussion has been archived.
No new comments can be posted.
Tips For A Budding Project Manager?
Related Links Top of the: day, week, month.
"And remember: Evil will always prevail, because Good is dumb." -- Spaceballs
"And remember: Evil will always prevail, because Good is dumb." -- Spaceballs
Use goals, not deadlines... (Score:4, Insightful)
Re:Use goals, not deadlines... (Score:5, Insightful)
However, we live in a world where deadlines are very real, very important beasts which will gladly destroy us if we ignore them.
Upper management, shareholders, customers, or whoever expects the product by a certain time, not because they are fucking inconsiderate pricks, but because without the program, they cannot do whatever it actually is, that they do.
For the sake of humanity, don't pull a DNF.
Re:Use goals, not deadlines... (Score:2)
Try to stay ahead of the people's needs, and predict what they will find useful in the future. My department has done this successfully. I would have to say that my boss lets me have quite a bit of autonomy, and I produce good stuff for him. Very few items have real deadlines, and those things are usually menial tasks like scanning & editing & converting things, or programming projects for less responsive and less responsibile organizations.
Provide the required amount of support, but always keep
Re:Use goals, not deadlines... (Score:2)
Not true. You just need to learn how to estimate. The best method is to simply repeat your question as often as needed, in a more urgent tone of voice. Do this enough, and you'll be able to precisely estimate any project, no matter how vague or how far in the future, long before the customers have decided what the project will consist of.
Sometimes this method gives you bad estimates, which you'll be able to spot, becau
My advice? (Score:5, Insightful)
What advice can you guys give me on not becoming a PHB? What are qualities that you wish your manager(s) had
Speaking as someone who has been on both sides:
Don't be a fake, your people will pick up on it.
Don't pick sides. You aren't there to make friends, you're there to get a job done.
Don't be afraid to say "I don't know" and defer to one of your people. It boosts their morale.
Ensure you can back up your decisions with facts and data. Bad decisions will cost you respect and potential promotions. They may even get you demoted or unemployed.
Don't talk shop with your people outside of work on a social level. Those that don't go out socially could perceive your decisions as biased. Ideally you'll minimize social interaction with small groups of your people.
You can't demand respect from your people, it must be earned.
A good manager should be though of as firm yet fair. Not a friend, not a drinkin' buddy, not someone easily influenced.
:)
Basically: you're a Grown-Up now. Your options are quite simple: take the ball and run with it or fail and go back to where you were. Heh, I re-read that and I thought "Man, you sound old." and I'm only 38...
Re:My advice? (Score:5, Funny)
Heh, I re-read that and I thought "Man, you sound old." and I'm only 38...
38? Dude, you are old!
Re:My advice? (Score:1)
No hard feelings.
Nah, none taken. I don't look 38 (39 on xmas eve) and I certainly don't act 38.
Re:My advice? (Score:2)
- B
Re:My advice? (Score:2)
Pay attention to what people are actually producing and how it's advancing the project-- some of your best workers will quietly go about doing a great job, and often go unrecognized as a result. People who pull off heroic efforts to recover from near distaster often get rewarded even when the disaster was essentially of their own making. The people who plan well and do things on time and correctly prevent disasters, too, but they do it so well that nobody even notices. Ma
Re:My advice? (Score:4, Insightful)
I'd add some more:
You're a coordinator. Just like in a real-time device, things break if they get overloaded. Managers are often ridiculed for not doing real work but this is actually important. All my good bosses had free time in their day. All my bad ones have seemed overworked. It's ok to get involved in doing actual work but it's best to say away from the deep projects (ones that require a lot of time to wrap your head around and pick back up if you get interrupted) and remember to keep a little time in your day to sit around and just let whatever's going on stew in your mind. Part of a project manager's job is to see obstacles that will show up in the future. It's hard to do that when you are head down working.
Re:My advice? (Score:1)
Re:My advice? (Score:1)
Agreed on socializing aspects (Score:2)
It pains me to say it, but polite but distant seems to be the safest mask to wear in the office.
Re:My advice? (Score:3, Insightful)
Great list :) Here's a couple of skills and tasks I consider essential:
Care about the project (Score:1)
Plan to debug, you'll have to anyway. (Score:5, Insightful)
"I don't know" is not a crime. (Score:3, Insightful)
If you do this well, you can say "I don't know" quite often, keeping your manager status and respect based on your validation and info distribution alone. Of course, you should also be learning the answers to questions, even anticipating the questions as much as possible. The key to keeping your dignity is not to pretend to know what you don't, and to enforce the scope on questions you're responsible for answering.
Re: (Score:1)
Re:"I don't know" is not a crime. (Score:2)
"I don't know," is never a good answer, but it is often the right answer.
Time and time again, I've seen management make weird ass technical decisions which every techinical person disagreed with. It's a bad thing. If the majority of your programmers say that Ruby is the right language for teh job, they may be right. Sometimes you do have to steam-roll over people with legit ideas in order to get anything done, but don't do it arbitrarily, just because you have the power to.
Re:"I don't know" is not a crime. (Score:1)
"I don't know," is never a good answer, but it is often the right answer.
Reminds me of my asm instructor in college -- on exams he would actually subtract points for wrong answers (and do nothing on questions left blank). He told us guessing is a bad habit to get into, and he didn't want anyone writing, say, auto-pilot software, just guessing when they weren't really sure.
Re:"I don't know" is not a crime. (Score:2)
In my experience it's better not to steamroll, but to actually get the relevant people together (everyone affected by the decision) and be very explicit about the fact that you don't know whether it's the best decision (and that it probably isn't), but that some decision has to be made in order for the project to move forward, and there isn't enough
Learn how to say "No" (Score:5, Insightful)
Note: I'm not saying to not listen to your end-users/customers and understand them. Just don't become this mindless "Yes-man" and sacrifice your team.
Re:Learn how to say "No" (Score:2)
What everyone wants is to get the job done, but no empty promises you cannot live up to.
Re:Learn how to say "No" (Score:3, Interesting)
Last week, one of the VP's was chewing my ass because some code that was moved into production 3 hours after its creation wasn't 100% correct. I stuck up for myself and said, "this is the very first initial version, it's not going to be perfect".
After the VP left, my boss assured me that the VP "is on our side". Oh, and he called me to come into work although I had Strepp throat.
Project Managers, support your people. You don't have to risk your jobs, but try to
Re:Learn how to say "No" (Score:5, Insightful)
The best thing to do is try to weed out the genuine concerns of the end user and present them to the dev team before making any estimates. Nothing angers a developer more than telling him that he has to stay up all night trying to meet an impossible deadline; and nothing angers an end user more than not having what they asked for for the price you give them or when you promised it. Always overestimate to the end user, and underestimate to the developers... it will all come out somewhere in the middle, and everyone will be happier. You won't have to slave drive your employees if something comes up (there is always something), and you won't have to apologize to the client.
When doing your job, a manager must maintain respect and integrity. If you aren't given enough freedom to do that, I would resign and go to development or look for another job. Don't let them corner you into failure quietly! Let them try to find someone else who thinks they can do the job.
Re:Learn how to say "No" (Score:4, Insightful)
I'll second this, but it is only half the story: A good project manager has to be able to say "no" to everyone. You have to say "no" to unreasonable requests from clients/superiors in order to keep your team-member's plates clear to work on the important stuff. You also need to say "no" to your team-members when they either want to go off the reservation for whatever reason.
A good manager, of any kind, acts as a wall between their people and the rest of the organization. They take care of conflicts and keep the team from getting distracted. They get the team what it needs to do it's job, and keep everything else out as much as possible.
Read Slack [amazon.com] and Peopleware [amazon.com] by Tom DeMarco and Timothy Lister.
Re:Learn how to say "No" (Score:1)
Employee wants time off: "Sure, but either get your work done or find someone to cover for you."
Client wants you to do something that your company doesn't do: "Sure but I'll have t
Re:Learn how to say "No" (Score:2)
Re:Learn how to say "No" (Score:2)
However, being a manager is hard. Whereas a tech person is required to go to work, do a competent j
Re:Learn how to say "No" (Score:1)
a manager of what... (Score:2)
Project managers do that - they act as the interface between the 'project' and the people doing the project. They are different to people managers, but still require people manager skills..
WardsWiki has some good stuff (Score:3, Informative)
http://c2.com/cgi/wiki?ProjectManagement [c2.com]
Communicate, and use good tools (Score:4, Insightful)
- design the product
- code the product
- build the product
- QA the product
- release the product
- sell the product
- nor fix the product.
Your job is to try to get all the people who do these jobs to communicate with one another, and to try to be aware of and consider solutionS for ALL the issues involved with the product.To that extent you need good tools to make all the issues as plainly visible to all the constiuents as possible. Which leads to the question: what is the best toolset to do this?
A caution (Score:2, Insightful)
For example, my team was frequently frustrated by sudden changes of plans from their previous manager. When I was on the team, so was I. When I asked what I should
Re:A caution (Score:2, Insightful)
The thing that has frustrated me the most with managers is being given a decision without any of the logic behind it. I remember submitting proposals for things we should be doing that if they gave me a few weeks of time (and an insignificant amount of budget) I figured I could save our team serveral hours of work a week. I put in the proposal (well researched). They asked for some clarification and to add a few things. I did so. At the end they said no. I can handle a proposal bein
Re:A caution (Score:3, Insightful)
Everyone involved in a project should have a picture of the overall goal of the project (who the end customer is and why they want it), as well as be given insight into why their boss is making the decisions they're making, and as much as possible some insight into why the boss's boss is making whatever decisions are going on at
Re:Go to Business School if you want to succeed (Score:1)
Only require what you really require (Score:2)
For example,
- Don't require team members to work 8am to 5pm each day. Instead require what you really want: that they execute on their part of the project within the specified timeframe and allocated resources. For some team members, this will necessesitate that they work during the so called "normal business hours", but for others, it won't
- Don't requi
Project management 101 (Score:2)
As someone else mentioned, your main purpose is to be the glue that hold the various groups working on a project together. This is done through meetings, and schedules.
You need to communicate, and clear up other's mis-communications. Keep asking questions - get the people to explain to you why something is going wrong. You'll eventually become an old hand at doing project estimates!
Re:Project management 101 (Score:1)
Re:Project management 101 (Score:3, Informative)
There's also MrProject [codefactory.se] for Linux, I don't know if there's a binary for Windows. I compiled this on Linux once and it was nice but it broke pgAdmin, I think it was some version incompatibility with GTK
Re:Project management 101 (Score:4, Insightful)
Maybe it's your main tool.
You'll eventually become an old hand at doing project estimates!
That's nice. But projects aren't about delivering estimates, they are about delivering products.
Re:Project management 101 (Score:2)
You are right about the job being - deliver the product, but if you don't have the contract in the first place, you're on the bread line!
So - my point to the guy was that he needs to ask questions to learn HOW the work is done. This makes him better at his job in the future - and less of a pain to the people he has to bug all the time to get their progress reports!
Also- like it or not - MSProject is the standard schedule package in
Re:Project management 101 (Score:2)
Re:Project management 101 (Score:3, Insightful)
I don't think MSProject (or its clones) gets the job done: it forces you to represent far too much detail and complexity far too early, and it will discourage you from exploring alternatives or making necessary changes.
I think good project planning, like good design in general, is still best accomplished with paper, pencils, index cards, and tape.
Have a clue (Score:2, Interesting)
Have as few meetings as possible. Managers seem to love meetings, underlings hate them. I do recommend one-on-one meetings with all your direct reports, but don't make them weekly. That's just overkill. Once a month, or twi
Work Breakdown Structure (Score:4, Informative)
The only way to resolve these two conflicting forces is with good hard data to back up any timetables you are presenting. The only way to achieve *that* is to break the work to be done down into the smallest chunks you can pallet. I personally refuse any time estimate larger than three days and look skeptically at those of one or two days.
The reason for that is that any estimate of "oh, that will take a week" implies that the task has not yet been broken down far enough to actually understand the task. It is perfectly acceptable to say: "yes, but what is that week going to be used doing". Usually you will get "well, I need to revise A, B and C". At that point you can say "give me an estimate of A, B and C separately".
Don't be surprised when the response is "but A B and C all require revising D". You have now achived forward progress understanding your work breakdown structure. D is a prerequisate for A, B and C, and yet your original estimate of one week may not have even considered that. Once you have tasks of "a couple of hours" and "half a day" you can be fairly sure that you have a handle on the tasks. But more importantly, if a task takes longer than it should, at the end of the day you can say "hey, I notice task D isn't done: what's up with that". It may turn out that D is an iceberg task... and you would have found that out a week later under the original estimate, now you have only spent a day learning that you have an iceberg and need to revise the schedule even more.
The truth of the matter is that all programmers are optimists when confronted with a simply stated task and they will give overly optimistic time estimates until you actually start analysis of the problem. Creating a work breakdown structure that is fine grained (don't go completely overboard: "a couple of hours" is a good target point) will help you create your broad schedule with more realistic targets.
Management will appreciate being able to back up your schedules with a fine grain detail (even if they ignore the detail itself) and your programmers will appreciate not being hit with iceberg tasks that kill the apparent productivity. Don't be suprised if the total of the fine grain schedule exceeds the initial WAG (wildly accurate guess) by a factor of 2 or more. Front loading the analysis usually uncovers many things that were ignored.
Re:Work Breakdown Structure (Score:1, Insightful)
Make sure that the estimates include time for clarifying requirements and for the various forms of testing. I've worked with developers who will leave that out thinking that developing and coding are the same thing.
The other thing to do is follow up and make sure that the estimates are being met. Once they begin to slip reanalyze the estimates and give your customer a heads up.
Re:Work Breakdown Structure (Score:2, Insightful)
Which should include, depending on the developer's situation, time for interruptions, such as customers calling, and having to suddenly run off and put out a fire somewhere in already installed/was-supposed-to-be-working code. Also include time for mandatory corporate "training" that comes due every now and then, filling out forms/dealing with corporate bureaucracy for travel reimbursement et al. Also include any system downtime that
Re:Work Breakdown Structure (Score:2)
Unless someone is totally unaware of reality, they should be using the "Working Time" defaults in the scheduling software to exclude meetings and other known overhead
Listen (Score:2, Insightful)
Learn how to communicate effectively in both written and verbal
Remember all of your Bad Bosses (Score:2)
If you haven't done so take some courses in Conflict Resolution techniques or Interest Based Problem solving.
Relish your role as the middle man - your role is twofold:
When the staff need to protect themselves from some unreasonable demand they can refer it to you. They can then rely on you to carry their concerns upstairs in a neutral fashion.
Likewi
shave your head (Score:3, Funny)
It's hard to be a PHB without having hair. You'll still make stupid decisions, but you'll look cooler doing it.
A couple of things (Score:2, Insightful)
Remember that there's no "I" in team. Do what's best for the team at all times and never let things get personal.
Expect software projects to take longer than people initially think. Dilbert once said that to come up with a realistic estimate, you take your initial estimate and multiply it by eight. He has a point there.
I have worked with PMs who can do none of these things and it
Re:A couple of things (Score:1)
Right or wrong, you make decisions that affect and direct the entire team. The best way to do that is through accountability.
If you make a wrong decision, its YOUR fault. Its not the teams fault or its not a specific team members fault.
if as a whole, the team makes a wrong decision, its not THEIR mist
Re:A couple of things (Score:1)
You wouldn't say sorry if you screwed up a project? Maybe this is a cultural difference, but I find that people will generally forgive you more easily if you aplogise. Apologising in itself is paramount to admitting responsibility.
I would agree that it's very important to be able to own up to one'
Re:A couple of things (Score:2)
The important thing to do as a manager, is to be aware of all the different "I"'s throughout the team and to keep them well fed. Then the "I" doesn't get in the way.
Also, be prepared to leave the project and move on to new ones. Software development always needs new talent and new brooms and that means developing the programmers to set up new projects and help you manage them, and bringing in new t
Kicking a dead whale down the beach (Score:2, Insightful)
Don't expect people to do what they volunteered to do or have been asked/told to do. If you don't keep checking on them they will begin to screw off.
The biggest mistake I made when starting out was to assume everyone was as interested in the success of the project as I was. Many times you will be the only person interested in the success of the project. Not even your boss or customers will be really interested. I have found this to be true on dozens of projects.
It's a fine line between keeping people
Some points (Score:1)
Re:Some points (Score:1)
Beware the senior manager or exec who goes straight to developers and asks "how long do you think X will take"!
Get the best people. (Score:1)
How I do it. (Score:2, Insightful)
0 - Not started (obvious)
25 - Activity started
50 - Work in progress
80 - Ready for team review
90 - Team review done and ready for client review
100 - Completed and signoffs completed.
When holding meetings try to set a standard number of days in advance for a notice. Also set a short and simple agenda. One that I usually use has the following items:
Minutes from last me
Re:How I do it. (Score:2)
Re:How I do it. (Score:2)
Yes, I agree with this list.
Those percentages (Score:2)
Let's be a bit more realistic:
And that last 85% optimistically assume
Re:Those percentages (Score:1)
Re:How I do it. (Score:2)
I just quit a job where I was constantly criticised in private and then the higher bosses were told how great I was in front of me, often within the space of a few minutes. This was extremely discomforting (especially since I was usually criticised for doing precisely what I was asked to do - or for not pointing out a problem when I had previously been glared at for pointing out future problems - even in meetin
Re:How I do it. (Score:1)
At the end of the project where I am the team lead I must do an evaluation on each team member and that is a bitch of a job. My last project took me a day to do for the six members of my team.
Planning (Score:2)
One useful idea is the concept of "project velocity": get your team to estimate the time for activities in ideal days, i.e. wi
take anti-depressants (Score:1, Flamebait)
Like everyone else, I've had to put up with a couple of real hardcore asinine bosses over the years. They were annoying, but after a while you get used to their rants and having to explain things to then three times before it sinks in. It's okay, I can deal with that.
The ones I can't stand are managers on ant-depressants. They are just ass-kissing zombies who do not accept any feedback from anyone except their supervisor. It's like they're toddlers again and
Required reading, Some thoughts (Score:2, Informative)
Required reading?
The Mythical Man-Month [amazon.com]
Dynamics of Software Development [amazon.com]
Death March [amazon.com]
Understand the unique challenges that come with developing software. For instance, developers are by nature generally optimistic about technology, since they are in the business of finding creative ways to make the impossible possible. Listen to them carefully: if they're getting ground down, the project is probably in danger.
Understand the relationship between Quality, Schedule, and Cost. The developers must have
Read some books (Score:2)
Never hurts to educate yourself with some techie business books. I like Crossing the Chasm [amazon.com] by Geoffrey A. Moore, especially the way he talks about the "whole product" customer proposition. The Innovator's Dilemma [amazon.com] by Clayton M. Christensen was also a fun read, though it's not directly related to your problem per se.
Eric
PHB Prevention (Score:3, Funny)
Always wear a crucifix. It should keep you safe but if it were to somehow fail and you begin to turn, the smoke from your roasting flesh will be noticed by your subordinates. Assuming you've been good to them before your fall, they will drive a stake through your heart as an act of mercy.
Project Management Institute for sure (Score:2, Informative)
Learn to treat your staff as equals (Score:1, Insightful)
Unlike an unskilled worker, a specialist is valuable because of his special knowledge and skills. He knows more about his area of expertise than you do, by definition. Don't try to tell him how to do his job. Instead, tell him what needs doing: let him figure out how. That's exactly what he's trained to figure out.
Your role
Learn from others' mistakes (and successes) (Score:1)
The project management profession has grown out of the experiece of failures and successes across many industries, organizations, and types of pr
Management Advise (Score:1)
1. A manager's job doesn't involve "Knowing" anything; it involves knowing who knows it and connecting them to the people with the questions.
2. A manager doesn't solve or identify problems; a manager brings what could be problems to the people with the knowledge to solve them,
and then LISTENS to their advice before making a decision.
3. A manager is not an empl
Starting PM (Score:2, Interesting)
The book is a great summary of information. Your primary job is a communications agent between everyone on the project, not as a coder, designer, etc.
While you may asked to plan, you'll need to get the estimates from peopl
Re:Starting PM (Score:2)
And when you've read that, get Software Project Survival Guide by the same author and read it once - a year.
Re: Do Yourself a Favor and Keep Consultants Out (Score:1)
Listen. (Score:2)
Your experts are going to be your business people, developers, testers, and sysadmins. Listen to what they have to say. Don't poo-poo anybody because they are not good communicators.
Once you have mastered the art of listening and understanding what people want and need, then you get to start trying to wres
You are both a leader and a salesman (Score:3, Interesting)
You are the leader of your project. You need to set an example for the attitude and morale of the teams that report to you. Always show up on time, and leave late. Never, never bitch about the customers or senior management. Never appear frazzled or irritated, as that attitude invariable trickles down to your team.
You are responsible for everything that happens on the project. Not just the technical execution of the work, but also the accounting, invoicing, reporting, vendors, and subcontractors. Follow up on everything, because if it doesn't happen, it's always your fault.
Always take opportunities to sell yourself and your company. Take every opportunity to call, or preferably visit your clients. I'm serious about this. Find out what your marketing budget is, and spend every nickel on visiting your clients. Eventually, they'll give you more work just to get rid of you. When dealing with a client, always keep your game face on. Know that you represent the best damn (whatever) company out there, and don't be afraid to take risks. Ask your clients often for more work. This can be a little uncomfortable, but rest assured that your competition is chasing the same work you are.
Expect excellence from your teams. If you don't know enough about the subjects to judge whether the people are producing what they should be, find a trusted advisor who does know, and get their opinion. After clearing it with senior management, quietly solicit some bids from other companies (even overseas companies) on a task-by-task basis to make sure that you are getting the most out of your teams. However, don't be an ogre. Find out the difference between regular, everyday complaining that technical people do all the time and the honest-to-gosh complaining that signals something's really wrong.
Limit senior management involvement. Always ask for help when you need it, but always propose a solution or a set of alternatives. You should try and schedule project reviews monthly or quarterly between senior management, QA, yourself and the task leads to make sure the project is on schedule and meeting performance objectives. Don't cc: half the damn company on every e-mail, and never when you chew someone's butt.
Try and grow scope whenever possible. This ties into face time with the customer, but also knowing what other services your company can provide, and also knowing the specific scope of your project, so that you know when the client requests are going out of bounds. When you do win more work, make sure everyone knows it. This will be one of the things that your boss will be evaluating your performance on.
Clients will always try and get more than what they are paying for, but limit the amount of freebies you give them, and ham it up a little when you give them one. ("You know, I could get fired for this, but since you're one of my best customers, I can make this happen.") Also, don't ever be afraid follow up on an invoice that is getting late. This might be a little embarrassing to the client, so this is probably best done over an e-mail.
As much as possible, define what your requirements are to the teams that report to you. Not just "I need XYZ done," but "I need XYZ done by 21 December. You have 64 hours to do it in, and use charge code ABC123.QQ." If the teams have problems delivering, find out whether it's a problem with your schedule, the team's resources, or if you have unreasonable production estimates.
Celebrate your teams' performance. Even if you're managing the project from hell, find something they're doing right, and send out a quick e-mail to your boss an
Do/Dont (Score:1)
Do:
Make a small schedule and identify the milestones.
"Socialize" the milestones.
Find out if there are any objections to the milestone! Dig!
Identify and remove objections: If someone is late or can't do something, find out why. Dig, cross reference. Remove the objection. If the objector objects too much, flag the person.
Have no opinion on anything: you are pure communication.
You don't know about
Solve the Problems of the Developers (Score:3, Informative)
Problem solving: figure what is the biggest obstacle preventing your team from making progress, remove that obstacle
Staffing: figure who is he best guy for a job, hire the best people available with your budget, prefer one less or a few people less if needed in favour for better quallified staff
Environment: keep optimizing tools and process! If a goal was not reached, why? Why? WHY? What can we do next time to prevent the same mistake? Different approach? Different tool? Different Process? For that you need to get a clue about "what does a software developer do in his dayly work?" You do not need to understand HOW he does his work, but WHAT and WHY
The last thing, Environment, is the most complex. E.g. while I suggest to allways have the BEST tools available, you won't go shopping on your first day and buy a set of 25 different new tools, because then the developers will learn/play the tools instead of developing.
To become a good project manager, you finally only have two choices: shift your career towards medium sized teams, 20 to 30 developers or towards big projects with over 50 to some hundret developers.
If you focus on small and medium sized teames, you have no chance. YOU MUST LEARN SOFTWARE DEVELOPMENT BASICS. You will allways be to close to the matter. A team of _good_ developpers, below 20 developers, simply does not need a project manager. If you want to feel respected and you want to provide value to the team, you need to dig into their work.
OTOH, if you focus on bigger teams you will likely be farer away from developement and the first two points above, problem solving and staffing, basicaly all resource plannings, are more important.
Finally, read something about SCRUM. (google for it) A modern project development approach mainly used in software development. A so called agile process and managment approach.
Regardless where you work, SCRUM will revolutionize your habits.
angel'o'sphere
Joel on Software (Score:1)
Information (Score:3, Insightful)
First Time Project Management (Score:1)