Why don't most IT processes work well

(prompted by the common failure of processes for fairly obvious reasons)

The key problem with most IT processes is that they don't deal with the complexity very well. And IT is full of complexity (and is getting increasingly complex)l. The irony is that the IT technology used to implement most IT projects is perhaps 20 years or more old i.e. Word documents, Spreadsheets, Diagrams - but IT people unable to see that they more than most other aspects of the business are failing to execute effectively because they have not kept up with technology I will give some examples: Development methods (e.g. RUP) - putting aside the fact that the method is to a large extent based on the false premise that the functional business requirements can be captured in UML. A key impediment to its success is that its implementation involves a number of documents. These documents are necessary to contain knowledge about the project. They contain information that is high inter-related, and needs to be explicitly connected, and should be able to be analysed. This is manifestly not the case when RUP is usually applied. What is really required is a model/knowledge base that represents the project that can produce the RUP artefacts as reports (and there be more of these tailored to specific audiences and aspects of the project than are produced at present) - while at same time allowing the information to be analysed and connected (i.e. to what exist, to other projects, to quality measures/strategies etc.). This solution would also allow management dashboards to exist to allow management at atomic level. Of course RUP really came from the package SW development domain (which is also where most C++ programming was done). In this context i.e. where there is no specific business as such, no specific business users etc. and where the task is very much engineering (vs the capture and elaboration of requirements that emerge from mist - as is the case with most bespoke development) - UML is quite well suited. Business continuity - is another example of something that is usually implemented in a plethora of highly connected documents. These documents must contain knowledge about the business, technologies, plans, compliance issues etc. and these aspects should be explicitly connected, and able to be analysed. What is required is a model/knowledge base that represents the business situation (including plans for ensuring continuity of operations, and alternatives for executing) that can produce the documentary artefacts as reports and allows the information to be analysed and connected (i.e. to what exist, to other projects, to quality measures/strategies etc.) IT Investment management - [..WIP]