I have been asked to provide a brief summary of the what the most difficult aspects of being a project manager of a software engineering project. However, I have no experience of this as I'm still at University and have no "hands on" experience of project management.
I was hoping that someone on SO would be able to provide some insight based on their experience.
What are the most difficult aspects of project management in Software Engineering?
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.
The most difficult aspect to grasp is that software development is much less manageable and predictable than many other activities. Planning is based on experience. First, you need to "test drive" a team to measure its speed in various activities. Then there are various types of projects for which you measure execution type. As soon as team changes or projects become not standard, the whole measurement goes out of the window.
The other thing is the general "misconception" of people being interchangeable. They're not. Some work slow, some very quickly. Some product miserable code, some write fantastic code. Regardless of their degrees, references and years of experience.
The quality matters and you only have ONE chance to do it right in the beginning. The later in the game you attempt some improvement, the more it's going to cost. After a certain time, rewriting code from scratch might cost less than an attempt to fix the current code base.
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
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 it can be obvious why they failed.
Scope management - Once you know what you're building, how do you define what the limits of the system should be? Where is the system boundary, and how can you avoid 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? And how do you make sure that everyone on your team knows that what they're working on at any particular moment is representative of stakeholder's need?
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.
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.