Transformation Warfare 2.1

Continuing on from: https://www.dhirubhai.net/pulse/transformation-warfare-11-james-patrick-mbcs-gj3le/?trackingId=9CgEnoLdQgS3plBGJyx6pQ%3D%3D

2.1 Ignoring Stakeholder Engagement

Digital transformation is not just about technology, it’s fundamentally about people. Developing solutions in a vacuum, without input from those who will use them, is a recipe for disaster. For reasons which aren’t necessarily clear, there has been some cultural downturn in some technology-centric functions, leading to the use of phrases such as “we ask forgiveness, not permission,” and “product tells you what change looks like.” The former is a red flag for budget holders, risk managers, and operational delivery, while the latter is a foundational misunderstanding of responsibilities and accountabilities. Sadly, these are just symptoms of technology gone wonky and corrosive culture filling a gap with a healthy dose of ego and basic human self-interest. If you’ve ever hear a project become centred around shouts of “happy path,” it’s almost certainly a bad project. - or, at very least, optimism-biased.

The key stakeholders of any technology project, are: the budget holders, the policy facilitators, the risk and security professionals, the system owners, the super users, and the users. Over the years, we’ve taken what is a simple and obvious truth and built layers in an around it. This has led to the implementation of various defensive mechanisms and kingdom builds, leaving the public sector “doing Agile” by duplicating roles, over-relying on certain niche skills, and under-resourcing core ones. All too often a stakeholder mapping exercise will start with a product owner, a delivery manager, and project lead, then a lead developer, lead QA, lead UX/UI designer, lead business analyst, lead user researcher. This isn’t stakeholder mapping, it’s bloat resourcing within a technology team.

For a long time, the public sector has been treated like a cash pi?ata, with tech companies selling bolt-on consultancy to naive and unsuspecting customers until it eventually became a norm, then was adopted internally based on partial understanding of observed behaviour. They key stakeholders haven’t ever really changed from those set out above, but the bloat approach often forgets or ignores them, leading to change resistance, lack of faith in solutions, and low adoption - because systems fail to meet the needs or expectations of users. Stakeholder engagement is critical in ensuring that the end product is fit for purpose, widely accepted, and effectively utilised. Without it, teams are building bridges to nowhere and costing large sums of taxpayer’s money while doing so.

2.1.1 Getting it Wrong:

Develop solutions in isolation and ignore the voices of those who facilitate or will be impacted by the changes. Assume that top-down technical directives and digital prowess alone can drive transformation. Accept misalignment with user needs and operational realities as a necessity of progress.

2.1.2 Getting it Right:

Identify and engage with genuine stakeholders early and often. Implement regular check-ins, feedback loops, and iterative development cycles which ensure that the final product remains user-friendly and fit for purpose. Treat stakeholder engagement as an open dialogue rather than a box-tick consultation.

2.2 Battle Plan:

2.2.1 Identifying Stakeholders:

The first step in effective stakeholder engagement is to identify all the people with skin in the change, and exclude those on the delivery teams. Your final list must include anyone who will be impacted by the project or has influence over its commencement, governance, and success. Think broadly: senior leaders, risk managers, security teams, procurement, internal staff, external partners, regulatory bodies, technical environment owners and, most importantly, the end-users. If a technical solution can’t be paid for, won’t comply with policy, doesn’t meet broader requirements including assurance, and does not provide a benefit the users can agree exists, it’s a failure. There are some corners you simply can’t iterate out of and this is one of them. Then map out project roles resources and define the relationships and interaction methods with the stakeholders.

2.2.2 Getting it Wrong:

Overlook key stakeholders and assume that certain groups don't need to be consulted. Choose to substitute some stakeholder views with bias and untested belief. Centre focus on bought-in senior leadership and technical teams, ignoring those such as the front-line staff who will use the systems daily. Assume that technical change requires no change management.

2.2.3 Getting it Right:

Create a full stakeholder map that identifies all relevant parties and separates out resourcing profiles and technical team roles. Map the touchpoints and interfaces between stakeholders and project resources. Ensure a balanced stakeholder representation that includes diverse perspectives and expertise. Use the map to guide your engagement strategy throughout the project lifecycle and minimise bias. Verify there are no orphaned product owners in the change tree to prevent rogue solutions being developed or zombie projects from commencing.

2.2.4 Building a Communication Plan:

Without a robust communication plan for keeping stakeholders informed and engaged, the project won’t work. This plan should outline how and when stakeholders will be updated on project progress, how their feedback will be solicited and incorporated, and how decisions will be communicated. This should not be one-way traffic and should include the creation of steering and working groups, proxy boards for hard to reach or hyper-secure stakeholders, and should incorporate measurable feedback mechanisms, such as surveys. Results of engagements should be available transparently to everyone, to improve discussion health and project ethics.

2.2.5 Getting it Wrong:

Assume that informal updates, sporadic communications, and broadcast only methods are sufficient. Overwhelm stakeholders with technical language, sales puff, and jargon. Provide updates that lack brevity, clarity, and relevance.

2.2.6 Getting it Right:

Develop a detailed communication plan that includes regular updates, clear timelines, and accessible language. Use multiple, two-way channels to reach different stakeholders – e.g. emails, meetings, newsletters, workshops, surveys. Ensure that communication is bilateral, allowing stakeholders to provide feedback and raise concerns, and deliver this information transparently.

2.2.7 Involving Stakeholders in Decision Making:

Effective stakeholder engagement goes beyond communication. It involves active participation in decision-making processes. Stakeholders should have a say in defining requirements, prioritising features, and assessing progress. It’s become common practice for product owners to reshape what is sponsored and validated through quiet, subjective backlog amendment - often in too close proximity to technical teams. This is a false wall approach and actively detaches stakeholders from decision making, leading to polar drift and delivery of, ultimately, poor quality outcomes. Commercially, the role of a product manager is to deflect questions and maximise opportunities for new work and rework. The public sector has been slow to understand this and, subsequently, has adopted a lot of negative practices without being in a position to realise the intended commercial benefits.

2.2.8 Getting it Wrong:

Treat stakeholder input as a formality. Hold token consultations that don’t impact decision-making. Make key decisions in isolation and allow product managers broad reductive control.

2.2.9 Getting it Right:

Create mechanisms for meaningful stakeholder involvement. Set up steering committees, focus groups, and feedback sessions. Ensure that stakeholder input is genuinely considered and reflected in project decisions. Recalibrate the product ownership role for the public sector and blunt the commercial intent.

2.2.10 Managing Expectations:

You must manage expectations to avoid misunderstandings and disappointments. Stakeholders need to have a realistic understanding of what the project can deliver, its timelines, and any potential challenges. This requires two critical inputs from technical teams. The first is an acknowledgement of inherent and unconscious bias on the part of those teams – optimism bias being a persistent failing of technologists. The second is honesty, which sounds simple but is often clouded by commercial clauses and hungry balance sheets.

2.2.11 Getting it Wrong:

Over promise and under deliver. Set unrealistic expectations that cannot be met. Fail to communicate delays or changes transparently. Hide behind technical language.

2.2.12 Getting it Right:

Be honest and transparent about what the project can achieve and the challenges it faces. Provide regular updates on progress and any changes to timelines or scope. Have difficult discussions early and often.

2.2.13 Training and Support:

Once the project is complete, stakeholders, especially end-users, need adequate training and support to effectively use the new systems and processes. Without this, even the best-designed solutions can fail. The most common ending to a public sector project is a rush to finish, a lack of documentation, and impossible to resolve late requests for commercial extensions when none can be granted. This is a collective failure, but can be resolved by ensuring that product books are a norm rather than an exception – an area where Agile struggles, because it is simply not geared to delivering a finished product and, rather, is a misunderstood sales tool used to prolong time and materials engagements.

2.2.14 Getting it Wrong:

Assume that users will figure out new systems without instruction. Provide minimal or no training or support. Leave documentation until the end of contract.

2.2.15 Getting it Right:

Develop a comprehensive training and support plan. Ensure that documentation is developed and released alongside the development. Offer training sessions, user manuals, and help desks. Ensure ongoing support to help users adapt to new systems and address any issues that arise. Ensure that a knowledge transfer plan is included in the procurement process.

2.3 Wargame:

Consider a government department that embarked on a digital transformation project to digitise its service delivery. The initial approach was top-down, with little to no input from front-line staff or service users. The project team assumed they knew best and developed a solution based on their own, unverified understanding.

As the project progressed, it became clear that the new system was not meeting the needs of front-line staff. It was cumbersome to use, lacked critical features, and created additional work rather than reducing it. The lack of stakeholder engagement led to low adoption rates and significant resistance. Front-line staff reverted to old, manual processes, undermining the entire project.

Another department took a different approach. From the outset, they identified all relevant stakeholders, including front-line staff, service users, and external partners. They held regular workshops and feedback sessions to understand their needs and priorities. This input was used to shape the project, ensuring that the solution was user-friendly and met real needs. The communication plan was robust, with regular updates provided in accessible language. Stakeholders were involved in decision-making through steering committees and focus groups. This approach built buy-in and support, ensuring that the final product was widely accepted and effectively used. Training and support were also prioritised, with comprehensive training sessions and ongoing support provided to help users adapt to the new system.

The result was a successful digital transformation that met its objectives, improved service delivery, and was widely embraced by stakeholders. This case underscores the importance of stakeholder engagement in achieving successful digital transformation.