The principles of technology management in financial services are to deliver solutions that
1. meet or exceed business needs;
2. are delivered within budget and on time or before;
3. support (rather than drive) regulatory compliance; and
4. have durability and resilience.
These may sound obvious but it is unfortunately a truism in both government and financial services projects that less than 50% of the above ever get delivered. Meeting business needs is most often missed because of a lack of welldefined objectives and/or loose management allowing IT departments or suppliers to define the deliverables in their own terms, which don't always coincide with the business's. Delivering to budget and on time is down again mostly due to loose control of the management process from both directions. IT departments and suppliers need to have definitive limits but business managers, renowned for either making it up as they go along or changing the rules as the business environment changes, also create problems by being too definitive and not making allowances while budgeting and time-scheduling for resource or market issues.
If it was easy, this article wouldn't exist. One of the most important elements of any project in financial services these days is to either ensure or assure regulatory compliance. If its not the core objective of the project, it will still be there as a second tier. Ensuring compliance means that it is the reason for the development. Assuring means that, as a second tier benefit, the development will also support more general compliance requirements, as well as its basic objective. We must of course remember from earlier in this article that a development or a project need not, and often isn't, a software application. The development may be of hardware, connectivity or application. Durability and resilience are often missed entirely from the deliverable. This can either be hidden or overt. If its hidden, the deliverable is stated as being durable and resilient because it uses or ‘sits' on other technology whose durability is deemed to ‘rub off' onto the project in hand. An example would be a software application designed to run on a Windows operating system. In a business case, the application will have a durability and resilience attached to it by virtue of the development cycles of Windows or the expected obsolescence of the hardware on which the application runs. While partially relevant, the resultant expectation may be inaccurate because the durability of the project may be affected by changes in the market.
The resilience may be affected by changes in the landscape of security threats. So business managers need to be aware of not just the top level requirements but also the underlying technology issues that can impact projects and their delivery.
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: Caitlin L. Foster at 01062010
1. Technology projects and firm resources
All articles are property of their respective authors. Please read our Privacy Policy!
© 2009 ArticleInput.com.