The world is a capricious place

Given the amount of moving parts – one wonders how it could be anything but. With the interests and desires of billions of people, the millions of companies they work for and the hundreds of countries they live within; it becomes relatively easy to understand the depths of the complexities, but far harder to understand the complexities themselves.

In the much smaller geo-corporate domain that is global IT, we are able to reduce the number of imperatives and variables several orders of magnitude; however vast amounts of the complexities still remain. Unadulterated successes continue to be such rarities that they are viewed as curiosities and so when we hear about them we tend to like to study them and understand why they were so successful.

Most of the time the analysis of these successful efforts, be they products or projects, points to successfully meeting expectations rather than completing requirements. This in itself is a very subtle point and is often missed in our line of work. Actually, who am I kidding, it is not often missed, but rather rarely realized – otherwise why would our successes be so rare.

Software development, the chief component – though in no ways the only component – of Global IT, started out as an art form. In the early days, examples of success were accompanied with associated tales of heroics from nearly super human programmers. The dramatic vagaries of the hit and miss nature of these efforts pushed the industry towards structure and rigor – establishing the discipline as a science that could be engineered. We invented frameworks and standards and eventually schemas to license practitioners. When this did not increase the probability of success substantially, we began to examine the differences between leadership and management. Unfortunately, like many business disciplines, we lost our way and focused on the precept that if we managed more strongly, we could manage out some of the degrees of freedom and improve the resulting probability of success.

Rather, what we accomplished was the introduction of regulation with the drive to reducing the statistical variation between what we asked for (including schedules and budget) and what we got. For a number of years, and an entire genre of literature, IT project management focused on how to encourage the teams to deliver what was asked for, when it was asked for, within the financial constraints required. It was here we coined the phrase “better, cheaper, faster!” It was also here where we discovered that in a highly regulated discipline, your IT organization could be considered no different than any other kind of factory with your staff viewed as interchangeable functional units, or “resources”.

Once we were of agreement here, the global economy kicked back in with a vengeance and we created a supply and demand based industry and the Outsourced IT model was born. But as Martin Fowler, a current day industry notable has been quoted: “I take the view that IT development is done pretty badly. If your communication is screwed up, then offshoring to India isn’t going to improve the situation. [But,] I suppose if you’re going to screw up anyway, you might as well pay less and screw up.” This is certainly not a complimentary view point and it is certainly not limited to India. You can substitute any country or culture you want. India isn’t even the most inexpensive outsource location anymore, though it is still the most common due to its vast number of highly trained individuals capable of working within the regimented frameworks we have invented to govern our attempts to force adherence upon our teams.

It is interesting to quote Martin here, as his punditing has, as of late, been focused around the Agile methods. These are still commonly viewed as ‘cowboy’ methods – unregulated, unreproduceable, and oft able to induce stampede behavior totally destroying not just the project they were working on, but the entire town through which they were riding. So why do we quote Martin? Because the agile methods focus principally on meeting expectations not completing specifications.