PAS Architecture Review

In order to build on its success in an increasingly competitive and time-sensitive market, our client looked to deploy new capabilities to its agents while exploring new channels and market opportunities. The client needed the ability to bring new products to market quickly and efficiently, deliver self-service capabilities to independent agents, position itself for a future move into the direct-to-consumer sales channel and create a platform to enable cross-selling and up-selling across products and lines.

Unfortunately, the insurer could not achieve these objectives due to proprietary legacy platforms that prevented the quick response to new market and process opportunities. As a result, the client needed to convert its entire policy administration platform to a modern architecture, but lacked the internal knowledge to make an accurate technology assessment. Additionally, a highly matrixed organizational structure created the potential for friction among stakeholders, making consensus on key issues difficult to achieve.

As the project progressed the client’s IT and project leadership guided the efforts, made changes, and reshaped approaches with the aim of accelerating the launch. The client needed an objective external viewpoint of the project, including a review of the overall architectural approach and its use of the agile development process methodology.

X by 2 led the agile architecture review as part of an in-flight policy administration initiative. The review began with an analysis of the overall project that encompassed three major buckets: scope management, team organization and resources, and development process and methodology. Initially, an approach was put in place to establish a breadth-first view of the key project dimensions that identified areas for a deeper review and analysis.

SCOPE MANAGEMENT ISSUES AND OBSERVATIONS

The client’s use of lengthy use cases created months of review before any software could be created, which elongated the iteration process. This led to problems with testability, communication, coordination, and work management. Overall, scope management was not change-friendly due to excessive document creation and rework that became a point of tension between business and IT functions.

TEAM STRUCTURE AND RESOURCES ISSUES AND OBSERVATIONS

Design and development on the project were done offshore, leading to the typical challenges surrounding communication, skill sets and time zones. One of the difficulties encountered was a general mismatch of culture in which the offshore partner was used to the parent company’s way of doing things and ‘never said no’ to the client. Roles were often too fine-grained with narrow responsibilities within the onshore team, and the skills and experience of the onshore and offshore team were not always adequate for the project. As a result of the X by 2 analysis, the client introduced a SWAT approach and implemented elements of collocation in which onshore and offshore team members worked in each other’s physical locations for defined periods of time. This enabled improved communication, including all offshore communication being channeled through one individual for coordination and prioritization.

DEVELOPMENT PROCESS AND METHODOLOGY ISSUES AND OBSERVATIONS

The client lacked clarity on methodology and lacked experience with agile development. This lack of project clarity led to confusion for both onshore and offshore teams. The onshore team expected the offshore team to collaborate and work with high-level direction consistent with agile practices; however, the offshore team expected the very detailed specifications of a waterfall approach. This communication disconnect between onshore analysis and offshore development led to significant quality issues and rework. Additionally, there was a misalignment between offshore and onshore teams for Quality Assurance expectations, and there was no single entity that focused on the holistic nature of the final solution from both the business and technology perspectives. These difficulties led to an unmet expectation that there would be a full set of detailed requirements and design documents to continually evolve the system.

Following the initial analysis period, X by 2 made recommendations to solve the pain points identified. These recommendations provided an objective viewpoint for the client to begin solving issues surrounding the overall architectural approach and agile process methodology within their policy administration initiative.

SCOPE BREAKDOWN AND MANAGEMENT RECOMMENDATIONS

To address scope management, X by 2 recommended using business scenario-based use cases rather than screenshots. The client should shift to smaller iterations that took no longer than 4-8 weeks to produce software, and where practical, interim releases to assess team progress. More broadly, the amount of planning should be reduced and the lean principle of eliminating waste should be applied to invest in value-added planning only. Finally, the root causes of failures need to be identified to get business buy-in for a flexible scope, and the business should be allowed to determine priorities.

TEAM STRUCTURE AND RESOURCES RECOMMENDATION

X by 2 suggested that the client create more coarse-grained team roles and put in place an approach to appropriately credential onshore and offshore resource roles. Team head-count should be reduced resulting from more coarse-grained roles that lead to smaller teams, helping to reduce communication overhead. This allows the best resources to spend more time actually doing work as opposed to coordinating and communicating. The quality and coordination of architectural solutions could be improved by creating a focused group to ensure the consistent and holistic nature of solutions from both the business and technology perspectives.

DEVELOPMENT PROCESS AND METHODOLOGY RECOMMENDATIONS

The client was advised to create a lighter process for documentation using clear and realistic goals for why process steps or documents were required. The best practice is to create higher-level and more sustainable artifacts that lead directly to working software, as that is the most important indicator of progress. Acceptance tests need to be created as part of defining and documenting business scenario-based use cases for requirements.