Research Korner: Profitable Trading Strategy

Trader Project Case Study

Introduction             It is the objective of the Trader product to develop methods and tools for ensuring reliability of consumer electronic products. This should result in minimizing product failures that are exposed to the user. A number of technical trends in embedded systems press a need for better development methods resulting in reliable products.  Complexity increase: the extent and complexity of embedded systems and software has been exponentially increasing in recent years and there seems no end in sight for this trend.  Product life cycle decrease: The innovation cycles for these products is decreasing continuously and has in many sectors now come down to a few months.  Open Systems: embedded systems are opened to the outside world as a result of which security, reliability, and availability are emerging problems. They become more open in two ways: They will not be solely developed by just one manufacturer. Increasingly, the provider of the basic functionality will be host to third parties who will add their own functionality.  They will, during their lifetimes, become involved in networked environments that affect these systems in ways that are not foreseen during their creation.    Project Objectives The project concerns itself with the evaluation of software, its acquisition and subsequent enhancement by the supplier, its installation in user premises and maintenance. The software enabled the finance of international trade to take place more easily and more accurately.   The Project Context             Barwest Bank has been involved in foreign trade and the finance products related to it for many decades.  Before the introduction of TRADER, all operations had been on a manual or semi-automated basis using the SITPRO multi-part set.  NOTE that SITPRO is just a set of documents.              Within Barwests, all foreign trade work whether collected by the account holding branch or not was forwarded to the specialist area, known as the Foreign Services Office (FSO) or its 14 local outlets, the Foreign Service Branches (FSBs).  These outlets handle a variety of business, including foreign currency, travellers’ cheques and the provision of Letters of Credit and Collections for its customers.              The ‘section work’ to be automated was a) Documentary Letters of Credits and b) Documentary Collections, together with the documentary evidence – normally Bills of Lading; Air Waybills; other forms of Manifest, Insurance and Bills of Exchange.  Each of the above documents forms a ‘complete set of documents’ but there may be several identical copy sets numbered ‘Copy 1 of n’, ‘Copy 2 of n’, etc.              Often ‘sets’ follow different physical routes – e.g. the originals travel by sea with the goods whilst another set is sent airmail to the recipient.  This enables the recipient to check that the goods being sent are the right ones, to arrange for finance to be available when the goods arrive; and for the payment to be made releasing the goods to the recipient.  It is important for the Bank to pay only on receipt of the correct set.   The pre-project scene (from September of previous year)              Bernard Bresslaw has been working in FSO for many years, and is Number Two to Mike Oldfield. He had seen an opportunity to automate the work of his area, and thus expand his importance. As a casual activity, he had been superficially investigating off-the-shelf packages to meet his main requirements.   Amongst a number of other companies he had visited was ABC, a US-based software house, where he had been entertained quite extensively. Rob Kramerski had also put him in touch with Graham Gooch, a manager with a rival bank, who had experience of implementing the ABC package in Lloylands Bank.   Bernard and Graham discussed the ABC package known as Trader and, in passing, Graham mentioned that he was thinking of moving on from Lloylands. Bernard jumped at the opportunity and hired Graham for his expertise.   The Project’s commencement Bernard and Graham decided to proceed with the Trader package and simultaneously commenced negotiations with ABC for the package acquisition. They set up a business team and then prepared a business case.   Once all these activities were under way, Bernard decided that he needed some assistance from the central computer department and so contacted the Chief Executive, John Turnbull. A new entrant, John was the first American to be employed by Barwests Bank at such a high level. He was trying to engineer change across the business and strongly supported Bernard's initiative.   The IT Team were brought together with Malcolm Shenley as the senior IT representative and Wally Welling acting as his adviser. Dave Duckham was given the task of leading the IT project. Note: Barwests Bank had progressively moved away from Assembler Language and Cobol 1 to become a Cobol 2 shop using IBM 3090 machines.   ABC had been contracted to deliver the system and have it operational within five months. Under David Jenkinson, they brought a ready-made team of three people (David himself, Iqbal & Jenny) across from the USA to help with the implementation.   APPENDIX 1 - BUSINESS PLAN (extracts)   The business goals were to:-   <ul style="margin-top: 0in; margin-bottom: 0in" type="disc"> <li class="MsoNormal" style="text-align: justify; line-height: 200%"> introduce an automated international trade finance system based on the ABC package, Trader, within 5 months;</li> </ul> ·        reduce staffing in the FSO and FSBs by 25% after full implementation; <ul style="margin-top: 0in; margin-bottom: 0in" type="disc"> <li class="MsoNormal" style="text-align: justify; line-height: 200%"> provide a sufficient return on investment that breakeven occurs in year three, with profits in year four onwards.</li> </ul>   Benefits   There were 14 branches and the central office totalling at the time, 400 staff, of whom about a quarter were involved in LC & DC work. The software supplier anticipated a staff saving in the region of 15-25% once Trader was fully operational. The capacity for new business was expected to be enhanced by the new system and forecasts suggested the ability to capture rivals' business to take a 40% market share by year three.   Managing Setbacks             The project schedule passed to the Project Manager was the initial impediment to the flow of the project.  It was when the Project Director had proven the perceived schedule to be unacceptable.  However, the Senior IT manager responded to the matter by enumerating the reasons why it should take seven months instead of five months that the Project Director indicated.              First, the Senior IT manager said that (a) the software has yet to be received, (b) the staff are untrained in its use, (c) the business requirements are still being identified, (d) the business case presents an over-optimistic cost position, and (e) the known amendments are quite extensive.              The above concerns would be enough to support the seven months plan of project activities.  These statements come from the IT sector itself that knows how the timeframe of the project activities for the smooth assignment.  Notwithstanding these reasons, the Project Director insisted on meeting the target date rather than the planned seven-month period.              Apparently, there had been a bit of disagreement as to the matter of project timeframe.  It should have been avoided had the communication between the User Department and IT department been discussing the timeframe before the project commenced.    Problems with the Software Supplier             The software supplier plays a great role in realizing the project objective of evaluating the software, its acquisition and subsequent enhancement, and its installation in user premises and maintenance.  Prior to the commencement of the project, there seemed to be no further business plan that would anticipate setbacks.              The predicament with the supplier came when two additional software staff arrived in addition to the expected one.  It actually created accommodation problems since they will be covered by the company until the last part of the project.    Problems with the Software Application             The Systems Analyst was the first person to notice the early problem encountered since the software acquisition.  He had spelled out three concerns associating to the acquired software system; (a) the sprocket feed is proving unworkable for the constant changes of stationery which are planned, (b) the company should buy a board to allow the font variations required that would cause additional expenditure to the project, and (c) the printer is subject to breakdowns and evaluation model has required an engineer each day within the week.  In the later month, the problem with the printer got worse as the printer board is no longer manufactured and apparently wouldn’t satisfy the users’ needs.  Moreover, the only choice recommended by the software supplier proved to be in a floating situation as its cost is not known and will possibly cause the budget and the roll-out schedule as well.             Furthermore, the Business Manager in the user department realized the incompatibility of the kit to the FSBs purpose.  It had also proved that impracticality of sharing a terminal which had been discussed in the project plan.   Conclusions and Recommendations             Obviously, the project went on a somewhat unplanned structure.  The business goals timeframe did not fit to that of the IT Department.  Along with the aim of introducing an international trade finance system, reducing staffing in the FSO and FSB by 25% after full implementation, and providing a sufficient return on investment that breakeven occurs in year three with profits in year four onwards, require a solid preset business plan that would look forward to realizing these goals with the considerations of possible problems that may occur along the project work.               The case got its huge fall on the dire communication between the IT department and the supplier that had caused further expenditure.  To mention, the IT department should have cooperated with the software supplier prior to the commencement of the project anticipating the actual needs of the users such as the Correspondence File.  How could it happen had the IT department and the software anticipated the possible outcome.  They should have given allowance or enough space on IBM’s current largest disk drive in order to allow multiple volumes to be recognized and thus, avoiding further cost to the project.                          In his e-mail dated 1 June, the Senior IT Technician was obviously was not pleased of the Project Manager’s statement that the project deadline was met and that the system is live commencing the roll-out with the branches.  It is actually a clear result that the budget for the project would fell short with all the financial problems encountered along the way.              Accounting to all setbacks mentioned, it gives the impression that the company took a fatalistic notion of committing to the project.  It looked like the company is too result-oriented fascinated by the software’s ability to enable the finance of international trade to take place more easily and more accurately notwithstanding the problems to be anticipated before committing to the software supplier.              Well, of course it will be a company’s advancement but the project should have been smooth-moving if there had been proper planning.  The most obvious missing part in the project was the positive and definite business plan that would have anticipated the setbacks mentioned with corresponding actions should anticipated problems occur along the way.              Such business plan would be helpful in determining where the company needs to go, that is, advancement in the finance system.  It would also serve for the purpose of forewarning possible roadblocks as the project goes along.  Consequently, it will formulate responses to contingencies and keeps the business on track in reaching the desired goals.              Department goals should also be design in order to connect with specific requirements of both the overall company goals and the goals of other departments in terms of product and timing.  It serves for the purpose of assisting other departments that depend on those specific results and achieving the overall company goals.

Trader Project Case Study

Introduction It is the objective of the Trader product to develop methods and tools for ensuring reliability of consumer el...