IT has a slogan: 'we have time and money to re-do the project three times but we do not have them to do the project one time right'. There is another believe as well saying that IT people should not expect the right development from the first attempt.
Some blame Business that pushes technology to deliver 'yesterday' without sustaining business requirements, others worship an idea of prompt delivery of something valuable (not necessary what was required and with the value, which might be not really justifiable). The latter is the survival habit caused by the former.
IT knows, more or less, what is wrong but why this is happening and how to fix this problem is generally unknown. This problem may be fixed if we find the criteria of what is right and the means to direct to this right doing. So, let's start from the beginning.
At the beginning, there is Business. I mean corporate Business with its strategic planning and transformation programmes, not an operational business team, which formulates burning business requirements. The strategic planning is based on what the company is doing now and what it should do in the future, why the changes are needed, who is supposed to perform changes and who will benefit from them. This is the cost estimate step only, which leads to creation of transformation programmes.
The transformation programme is the first place where the company 'hides' the cost because the transformation programme is about implementation of the strategic tasks and, as such, embraces numerous risks of ineffective actions and activities. At the same time, the programme has a capability of self-healing because this is the level where Business can manipulate implementation projects dynamically balancing 'money for value', mitigating investment risks and compensating unavoidable mistakes (this is human life after all). Also, this is the level of realisation of business ideas that formulate the high-level requirements to the business transformations/changes the first time.
The better we see the cost of the solution ownership 'forest' behind the project 'trees', the less the projects will cost us
Since in the next step the projects ought to be formulated, it is the right time to challenge the business requirements the first time. This is the job for Enterprise Business Architects who are supposed to review transformation requirements in the contexts of existing business functional model, business operational model, available resources and future transformation outcomes in the future market environment (though the last is better be done during the strategic planning phase). As we know, one of the most effective instruments for business architectural review is modelling and simulation. The modelling has to define what the business services, functions, features and processes should be created in line with the strategic directions; 2) what existing services, functions, features and processes should be changed and what their final states to be. The simulation must uncover what changes in the existing services, functions, features and processes have to be done; this helps to define what their final states should be as well as what new relationships between the business services, functions, features and processes should be set up. If this step is omitted, the company may be sure it incurs hidden cost already.
The phase of defining business projects within the transformation programme (and related IT projects) is associated with risks of loosing money due to inconsistent, missed or overlapping business requirements and project scopes. This is the second place where Enterprise and LOB Business and Technical Architects should review all individual projects. Those Architects must have enough authority 1) to stop erroneous allocation of business requirements and related project scopes, and 2) demand the adjustments. The criterion for changes at this step is agility to the corporate strategy for each individual project. The same criterion must be applied to every business and IT project even outside of the boundaries of the transformation programme. In other words, a business project should be allowed only under the constraint of the business functional integrity. If a company does not preserve such integrity and relays on the Value Chain magic, it risks loosing money on disproportional investments into individual Chain elements that do not necessary provide for the best company benefits in the context of other weak Chain elements.
The IT projects have their specifics related to creation and maintenance of the technical infrastructure that is supposed to support business quality of service. This infrastructure (including new development) costs serious money that Business has to pay to stay competitive in the market. There is a popular belief that an investment into IT infrastructure is a pure 'cost centre' action. I argue that this belief as well as the blur project business requirements generates enormous hidden cost for the business. Nowadays, technology has transformed from supporter to enabler of business in many industries. Investing 'cheap' into Technology means only that Business will pay twice ("the poor pay twice").
Since all projects, business and technical, are paid by Business, it is Business who is accountable to the enterprise for all project level decisions. Every decision of doing something directly associates with the cost of having the results. This is also called a cost of the solution ownership. This cost comprises the cost of the following factors:
- researches and solution discussions
- business modelling and simulation
- programme management
- architectural business and technical services
- project realisation
- project result support and maintenance
- modifications in the operational and technical environment caused by the project results
- fixing the execution failures
- lost business opportunities and customers for each execution failure
The majority of IT operates based on perceptions of the project implementation cost only. In my recent practice I witnessed the case where the business sponsor insisted on the quick implementation of new business requirements as a patch on the WebSphere v.4 Application Server ( the obsolete and already non-supported product from IBM). They tried to save about £19K having an alternative to implement the solution on the modern WebSphere v.6 which required a bit longer delivery cycle that time. The patch was done breaking business and technical integrity and for next two months the business acquired 4 cases of business interruptions and 3 sever errors in the surrounding systems because of malfunctioning of the old Server. It took hours and hours of high level executives and middle-level management to discuss the cases and fixes in the meetings and days of 24-hour work for the developers and business operational personnel to handle the process manually. I calculated the total cost of these exercises and got a figure around £58K.
Though that was a quite convincing illustration of hidden cost, it took significant efforts to introduce it to the cross-division management because low-level operational managers clearly saw a threat to them - it was obvious that the value they generated by 'quick' time to market was undermined by the final results at the enterprise level. The resistance was not about this particular case but about entire idea of considering the cost of the solution ownership as the responsibility of those who make business decisions on this ore that actual implementation.
It is interesting to note that described case had opened the door for the wide acceptance of SOA in the company. In my opinion, the reason was in the clearing the aspects of relationships, interactions and inter-dependencies associated with service-oriented environment. The factors 6 to 9 listed above 'contributed' a lot into the business understanding of the business value/cost of service orientation.
A lot of hidden cost occurs due to violation or ignorance of the business informational and functional integrity. This appears as an isolation of business and technical projects that are typical to the business Value Chain model. A lot of extra cost might be uncovered and avoided if the business needs and requirements were overviewed and considered in the context of existing business and technical constraints and, especially, in the context of the future state of both business and technical execution environment, i.e. in the context of relationships between them. Such relationship consideration is the native part of the business Value Networks model that has its reflection in the IT management model based on ITIL v. 3 recommendations.
Leave a comment