I have never come across a build project that came in under budget. Nor, it has to be said, have I ever seen one that was adequately and extensively costed before it was approved. Some of the issues raised above never see the budgetary light of day, even in a risk assessment. The reader can assume that I'm not a great fan of building solutions in financial services. There are far more ways for such projects to go wrong than there are for them to go well. The speed with which firms now have to act in the market is too fast to really follow for a properly designed system ever to hit the ground before it is entirely or substantively obsolete. Even the build projects which are collaborative between large players, more often than not, fail spectacularly or simply never get enough traction in the market to succeed. Everyone has a different model to work to and there are certainly as many development methodologies as there are consultancies to dream them up. Apart from the technical development methodology however, such as Rational Rose or SSADM, I believe that a simple yet stringent approach is vital. These elements, described below, have almost the same relationship to each other as aims do to objectives and objectives have to activities. Each is a nested element that relates both upwards and downwards and is iterative in any good deployment.
1. Business Specification - defines the needs of the business and the top level objectives that the deployment must satisfy. These would usually be categorised as (i) mandatory and (ii) optional;
2. Functional Specification - defines the specific function sub-set that, in aggregate, allows the business level objectives to be met. This may include both technical and non-technical aspects. This is where the issues raised earlier, for example age and gender, are incorporated through user group analysis. Technical aspects may include things such as acceptable response speeds as well as the fundamental processes the deployment must achieve;
3. Technical Specification - defines the technical architecture that will be delivered to meet the needs and parameters of the functional specification of the project.
This may include adherence to general policies in the business that are not elucidated in the business specification, regulatory requirements (although these are likely to also be in the business specification).
Typically, most deployments will technically follow the layered approach discussed earlier - communications, systems and application levels;
4. Technical Development - represents the build itself;
5. Testing - represents several issues, some of which are often forgotten or left out. First, the final project must be tested against the technical and functional and business specifications to make sure that all the required constraints have been met.
This is usually an iterative process. Second, the project must be tested in its environment with user groups, who will, in a high-grade deployment, also be tasked with simultaneously testing against required deliverables, and also developing the embryonic training schedule, help systems and other peripherals that users will want, and that users are best placed to design. It is a mistake to leave help systems to technicians. They are neither qualified nor best placed to present information to users about the use of the system. This also provides a robust counter-balance to the technical development and an additional layer of fit testing to the basic functionality;
6. Training - would seem to be obvious, but is rarely so. The user groups that were part of the specification stage should be the core of development of training together with the professional training department, if there is one. The development of training schemas should also involve a third group, if resources allow. This is a control group, essentially a group that has no knowledge of the system and can provide a relatively naïve response to the training schema without the pre-judgement of the content;
7. Roll-out - again a critical issue where communication is paramount. Many deployments fail to achieve their full potential simply because the staff that built and tested the system are so close to it that they fail to communicate effectively. A degree of complacency through association is common. The answer is to find a deployment champion who has been peripheral to the project but is senior enough to reinvigorate the project at this critical time and essentially stimulate and excite people about the upcoming launch;
8. Version control - Any deployment of any size will have version control. This has two meanings here. The technical meaning is not our concern here, but the iterative process of identifying, classifying, developing and integrating new ideas or fixes to an existing deployment is of concern to us from a technology management perspective. The success of a deployment is linked to the way in which users interact with it. Unless it is managed well, users fall quickly into a failure approach. The fact that the deployment does mainly what it is supposed to do becomes secondary to the little niggles and bugs that always exist. Other improvements are often market driven and so beyond the remit of many users. And so, the need exists to keep users enthused, to highlight the good things and the savings and efficiencies that are being made. Management version control (MVC) may or may not be contemporaneous with technical version control (TVC).
Clearly, many ‘fixes' will be used as a reason to fly the flag, but this would be a false message. MVC needs to reward users directly for their part in the continued existence of the deployment, not just make them aware of the problems with it.
If you've managed to design and build your own system, the chances are that you are an extremely large organisation. These are really the only ones that can afford it. So, by inference, one of the largest issues, given that the solution designed does what it is theoretically supposed to do, is how it is delivered to its intended audience. I have been struck in recent times, by the degree to which even large organisations have very little sense of self other than at brand level. I see this as a major failure of senior management. There are firms spread over the globe that share the same brand name yet don't have a clue about who or where their co-workers are, what they do and what business units are involved in the same business. I know of firms with global reach who have data on different platforms where the data is not held in a consistent way, where the platforms have no way to communicate with each other and even simple data mining exercise would take months. I see firms which, even though they have a regulatory requirement to keep records for several years, could not produce client transactional data older than six months. These things are not only common, they are endemic to an industry, which along with everyone else thought that two digits to represent the year in a date field would be sufficient.
Problem in that case was that the financial services industry, of all the industries on the planet, have the highest reliance on date-based information. So, before we get too far into the discussion based on a view of the world that uses rose-tinted glasses, let us be honest with ourselves. Our technology management currently sits in the context of constantly papering over the cracks faster than the cracks start to show. So, presuming a build has been effected, its roll-out needs to be considered in some detail. You have to write it yourself and deliver it yourself. One of the most difficult areas of roll-out is integration to existing systems. In any new deployment, integration will need to take place in the context of:
1. Legacy systems that the new deployment replaces
2. Other in-house systems which either:
a. Needed to communicate but could not
b. Could communicate but the new system requires a reengineering of interfaces
3. Other in-house systems that the new system will need to communicate with that the old legacy system did not or could not communicate with
4. Third-party systems that
a. could not communicate with the legacy systems but a need existed
b. existed and could communicate with legacy systems but did not
c. are contemporaneously implemented or implemented after the new system where communications are required
As you can see, even within this rather limited context, what any new deployment does in and of itself is, in the context of modern financial services, by no means the only consideration as to its ultimate efficacy. The most common scenario is that a firm's ‘built' systems consist of two or three core elements that form the basis of its business. Other systems, more peripheral to the core, are open to potential buy or outsourcing as there is a clearer business case to access third-party skills. The core systems, however, are usually a much more ethos-based issue and represent, at least in the minds of the board of directors, the intellectual property of the firm and are listed as such on the balance sheet. To outsource these is a much more painful process, hence core systems in most banks continue to be built rather than bought. That's not to say that outsourcing doesn't have a place. Many firms for example, outsource the hardware portion of a deployment while retaining the integrity of their IPR in software systems and knowledgebases. The one major benefit of a built system is of course that it does encapsulate the skills and knowledge of the employees and the firm's unique propositions in the market. This represented a key value element in the last century. In this century however, the degree of inter-connectivity of systems, and the degree to which otherwise competitive companies must collaborate to survive, means that built systems have far less value in the long run. The cost of keeping up with the outside world using merely internal resources is just too great. Built systems do share some common elements as I have pointed out. Some of these in terms of roll-out and delivery, are the issues of training, maintenance and support.
Our website is not responsible for the information contained by this article. Articleinput.com is a free articles resource thus practically any visitor can submit an article. However if you notice any copyrighted material, please contact us and we will remove the article(s) in discussion right away.
Note: This article was sent to us by: Rachel D. Johnson at 01112010
1. How to use technology in business
All articles are property of their respective authors. Please read our Privacy Policy!
© 2009 ArticleInput.com.