Process vs. Outcome

Enterprise software development is a discipline in which process is often a deciding factor between success and failure. In my experience, more often than not projects run over time and over budget which I would put down primarily to one thing, focussing on the outcome of the project rather than focussing on the process of achieving the outcome. Through desperation, most managers falsely believe that adding more developers will help. Instead deadlines slip further. Getting developers to work longer. Instead deadlines slip further. Emergency measures whatever they may be. Yet deadlines still slip further. In other words, most software projects are conquered with brute force rather than careful thought and finesse. Instead of concentrating on eating the carrot, why not first work out how to get the carrot.
As anyone who has thought about software development for what it is can tell you, the complex relationships between understanding client requirements and technical complexity are difficult. Only when the actual process of the software development process is addressed are development teams enabled to start building malleable and flexible software that meets business and technical requirements. What needs to be understood is how software that is malleable and flexible in its design is cheaper to maintain, easier to build and less problematic overall. Only with a disciplined process can this result be achieved. Unfortunately, the brute force approach nearly always creates software that is late, over budget, barely satisfies the business requirements. Moreover, a long term legacy of difficult and expensive maintenance is born. This approach of focussing on the outcome rather than the process behind the final outcome comes down to our need for instant gratification regardless of long term results. It’s the feel good factor that drives us. When projects are faced with challenges a well defined process does not instantly lead to better results but in aggregate it does and this is why most people continue to carry on with the brute force approach. It’s the average speed, not maximum speed that counts.
To me, it is pretty clear that investing is not much different from software development in its need for process. Process brings to the table a set of disciplines that are not available with a “gut feeling” approach. To consistently repeat logical decisions a well defined process must be in place. Sustainability of execution is the all important. However, it is important to realise that even with a “superior” process we will not be guaranteed against failure. What we will see is a lower chance of failure. We are just moving the odds further into our favour. Over the long term, we will see an stronger aggregate result.
We are seriously limiting our chance of success by focussing on the short term. As investing is a probabilistic endeavour it can not reasonably be expected that a process will lead to a desired result every time. Coin tossing is a useful analogy of how long term results revert back to a process mean. A toss of a fair coin obviously has a 50% chance of heads and a 50% chance of tails. If coin is flipped twice is this going to be an indicative of these probabilities? The chances of flipping two heads or two tail are pretty high (25%). However the more times the coin is flipped the closer our results will be 50% heads, 50% tails. This is the mean of our process and over an extended set of outcomes it can logically be assumed. In other words, this is “the law of large numbers”.
An investment process is exactly the same. If you only give it a limited chance to work then the chances that you will be disappointed are high. You are not moving the odds into your favour because you are forgetting about the law of larger numbers. Accepting that there will be periods of under performance and that the aggregate results are what count. There is no such thing as “the law of small numbers”.