Editor's Pick (1 - 4 of 8)
The Changing Dynamics of Engineering Industry
CIO ... Only Until the Next Data Breach
Embrace Technology to Stay Ahead!
AI and the Future of Field Service: Moving from Efficiency to Innovation
The Changing Role of the CIO
Mel Kirk, SVP & CIO, Ryder System, Inc.
Effective Strategy While Implementing SAP or ERP Systems
Daniel M Horton, CIO, Michael Baker International
Innovation & Governance Through Business Alliances
Larissa Tosch, CIO, Glatfelter Insurance Group
Leveraging Data as an Enterprise Asset
Renee P Wynn, CIO, NASA
Balancing Priorities in a Transactional Environment
By Behz Naini, VP, Giesecke & Devrient Systems Canada, Inc.
In a growing, highly competitive, and heavily regulated environment, such as in the financial industry, CIOs need to frequently make trade-offs in handling three different sets of requests: day-to-day, projects, and new innovations.
An approach and structure that would make handling these requests less disruptive to the organization is of high significance, while at the same time ensuring each type receives the appropriate level of focus in delivering quality and timely solutions.
Alignment on IT Mandate and Skills Set
As competencies in IT organizations could differ, regardless of the request type, any IT deliverable encompasses activities that involve analysis, design, coding, testing, and deployment.
Production Support and Infrastructure functions are purposely left out as they are not directly part of building applications or development teams. This is not to say that they are not important, but rather their role and structure are not, in most part, affected by the nature/source of the requests.
With IT contextualized, we can now proceed into the details of the approach. It proposes separate groups be set-up to handle each type of request. The differentiating factor in ensuring a minimal level of organizational disruptions in delivering on various IT commitments is how the individuals are assigned to the groups.
Handling Sets of Requests
For the day-to-day requests that are received from internal/external customers or the Production Support team (as incidents), team members handling them need to be able to work independently and therefore must have advanced familiarity with respective accounts or platforms. Given these requests come in an ad-hoc fashion with limited advanced planning, the individuals working in this group need to also be able to work and communicate well under pressure. When appropriately matched, this group could assist in enterprising the solutions across platforms and/ or the customer base, helping the organization with value-added services or standardization of platforms/processes.
The complexities of inter-application dependencies, external interconnects and legacy requirements can undermine even the best laid plans
Interfaces to this group are, in general, Production Support, Customer Service, Relationship Managers, and Intake teams.
For project requests, the team working on them could be relatively less experienced than those working on the day-to-day requests. The reason for this distinction is that by nature, project requests have support and controls built into their structure. They are planned, most likely ran by a Project Manager or through a Project Management Office, and follow a structured methodology such as: Waterfall, Agile, PRINCE2. Given the nature of project requests, this group interfaces with the Project team, Project Management Office, Customers, and On-boarding groups.
To handle new concept or emerging initiatives, the individuals working on them should be comfortable in an unstructured environment. These activities deal with first implementation of a new technology or process, involving research and developing new services/competencies, e.g. big Data, Cloud, multi-channel marketing, mobile payment, or any initiative that is new to the company.
As such, the individuals in the group need to be early adopters and be engaged in their fields. They usually have a large and niche network and are also characterized as being creative, self-starters, and out-of-the-box thinkers. Interfaces to this group are in general, Product Development / Management, Engineering, Research and Development, Architecture, and Innovation departments.
Once the three groups are set-up, the next decision to make is how to partition the IT organization into the above groups. Having a clear vision and a long-term plan (i.e., 5 years and more) is a key success criterion. As in any structural change, this transition requires investments and expenses in training, replacements, or displacements of resources. Change management and organizational communications are essential to successfully establishing these groups.
Once these groups are set-up, there are opportunities to allow movement between groups as a progression path or for load-balancing purposes. To perform this effectively, executives and managers need to view the potential transitional path from the inherent structure in the groups. From this perspective, projects and new concept initiatives are at the extreme ends of the structured and unstructured scale. As such, there is limited long-term compatibility in transferring team members between these groups.
In the middle of the scale are those who work on day-to-day requests. Given the level of business/technical expertise and ability to work independently in a fast-paced environment, this group could easily move between projects and emerging initiatives.
Managers and C-level executives should take into account other factors, including personal aspirations, career motivations, and market conditions, to ensure a sustainable transition and appreciate the team member’s role in the corporate and individual decisions. In summary, although it is difficult to have dedicated teams working on single requests at a time and also balance different priorities within the Financial Industry, organizations can mitigate against conflicting commitments by compartmentalizing requests types and aligning their specific dynamic to the inherent aptitude of the resources.