E-Banking Project Management
Because the banking industry has been static for many years, the project management skills necessary to transition to e-banking have deteriorated and are largely misunderstood. This chapter is meant as an overview of the discipline.
PROJECT MANAGEMENT OVERVIEW
Project management is a specialized discipline geared toward finite actions (as opposed to ongoing operations), with methodologies that offer a systematic approach to planning, monitoring, and measuring throughout the project lifecycle. There are various industry and academic groups that seek to define the discipline and provide resources and training.
Project management can be done by a dedicated specialist (a project manager), or the skills can be learned and applied by traditional managers, though the latter approach tends to be less effective, as it conflicts with existing interests and such mangers have (and gain) little experience in project management.
PROJECT PLANNING
Each project begins with a pre-development phase that involves defining the project (its goals) and assessing the existing resources. Of importance is assessing whether the project is in line with organizational objectives or at conflict with existing corporate culture. The "as-is" state is analyzed and current resources assessed, and the project manager develops a plan that indicates the timeline, costs, and resources that will be needed to achieve the desired "to be" state.
Of importance is that a project is finite. At some date, it will end and the result will be a change to the ongoing business activities (either the activities themselves, or the way they are done). Included in the plan should be an indication of the effect it will have on ongoing business operations.
Also of importance is promoting the project internally - gaining the support of senior management, having a "champion" to promote the project, and preparing and training the employees (and sometimes customers) who will be affected by the change.
SETTING SUCCESS CRITERIA
The "success" or "failure" of a project to meet its desired ends can often be a matter of perception. Largely, this perception depends on the goals that were defined for the project: more nebulous goals are harder to assess than concrete and quantifiable ones.
While the primary measure of success is dollars gained (increased revenues or decreased expenses), there are also goals that are less objectively measurable but nonetheless important: increasing customer (or employee) satisfaction, increasing capacity to accommodate business growth, increasing system stability, improved perception of the company by prospective investors, etc.
There are also intrinsic measures of success - that a project is completed on time and within budget. However, when meeting such goals is prioritized above the objectives of the project, conflict arises between the project team (because the project met time and budget constraints) and the business (because the project failed to achieve its stated purpose).
Some projects may have multiple goals. Where this occurs, the goals should be prioritized. Compromise may be necessary.
Finally, success is not always complete. Especially when specific and concrete goals are set, there is a tendency to dismiss a product as a failure if it did not achieve them completely (a 6% increase in sales instead of a 10%). Where possible, avoid litmus tests.
Success Models
The author describes a few different models that have been developed for measuring project success. The level of detail is a bit much, but the core metrics they include are:
- Project efficiency - The ability to meet or beat deadlines and budgets (which is the least important factor)
- Financial results - The consequences of the project are increased revenues or decreased costs, resulting in profitability.
- Staff Performance - The increased efficiency or accuracy with which employees accomplish tasks as a result of the project
- Staff Morale - The "job satisfaction" of employees who are impacted by the project
- Customer Satisfaction - The change in customer's impression of the company and its products/services
- Business Improvement - The project results in creating a new product or a new market
Some of these are short-term measures that can be witnessed immediately upon the completion of the project, others should be measured over a long period of time (e.g., a project may result in a decrease in staff morale initially, as employees are resistant to the change, but have an overall positive impact several months later).
Common Reasons for Failure of Technology Projects
Aside of perceived failure (when the success measures were poorly conceived or that the methods for measurement produced erroneous results), there are a handful of common reasons that technology projects genuinely fail. The author provides a laundry list.
- Organizational Structure. The politics and culture of an organization may work against the stated goals of a project. There is a "status quo" that organizations will attempt to preserve, and a project can be undermined by the desire to maintain power or control, reluctance to work cooperatively across organizational silos, competes with an alternative course of action, etc.,
- Unclear Purpose. The core purpose of a project is unclear, or becomes blurred over time, or isn't adequately communicated or "sold." Note that "purpose" is different from objectives - it is more along the lines of "why" than "what"
- Unrealistic Targets. The objectives set for a project were unrealistic, whether in the goals themselves or in the qualitative metrics (how much, when, etc.)
- Lack of Communication. Communications between different stakeholders and groups were unclear and the objectives/requirements misunderstood or misinterpreted.
- Lack of Planning. While it is not possible to plan every detail and expect every contingency, planning should strive to achieve granularity and account for as many contingencies as possible,
- Poor Requirements. A project plan should entail a comprehensive list of requirements that are clearly defined, such that it they can be easily understood and objectively evaluated.
- Environmental Factors. Stuff happens, in the company, the industry, the market, or the political environment, that impact the expected outcomes of the project.
- Scope Creep. After a project plan is finalized, it is very common for clients or stakeholders to heap on additional requirements or change existing ones once the work is underway, without providing the resources (budget and time) to accommodate them. In the worst of cases, a plan may need to be scrapped and redone to accommodate changes in the requirements.
- Lack of management support. For both practical reasons (getting the resources and administrative support needed to do the job) and political ones (gaining cooperation and acceptance), management support is critical to project success.
- Poor project control. Once a plan is created, the project manger must make sure that it is achieved as planned and, when necessary, guide it back onto the rails.
- Poor (or nonexistent) testing. Prior to the delivery of the finished product, there should be instances in which it is tested to ensure compliance with requirements (that it functions as described, and does not malfunction). Testing should be done throughout development, but there should also be a thorough shakedown at the end.
- User rejection. Ultimately, a system will only succeed if it is used as intended. Users may reject a system for political reasons (if they feel it is forced upon them) or practical ones (if it fails to enable them to do the task, or certain elements of the task, as accurately or efficiently as older methods). Remember that the company has no formal control over some users (customers, vendors, etc.) and limited ability to coerce acceptance (even with employees).
- Poor change management. In addition to obtaining buy-in from users (covered in the previous point), integration with existing systems and processes must be managed to ensure a seamless transition.
Typical Steps in an E-Banking Project
Each project management methodologies has its own prescribed sequence of events. The author attempts to consolidate and generalize:
- Feasibility Study. Determining whether a given goal is worth pursuing.
- Authorization. Management at the appropriate level approves the application of resources to investigate a solution.
- Definition. A course of action is identified and described in detail (the project plan, including requirements documents)
- Risk Analysis. The author provides no clear definition of what this means, but my sense is it's asking what might go wrong.
- Project Planning. Detailed plans are developed, indicating the sequence of tasks and resources required.
- Pilot Project. In some instances, a prototype will be developed and even put into production on a small scale to identify defects and missing requirements.
- Development. The work required to implement the project is done.
- Training. The individuals who will use the system are trained
- Deployment: The project is moved into production, typically in a phased manner
- Evaluation - After the project ends, there should be ongoing evaluation of its success.
The author presents these steps as a sequence, but there are some instances in which steps may be done concurrently or in a different order.
PROJECT MANAGEMENT TASKS, TOOLS, AND METHODOLOGIES
Where tasks are concerned, the author asserts that a project may involve hundreds of individual activities, but they generally fall into these categories:
- Cost estimating and preparing budgets
- Communications planning
- Setting goals for individuals and project teams
- Implementing change and process improvement
- Quality assurance and controls
- Risk assessment and management
- Scheduling and time management etc.
Regarding methodologies, he briefly outlines the "PRINCE 2" methodology developed by the British government:
- Document the business case
- Identify the stakeholders and project participants
- Develop project plans
- Define controls and measurements
- Identify possible risks
- Identify quality issues and metrics
- Determine how the output will be developed and configured
- Manage changes in specifications or changes to project scope
Regarding tools, he refers to Microsoft Project, which is primarily a task and resource management tool that produces Gantt charts, schedules, and resource lists.
A SYSTEMS APPROACH TO PROJECT MANAGEMENT
Traditionally, banks used a myriad of different systems to manage their business data: a system to manage checking and savings accounts, another to manage credit cards, another for mortgages, another for auto loans, etc. This does not include numerous other business systems that are not related to the financial products (payroll, marketing databases, procurement, etc.).
The ideal of e-banking is a complete integration of these formerly disparate systems, for customer service and operational efficiency.
EN: The data and functionality of these systems was integrated by the employees - a teller, financial advisor, personal banker, or ought - who interacted with the customer and utilized these different systems to provide service. The emergence of e-banking now requires this integration to be mechanized.
Companies are largely protective of their existing systems: each was chosen for a specific reason, and is designed to suit the unique needs of a specific product, and the primary concern in integration is the loss of the specialized function of separate systems.
From a systems perspective, the primary goal of project management is to evolve systems toward an integrated whole while preserving the required capabilities of the component systems.
Thinking in terms of systems, we must understand the need for division and specialization, but should regard the distinction of functions as borders, but not barriers. This means overcoming the myopic view of each system as an end unto itself.
As an aside, the structure of an organization is also a system: a bank may be divided into departments that deal with a specific product (checking, credit cards, auto loans) or a specific function (marketing, purchasing, etc.). This is often the cause of the existence of various systems (each department obtained the systems it needed), but it is similarly a symptom of the same root cause - a compartmentalized approach to managing the business.
EN: IT departments tend to echo the compartmental myopia of organizations: each team considers only their own systems, and an "us vs. them" mentality arises.
While it may seem off-topic to go into organizational structure in the context of computer systems, the two are inseparable. In order for parts of a system to work together, the people within the organization must work together. It is in this way that technological change drives organizational change
EN: I don't think the author has it quite right - IT should not wag the dog. From a management perspective, the organization structure and IT systems should be considered as a whole. If anything, IT should follow the needs of the organization. But admittedly, IT integration projects often precipitate organizational integration, or are undermined by lack of it.
MANAGING HUMAN ISSUES
An e-banking product will have significant impact on the organization. They require employees to learn new skills and adopt new behaviors. There may also be negative side effects - jobs may be eliminated, or new jobs may be created that bring new employees into the organization. For these and other reasons, there will be social issues (resentment, fear, rejection) that precipitate. These must be carefully mitigated.
The author has no answer for change management, but indicates that there are a number of "common themes": creating and selling a vision to inspire, involving employees to engender a sense of participation and ownership, communicating the plan to avoid unpleasant surprises, direct communication to those directly affected, training and preparation for the change, mitigating miscommunication and rumors.
EN: this seems far-flung from the chapter topic (project management), but perhaps it's here to indicate that managing the human issues should be included in the project plan.
A stray note: for multinational companies, communication problems are exacerbated. Information is lost in translation, or a message that is acceptable in one culture may be offensive in another.