What are the most difficult aspects of project management in Software Engineering?

Most difficult, hmmm First and foremost the most difficult part of project managment is that you are dealing with people. People who don't know what they want, prima donnas who don't want to do what the client wants, people who have sudden personal problems that affect your schedule such as these that I've personally encountered at work: the analyst who left her husband the week before a deadline when she hadn't finished the requirements yet The dev who found out a two days before the deadline that his wife had lung cancer The dev whose husband died four days before a deadline Next most difficult - pining down the actual requirements. First because people don't know what they want and second because there are many small details that are hard to know about especially if they are in the back end and not the user interface. Project managers are often in the middle and have to deal with many crises. They are the ones the who get slammed when the the client discovers a bug or when the application doesn't work the way it was expected to work (even though that particular expectation was often not ever expressed). They are the ones who get to tell the client that the project is running behind or over budget or that the requirements need to be scaled back. They are the ones who have to tell the devs that they have to work overtime to meet an arbitrary dealine that "Can't" be moved even though they know and the devs know that when the the client has a last minute change (which they will) , the client will hapily move that can't move deadline. When things go down the tubes in a major way, they have to find out why and they have to explain to senior managment what went wrong and what they are doing about it. Another difficult issue for the PM is hiring and firing. It's hard to get the best staff. It's even harder when you aren't the hiring official and have to negotiate internally to get good people assigned to your projects. It's even more stressful to be the one who has to say, this person isn't performing and has to go. Especially when you know he's the sole income and his wife is pregant and they need the health insurance. But sometimes you have to be the bad guy.

Inception - Determining why you're building a software component, and who is your target stakeholder and user. This is perhaps second most important, after remembering what you decided. Sometimes a software system obviously skips this step, and http://en.wikipedia.org/wiki/Microsoft_Bob. Scope management - Once you know what you're building, how do you define what the limits of the system should be? Where is the http://books.google.ca/books?id=h4pPpXp-xrEC&pg=PA52&dq=software+system+boundary&hl=en&ei=fXr2S4-zPIT78AaxmvnRCg&sa=X&oi=book_result&ct=result&resnum=1&ved=0CDMQ6AEwAA#v=onepage&q=software%20system%20boundary&f=false, and how can you avoid http://en.wikipedia.org/wiki/Feature_creep. How do you decide when a feature doesn't serve the needs of your stakeholders? Traceability - How do you prove that the work you've done corresponds to the the requests your client made? How do you prove that the system you delivered delivers on the terms of your contract, and that additional work is in fact additional work? http://www.codinghorror.com/blog/2007/09/can-your-team-pass-the-elevator-test.html?

Well if the Project Manager does not have a technical background, it will be difficult to track which programmer is on track with the daily activities. Bit like the boss with wally in dilbert

I think the main common challenge may be that trying to manage engineers is like herding kittens. Trying to keep everyone going the same way will be a challenge, but that can be true for any endeavor where you have a large number of engineers working together. If you are starting with a new project, then trying to decide on a methodology, such as waterfall or agile, or some hybrid, may be easier than if you have a very process-heavy system and you want to make it more agile, as you will run into culture pushback, but that is the same whenever you are trying to make system changes. You can see this in some of the writings by Peter Senge.

Managing expectations - Expectations of the stakeholders, testers, developers, and anyone else involved in the project would be my answer. Each side has their perspective and it has its own biases that may or may not always been easily seen. When something does work out as planned, how does the project recover from that? If requirements change in a massive way part way into the project, how is this handled? Those are a couple of questions that PMs deal with on a regular basis I'd imagine.

I am not sure whether project management is that difficult and only those with PMI can manage it. What I have personally come across in my entire life in IT field is which is where I come from, that Project Managers are not technical people and they only understand what they have been taught in PMI. This is not really good for technical people who are on the front end who do the job. Ofcourse, there are technical people sometime who are not clear about what needs to be done, or for that case I have managed projects without any PMI and I have made it successful without any project management. PMI has become some kind of strategy that is used nowadays. This is not something I would say that it is so great. On the other hand now I am facing another challenge of dealing with a project manager who was technical and he/she (not to be specific about the gender) thinks that they can be hard on the someone and think that they can get the job done. Well, in the first place this person itself was the one who initiated the project and moved up to be a PM with a PMI and the person thinks that they KNOW IT ALL. I thought initially, that it has to be a technical person who has to lead the project, but unfortunately that has become a nightmare. I was thrown into a project which was never done by me, but took up the challenge, it is almost there, but unfortunately, it is getting frustrated as at the customer end, we have difficult people. Most of the time this is faced with companies that are outsourced and the customers side people think that they are loosing their job or might lose their job and make it difficult for you to make things work. So, there is no one golden rule, as I could say this from being in this industry for almost 20 years.......I hope there is a golden rule that everyone can follow and make things work. But, I can go on and on in how some of the projects it does not work having a project manager who thinks they can manage project, time and cost. It does not really work. Maybe, another certification on your shoulder saying I am PMI certified, but that is not really true, because they are not taught the real world scenario in a technical project and the many things that are involved. I wish I had chosen some other career, regret and can't get out of this also.