In a recent short discussion on "3 common mistakes a project manager makes' over at Linkedin, I mentioned that the three most common mistakes are: 1. Rely on his or her instinct and not measurable parameters 2. Manage people and not activities/ deliverables 3. Not set expectations with all stakeholders The set of what one perceives to be the most common mistakes is likely to vary from person to person. Nevertheless, the second point came in for a sharp retort at the forum:

I have a contention on point # 2 in your response. In any people centric organization, managing people is an integral part of Project Management. I am not sure why you consider it as a mistake. Can you explain?

This is not the first time that I have encountered this criticism

 

- that software is "people centric" and hence the focus should be on managing people and not the deliverable. The root cause of this observation goes much deeper- that somehow, software development is something very unique, that it is not similar to other engineering disciplines, that it should not emulate manufacturing.
My contention is that while, like any other discipline, software has its unique aspects, it is still part of the long tradition in engineering. Indeed, over the years, consistent attempts have been made to align it with engineering- establishment of standards, the ISO and CMM models all intend to achieve the same objective.
By stating that software is somehow "people centric", the real point is lost- where software differs fundamentally from manufacturing is that its work products are intangible- they do not have a tangible physical inventory of items that can be measured discreetly, in that software is closer to process engineering where the basic ingredient undergoes a number of changes throughout its lifecycle. In the absence of such tangible artifacts, it seems that somehow it is people centric because that is the nearest tangible association one can make.
Over the years, there has been an increasing recognition of the engineering or manufacturing aspect within  the software industry- where there is the increasing preponderance of "components" (like from Microsoft), frameworks, standards, metrics and processes.
I am sure the the debate will, nevertheless continue, and provide better insights into this still- young discipline.