Project Management is interesting for a wide variety of reasons. Despite so many projects having been completed over the years it really hasn’t proportionately improved our chances of success. Of course I truly believe that this iterative way of building helps significantly. But even then I believe the applicability of learning is more limited than other areas. The reasons for this is that there probably isn’t any field where it is so people intensive. Look at the following factors:
Yes, there are many endeavors that need people. But not that many that need people that need to be creative, logical while collaborating towards a common goal.
Productivity – that dirty word – varies wildly between one programmer to another. Having 10 programmers in one team and 10 in another doesn’t equate well. The notion of swapping one programmer with another cannot be done with the confidence that it is a fair swap.
It is very easy to go down a path that is sub-optimal in the ether world. A technology choice, a library package, architecture – and more – all have an impact.
You cant get nine women to deliver a baby in a month. This is very difficult to explain in the software world. Even people who know this very well act irrationally in the face of schedule pressure.
Relationships have a huge impact on team productivity. A happy team that respects each other will deliver better code faster than one where there are clashes of egos and personalities.
There is very little cost to building software other than people. this makes project delivery decisions isolated to adding and removing people.
It is very easy to be optimistic about software. I have never in my 20 years of managing projects seen one deliver all features the team (or at least me) expected to at the beginning. Every project has required difficult decisions around priority.
While you can take a template of a WBS from one project to another – its not nearly as effective as say a construction project. Hence the reason why a PMP isn’t really that useful for a software project.
Many issues have to discovered during the journey and cant be predicted up front.
Let me quote Frederick R Brooks and his Mythical Manmonth on the reason why lack of calendar time is the biggest reason software projects fail:
First, our techniques of estimating are poorly developed. More seriously, they reflect an unvoiced assumption which is quite untrue, i.e., that all will go well.
Second, our estimating techniques fallaciously confuse effort with progress, hiding the assumption that men and months are interchangeable.
Third, because we are uncertain of our estimates, software managers often lack the courteous stubbornness of Antoine’s chef.
Fourth, schedule progress is poorly monitored. Techniques proven and routine in other engineering disciplines are considered radical innovations in software engineering.
Fifth, when schedule slippage is recognized, the natural (and traditional) response is to add manpower. Like dousing a fire with gasoline, this makes matters worse, much worse. More fire requires more gasoline, and thus begins a regenerative cycle which ends in disaster.
Many of these issues are mitigated with an iterative approach of course. This doesn’t mean projects managed thus are immune to failure. Of course estimating using story points help. A prioritized backlog being tackled in order of decreasing value helps. Monitoring progress by defining Done as something that is production-deployable allows us to measure progress better. Even then we run into issues that are touchy feely and ignored.