This thought leadership article is based on our experience supporting many leading global Asset Managers in their new ‘ways of working’ to eliminate waste, reduce handoffs and become more responsive and relevant to their customers.

Let us be pragmatic on what a ‘Product’ is in the context of an Asset Manager – what is the trigger?

Operating in a product-mode is classically defined as loosely coupled, autonomous teams ‘vertically’ aligned with the company’s products. In the context of an Asset Manager, a typical product is a ‘Fund’ in an asset class. It is not viable to align teams vertically around ‘funds’ or ‘asset classes’.

The traditional and easiest organisation design is a functional orientation or ‘activity-oriented pool’, e.g. BA Team, Dev Team, Testing Team, Change Team, Data Team etc. In the activity-oriented model, Project Management becomes a pivotal function to act as the glue in bringing people together and delivering change. Projects are staffed from a pool of talent whose members are considered fungible within lines of specialisation. Usually, a Project Team’s job is to build or enhance a system or application and move on.

Since most of the measures are focused on project delivery, no real consideration is given to systems and applications. Over time, these systems and applications become unrecognisable and complex with customisation, garnering huge technical debt and unwanted or unused features. This gives rise to increased architecture complexity, unstable systems, increased rework, multiple handoffs and unacceptable cycle time; this leads to frustration between teams and the business and is often the key trigger for a more ‘Product-aligned’ agile delivery approach.

In the context of Asset Managers, the ‘Product’ is synonymous with business capabilities — common services, features and functionality used in many or all of the company’s business products e.g. Distribution, Risk/Investment management, Data management, Customer reporting, Asset administration, Transaction processing, Settlement, Payments etc.

Why ‘Programmes’ in a Product context?

Initiatives like a new Product launch, addition of a new Asset Type, Operating Model Transformation, new Regulatory requirements etc. require Asset Managers to add or change features in multiple capability/product areas of the organisation. These initiatives need cross-team coordination to deliver value. The coordination effort involved in them is what we call Programmes. If not managed effectively, the opportunity cost is missed revenue, unsatisfied customers and wasted team capacity.

Are Programmes hard?

Programmes that cut across operational value streams or customer value require orchestration across multiple teams and are a real challenge for product-centric organisations:

• It is extremely difficult to change a product operating model to provide value to a programme.
• The autonomous culture that is common within product/capability teams can be challenged by programmes. Usually programs benefit by standardising the delivery process across multiple streams of work.
• The leadership techniques appropriate for agile product teams may not translate well to the programme level, where multiple teams with various priorities need to be aligned.

Our observations and experiences

Many Asset Managers have created capability-aligned Product teams. This organisational structure is similar to the Spotify model where squads and tribes are aligned to the product architecture. It suits extremely well in a micro-service based modern tech ecosystem, where API culture can minimise backlog-coupling and reduce data dependencies. But for most of the Asset Managers that we have come across, their current architecture is complex and not modular – they are in a journey towards modernising their architecture by transitioning their platforms to cloud. API-based mindset and platform thinking is not organic or natural to them. Any new transversal change or a new product launch, where it requires multiple capabilities/products, need to have a different and adaptive approach towards ‘programme management’

Holley Holland is often brought into an organisation to help them improve their operating model, which includes programmes, data strategy and other transversal initiatives.

We start with a retrospection. Here are a few of the retrospection themes;

The flow of value to the customer vs Product alignment

Local optimisation by the product delivery teams without considering the end-to-end operational value-stream flow.

Lack of visibility of programme information

There is no consolidated programme status view. The progress updates are focused on individual product delivery teams instead of an overall reflection of the working solution addressing the customer outcomes. The teams are not aware of their involvement or impact on the programme.

Risk management

This is left as an implicit task assumed to be managed within the delivery teams, but not as an explicit programme-level effort. This means that there are many surprises along the way which impact the delivery date.

Dependencies between teams

Lack of cross-team collaboration leads to tensions forming between the delivery teams, which damages the working environment and impacts the morale of both the individuals and the team.

Communication

The programme leadership team do not change their communication style to suit the context and situation. There is often no shared understanding of the programme goals and outcomes. It is assumed that each product team has the information needed to deliver their piece of work!

Overall team motivation and accountability are compromised due to the problems above.

Strategies, practices and principles for managing programmes in product-mode organisations

The observations above describe what we see to be common challenges for product-mode organisations when responding to operational value-stream based demand with a requirement for cross-team coordination in a programme-like situation.

The remaining points of view outline strategies, practices and principles that we have used when working with organisations to address some of these challenges;

Structured and proper discovery

Discovery should help business stakeholders and key Product Team members be aware of the initiative and its significance, their role in it, how it’ll be delivered and the high-level scope of the first release – MVP1. We recommend setting aside time to run a set of discovery workshops that provide the following outcomes:

• Shared understanding and alignment with all stakeholders on what needs to be done and why
• Define consistent ways of working, ceremonies and practices
• Socialise the business, technical and customer context with all teams involved
• Build trust across the teams by making explicit the roles, responsibilities and motivations of individuals
• Lay a foundation for building empathy and understanding within the team
• Focus on the risks, dependencies, assumptions and complexity that exists in the delivery

An example schedule for a Discovery intending to address these outcomes might look like this:

Shared understanding and early involvement

A programme canvas workshop will help to drive a shared understanding of roles and responsibilities, goals, purpose, and rules and activities of the programme.

Red Team for the Programme

Red teaming techniques help to identify the riskiest assumptions in the programme and the approach in order to validate them and learn. Red Teaming is a more structured and lean approach to programme risk retrospection and reflection.

Change in the leadership style

Programme leaders need to adapt their leadership style to the demands of the initiative. It is usually a disaster if the Programme Manager operates in command and control of the Product-based teams. As an example, the situational leadership model, which involves more time in clarifying, empowering and defining is a wise choice.

Managing backlog-coupling dependencies

Dependencies between teams, known as backlog-coupling, are common in programme delivery as multiple teams will be responsible for delivering different discrete parts of the solution. A good practice for proactively managing these dependencies is to frontload the programme delivery with activities intended to decouple individual team backlogs, enabling teams to deliver more autonomously.

For example, to reduce the backlog-coupling between the product teams, the discovery team might decide to spend its first few iterations; MVP 1, teaming around building a walking-skeleton. This enables future programme progress updates to focus on the evolution of the walking-skeleton as more fidelity and depth of scope is added by the product teams.

Strong communication strategy

A large part of the coordination effort in programme management is spent on communication to:

• Make sure all relevant stakeholders are kept informed and given a chance to raise issues and ask questions
• Facilitate the communication across teams to help relieve bottlenecks in delivery
• Surface blockers to the programme leadership team so that they can help alleviate them.

Due to this required overhead of communication in programmes, programme leadership should look to create a strong communication strategy with touchpoints that satisfy the needs of each stakeholder group

An example communication strategy:

Visible Programme board

In addition to a programme Jira board, there could be a virtual Programme wall in a Confluence page which radiates – user journey maps, story maps, retro themes and MVPs. Moreover, virtual programme walls can help prompt questions from other people in the company by allowing them to consume information quickly without needing to schedule time with anyone.

Clarity on responsibilities of the roles

The discipline of programme management is crucial to ensuring success when any transversal and operational value stream initiative involves the orchestration and coordination of multiple agile teams to deliver value. However, the actual role definition and responsibilities will depend on the organisational context and programme complexity.

One of the outcomes of the discovery session is bringing a shared understanding of roles and responsibility. For example, the need to deliver.

The following example RACI matrix shows the separation of responsibilities between roles:

Summary

We shouldn’t be dogmatic about a model/pattern/methodology. Instead, define key guiding principles for a context. Once we understand the initiative is transversal and aligned to an operational value stream, it becomes clear that an adaption in the operating model is required to deliver value to the customer. Even where we have listed several strategies, practices and principles that can put the programme on the path to success, there is no silver bullet for that success. Regardless of the mechanisms you choose, make sure you put in place a feedback loop and continuous retrospection with the programme constituents, to learn and adapt whenever necessary.

About the Author:

Prasad.prabhakaran@holleyholland.com

Prasad Prabhakaran has more than 20 years of experience working with large and medium multinational enterprises and product companies. He has hands-on experience in building Digital Products and helping enterprises in their journey towards business agility. This has led him to becoming a trusted partner and coach to CXOs of Enterprises and helping Boards of some of the leading firms rethink about how the operate via Ways of Working.

Prasad is also associated with many international conferences as a speaker and program organiser such as Agile UK, Agile India, Discuss Agile, and Digital Conclave. As recognition of his contribution to this community, Prasad was honoured with ‘Agile Leader’ of the Year award in 2016.