CLIENT
A top 5 (by revenue) global Corporate and Investment Bank
CHALLENGE
Large financial services corporations often balance hundreds of complex projects, with considerable resource commitment and capital cost. For the most complex initiatives, a multitude of variables can collude to derail success: arcane requirements, varied resources with divergent skill sets, stakeholders with conflicting objectives, and dependencies that cross internal areas. How can firms effectively manage these factors, and do so consistently across projects?
Our client engaged us to help find an answer. Midway through one of its most high profile and costly initiatives to build a corporate data warehouse, we were to perform a project review, addressing specific tactical problems, as well as strategies to restructure and administer projects more effectively. With the laws of inertia keeping bad practices in motion and momentum building toward eminent delivery schedules, we endeavored to provide a fresh perspective, reframing the project with an eye toward standards, process, and discipline. Nouns that translate well to any initiative.
IDEAS
We approached the engagement with two objectives in mind: 1) document best practices and 2) provide tactical examples of how to apply the best practice concepts to their current challenges.
What leaped out at us was a need for structure. Business requirements were misinterpreted without functional input, project teams were compiled inconsistently as a reaction to business demands, and technologies were developed without coordination, often overwhelming the underlying technical infrastructure.
Our ideas would need to keep structure at the forefront.
We recommended 4 actions:
1) Mandate Structure
- Define how project teams should be constructed: according to technology and functional goal.
- Define staffing of project teams according to Solution Delivery Life Cycle (SDLC) phase.
- Define roles and their responsibilities and required skill sets. Resources are not allocated to a role unless their skill sets match the role.
- Structure a Program Management Office to include project sponsors, vendor representatives, project managers, and oversight committee chairs.
- Create oversight committees, compiled with subject matter experts (SMEs), to guide project teams and define standards.
- Structure oversight committees to cover SDLC phases and infrastructure areas, led by a committee chair, as follows:
Committee Name Area Responsibilities Business Requirements
SDLC: Define
1)BRD and FRS standards and business process definitions 2)Approval of related project documentation
Data Model & Data Integration
SDLC: Design
1)Data model standards 2)Approval of object creation
Technical Process Design
SDLC: Design
1)Design document standards 2)Approval of related project documentation
Testing & Migration
SDLC: Test & Deploy
1)Test Plan standards, including approach for test issue triage 2)Migration standards
3)Approval of test plan documents and migration requests
Operations & Support
SDLC: Support
1)Transition Plan standards 2)Training standards
3)Approval of related documentation
Technical Infrastructure
Infrastructure
1)Hardware assessments: CPU, Memory, I/O capacity
2)DB Software assessments:
Partitioning, Table Spacing, Page File Sizing, Transaction Log Sizing
3)Application Tuning assessments
4)Vendor selection and management
Batch Scheduling
Infrastructure
1)SLA management on data inputs and outputs 2)Dependency and metadata standards
3)Software Integration management
Data Gaps & Source System Remediation
Infrastructure
1)Data quality management 2)Remediation strategies with source systems
2) Document Standards
Standards are critical in every aspect of a project. Without them, one cannot validate if something was done the right way or determine a remediation strategy. It was clear that our client could benefit from clearly defined standards, and we recommended oversight committees as the vehicle to realize them. Staff them with people well versed in a discipline, and let them document their wisdom for the benefit of others.
Thus, the guiding purpose of oversight committees and the standards they create: define the best way to do something, and ensure that it is done that way every time.
3) Define Processes & Procedures
With the recommended structure of projects clearly defined, we outlined communication matrices: how resources within certain roles should interact. Of particular importance for this project was the relationship between project teams and oversight committees. It was clear that, for the sake of design consistency and standards adherence, project leads would need to report to, and gain approval from, oversight committee chairs as a criteria for progressing through SDLC and implementing any technology. A process for defining standards, training users on those standards and offering an avenue to improve the standards would ensure that all project resources would have the information they need to implement successfully.
If oversight committees determine gaps against defined standards, define a procedure to reconcile the differences: document gaps, suggest a fix or new technology, and initiate a new feedback loop for the amendment. Define repeatable procedures where lacking, in areas like technology migrations and project issue management.
4) Institute Governance & Control
Leverage the PMO concept to control the execution of best practices. Its recommended revised structure includes representatives across all effected groups: oversight committees, project teams, vendors, and sponsors. Collaboratively monitor and govern the rollout of this new operational model.
In parallel, administer the common responsibilities of a PMO: budget, secure funding, track progress, control project scope and risk.
SOLUTION
Our solution objective was to apply our ideas tactically to stated client needs, illuminating where our concepts meet their practice.
For our prototype, we addressed a business problem in foreign jurisdiction reporting. Some sovereigns require accounting that differs from GAAP, mandate bespoke customer reporting, and specify unique criteria for customer actions, such as default. Poland, in particular, diverges from other EMEA nations in these areas. Sub-systems were configured to handle these peculiarities, but how could a conformed data warehouse, with its standardization, integrate them?
We felt it a great opportunity to demonstrate how processes focused on implementation standards could handle unforeseen curveballs. With oversight committees established to guide implementation teams, it was a question of flowing the new requirements to the appropriate committees. Let the committee members interpret, and then add to or amend existing standards to accommodate the oddities. Voila. The implementation teams then have the information to execute, not just for this requirement, but for anything similar that might arise in the future.
Specifically for foreign reporting, we documented the types of standards for which each oversight committee was responsible. Then, we applied 5 sample business requirement gaps to the committee(s) that would need to incorporate them:
| Foreign Reporting Business Requirement Gaps | Oversight Committee(s) |
| 1) System input for calculation of unused commitment amount | Data Model & Data Integration |
| 2) Local system input for collateral pledged at transaction level | Data Model & Data Integration |
| 3) Revised EAD calculation for collateral offset at transaction level | Technical Process Design |
| 4) Revised definition of Basel counterparty default and customer classification of Corporate vs. Government | Data Model & Data Integration |
| 5) Batch scheduling adjustments to meet reporting Service Level Agreement (SLA) | Batch Scheduling; Data Gaps & Source System Remediation |
From there, it was an exercise of staffing project teams to use the standards for the new requirements, embracing the review and approval procedures between project teams and oversight committees, and monitoring timelines and project risk. All of these were processes under the guise of our reengineered operating model: a complete solution for running projects more effectively.
RESULTS
Enterprise projects are complicated. And it’s a complex task to make them simple.
While perhaps not simplification, structure at least provides the means to consistently coordinate efforts, defining who, what, when and how. Our reengineering solution did just that: it defined the parameters under which standards are conceived, implemented and monitored. These perspectives provided a sustainable model for project management and solution delivery of large scale projects. Projects that, if they become unwieldy, can produce outcomes worse than cost overruns: solutions that lack utility.
Our client took our ideas and applied them, over time, to their initiatives. The result? Portable, reusable processes. Better management tools. Outcomes with higher quality.