TransformaITonal Management

In my experience working with management of several organisation to institute change in IT processes they usually get it backwards. Hence my deliberate misspelling of transformational to clumsily insert IT into the word.

For instance, the first step usually taken when an unacceptable number of failures are reported in production software is to institute an increasingly onerous bug fixing and tracking system. The second step is to mandate a tougher testing and acceptance regime. The third step, if they haven't yet given up on the idea of writing higher quality software, is to examine the software development process in toto. If there is one at all.

Even among those who accept the commonly held truth that most bugs are introduced early in the development cycle it is rare for managers to put their best efforts into the area where they have the highest chance of success. Rather than fix the problem at its source, easy enough to identify by a simple Pareto or root-cause analysis, they will persevere with the option perceived to be the lowest-cost path with the quickest return.

The last place they look is the most obvious. Usually the barriers origin is at the boundary of the project development centre of the organisation. Poor leadership and lack of accountability leads to placement of blame with those least able to ameliorate the situation.

The steps in any project development are well understood. The strategic outlook dictates feasibility and sustainability issues relevant to projects. For each project, can it be funded and can the project outcome be sustained? By definition, projects are fixed-term endeavours with fixed resources that aim to deliver a product.

Short-term thinking easily leads project management to focus on their own risk management to the detriment of the organisation. It is easy for a project to lack focus on its requirements, to skimp on design, cobble together an implementation and deliver an inferior product on time and under budget to testing and production.

Leaving testing and support to wear the incremental cost of rectifying errors that should not have occurred in the first place. Imposing a long-tail liability on the organisation to maintain a substandard product where the project should have delivered an outcome requiring little or no recurring support and maintenance.

The solution partly involves formal processes and quality standards. I propose a quality tax. Maybe call it VVT for the Verification Validation Tax payable out of the project budget for failing to meet it obligations to verify against build process and to satisfy the users' needs.

Like a carbon tax for users of fossil fuels the goal is to encourage behavioural change.