For an organisation to be able to deliver transformational change, thorough careful consideration and preparation are needed in the design of the change program itself. Simply picking a delivery methodology and a technology platform is not enough. A successful and truly transformative change program needs as much consideration into the how as the what. Yet the how it is often overlooked or neglected with leaders simple stating “we will be using agile” or creating an org chart and assuming everyone will just work it out.
In this article, I describe three important steps I have learned are critical in establishing a high performing digital transformation program. The intent is not to undervalue other important activities such as technology decisions, make a theological stance on methodology or take away from other important and foundational change management activities; it is intended simply to highlight that these things alone are not enough.
People Design:
Your transformation program will likely start up at pace with lots of new people who have never worked together before, from different backgrounds and with different skill sets.
People will be seconded from within the business who will likely be experts in their domain but will not have experience in managing large change programs. You will also likely have an environment with multiple vendors, suppliers and teams, each with best intentions but early on will often spending more time “grabbing land” and “chest-beating” than getting on with the job.
People Design looks to address how to align and organise the people in the program team and the broader organisation to deliver the right focus, organisational priorities, leadership, outcome, behaviours, role clarity and support for performance. It specifically looks to accelerate the program through the forming, storming and norming stages that, while unavoidable, can be managed.
Some key considerations in the people design:
- Engage the cultural business leaders, create business ownership and buy-in. This is an important change management technique that most change frameworks agree on. A good example of this is Kotter foundational change model here. The building advocacy within the business groups to break down pockets of resistance and create a sense of unity in what the program team is building toward for the business users.
- Clearly define roles, accountability and responsibilities for everyone. There have been a lot of studies on high performing teams and they tend to agree on this point. An example of a study from Google here. Being clear on the roles, responsibilities and purpose is important, not only for individuals but also for the team. It particularly helps to navigate quickly through the forming, norming and storming stages and all teams will transverse but some for a longer period than they should.
- Align suppliers and vendor roles to protect the interests of the principal (client). The principal-agency problem (or Agency Theory) is a well-documented description of the conflict an agent (vendor or project team) has in balancing their own interest while representing a principal (client, business, shareholders). When vendors and third-party organisations are engaged in your program, despite best intentions, this will inevitably happen and must be designed for. The effect can also happen with internal project teams.
- Invest in skills, both short and long-term. Ensuring people have the right skills will be a big factor in the success of the program. This includes the people who will be fundamentally involved in delivering the change and also the people who will be encumbered with the change when the program is over. This also goes beyond simply skills uplift like training, it also means investing in being able to free key people up from their day-to-day job so they can focus on delivering the change.
- Use the right people for the right jobs. Set people up to be successful and to deliver their best. Consideration should be given to being deliberate with who plays what role in the program so both the program and the individual can be successful. Your best sale person, for example, may not be a good choice to run a workstream. The skills and traits that make a salesperson successful in sales are not always the same traits that are needed in a leadership role on a change program, despite a wealth of subject matter expertise or their position in the organisation structure.
- Support governance and consistency without bureaucracy. Governance will be required. Difficult decisions will need to get made, things will go wrong, changes will need to be accommodated, the investment returns will need to be measured and the underlying business will need to continue. Making sure the program governance structure is fit for purpose is important. Fit for purpose means the appropriate checks and balances are in place to protect the business/shareholder investment without a level of bureaucracy that would otherwise stifle leadership, energy and innovation within the broader project team.
Information Design:
We work in the information age and much of what we do in digital change programs is about managing information technology solutions. The information created by a transformation program itself, however, is just as critical to design for as the solution the change will ultimately deliver.
As the team comes together, clarify on where to get information, how information is created, why it exists and how it is used to facilitate the delivery of the program is important for efficient and effective communication and alignment on purpose.
While the days of heavyweight bureaucratic methodologies are behind us, what has also been left behind is a common language of the information required to enable change. A definition of user stories and a kanban is most certainly not enough to help a team navigate the ocean of information and decisions that need to be understood in a large scale organisational change delivering change beyond just technology.
Some key considerations:
- Ensure everyone understands how information is connected throughout the program and their own role in the information life-cycle. This aims to provide clarity to all on the purpose of information and how it will facilitate the program outcomes. Your project will consist of different groups of people with different skills, objectives and producing different outcomes yet they must all come together to deliver the change as a whole. Understanding how the business case informs the service design which informs the technology architecture, change and communications plan, dependency plan, training needs analysis, user stories, work instructions and so on is important so your team can truly understand their individual contribution and how the component parts of will make the whole. People are uncomfortable with uncertainty. Helping everyone to see the program information architecture as a whole can reduce friction, lift collaboration and refine alignment to make sure the metaphoric jigsaw will really fit together at the end. Spend the time to develop an information architecture for your program and publish it for everyone to see.
- Make information available and accessible. Your program will develop an enormous amount of information yet if people can’t find it and access it, it might as well not exist at all. This can lead to duplication, missed dependencies, errors, rumours, frustrations and all sorts of confusion.
- Capture information in discrete artefacts that can be finished and published. Controversial I know. A trend with technology folk has been to capture information on a wiki, never really finishing a document or recording it as done. While this is fine for sharing some types of information within a small team, in a large change program, where information needs to be shared between multiple teams of varying disciplines, this is not a good approach. No-one ever really knows if the information is correct and is similar in effect to not having information available and accessible. The discipline of publishing small discrete documents and artefacts drive a discipline, understanding and appreciation of the importance of sharing accurate information with a broader team. Many artifacts will continue to evolve throughout the life of the project but this need not stop publishing regular reversions. These concepts will seem obvious in any construction or engineering industry but in information technology and business transformation domains, our side of software source code, the concepts have become often foreign or at least forgotten.
- Don’t duplicate information, avoid waste. While building out discrete publishable and finished artefacts is important, it is also important not to burden this process by creating unnecessarily complex and heavy artefacts. Don’t repeat sections across multiple documents, don’t waste time filling documents with information that is not needed or is better served in another document. I don’t subscribe to each document needing to ‘live on its own’; it is the programs information architecture as a whole that needs to make sense collectively. Keep each individual artefact clean, clear and pure of purpose.
- Make governance of information valuable, simple. Most agree that bureaucracy stifles innovation and fortunately, the days of heavyweight governance frameworks and processes are behind us. Consideration should, however, be given to finding a balance as with a large workforce, forming quickly and executing fast, some guide rails will be invaluable to drive consistency, quality and ultimately success.
Interaction Design:
Out of the gate, it is important to define the interaction design as being far more than choosing agile vs waterfall. The interaction design defines how work and information flow between people, how stakeholders will stay informed and engaged, how decisions get made and how progress is tracked.
The interaction design will help clarify how you will empower teams to work together to implement truly transformational change.
A common theme in digital transformation is to simply re-platform the core technology systems. This aligns with the thinking that digital transformation is all about the technology. It’s not, you can read more in an interesting HBR paper here. Implementing old processes in a new system is not transformative, that’s just a systems upgrade, yet it is an inevitable outcome when the program is structured and oriented to do so.
Simply picking a delivery methodology is certainly part of this design but alone it is not enough. As mentioned in the opening, a successful and truly transformative change need as much consideration into the how as the what. This part of the how describes how information is shared within and outside of the project, what the hand-off points will be with team members and between teams, how the information will feed delivery execution activities and continuous improvement. It considers what cadence information will be shared, to which groups and to what purpose. It will consider how the program will transition through various phases and will provide a stake in the ground from which individual project teams can find their own groove. It will be the playbook for the program as a whole.
For example, how will a service design or process re-engineering team be empowered to define truly transformational process change without defining solution requirements that a software delivery team can’t possibly build within the allocated time and budget? Similarly, how does a software delivery team build our the solution using ‘out-of-the-box’ configuration so that is it supportable and maintainable? How will one stream prioritise conflicting requirements from different stakeholder groups? How is progress, accountability and ultimately success measured? How will the people at all levels in and around the program stay inform aligned and true to the program purpose and objectives?
None of these problems is new and many solutions exist to address them but a single unified multi-disciplinary approach does not exist for business and digital change. Many assume there is a unified approach and we have all heard people quote how their last project did it properly, or make ridiculous statements like ’this isn’t true agile’. The fact is projects are hard, they are typically unique and bespoke solutions and will most certainly be bringing people together with very different ideas of what is the right “way”. The most important thing is to define “away”, educate people about that “way”, continue to improve the “way” and don’t assume the “way” is a given and inherently understood. A balance, of course, will be required so as to give teams within the program the autonomy to find their own groove while guiding them toward a common purpose and rhythm.
Thorough consideration must be given to how the component parts will all fit together and the role the program and project management leaders take in establishing this interaction design will be crucial.
Side note, if you are running a project(s), particularly in the form of a large transformation program, it will need project management. The project can support agility and flexibility and use Agile methods to manage the work tasks but the discipline of managing the project and program as a whole cannot be neglected. The topic for another discussion.
Conclusion
Delivering change that transforms business across all aspects of business operation is hard. Someone once told me that if you find it easy, you are likely not doing it well. This article has discussed the consideration needed to design for the change as much as designing the change itself. In summary:
- Consider the people design of your program. How will you align and organise the people in the team and the rest of the business, to deliver the right focus, priorities, leadership, outcome, behaviours and performance?
- Do not neglect the design of the information the program will define and will need to be able to deliver and co-ordinate activities achieve the program objectives. This information architecture will be key in people’s understanding of where to get information, how information is created, why it exists and how it is used to facilitate the delivery of the program as a whole.
- Develop a playbook for the program to describe the design of the interactions, hand-offs, cadence and feedback of information as it builds and enables the delivery execution.