Working for a company, any company is often loosely based on your experience and the things that you as a worker are able to produce - at least this is what the companies would like you to think. Working for a company especially when you are a software developer or a project manager who oversees a software development project is so much more then more then the sum of the capabilities of the people on a given team.
Recently a friend of mine wrote a post on predicting the outcome of a software development project by objectively observing it. He posited that it should be possible to predict the projects outcome and if it is possible to do that, there should be a way of mechanizing the observances being made so that you could always accurately predict the outcome of a given software project. The perceived desire would be to be able to cut off a project that was destined to fail - long before it actually DID fail. What he found is something that I have often felt was at the heart of working for a company in general and more specifically and directly about software development as a whole.
What he found was that it was damn near impossible to mechanize the observations about a software development project and as such to use that information to predict the general health of said project. What he did find was that the social aspects, the interactions that the team was having and how they were having them was actually a far better indicator of the success or failure of a given project. More specifically he stated that the good Project Management of a project was about getting the people on the project who have information that can help you determine the general health of said project to give it up freely.
"Project management is a social problem. It is 99.5% about getting everyone who knows something about the state of the project to share what they know with everyone else. Getting all the relevant information is 99.5% of the problem, analyzing the information is 0.5% of the problem."
For some time now it has been my observation that working for a company and specifically doing software development is a social thing. You spend a great deal of time with the people that you work with, in some instances more time is spent with the people that you work with then you spend with your family at home - it should, due to that fact, stand to reason that what you do at work is going to have a social aspect to it. Beyond that you have to take into account that in order to like where you work you will also have to at least like "SOME" of the people that you work with. Add to the above facts that software development when you are part of a larger team is about information and its exchange you can not help but come to the conclusion that Project Management is about being social.
Think about it this way:
Software you are developing on your own, by yourself only requires that you know whats going on. Software developing in a team requires that the whole team know what is going on and that the information about whats going on is 'well' communicated to the company / project management.
I am sure you have all been on projects where this is not the case. Better yet you may currently work for a company that doesn't foster open and honest communication about project/development status. Did you feel that any of those projects where successes even if they actually did succeed? Or did you feel that the project somehow miraculously succeeded in spite of itself? I personally fall into the later case more often then not.
So whats the take away? Spend time in your company fostering open honest communication, either through tools (wiki, threaded forums, IM) or via personal interactions. Those open lines of communication can only help the situation not hurt it. If you squelch the lines of communication and ignore the social aspects of the working world you will almost certainly be destined for failure.