Organisational Development for Successful Digital Transformations – a Perspective Based on Key Capabilities
Recently, at the end of a public sector project, I sat down with a client to discuss planned activities. During our discussion, the client asked: "As a policy-maker, how am I supposed to manage an IT project and guide its needs? I know my field very well, but I know much less about IT development." This problem - that business specialists are expected to have a high level of IT project management skills - can affect many business professionals. Due to digitalisation the business field specialists are increasingly expected to possess IT-related capabilities. Here, we will explore how to address this challenge.
The solution to this concern may lie in selecting an appropriate operating model (rather than hastily choosing a project development partner). An ICT operating model, in brief, is an approach to service management aimed at creating value. A comprehensive approach encompasses categories such as
- organisation and people,
- information and technology,
- partners and suppliers,
- and value streams and processes.
One central and crucial aspect, which we will focus on in this article, is the roles and responsibilities matrix that defines management objects and the capabilities required for managing them. In 2022-23, our long-term partner Mihkel Lauk conducted an analysis focusing on the ICT development operating model and we use his work as a basis for this article. Although the project focused primarily on the public sector, the results are also applicable to the private sector.
To better understand the operating model, let us start with an explanation why Mihkel's analysis was initiated – which specific problems it was supposed to address. The project team also included Ragner Paevere, Madis Tapupere, and Janar Linros. The addressed problems can be divided into two categories:
- Perceived Issues (Symptoms): Development is rigid, and priorities cannot be changed; projects run over time; priority changes are slow and resource-intensive; there is a lack of in-house development capability; technology management is in the hands of external partners. Also, there is a project-based approach and dependency on structural funds; duplicate ICT services within ministries and institutions; significant diversity of systems and technologies with high resource consumption.
- Objective Issues: These primarily stem from how ICT has been developed in Estonia. The business side has primarily described business needs and conducted procurement. IT (e.g., a partner) has then gathered, organised and analysed these business needs. This has led to a situation where businesses remain in a comfort zone and do not need to know much about technology. Both the pandemic and other changes increased the demand for IT specialists beyond supply, leaving businesses without sufficient IT support and alone with IT issues. Another aspect is that when the business depended on IT and did not have a say in the process, the resulting IT solution would reflect paper-based processes without achieving a quality leap in digitalisation. This occurs when IT does not understand the business or when the business does not participate in the design of the IT solution.
The project aimed to design ICT project operating model. The reference model for the operating model is based on the premise that the mandatory management object is business architecture and its components. IT does not exist independently, and IT architecture is a result of and subordinated to business architecture. The prioritisation of business architecture significantly affects responsibilities. IT does not bear sole responsibility; in IT issues, the ultimate responsibility lies with business.
For instance, information security issues are a business problem, not an IT problem. The business must decide the extent to which it tolerates the problem or allocates resources to solve it. Business architecture comprises various architectural views linked to management objects and supporting methodologies.
However, one person on the business side cannot handle all of this; tasks must be distributed among various people. The following diagram illustrates the MVP (Minimum Viable Product) of essential roles and responsibilities.
In the context of the government, additional complexity arises from different management levels, from lowest to highest – development project, institution, and ministry. Applying this diagram to a real organisation or, in this case, a ministry's jurisdiction, we can see very different situations, but they generally boil down to four models.
- Dispersed Model: All ICT governance and management take place within the institution. The institution has all the necessary capabilities, including business architecture and technology architecture management, as well as critical business systems’ maintenance and upkeep. In the context of a private sector business, an example of this model is a department specialised in a particular product, operating completely independently with it.
- Shared Model: In a shared services scenario, strategic and budget planning occurs at the ministry's management level. Infrastructure core services and computer workplace services, as well as other standardisable support services such as procurement, are shared. In the context of private sector business, this means a department has considerable independence, but certain services are centrally provided.
- Competence Centre Model: This model supports business architecture management maturity and suits situations where the business architecture management maturity level is low. The IT side assumes a significant portion of the business responsibilities, maximising the benefits of technology involvement within constraints. In the context of private sector business, this means a department understands its business well, but a separate IT department is established for IT projects, providing services. The business, in this context, is the IT customer.
- Centralised Model: In the context of the Estonian state, this is the least likely scenario as it requires central integrated management of the public services portfolio and ICT budget at the state level. In the context of private sector business, it would be a situation where a specific product is built, and the entire company is subordinated to it. Almost all product-related management decisions must pass the management.
Considering the state's multiple management levels and potential management models where ICT may be part of the business or a separate unit, it is necessary to consider where responsibilities for specific activities should lie. The general rule is that responsibility should lie where most of the work associated with that responsibility is done. Business architecture is a central management tool, and one of its subcomponents is IT architecture. If IT architecture-related activities are primarily conducted in the IT department/institution, then responsibility for this subtopic should also lie there. The business, not IT, must remain responsible for the whole and business architecture is a tool to manage it.
One of the project's focuses was identifying success preconditions. During the analysis, 16 prominent projects were examined. Instead of focusing on failures, the analysis looked at why projects succeeded. The following aspects were clearly present in all studied projects as prerequisites of success.
- Value Co-Creation: Modern IT goals align with business goals. There is no longer talk of business services and IT services, but only business services and business development, sometimes achieved through the involvement of technology.
- Service Management Integrity: Services are managed based on business architecture, using dimensions described by ITIL (Information Technology Infrastructure Library):
- Organisation and People;
- Information and Technology;
- Partners and Suppliers;
- Value Streams and Processes.
- Clarity of Management System, Roles, and Responsibilities: Every participant in the value stream understands their role's associated responsibilities and updates their skills and competencies accordingly – across all management levels.
- Strategic Focus: The most critical goals in software development are development speed, quality, and security. Critical control points are transparency in usage of time and money.
- Top Management Contribution: Top management's involvement increases the commitment of others. Top management involvement, participation, and leadership are important as they support changes in work and mindset.
- Business Responsibility: An expert business representative is necessary in ICT developments – a product owner who dares to take responsibility and make quick (sometimes risky) and specific decisions. Details can be ironed out later, if needed.
- Agile and Iterative Development: It is important that development results are created as quickly as possible, allowing all stakeholders to quickly adopt them, gain experience, and make better decisions for subsequent iterations.
- Good Partnerships: The principle of considering partnerships means that, due to external factors and business needs (speed, deadline, security), it is beneficial to maximise partnerships, balancing this with information architecture requirements. Management should not be handed over to the partner. The partner is not an order taker, but an ally in problem-solving. Cooperation and striving for a common business goal are essential.
- Integrated Teams: Team members should not be held back by formal organisational boundaries. The principle of an integrated team means that necessary competencies are involved purposefully and flexibly, using both internal and external resources.
- Flexible Budget: Budget management must be business-autonomous, continuous, and flexible. Flexibility is ensured if the business can prioritise development needs within the framework of a comprehensive service budget (from which technology maintenance and lifecycle management costs have been previously allocated).
Meeting these preconditions does not guarantee project success, but significantly increases the likelihood of success. Conversely, failing to meet these preconditions clearly increases the likelihood of failure.
We started with the premise that the ultimate responsibility lies with the business, then clarified that the business uses various organisational resources to delegate tasks and finally described the success preconditions that should support project success within the organisation.
From the external partner's viewpoint, when the client (the business) has not met the necessary conditions for success, the question arises of how to handle this situation. The assumption is that the partner also wants to succeed with the project and reach the outcome that satisfies their client. Several options can be considered:
- Draw the business's attention to success preconditions and support their fulfilment where possible. The goal of collaboration in every ICT development project is the project's success and mutual satisfaction. When the business understands its responsibility and meets success preconditions, collaboration becomes smoother and more beneficial for both parties. The project is clearly focused, and decisions are made based on objectives. As a partner, it is impossible to forcefully rearrange things, but at the right moment, attention can be drawn to missing aspects, which hopefully will lead to desired changes.
- Exit the project with integrity. If attention has been drawn to problems and shortcomings, but significant improvements are not made. If the partner sees that nonsense is being produced and Estonian taxpayers' money is being wasted, it may be better to exit the project rather than tarnish one's reputation. Such a decision is not easy for the partner, as investments have been made to win the job, and further investments have been made during the project to recover the initial investment. Additionally, penalties in contracts may hinder such an exit. However, working on a project doomed to failure can be demoralising for the partner's employees, and ultimately it may be more prudent to exit the project than endure it.
- Endure and extract as much profit as possible. If the situation cannot be improved and exiting is not possible, the only option left is to endure the project destined for failure. This may sound cynical, but in such a context, the partner can only create a buffer to cope with potential negative consequences.
