Financial services transformation programs tend to be large-scale ordeals that can involve hundreds of skilled (and costly) knowledge workers, important business resources, and expensive global consultants. When these groups “churn” or spend time revisiting unnecessary topics this is a major source of inefficiency leading to cost and schedule overrun and can potentially derail the program itself.
I’m sure that I don’t need to convince you that churn is a bad thing, but let’s explore the impact that it has on the program:
- It burns time and money both which are considered valuable and necessary for the sustainment of the program
- When resources are focused on unnecessary items they may not be focusing on necessary items – thus the feasibility of the solution is at risk if key items are missed during design
- Churn can sap the morale of the teams engaged and is often a source of frustration for all parties
There is no churn detecting iPhone app (yet) but this is a great idea (I’m working on it..) until then isolating churn from progress takes some judgement and reflection.
It is really important that the program be making great decisions and taking the right amount of time to understand the facts and move forward. So how can you tell churn from healthy analysis, discussion and debate? Here are some key differentiators:
- Where healthy analysis has structure, churn is chaotic and lacks structure. There is not a linear path in the discussion
- Where churn tends to revisit or replay existing facts, healthy analysis only visits new facts
- Where churn asks the same questions until the old answers are found, healthy analysis has both at the ready – so new facts or questions are clearly seen
- Inexperience can lead to basic questions being asked late in the program, experience helps navigate the analysis to the important topics at the right stage of the program
Sources of Churn
Large program churn can occur for several reasons. There is no single source of churn but often several contributing factors:
- Structural: The way that the team and organization is structured does not facilitate clear/direct communication or a linear/logical path from problem to solution. Sheer size is a contribution factor as the larger the team is the more difficult it is to communicate within the program
- Expertise shortage: Without experienced and knowledgeable team members decisions and directions can be uncertain and circular
- Team turnover: When new team members arrive, they will ask questions (this is normal, and a good thing) but without sufficient continuity the program can be mostly questions
- Lack of lock in: When key decisions are made it is important that these be locked in with sufficient documentation including why the selected option was chosen and the risks and implications of each option. This helps reduce churn when team members turnover or memories fade.
- Lack of clarity on method: Without a clear method to move from uncertainty to clarity into execution. It is important that the method underpin all of the activities in the program and that it be well communicated.
- Lack of end to end thinking: Too often the program is focused on the moment and not the moment that comes next. When solution components are designed in isolation, surprises will be found and these can create ripples of redesign, change, and cost increase within the program.
Not all programs are the same and your mileage may vary when considering some of these — but much of the following suggestions are key principles that can help you reduce churn in your transformation program:
- Collaborate early/often: It is important to get key team members to align on the end to end design of the solution. These programs often consist of several third-party and organizational groups that will make the final solution happen. Having design alignment sessions that produce documented agreement and design artifacts is a good investment in reducing churn and delay.
- Document key decisions: Imagine that most of the people making these key decisions will turn over through the program — it is important to think about what needs to be retained in this event and to capture this as part of the decision documentation. I have found that it is often the “why” that is most important here. I can see and understand the “what” based on experience and observation, but why certain decisions were made can involve organization specific implications that need to be documented for posterity.
- Create linear structure: When it comes from moving issues from ambiguity to clarity and into execution, have an agreed upon structure that is communicated in the program. Be clear about who is responsible for the stewardship of key issues and what closure looks like. Have a process to reopen issues, but as part of this process ensure that new facts exist and all existing information has been considered
- Define materiality and delegate authority: For some decisions, the debate and discussion can be more costly that the worst case scenario. Experienced resources should help triage issues so that the immaterial items are delegated appropriately and the important issues are taken through the right process
When it comes to tackling issues of turnover and retention which can help to maintain the corporate memory of issues and decisions, I believe that reducing churn helps to create a more constructive and results oriented program which should help with reducing some of the program angst and support retention.
These programs are large, complicated and challenging. By adding churn we can make them nearly impossible! I hope that some of these suggestions help, and if you have any other suggestions or ideas please add them to the comments.