(contd)
This paper touches on a vital subject on page 8 under project outcomes. In the most understated sentence of the paper the authors say "In general, there remains a lack of consensus on how to define success, lack of success, and failure." In my commercial work, this was rarely done well and often remarkably badly. I remember being the junior member of team from a subcontracter under one of the most respected management consultants in the country discussing the initiating phase of a major project for a F100 company. I naively asked what benchmark they had established against which to measure the success of the project. You could have heard a pin drop in that room. There had been no thought to gathering any baseline of the existing performance of the system despite the clear need to demonstrate a hard financial benefit from the project. There are many times that metrics matter and in this case they mattered a lot. We needed to discuss the various ways that success for that project was going to be measured and take the time to gather the basis for comparison. An this was one of the successes.
Too often a management team will not be interested in doing the hard work of reifying their needs to the point of any metrics at all, no less a set of metrics that will withstand the intense scrutiny that is shone on a failed and expensive project. Yet for corporations that invest great amounts of time an effort in management information systems and detailed cost accounting it is astounding how often major capital projects are undertaken without any regard for how success or failure will be measured. Is it any wonder that when the way the success will be judged that success is sometimes a reconstructed reality post hoc?
In summarizing their survey, these authors offer several important dimensions: technical, economic, behavioral, psychological and political. Clear above I was focusing on the economic which can lend great clarity to decision making when it is the driver behind the project. With some reflection I can think of instances of the others. For example, the installation of some form of middleware or infrastructure is clearly a case of the technical dimension. While the project may run over budget or time, those are largely secondary since the need is to establish that technical capability for many other projects to leverage. While it might be desirable to quantify the payback on this kind of investment, it is rarely possible to do that easily and is often not worth the bother. For these other dimensions, I'll be interested to read the cited papers to get a better idea of what they have in mind.
I naively believe that the central point of success or failure can only be measured against the motivation for starting the project. If that objective has not changed over the course of the project, a well thought out and reified objective should provide many points to argue for the success or failure of the project. Where there has been failure, they should also provide some trace-ability back to the decisions that caused the outcome and objective to diverge.
**************************
I am rethinking my plan of working through this paper at this depth. This lays out a very big forest to me and while I am looking for a few good trees to prune, I can't complete the survey in one or two sessions. I intend to refer back to this paper throughout the year as I try to survey the various areas within the scope of ESE.
This raises an issue I have been struggling with to understand where ESE fits in. Where is the line to be drawn between Economics and Software Engineering? Clearly Boehm made a significant name for himself at this intersection. Since SE is about purpose built products it is hard to imagine that economics are ever too distant. Yet how risky will it be to invest myself in looking at the utility curves of the various choices that can be made in development?
No comments:
Post a Comment