• risk: nature of software
• risk: team dynamics
• risk: roles
• risk: resources
• risk: analysis
• risk: architecture
• risk: design
• risk: implemention
• risk: quality assurance
• risk: project management
• risk: technologies
• risk: tools

The Wikipedia article on software project management includes this:

As a subdiscipline of project management, some regard the management of software development akin to the management of manufacturing, which can be performed by someone with management skills, but no programming skills. John C. Reynolds rebuts this view, and argues that software development is entirely design work, and compares a manager who cannot program to the managing editor of a newspaper who cannot write

The software project management role needs to be done with great finesse, without introducing other risks. Significant risk is caused by the project manager performing technical functions, which is very often the case.

The best role for the project manager is to increase communication between customers, users and development team members. Agile methodologies provide significant help in this regard. Meetings should be kept to a minimum because with the shadow effect, they reduce productivity.

With the old fashioned waterfall mentality, project managers created elaborate project plans with Gantt charts. Software design and construction are intertwined and moves too fast for this approach. It is counterproductive to ask a developer for a single estimate for an individual task and then hold them to it. It emphasizes estimating ability and creates a bad team dynamic.

A more constructive and productive approach is to get continuous updates of time and risk remaining. Agile methodologies gather chunks of work into sprints or milestones, which helps the team focus. Estimates of tasks are combined together with resources to predict a timeframe for project completion. Many individual estimates were wrong, but over a whole project, overs and unders will average out.